HashiCorp Vault Associate (003) Question 126
Single answer5a Choose a secrets engine based on use caseA company is moving a legacy application to Kubernetes. The application needs database credentials for PostgreSQL, and the security team wants each application instance to receive short-lived credentials that are created on demand and automatically revoked when they expire. The team also wants to avoid storing long-lived database passwords in Vault as static secrets for application use. Which Vault secrets engine is the best fit for this requirement?
- A
KV secrets engine, because it stores database usernames and passwords versioned for the application to read at startup
- B
Database secrets engine, because it can generate dynamic PostgreSQL credentials with leases and TTL-based revocation
- C
Transit secrets engine, because it can encrypt the PostgreSQL password without storing it in plaintext in Vault
- D
PKI secrets engine, because it can issue certificates that the application can use as database passwords
Show answer and explanation
Correct answer: B
Explanation
The best choice is the Database secrets engine because Vault supports dynamic secrets for databases, including PostgreSQL. Dynamic secrets are created on demand, associated with a lease, and can be revoked automatically when the lease expires. This reduces the operational and security risk of distributing shared, long-lived credentials. In contrast, the KV secrets engine is for static secret storage, Transit is for cryptographic operations, and PKI is for certificate issuance. HashiCorp Vault documentation and best practices consistently position the Database secrets engine as the correct solution when applications need short-lived, automatically managed database credentials rather than static passwords.
- A. Incorrect.
Incorrect. The KV secrets engine is for storing static key/value data, such as application configuration or manually managed credentials. While it can hold a database password, that would still be a long-lived secret unless you rotate it externally. It does not generate database users dynamically or manage leases for database credentials, so it does not meet the requirement for on-demand, short-lived PostgreSQL credentials.
- B. Correct.
Correct. The Database secrets engine is designed for this use case. It can connect to PostgreSQL using a privileged account, generate unique database credentials dynamically for clients, and attach a lease with a TTL. When the lease expires or is revoked, Vault can revoke the generated credentials in the database. This aligns with the requirement to avoid distributing long-lived static database passwords and to give each application instance short-lived credentials.
- C. Incorrect.
Incorrect. The Transit secrets engine provides cryptographic operations such as encryption, decryption, signing, and hashing without storing the plaintext data. It is not used to generate or manage database accounts. Encrypting a static password would still leave the application dependent on a long-lived credential, which does not satisfy the requirement for dynamic, automatically revoked database access.
- D. Incorrect.
Incorrect. The PKI secrets engine issues X.509 certificates and is appropriate for TLS certificates or certificate-based authentication scenarios. It does not generate PostgreSQL usernames/passwords as database credentials. Someone might choose this option because certificates are also short-lived credentials, but they are a different credential type and not the right fit for the stated password-based database access requirement.