Final assessment · expert · ~180 min · pass ≥ 80%

Secrets, PKI & Certificate Management for Infrastructure Engineers — Final Practical Assessment

Objectives

Take ownership of an undocumented estate and produce an inventory that supports action rather than description
Distinguish the evidence that confirms a diagnosis from the evidence that merely accompanies it
Separate the security consequence of a defect from its availability consequence and argue both
Scope blast radius by what a credential authorises, for how long, and across which systems
Sequence remediation so that containment precedes cleanup for every exposed credential
Validate a fix from an independent channel rather than from the system that applied it
Propose structural prevention that retires a failure class instead of an instruction that reduces its likelihood

12 graded questions · last verified 2026-08-26

Assessment questions

Objective questions are scored automatically. Scenario answers use a second-stage rubric for evidence, remediation, and rollback.

Knowledge check · 12 questions

Q1. Finding 1. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the renewal defect.

The certificate on the load balancers for api.example.com expires in six days. A timer runs the ACME client twice a day and the timer has reported success on every run for the last several months, including this morning. The certificate files on disk have modification times from the original issuance and have not changed since. The timer does not run the client directly. It runs a wrapper script that performs several steps and finishes with a notification command. The notification command succeeds whether or not the steps before it did, so the wrapper exits with a success status regardless of what the ACME client did. The only monitoring attached to this certificate watches the result reported by the timer.
Q2. Finding 2. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the chain defect.

The six-week-old support ticket describes intermittent certificate errors. Every browser inside the office works. Two partner integrations and one mobile client fail. The failures do not correlate with time of day, with which load balancer served the request, or with any deployment. The internal certificates on the four origin hosts were installed by hand at different times. On two of the origins the configuration points at a file containing the leaf certificate only. On the other two it points at a file containing the leaf and the issuing intermediate. Clients that reach the origins directly, which includes an internal batch integration and two monitoring probes, are the ones reporting the problem.
Q3. Finding 3. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the secret-manager policy defect.

The busiest application authenticates to the secret manager with a token issued by hand during its deployment. Its policy grants read capability across a path prefix that covers every application secret in the key-value store, and list capability on the corresponding metadata paths. The application reads two secrets at start-up and nothing else. The store is mounted as key-value version 2. When the policy was written the specific paths were not known, and the prefix was chosen because it made the deployment succeed. Nobody has revisited it. The same pattern was copied into three later applications, because the first policy was used as the template.
Q4. Finding 4. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the CI cloud credential.

A static cloud access key is stored as an organisation-level CI secret and is therefore available to every workflow in roughly forty repositories. It was created during the initial migration, it has broad permissions in the production account, and it has never been replaced. Nobody can say which workflows use it and which merely have access to it. At least one repository in the organisation runs a workflow triggered by the pull_request_target event so that integration tests can reach deployment credentials. The team believes masking makes a leak in job output a non-issue. Job logs are retained for days and are not collected anywhere.
Q5. Finding 5. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the committed token.

An API token for an internal service was committed fourteen months ago to a private repository, in a file whose name suggests a test fixture. The secret scanner raised an alert at the time. The alert was dismissed with a note stating the value was a placeholder. The token is still accepted by the service. The repository has around forty contributors, several forks inside the organisation, and a mirror used by a build system that keeps its own cache. You have been asked by a senior engineer to "clean the history first so the scanner stops complaining, then we can look at rotating it".
Q6. Finding 6. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the shared database password.

One database password is used by four services. It is held in the secret manager, in the Kubernetes Secrets of two namespaces, in the configuration management repository for one host-based service, and in the connection string of a reporting tool that was set up by a team that no longer exists. All four connect as the same database user. The database secrets engine in the secret manager was configured during a proof of concept and is used by nothing. Nobody has attempted to change this password, because the belief within the team is that changing it would take all four services down simultaneously, and that belief is correct as the estate currently stands.
Q7. Finding 7. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the ServiceAccount defect.

A ServiceAccount in one namespace is bound to a role granting broad access across the cluster. It was created so that an installation could be finished during the initial build. It is now used by two deployment pipelines and one long-running controller. Nobody knows which permissions are exercised. Separately, the teams believe a namespace is a security boundary between them, and several applications read the projected ServiceAccount token from disk once at start-up and hold the string for the life of the process. One of those applications has been restarted twice this year.
Q8. Finding 8. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the ACME automation defect.

The ACME client on one load balancer answers a DNS-01 challenge by writing a TXT record through an API credential authorised over the whole example.com zone. Roughly one renewal attempt in four fails at the challenge stage and the following attempt succeeds, so the certificate has always been obtained eventually and nobody has investigated. The zone is served by several authoritative nameservers. The credential on the load balancer can create, modify and delete any record in the zone, including the records for the production service itself. The client requests a wildcard certificate covering several names, and it does not consult any renewal window published by the certificate authority.
Q9. Finding 9. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the SSH access defect.

