Secrets management: multiple-choice review
Multiple-choice synthesis across the secrets unit — leak remediation, the maturity ladder, dynamic short-lived credentials, envelope encryption, and least privilege under real incident pressure.
Six questions that cut across the whole unit. Each mirrors a call you make in a real incident — not a definition to recite, but a tradeoff to weigh while a key is live and an attacker may already hold it.
Confirm you can connect leak remediation, the maturity ladder, dynamic credentials, envelope encryption, and least privilege — the synthesis the lessons built toward.
A live AWS key was committed to a public repo last week. A teammate deleted the line and force-pushed. What is the first action that actually ends the exposure?
Your team stores production DB passwords in a .env file deployed to each server, kept out of git via .gitignore. Why is a secret manager the next rung, and what does it add that .env cannot?
A service fetches a dynamic database credential from Vault with a one-hour TTL instead of a static password. What does the TTL actually buy you?
A team encrypts a 2 MB config blob by sending the whole payload to KMS on every request and hits the KMS request-rate limit. What does envelope encryption change?
An auditor finds one shared API token used by twelve services, granting full admin scope. The reporting service was compromised and the attacker dropped a production table. Which principle would have contained this?
A six-year-old org has the same Stripe key pasted into four repos, three CI systems, two wikis, and a Slack thread, and nobody knows which copy any service reads. What is this called and what is the durable fix?
Across the unit the through-line is one decision chain: a secret that touches a repo is leaked, so rotation — not deletion — ends the exposure; the maturity ladder climbs from hardcoded to .env to a manager (encryption at rest, access control, audit) to dynamic short-lived credentials whose TTL is the blast radius; envelope encryption lets KMS protect data at scale by wrapping a local data key instead of your payload; least privilege with unique per-service identities contains and attributes a breach; and secret sprawl is cured by a single source of truth, not more copies. Every answer resolves back to bounding and attributing the damage before it happens. Now when you see a colleague reach for gitignore or a force-push to “clean up” a leaked key, you know the first question to ask: has it been rotated?
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.