HashiCorp Vault Associate (003) Question 125
Single answer5a Choose a secrets engine based on use caseA platform team is migrating several internal applications to HashiCorp Vault. One application connects to PostgreSQL and currently stores a long-lived database username and password in a configuration file. The security team wants each application instance to receive credentials at startup that automatically expire after a short time, and they do not want operators to manually create or rotate database users in PostgreSQL. Which Vault secrets engine is the best fit for this use case?
- A
KV secrets engine, because it can store the PostgreSQL password and version changes over time
- B
Database secrets engine, because it can generate dynamic database credentials with leases and automatic revocation
- C
Transit secrets engine, because it can encrypt the PostgreSQL password without storing it in Vault
- D
PKI secrets engine, because it can issue short-lived certificates for authenticating to PostgreSQL instead of usernames and passwords
Show answer and explanation
Correct answer: B
Explanation
The best answer is the Database secrets engine because the scenario explicitly requires dynamic, short-lived PostgreSQL credentials that are generated automatically and revoked when no longer needed. This is a core Vault use case: replacing static database credentials with dynamic secrets tied to leases. By contrast, the KV secrets engine stores static data, Transit performs cryptographic functions, and PKI issues certificates rather than database usernames and passwords. HashiCorp Vault documentation describes the database secrets engine as the appropriate choice for generating dynamic credentials for supported databases, including PostgreSQL, using configured creation and revocation statements. For exam purposes, a key skill is mapping the use case to the right engine: KV for static secret storage, Database for dynamic DB credentials, PKI for certificates, and Transit for encryption as a service.
- A. Incorrect.
Incorrect. The KV secrets engine is intended for storing static secrets such as manually managed usernames, passwords, API keys, or configuration data. While KV v2 supports versioning, it does not generate database accounts dynamically or manage lease-based database credential lifecycles. This option reflects a common misconception that any secret stored in Vault becomes dynamic automatically.
- B. Correct.
Correct. The Database secrets engine is designed for this exact scenario. It can connect to PostgreSQL using configured administrative credentials, create dynamic database users on demand, return short-lived credentials to clients, and associate those credentials with a lease. When the lease expires or is revoked, Vault can revoke the database user according to the configured revocation statements. This reduces operational overhead and avoids long-lived shared credentials.
- C. Incorrect.
Incorrect. The Transit secrets engine provides cryptographic operations such as encryption, decryption, signing, and hashing without storing the plaintext application secret. It is not used to create database users or issue leased PostgreSQL login credentials. Someone might pick this option if they focus on protecting the password rather than eliminating static passwords altogether.
- D. Incorrect.
Incorrect. The PKI secrets engine issues X.509 certificates and is appropriate when applications or infrastructure authenticate using TLS certificates. Although some PostgreSQL deployments can use certificate-based authentication, this option does not match the stated requirement to avoid manually creating or rotating database users while issuing short-lived database login credentials. For standard dynamic username/password database access, the Database secrets engine is the best fit.