HashiCorp Vault Associate (003) Question 154
Single answer5f Explain the value of short-lived, dynamically generated secretsA company is migrating a legacy application to HashiCorp Vault. Today, the application uses a shared database username and password stored in a configuration file on every application server. Security has identified two major risks: credentials remain valid for months, and the same password is reused across environments. The team wants to reduce the impact of credential leakage without requiring manual password rotation by database administrators. Which Vault approach best addresses these requirements?
- A
Store the existing shared database password in Vault KV and have the application read it at startup
- B
Use Vault's database secrets engine to generate dynamic database credentials with a short TTL for the application
- C
Encrypt the database password with Transit and keep the encrypted value in the application's configuration file
- D
Create a Vault token with no expiration so the application can access the database through Vault indefinitely
Show answer and explanation
Correct answer: B
Explanation
The key value of short-lived, dynamically generated secrets is risk reduction through limited lifetime and reduced reuse. In this scenario, the organization's pain points are long-lived shared credentials and manual rotation overhead. Vault's database secrets engine is designed for this exact use case: it can create database users dynamically, return them with a lease, and revoke them when the lease expires or is explicitly revoked. This means each application or session can receive unique credentials that automatically expire, shrinking the blast radius if credentials are exposed. By contrast, storing static secrets in KV improves secret distribution and auditability but does not change the fact that the secret is static. Transit helps protect sensitive data cryptographically but does not rotate or dynamically generate database logins. Vault documentation and best practices consistently emphasize dynamic secrets and short TTLs as a way to reduce credential sprawl, avoid manual rotation, and improve security posture.
- A. Incorrect.
This is not the best solution for the stated requirements. Storing a static credential in the KV secrets engine centralizes access control and auditing, but the underlying secret is still long-lived and shared. It does not inherently solve the problem of months-long validity or eliminate manual rotation of the database credential itself. A candidate might choose this because Vault can securely store secrets, but the question is specifically about reducing leakage impact through short-lived, dynamically generated secrets.
- B. Correct.
This is correct. Vault's database secrets engine can generate unique database credentials on demand and attach a lease with a short TTL. This reduces blast radius because leaked credentials expire automatically and are not reused across applications or environments. It also avoids manual password rotation workflows because Vault creates and revokes credentials dynamically. This is a primary example of the value of short-lived, dynamically generated secrets in Vault.
- C. Incorrect.
This is incorrect. The Transit secrets engine provides encryption-as-a-service and is used to encrypt or decrypt data without storing the plaintext in the application, but it does not make the database credential short-lived or dynamic. The application would still depend on the same long-lived shared credential, just stored in encrypted form. Someone might select this because encryption improves secrecy at rest, but it does not address credential lifetime or reuse.
- D. Incorrect.
This is incorrect. Vault tokens control access to Vault, not direct database authentication in place of database credentials. In addition, a non-expiring token increases risk rather than reducing it. The scenario calls for minimizing the impact of leaked database credentials, and long-lived tokens conflict with Vault best practices favoring short-lived, renewable credentials where possible.