HashiCorp Vault Associate (003) Question 121
Single answer5 Secrets enginesA platform team uses HashiCorp Vault to provide database credentials to application teams. The security team wants each application to receive short-lived, automatically generated database usernames and passwords, and they do not want static credentials stored in Vault for application use. The team is deciding how to configure Vault to meet this requirement with the least operational overhead. Which approach should they choose?
- A
Enable the database secrets engine, configure a connection to the target database, and create a role that generates dynamic credentials with a TTL
- B
Enable the KV secrets engine version 2 and store a different database username and password for each application, then rotate them manually on a schedule
- C
Enable the transit secrets engine and use it to encrypt a shared database password before giving it to applications
- D
Enable the PKI secrets engine and issue certificates that applications can exchange directly for database passwords
Show answer and explanation
Correct answer: A
Explanation
The best choice is the database secrets engine because it supports dynamic secrets, one of Vault's core capabilities. For databases, Vault can create unique credentials per client or application based on configured roles and SQL creation statements, then attach a lease and TTL so the credentials expire automatically. This is operationally simpler and more secure than distributing static credentials through KV. Transit is for cryptographic functions, not secret generation, and PKI is for certificate issuance rather than username/password creation. HashiCorp Vault documentation describes the database secrets engine as the recommended approach for dynamic database credentials, including roles, leases, revocation, and rotation of the root credentials used by Vault to manage the target database.
- A. Correct.
Correct. The database secrets engine is designed for this exact use case: generating dynamic database credentials on demand. Vault connects to the database using a configured administrative account, creates unique usernames/passwords based on defined SQL statements, and leases them with a TTL. This reduces credential sharing and supports automatic expiration and revocation, which aligns with the requirement for short-lived credentials and minimal operational overhead.
- B. Incorrect.
Incorrect. KV v2 is for storing arbitrary static secrets, not generating dynamic database credentials. While an organization could store database passwords there, that would still require manual or external rotation workflows and would not provide unique, short-lived credentials per application request. This is a common misconception because KV is often the first engine people use, but it does not solve dynamic secret generation.
- C. Incorrect.
Incorrect. The transit secrets engine provides cryptographic operations such as encryption, decryption, signing, and key derivation, but it does not manage or generate database accounts. Encrypting a shared password does not make it dynamic or short-lived; it only protects the secret at rest or in transit. Applications would still be using the same underlying static credential.
- D. Incorrect.
Incorrect. The PKI secrets engine issues X.509 certificates and related artifacts. It is useful for TLS and certificate-based authentication scenarios, but it does not natively issue database usernames and passwords. Some databases can use certificate-based auth, but the requirement here specifically calls for automatically generated database usernames and passwords, which is the database secrets engine's purpose.