Interactive access to 220 hosts is authorised by authorized_keys files rendered from a list of 61 entries in the configuration management repository. Eleven entries carry no comment. There is no expiry mechanism. The last removal was eleven months ago and three people have left since. There is no SSH certificate authority. Host keys are trusted on first use, and the shared engineering runbook advises disabling strict host key checking when a host has been rebuilt, describing it as the standard workaround for the warning.
Q10. Finding 10. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the audit defect.

Audit is enabled in three places and read in none. The secret manager writes an audit record to local storage on bao.lab.example. The cluster records API activity to a file on each control-plane node. The cloud provider records API calls. None of these is collected centrally, none has an alert attached, and the retention on two of the three is measured in days. The team describes the estate as audited. During the previous three findings you needed audit evidence covering periods of fourteen months, eleven months and six weeks, and in each case the record either did not exist or had aged out.
Q11. Finding 11. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the backup and recovery defect.

The application databases are backed up and restored into staging monthly. Nothing else has a tested restore. The root certificate authority is a key and a certificate on an encrypted volume attached to a workstation in a safe. The issuing authority runs on ca.lab.example. Neither has a documented, tested recovery procedure. The secret manager unseal key shares were split at initialisation between five holders, two of whom have left. The unseal procedure is written down and has never been rehearsed against a stopped instance.
Q12. Finding 12. Produce evidence, root cause, security impact, availability impact, blast radius, remediation, validation and prevention for the rotation defect.

A rotation procedure exists in the internal wiki. It is thorough, it was written by the departed engineer, and it was last edited two years ago. It names a host that no longer exists and a tool whose deployment path has changed. No rotation has been performed for anything in this estate within the period covered by the available records. Your manager has read the procedure, considers rotation to be a solved problem here, and has asked you to confirm that in writing so the item can be closed on the compliance register.

Passing score: 80%. Answers are checked in this browser.

Secrets, PKI & Certificate Management — Final Practical Assessment

This assessment gives you an estate rather than a question bank. It is small, ordinary, and entirely plausible: an internal certificate authority, a public-facing API, one Kubernetes cluster, a CI system, a secret manager and a fleet of Linux hosts. It contains twelve defects. None of them is a trick, none of them is the result of incompetence, and every one of them exists somewhere in production today.

You have three hours and you are not expected to change anything. What is being graded is whether you can establish what is true, decide what to do first, and defend the ordering.

How the twelve findings are presented

Each finding is a scenario carrying the part of the handover that matters for it. The description is factual and deliberately incomplete, in the same way a real handover is. Where a scenario states a belief held by a team or an instruction given by a colleague, that belief or instruction is part of the material and may be wrong.

Two of the findings put you under explicit pressure to do the wrong thing in the right order. Both are graded on whether you push back and on whether you say why.

What each answer must contain

Eight headings, in this order: Evidence, Root cause, Security impact, Availability impact, Blast radius, Remediation, Validation, Prevention. The full definition of each is in the sections above and it is worth reading before you start rather than after.

The weightings are Evidence 20%, Root cause 15%, Remediation 15%, and 10% each for Security impact, Availability impact, Blast radius, Validation and Prevention. The pass mark is 80%, averaged across the twelve findings.

The ordering rule

For every finding involving an exposed, over-scoped or shared credential, the first remediation step is to revoke or rotate that credential at the system which issues or accepts it. Everything else is cleanup.

Removing a file, rewriting repository history, purging a cache, deleting a log line, tightening a policy, reissuing a certificate: none of these makes a live credential stop working, and every hour spent on them is an hour the credential remains usable. An answer that performs cleanup before revocation scores zero for Remediation, however complete the rest of it is. This single rule separates people who have run an incident from people who have read about one.

The corollary is that revocation usually costs availability, and a strong answer says so, plans the cutover, and states the trade explicitly rather than delaying containment to protect a pipeline.

Two habits that are graded throughout

Evidence from an independent channel. Where the obvious source of truth is the system under suspicion, name a different one. A renewal timer reporting success, a deployment record, a wiki page and a file your own change just wrote are all evidence that something was attempted. None of them is evidence that it worked.

Structural prevention, named as such. Every finding will accept a procedural answer, and every procedural answer will be marked lower than the structural one that retires the failure class. Propose both if you like, but say which is which. The estate you have inherited was built entirely from procedural controls written by a capable engineer, and it is in this state four weeks after that engineer walked out of the door.