HashiCorp Vault Associate (003) Question 103
Single answer4 Vault leasesA platform team uses Vault's database secrets engine to generate dynamic PostgreSQL credentials for an internal reporting service. The service authenticates to Vault with AppRole, reads database credentials, and then runs long-lived jobs that can last several hours. Recently, jobs have started failing because the database username created by Vault disappears before the job completes. The team wants the application to keep using dynamic credentials but avoid manual operator intervention. Which action is the BEST solution?
- A
Have the application renew the lease for the dynamic database credentials before the lease expires, up to the role or mount maximum TTL
- B
Increase the AppRole token TTL only, because the database credentials lease automatically extends whenever the client token is still valid
- C
Convert the database role from dynamic credentials to static credentials, because only static credentials support renewal for long-running jobs
- D
Use a periodic token for AppRole and assume all secrets read with that token will remain valid as long as the periodic token is renewed
Show answer and explanation
Correct answer: A
Explanation
In Vault, leases control the lifetime of many dynamically generated secrets, such as credentials from the database secrets engine. A client token and a secret lease are separate objects with separate TTLs. If an application needs a dynamic secret longer than its initial TTL, the correct operational pattern is to renew the secret's lease before expiration, assuming the lease is renewable and has not reached a configured maximum TTL. If the lease is allowed to expire, Vault revokes the secret, which for database credentials commonly means deleting or disabling the generated username. This scenario tests the important distinction between token renewal and secret lease renewal. Vault documentation for leases, token concepts, and dynamic secrets emphasizes that secret leases must be managed explicitly and are constrained by backend and role TTL settings.
- A. Correct.
Correct. Dynamic secrets issued by Vault, including database credentials, are associated with a lease. If the secret is renewable, the client should renew that lease before it expires. Renewal extends the lease only within the limits configured by the secrets engine, mount, and role settings such as max TTL. This is the standard way for an application to keep leased dynamic credentials valid during long-running work.
- B. Incorrect.
Incorrect. A valid client token does not automatically renew the lease on a secret that was previously issued. Token lifetime and secret lease lifetime are related but distinct concepts in Vault. If the database credentials have their own lease and TTL, that lease must be renewed separately if renewable. Raising only the AppRole token TTL may prevent token expiration, but it will not by itself keep the database username from being revoked when its lease expires.
- C. Incorrect.
Incorrect. Static credentials are not the best solution here because the requirement is to continue using dynamic credentials. Dynamic database credentials are specifically designed for this use case, and lease renewal is the appropriate mechanism when jobs outlast the initial TTL. Choosing static credentials would reduce the benefits of ephemeral, automatically revoked access.
- D. Incorrect.
Incorrect. Periodic tokens can be renewed indefinitely if the holder continues renewing them, but that behavior applies to the token, not to every leased secret obtained with it. Dynamic secrets such as database credentials still have their own leases and renewal behavior. Renewing a periodic token does not automatically make those secret leases indefinite.