HashiCorp Vault Associate (003) Question 122
Single answer5 Secrets enginesA platform team stores application configuration in Vault and wants to reduce the risk of long-lived database credentials being exposed. They decide to use a secrets engine so each application instance can obtain short-lived PostgreSQL credentials at startup, and Vault should automatically revoke those credentials when the lease expires. Which Vault approach best meets this requirement?
- A
Enable the KV secrets engine and store a shared PostgreSQL username and password under a versioned path for applications to read at startup
- B
Enable the database secrets engine, configure a PostgreSQL connection and role, and have applications request dynamic credentials from that role
- C
Enable the transit secrets engine and have applications encrypt a static PostgreSQL password before storing it locally
- D
Enable the PKI secrets engine and issue X.509 certificates that applications exchange directly for PostgreSQL usernames and passwords
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use the database secrets engine for dynamic secrets. In Vault, secrets engines serve different purposes: KV stores static secrets, transit performs cryptographic operations, PKI issues certificates, and the database secrets engine generates dynamic credentials for supported databases. For PostgreSQL, Vault can be configured with a connection and role so applications receive unique, time-bound credentials instead of sharing a static password. This aligns with Vault best practices for reducing credential sprawl, limiting blast radius, and using leases with TTLs for automatic expiration and revocation. Refer to HashiCorp Vault documentation on the database secrets engine and dynamic secrets behavior for the supported workflow: enable the engine, configure the database connection, define a role, and read credentials from that role endpoint.
- A. Incorrect.
Incorrect. The KV secrets engine is designed for storing static secrets, including versioned key-value data, but it does not generate dynamic database usernames and passwords or manage lease-based revocation of those credentials. This is a common misconception because KV is often the first secrets engine teams use, but it is not the right fit when the requirement is short-lived, automatically revoked database access.
- B. Correct.
Correct. The database secrets engine is specifically intended for generating dynamic database credentials. You configure a database connection and one or more roles that define how Vault creates accounts and grants privileges. When an application reads from the role endpoint, Vault returns leased credentials with a TTL, and Vault can revoke them when the lease expires or is explicitly revoked. This directly addresses the requirement to avoid long-lived shared credentials.
- C. Incorrect.
Incorrect. The transit secrets engine provides cryptographic functions such as encryption, decryption, signing, and key derivation without storing the plaintext data itself. It does not manage PostgreSQL accounts or generate leased database credentials. Someone might choose this option because transit helps protect sensitive data, but it does not solve the problem of rotating and revoking database usernames and passwords.
- D. Incorrect.
Incorrect. The PKI secrets engine issues certificates and is used for certificate-based trust models. While some databases can support certificate-based authentication, the option states exchanging certificates directly for PostgreSQL usernames and passwords, which is not how the PKI secrets engine works in Vault. More importantly, the scenario explicitly asks for short-lived database credentials with lease-based revocation, which is the database secrets engine use case.