HashiCorp Vault Associate (003) Question 123
Single answer5 Secrets enginesA platform team uses Vault to provide database credentials to an application. They enabled the database secrets engine at path database/, configured a PostgreSQL connection, and created a role that generates dynamic usernames and passwords with a 1-hour TTL. During a security review, the team is asked to ensure that credentials are short-lived and automatically become unusable when their lease expires, without requiring developers to manually rotate them. Which approach best meets this requirement?
- A
Use the database secrets engine role to issue dynamic credentials and rely on Vault lease expiration and revocation to remove or disable those credentials in PostgreSQL
- B
Store a static PostgreSQL username and password in the KV secrets engine and set a metadata TTL so Vault deletes the secret after 1 hour
- C
Use the Transit secrets engine to generate database passwords and have the application save them back into PostgreSQL
- D
Create a long-lived database account manually in PostgreSQL and use response wrapping so the credentials expire after 1 hour
Show answer and explanation
Correct answer: A
Explanation
The best practice for short-lived database access in Vault is to use the database secrets engine with dynamic roles. Vault generates credentials on demand, associates them with a lease, and can revoke them automatically when the lease expires or is explicitly revoked. This is fundamentally different from storing static credentials in the KV secrets engine, which is appropriate for static secrets but not for automatic account lifecycle management. Transit is unrelated because it provides cryptographic functions, not database credential issuance. Response wrapping improves secret distribution security but does not change the lifecycle of the secret itself. In Vault documentation, dynamic secrets are emphasized as a core advantage of secrets engines like the database secrets engine because they reduce secret sprawl and support automatic expiration and revocation.
- A. Correct.
Correct. The database secrets engine is designed for this exact use case: generating dynamic database credentials tied to a Vault lease. When the lease expires or is revoked, Vault can execute revocation statements against the database so the issued credentials are no longer valid. This reduces manual rotation effort and limits credential lifetime.
- B. Incorrect.
Incorrect. The KV secrets engine stores static secrets; it does not create database accounts or automatically revoke them in PostgreSQL when a TTL expires. Also, KV v2 metadata such as versioning and lifecycle controls are not a substitute for lease-based dynamic secret revocation. This option reflects the common misconception that any Vault secret can become dynamic simply by assigning a TTL.
- C. Incorrect.
Incorrect. The Transit secrets engine is used for cryptographic operations such as encryption, decryption, signing, and key management. It does not manage database accounts or issue leased database credentials. Choosing Transit here confuses cryptographic secret handling with dynamic secret generation.
- D. Incorrect.
Incorrect. Response wrapping only protects secret delivery by wrapping a response in a single-use token for secure handoff. It does not make the underlying database credential short-lived or automatically revoke the database account in PostgreSQL. A manually created long-lived account would remain valid until rotated or disabled separately.