HashiCorp Vault Associate (003) Question 151
Single answer5f Explain the value of short-lived, dynamically generated secretsA company is migrating a legacy application to HashiCorp Vault. Today, every application server uses the same long-lived database username and password stored in a configuration file. Security incidents have shown that when one server is compromised, the shared credential is often reused from other hosts for weeks before it is rotated. The team wants to reduce the impact of credential theft without changing the application code significantly. Which approach best demonstrates the value of using short-lived, dynamically generated secrets in Vault for this scenario?
- A
Configure Vault's database secrets engine to generate unique database credentials for the application with a short TTL, so compromised credentials expire automatically and can be revoked without affecting other clients.
- B
Store the existing shared database password in Vault KV and have all application servers read the same secret at startup, because central storage alone prevents credential reuse after a host is compromised.
- C
Create a single static database account in Vault and extend its lease duration to reduce authentication traffic between the application and Vault.
- D
Use Vault Transit to encrypt the database password in the configuration file, because encrypted static credentials provide the same security benefit as dynamic secrets with short leases.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Vault's database secrets engine to issue short-lived, dynamically generated credentials. In Vault, dynamic secrets are created on demand and are typically leased with a TTL. This provides several security and operational benefits: reduced blast radius because each client can get its own credential; automatic expiration so stolen secrets become useless after a short period; easier revocation without broad service disruption; and improved auditing because issued credentials can be tied to a specific Vault token, role, or workload. By contrast, storing static secrets in KV only centralizes storage and access control; it does not eliminate long-lived reuse. Likewise, encrypting static credentials with Transit protects data at rest or in transit but does not change the fact that the application still depends on a long-lived shared secret. HashiCorp documentation and best practices consistently emphasize dynamic secrets and leases as a key advantage of Vault, especially for databases and cloud credentials.
- A. Correct.
Correct. This is the core value proposition of short-lived, dynamically generated secrets in Vault. With the database secrets engine, Vault can create credentials on demand, scoped to a role, and attach a lease with a TTL. If one credential is stolen, its usefulness is limited by time, and it can be revoked independently. This reduces blast radius compared with a shared, long-lived credential and supports least privilege and better auditability.
- B. Incorrect.
Incorrect. Storing a static secret in KV may improve secret distribution and reduce hardcoding, but it does not provide the main benefit of dynamic secrets. All servers would still use the same credential, so a compromise on one host still exposes a reusable secret until it is manually rotated. Centralized storage is helpful, but it is not equivalent to short-lived, dynamically generated credentials.
- C. Incorrect.
Incorrect. A single static account with a longer lease works against the goal of limiting credential exposure. Extending lease duration increases the window in which stolen credentials remain valid. It also preserves the shared-credential problem if multiple clients use the same account. Someone might choose this option thinking it improves performance, but it weakens the security benefit being asked about.
- D. Incorrect.
Incorrect. Vault Transit is for encryption, decryption, signing, and related cryptographic operations; it does not turn a static password into a dynamic one. Encrypting a password at rest in a config file may reduce exposure of the file contents, but once the application decrypts and uses the same long-lived password, the credential can still be stolen and reused. This does not deliver the short lifetime, revocation, or per-client isolation of dynamic secrets.