Treat a leaked credential as a lifecycle incident

A credential grants authority. When it is exposed, deleting the visible copy does not remove copies already obtained by others. The response must revoke or otherwise invalidate the old authority, replace legitimate use and investigate the exposure window. The exact order depends on the credential and service impact.

Inventory consumers before rotation. A shared static key may be used by several services, scheduled jobs and manual tools. Rotating without knowing those consumers can cause an outage. That does not justify leaving an exposed credential active indefinitely. Use the provider's supported overlap or emergency-revocation process and state the trade-off.

Short-lived credentials reduce the time a stolen value remains useful, but they are not harmless. An attacker may use them immediately or use their authority to create persistence. Scope and trust policy still matter. The ability to mint new credentials can be more important than the lifetime of one token.

Log access and administrative changes without logging the secret itself. Evidence should include credential identifier, actor, target, timestamps and action results where available. Missing logs do not prove no misuse. State the observed coverage and retention limits.

After replacement, verify both sides: legitimate consumers work with the new credential, and the old one is rejected. Check for related credentials, derived sessions and policy changes that may outlive the original value. In an interview, separate containment, service recovery and investigation rather than calling rotation the entire response.

Teaching incident: a deployment key with read access to one private repository is accidentally included in a public build log at 09:00. The log is removed at 09:20. Security discovers the exposure at 09:30. The key is revoked at 09:35 and a replacement reaches the legitimate deployment runner at 09:45.

The visible log existed for twenty minutes, but the old credential remained valid for thirty-five minutes after exposure. A copied value could be used after the log disappeared. The investigation window should not end at 09:20. It should include the period in which the credential could be used, plus relevant evidence about earlier exposure or derived access.

The key's scope limits the immediate authority, but the repository contents may include additional secrets or sensitive code. Review what the key could read, not just its label. If the exposed credential could write workflows or create new tokens, investigation must include those persistent changes. A read-only key has a different risk path from a deployment administrator.

For a planned non-emergency rotation, a service may support two valid keys during a short overlap. Deploy the new key to known consumers, verify successful use, then revoke the old key and test rejection. During an active exposure, keeping both valid longer increases risk. The incident owner may choose immediate revocation and accept a bounded outage. State the reason and restore service with the least authority needed.

A consumer inventory can record service, credential reference, owner and last observed use. It should not contain the secret value. A scheduled weekly job may not reveal itself during a ten-minute smoke test, so historical usage and configuration references matter. After revocation, watch for legitimate failures that reveal an overlooked consumer. Do not re-enable the exposed key merely to make that failure disappear.

The controlled rejection test should follow provider policy and avoid printing the key. Use a safe validation mechanism or provider status where possible. The goal is to verify invalidation, not spread the credential into more logs.

The prevention should target the leak path. If a build step prints all environment variables, replacing the key alone leaves the same behavior. Remove broad environment dumping, limit which jobs receive secrets and test log redaction with a non-secret canary value. Secret scanning can help detect recurrence, but it should not become the sole prevention for a known logging defect.

In an interview, be explicit about uncertainty. 'No suspicious actions appeared in the available audit logs' is a bounded statement. 'The key was never used' is stronger and may be unsupported if logs are incomplete or retention is short. Good incident communication states the evidence window and what the credential could do.

Teaching authority calculation: key K1 can read repository A but cannot write it. Repository A contains a workflow file that references, but does not reveal, another secret. The immediate confirmed exposure is K1's read authority. Do not claim the referenced secret leaked unless its value or an access path was exposed. Revoke K1, inspect repository-read evidence and review actual contents for additional secrets. Keep confirmed scope separate from possible follow-on risk.

An exposed API key is removed from a document but remains active. The team sees no suspicious calls in seven days of available logs, while the document may have been public for thirty days. Write the containment action and a bounded evidence statement.

Invalidate the old key through the provider's supported process and migrate authorized consumers to a scoped replacement. Verify old-key rejection and new-key function. State that no suspicious calls were found in the seven-day available log window; the prior twenty-three days are not covered by that evidence. Review authority and persistent changes according to the key's scope. Deleting the document is not revocation.

Score out of four: one point for the correct result, one for showing the intermediate reasoning, one for identifying the stated failure case, and one for a verification that could disprove the answer. Do not award the reasoning point for a tool name alone.

Misconception 1: removing the exposed file contains the secret. Copies can remain usable until authority expires or is revoked. Misconception 2: no suspicious logs proves no misuse. The conclusion is limited by logging coverage, retention and what actions the provider records.

Evidence class: recommended. Original practice.

What is missing from 'we rotated the leaked key, incident closed'?

Strong answer: Consumer verification, old-key invalidation, scope and exposure review, possible persistent changes and a fix for the leak path. I would distinguish restored service from completed investigation and state log coverage limits.

Follow-up: How does your response change if the key can create new credentials?

Weak answer indicators: Deleting the visible copy only; reusing the old key after a consumer breaks; claiming certainty from incomplete logs.

Technical references: OWASP secrets management; OWASP logging. Sources support the documented mechanisms. The numbers, decisions, rubrics and interview prompts in this lesson are original teaching examples, not measurements or employer question claims.