HashiCorp Vault Associate (003) Question 131
Single answer5b Compare and contrast dynamic secrets vs. static secrets, and know their use casesA company is migrating several applications to HashiCorp Vault. Their PostgreSQL database currently uses one shared username and password stored in a CI/CD system, and the security team wants to reduce the risk of long-lived credentials being reused across environments. However, one legacy reporting tool cannot automatically rotate credentials and expects the same database password to remain valid until an administrator changes it. Which approach best meets both requirements?
- A
Use Vault's database secrets engine to issue dynamic credentials for the applications, and store a separately managed static credential in Vault for the legacy reporting tool.
- B
Use a single static credential in Vault for both the applications and the legacy reporting tool, because Vault storage alone makes the credential dynamic.
- C
Use Vault's Transit secrets engine to generate database usernames and passwords for all clients, including the legacy reporting tool.
- D
Use dynamic credentials for the legacy reporting tool and static credentials for the applications, because static credentials are easier to revoke automatically.
Show answer and explanation
Correct answer: A
Explanation
The key distinction is that dynamic secrets are created by Vault on demand for a client or workload, usually with a lease and TTL, and can be revoked automatically by Vault. They are ideal for machine-to-machine access such as databases, cloud credentials, and other systems where short-lived, unique credentials reduce blast radius and credential sharing. Static secrets are pre-existing values stored in Vault, such as API keys, passwords, or tokens that remain valid until manually or externally rotated. They are appropriate when the target system or client cannot handle frequent rotation or does not support dynamic credential issuance. In this scenario, the modern applications should use dynamic database credentials via the database secrets engine, while the legacy tool should use a static credential stored in Vault. This aligns with Vault best practices around least privilege, short-lived credentials, and selecting the correct secret type based on application capability and backend support. See HashiCorp Vault documentation on dynamic secrets, static secrets, leases, and the database secrets engine.
- A. Correct.
Correct. Dynamic secrets are generated on demand, are typically leased with a TTL, and can be revoked automatically, which makes them a strong fit for applications that can request and renew credentials at runtime. For the legacy reporting tool, a static secret is more appropriate because it expects a stable credential that does not change unless an administrator updates it. This design matches the use case differences between dynamic and static secrets while reducing exposure from shared long-lived database accounts.
- B. Incorrect.
Incorrect. Storing a static credential in Vault improves secret distribution and access control, but it does not make the credential dynamic. A static secret remains the same until it is rotated. This option also fails the requirement to reduce risk from long-lived shared database credentials for the applications.
- C. Incorrect.
Incorrect. The Transit secrets engine is used for encryption, decryption, signing, and related cryptographic operations. It does not create database accounts or issue database usernames and passwords. A candidate might choose this if they confuse cryptographic key management with secret generation.
- D. Incorrect.
Incorrect. This reverses the best fit for the two use cases. Dynamic credentials are generally better for applications that can consume short-lived, automatically revoked secrets. The legacy reporting tool cannot handle credential rotation well, so giving it dynamic credentials would likely break its workflow. Static credentials are not easier to revoke automatically than dynamic leased secrets.