HashiCorp Vault Associate (003) Question 128
Single answer5a Choose a secrets engine based on use caseA platform team is migrating several applications to HashiCorp Vault. One legacy application cannot be modified and expects to read a fixed database username and password from a configuration file. A new microservice can authenticate to Vault directly and the security team wants its PostgreSQL credentials to be short-lived and automatically revoked when no longer needed. To meet both requirements using the most appropriate Vault secrets engines, which combination should the team choose?
- A
Use the KV secrets engine for the legacy application's fixed database credentials, and use the Database secrets engine for the microservice's dynamic PostgreSQL credentials.
- B
Use the PKI secrets engine for the legacy application's fixed database credentials, and use the Transit secrets engine for the microservice's PostgreSQL credentials.
- C
Use the Database secrets engine for both applications, because Vault can generate all database credentials dynamically and static credentials are not a valid Vault use case.
- D
Use the Cubbyhole secrets engine for the legacy application's fixed database credentials, and use the KV secrets engine for the microservice's PostgreSQL credentials.
Show answer and explanation
Correct answer: A
Explanation
This question tests choosing the correct secrets engine based on the application's use case. In Vault, the KV secrets engine is typically used for static secrets that applications read as-is, such as API keys, passwords, or configuration values. The Database secrets engine is designed for database integrations and can generate dynamic credentials for supported databases, including PostgreSQL, with TTL-based leases and revocation. That makes it a strong fit when the goal is to reduce credential lifetime and operational risk. By contrast, PKI is for certificate issuance, Transit is for encryption-as-a-service, and Cubbyhole is token-scoped storage. HashiCorp documentation and Vault best practices consistently emphasize selecting the engine that matches the secret lifecycle and consumption pattern: KV for static secret storage and Database for dynamic database credentials.
- A. Correct.
Correct. The KV secrets engine is appropriate for storing and retrieving static secrets such as a fixed database username and password that an unmodified legacy application expects. The Database secrets engine is the right choice for the microservice because it can generate dynamic database credentials with leases and revocation, which matches the requirement for short-lived PostgreSQL access.
- B. Incorrect.
Incorrect. The PKI secrets engine issues certificates, not database usernames and passwords. The Transit secrets engine performs cryptographic operations such as encryption, decryption, signing, and hashing; it does not issue PostgreSQL login credentials. This option confuses different Vault engine use cases.
- C. Incorrect.
Incorrect. The Database secrets engine is ideal for dynamic credentials, but the statement that static credentials are not a valid Vault use case is false. Vault commonly stores static secrets in the KV secrets engine, especially for applications that cannot be changed to use dynamic secret workflows. While Vault also supports static roles in the Database secrets engine for credential rotation scenarios, that is not the best match for a simple fixed secret retrieval requirement described here.
- D. Incorrect.
Incorrect. Cubbyhole is tied to a specific token and is mainly used for per-token private storage or response wrapping workflows, not as a shared location for an application's long-term database password. KV can store static values, but it does not generate dynamic PostgreSQL credentials with leases and revocation. Using KV for the microservice would miss the requirement for short-lived automatically revoked database credentials.