HashiCorp Vault Associate (003) Question 132
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 short-lived credentials that are generated on demand. Another legacy application connects to an external SaaS API that only supports a single long-lived API token created in the SaaS console and rotated manually every 90 days. The team wants to reduce credential exposure and operational overhead where possible. Which approach best fits these requirements?
- A
Store the PostgreSQL credentials as a static KV secret and store the SaaS API token as a dynamic secret, because KV is better for databases and dynamic secrets are best for any externally managed token.
- B
Use Vault's database secrets engine to generate dynamic PostgreSQL credentials, and store the SaaS API token as a static secret in KV or a relevant engine that returns fixed credentials.
- C
Use dynamic secrets for both systems, because Vault can automatically generate short-lived credentials for any service as long as a lease duration is configured.
- D
Store both credentials as static secrets in KV, because dynamic secrets are only useful for human users and not for applications.
Show answer and explanation
Correct answer: B
Explanation
The key distinction is that dynamic secrets are created by Vault on demand and are typically short-lived, unique per client or request, and revocable via leases. Static secrets are pre-existing values that Vault stores and returns, such as a fixed API token, password, or certificate material that Vault is not generating per request. In this scenario, PostgreSQL is a strong use case for dynamic secrets through the database secrets engine because Vault can create temporary database credentials and revoke them automatically. The external SaaS API token is a static secret use case because the token is created outside Vault and does not support on-demand credential generation by Vault. HashiCorp documentation and best practices consistently position dynamic secrets as preferable when supported, because they reduce secret sprawl, avoid credential sharing, and limit blast radius through TTLs and revocation. Static secrets remain appropriate when the target system does not support dynamic creation or when an organization must manage a fixed credential.
- A. Incorrect.
Incorrect. This reverses the appropriate use cases. PostgreSQL is a classic fit for Vault dynamic secrets through the database secrets engine, where Vault can create unique, leased credentials on demand and revoke them automatically. A SaaS API token that exists only as a pre-created, long-lived token is not typically something Vault can dynamically generate unless the service has a supported mechanism and integration for credential creation.
- B. Correct.
Correct. Dynamic secrets are ideal when Vault can create credentials on demand through a supported secrets engine, such as generating database users for PostgreSQL. This reduces credential sharing, limits lifetime through leases/TTLs, and supports revocation. A manually created SaaS API token that is fixed and externally managed is a better fit as a static secret, because Vault stores and distributes it securely even though Vault is not generating it dynamically.
- C. Incorrect.
Incorrect. A common misconception is that any secret becomes dynamic just by assigning a TTL. Dynamic secrets require Vault to generate unique credentials through a supported backend or integration. Simply setting a lease duration does not mean Vault can create or rotate credentials for arbitrary external services, especially when the service only provides one manually managed token.
- D. Incorrect.
Incorrect. Static secrets in KV are useful, but saying dynamic secrets are only for human users is wrong. Dynamic secrets are commonly used by applications and services, especially for databases, cloud IAM credentials, and similar integrations where Vault can create short-lived credentials. Using static credentials for PostgreSQL would miss one of Vault's major security benefits.