HashiCorp Vault Associate (003) Question 134
Single answer5b Compare and contrast dynamic secrets vs. static secrets, and know their use casesA platform team is migrating application credentials into Vault. One application connects to PostgreSQL and can tolerate reconnecting when credentials change. Another legacy integration uses a third-party API key that Vault cannot generate or rotate automatically because the provider does not support just-in-time account creation. The team wants to reduce long-lived credentials where possible while still centralizing secret access in Vault. Which approach best fits these requirements?
- A
Use Vault dynamic secrets for the PostgreSQL database credentials, and store the third-party API key as a static secret in KV or through a suitable static secret workflow.
- B
Store both the PostgreSQL credentials and the third-party API key as static secrets in KV so that applications can read the same values consistently over time.
- C
Use dynamic secrets for both PostgreSQL and the third-party API key, because Vault can generate any type of secret as long as a lease duration is configured.
- D
Store the PostgreSQL credentials as a static secret and use dynamic secrets only for the third-party API key, because dynamic secrets are intended mainly for external SaaS credentials.
Show answer and explanation
Correct answer: A
Explanation
Vault distinguishes between static secrets and dynamic secrets based on how the secret is obtained and managed. Static secrets are fixed values that exist independently of Vault, such as an API key, password, or certificate material stored in a secrets engine like KV. They remain the same until explicitly changed or rotated. Dynamic secrets are generated by Vault on demand for a specific client or request, usually through a secrets engine that can create credentials in an external system, and they are typically leased with a TTL and revocation behavior.
In this scenario, PostgreSQL is well suited for dynamic secrets because Vault's database secrets engine can create short-lived database users or credentials and revoke them when the lease expires. This reduces credential reuse and limits blast radius. The third-party API key is a static secret because Vault cannot generate it just in time if the provider does not support that model. Best practice is to use dynamic secrets where supported and beneficial, and use static secret storage for values that must still be centrally controlled but cannot be dynamically issued.
This aligns with HashiCorp Vault documentation and training guidance on secrets engines: database and cloud engines are common dynamic secret use cases, while KV is a common choice for storing static secrets.
- A. Correct.
Correct. This matches the core distinction between dynamic and static secrets in Vault. Dynamic secrets are generated on demand, typically with a lease and TTL, and are ideal for systems like databases where Vault can create short-lived credentials programmatically. A PostgreSQL secrets engine use case fits this well, especially since the application can tolerate credential changes and reconnects. By contrast, a third-party API key that Vault cannot generate just in time is not a good candidate for dynamic secrets. In that case, the value is generally stored and managed as a static secret, often in the KV secrets engine or another appropriate workflow depending on the integration.
- B. Incorrect.
Incorrect. While storing both values as static secrets would centralize them in Vault, it does not meet the requirement to reduce long-lived credentials where possible. PostgreSQL is a classic use case for dynamic secrets because Vault can issue unique, time-bound database credentials per client or application. Choosing static storage for the database credentials misses a major security benefit of Vault.
- C. Incorrect.
Incorrect. This reflects a common misconception that any secret becomes 'dynamic' simply by attaching a TTL. In Vault, dynamic secrets are generated by a secrets engine that can create credentials on demand against an external system, such as a database or cloud provider. If the third-party API does not support just-in-time credential generation or automated account provisioning, Vault cannot truly issue dynamic secrets for it merely by setting a lease.
- D. Incorrect.
Incorrect. This reverses the recommended use cases. PostgreSQL is one of the most common and well-supported use cases for dynamic secrets through the database secrets engine. The third-party API key described here is static because Vault cannot generate or rotate it dynamically using the provider. Dynamic secrets are not mainly for SaaS credentials; they are for integrations where Vault can create ephemeral credentials programmatically.