HashiCorp Vault Associate (003) Question 133
Single answer5b Compare and contrast dynamic secrets vs. static secrets, and know their use casesA company is migrating several applications to HashiCorp Vault. One application runs batch jobs against PostgreSQL and can authenticate to Vault at startup. The security team wants database credentials to be short-lived, automatically revoked when no longer needed, and different for each job run. A second legacy application reads a third-party API key from Vault, but the API provider issues only one long-lived key that cannot be programmatically generated or rotated per client. Which option best matches the appropriate Vault secret type and use case for these two applications?
- A
Use a dynamic secret for the PostgreSQL application and a static secret for the third-party API key.
- B
Use static secrets for both applications, because all secrets in Vault should be stored and versioned rather than generated.
- C
Use a dynamic secret for both applications, because Vault can automatically create short-lived credentials for any external system.
- D
Use a static secret for the PostgreSQL application and a dynamic secret for the third-party API key, because database passwords should remain stable while API keys should change per request.
Show answer and explanation
Correct answer: A
Explanation
Dynamic secrets are generated by Vault on demand for supported systems and are typically leased with a TTL, making them ideal when you want unique credentials, limited lifetime, and revocation. Common examples include database credentials from the database secrets engine and certain cloud credentials. Static secrets are pre-existing values that Vault stores and returns, such as manually issued API keys, certificates, or passwords that Vault does not generate dynamically. In this scenario, the PostgreSQL batch jobs benefit from dynamic database credentials because the requirements emphasize short-lived, unique, automatically revoked access. The legacy third-party API key is a static secret because the provider offers only one long-lived key and no dynamic issuance model. This distinction aligns with HashiCorp Vault documentation and best practices: use dynamic secrets where the target system supports just-in-time credential generation, and use static secrets when Vault is acting as secure storage and access control for externally managed credentials.
- A. Correct.
Correct. The PostgreSQL use case is a classic fit for Vault dynamic secrets: Vault's database secrets engine can generate unique, leased database credentials on demand with a TTL, and those credentials can be revoked automatically. This reduces credential sharing and limits exposure if a credential is leaked. The third-party API key is better treated as a static secret because the provider supplies a single long-lived credential that Vault cannot dynamically generate on demand. In that case, Vault securely stores and controls access to the existing secret.
- B. Incorrect.
Incorrect. This reflects a common misconception that Vault is only a secure storage system for existing secrets. While Vault can store static secrets, one of its major capabilities is generating dynamic secrets for supported systems such as databases and some cloud providers. Using only static secrets for the PostgreSQL batch jobs would miss the benefit of unique, short-lived credentials and automatic revocation.
- C. Incorrect.
Incorrect. Dynamic secrets are not available for every external system. They require a compatible secrets engine and an external system that supports creation of credentials by Vault. For a third-party API that exposes only a single manually issued key and no mechanism for Vault to generate per-client credentials, Vault cannot turn that into a true dynamic secret. It would remain a static secret stored in Vault.
- D. Incorrect.
Incorrect. This reverses the appropriate use cases. The PostgreSQL application is the stronger candidate for dynamic secrets because databases commonly support credential creation and revocation through Vault's database secrets engine. The third-party API key is static because it is externally issued, long-lived, and not dynamically generated by Vault. The claim that database passwords should remain stable is contrary to Vault best practices for reducing credential lifetime and reuse.