Build fluency in the vocabulary of issuing short-lived, per-application credentials instead of a shared password.
0 / 5 completed
1 / 5
At standup, a dev mentions a secrets manager generating a short-lived database credential on demand for each requesting application, rather than distributing one long-lived, shared password to everyone. What capability is being described?
HashiCorp Vault's dynamic secrets generate a short-lived database credential on demand for each requesting application, rather than distributing one long-lived, shared password to everyone that needs access. Distributing a single long-lived password widens the blast radius of a leak, since every application shares the exact same credential indefinitely. This on-demand, short-lived generation is what makes a leaked dynamic secret far less damaging than a leaked long-lived one.
2 / 5
During a design review, the team wants each dynamic secret Vault issues to automatically stop working after a configured time-to-live, without anyone needing to manually revoke it. Which capability supports this?
Time-to-live-based automatic secret expiration makes each dynamic secret Vault issues stop working after a configured lifespan, with no person needing to manually revoke it once that time has passed. Issuing a secret with no expiration at all leaves it valid indefinitely unless someone remembers to revoke it by hand. This automatic expiration is what keeps a dynamic secret's exposure window naturally bounded, even if nobody actively tracks when it should be revoked.
3 / 5
In a code review, a dev notices Vault can immediately revoke every credential it issued to a particular application if that application is found to be compromised, without affecting a credential issued to any other application. What does this represent?
Fine-grained, per-lease revocation lets Vault immediately revoke every credential it issued to a particular compromised application, without affecting a credential issued to any other application. Revoking every credential across the entire system simultaneously causes far more disruption than the actual incident requires, since only one application was ever compromised. This per-lease granularity is what lets an incident response stay targeted rather than forcing an unnecessarily broad credential rotation across every application.
4 / 5
An incident report shows a leaked long-lived, shared database password required rotating credentials across every single application that used it, causing a wide outage during the emergency rotation, because no per-application credential distinction existed. What practice would prevent this?
Issuing a distinct, short-lived dynamic secret per application through Vault means revoking one application's leaked credential doesn't affect any other application at all, avoiding exactly the wide, disruptive rotation this incident describes. Continuing to share one long-lived password across every application means a single leak forces rotating everyone's credential simultaneously. This per-application distinction is a core reason dynamic secrets meaningfully reduce the operational pain of responding to a credential leak.
5 / 5
During a PR review, a teammate asks why the team adopts Vault's dynamic secrets instead of just storing one long-lived database password in a shared configuration file used by every application. What is the reasoning?
A shared, long-lived password widens the blast radius of a leak and forces rotating every application's credential at once during an incident response. A dynamic secret is short-lived, issued per application, and revocable without affecting anyone else, keeping both the exposure window and the incident-response scope much smaller. The tradeoff is the added operational dependency on Vault itself staying available, since every application now needs to fetch its credential from it rather than reading a static configuration value.