HashiCorp Vault Associate (003) Question 130
Single answer5b Compare and contrast dynamic secrets vs. static secrets, and know their use casesA platform team is migrating several applications to HashiCorp Vault. One application runs short-lived CI jobs that need temporary PostgreSQL credentials during each pipeline run. Another legacy application can only read a fixed API token from a configuration file and cannot refresh or rotate it automatically. The team wants to reduce credential exposure and operational overhead where possible. Which approach best fits these requirements?
- A
Use Vault dynamic secrets for the CI jobs' PostgreSQL access, and store the legacy application's API token as a static secret in KV until the application can be redesigned.
- B
Use static secrets for both applications, because dynamic secrets are only for human users and not for applications.
- C
Use dynamic secrets for both applications, because Vault can automatically convert any fixed third-party API token into a leased, rotating credential.
- D
Use static secrets for the CI jobs' PostgreSQL access, and use dynamic secrets for the legacy application's fixed API token so Vault can rotate the file automatically.
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 stored values, such as API keys or passwords, that Vault returns as written; they remain the same until updated or rotated through some process. The KV secrets engine is a common example. Dynamic secrets are generated on demand for supported backends, such as database credentials from the database secrets engine, and are typically leased with a TTL so they can expire or be revoked automatically. In this scenario, the CI pipeline is the classic use case for dynamic secrets because each job can receive unique short-lived PostgreSQL credentials, reducing reuse and operational burden. The legacy application is better served by a static secret because it expects a fixed token from a file and cannot participate in renewal or rotation workflows. This aligns with Vault best practices and documentation on KV for static secret storage and secrets engines like the database engine for dynamic credential generation.
- A. Correct.
Correct. Dynamic secrets are ideal for the CI jobs because Vault can generate unique, time-bound database credentials on demand through the database secrets engine. This reduces secret reuse, limits blast radius, and fits short-lived workloads well. For the legacy application, a static secret stored in the KV secrets engine is appropriate when the application expects a fixed value and cannot handle leased credentials, renewal, or automated rotation. This option correctly contrasts the use cases: dynamic secrets for ephemeral access and static secrets for fixed values that must be retrieved as stored.
- B. Incorrect.
Incorrect. This reflects a common misconception. Dynamic secrets are not limited to human users; they are commonly used by applications and automation, including CI/CD systems, to obtain ephemeral credentials for databases, cloud providers, and other integrated systems. Using static secrets for both would miss one of Vault's main benefits: generating short-lived credentials to reduce long-term exposure.
- C. Incorrect.
Incorrect. Vault can generate dynamic credentials only for supported systems where it can create and revoke access, such as databases or certain cloud/IAM integrations. It does not automatically transform any arbitrary external fixed API token into a dynamically generated leased secret. If the third-party system only provides one fixed token and lacks dynamic credential creation, Vault typically stores that as a static secret.
- D. Incorrect.
Incorrect. This reverses the appropriate use cases. Static secrets are a poor fit for ephemeral CI database access because they are long-lived unless rotated manually or by an external process. Dynamic database credentials are specifically designed for this scenario. Also, Vault cannot simply make a legacy application's fixed file-based API token dynamic if the upstream service and application workflow do not support that model.