HashiCorp Vault Associate (003) Question 111
Single answer4b Describe how to renew leasesA platform team runs an application that reads short-lived database credentials from Vault using the database secrets engine. The application stores the lease ID returned with the credentials and wants to keep the credentials valid for as long as Vault policy allows, without requesting a brand-new secret every few minutes. Which action should the team take?
- A
Call Vault's lease renewal endpoint (for example,
vault lease renew <lease_id>or the corresponding API) before the lease expires, and handle the case where the lease is not renewable. - B
Re-run
vault token renewusing the application's client token, because renewing the token automatically renews all dynamic secret leases created with that token. - C
Use
vault kv puton the database path to extend the lease duration on the existing credentials. - D
Increase the TTL in the application's request payload after the credentials are issued, because clients can extend the server-side lease as long as they still have the lease ID.
Show answer and explanation
Correct answer: A
Explanation
To keep dynamic secrets valid, a client should renew the secret's lease using the lease ID before it expires. This is different from renewing the client token. In Vault, tokens, leases, and dynamic secrets each have lifecycle rules. For database credentials and other leased secrets, the correct workflow is: read the secret, retain the lease ID, renew it when appropriate, and if renewal is no longer allowed, fetch a new secret. This aligns with Vault documentation on leases and renewals, including the CLI command vault lease renew and the system lease renewal API behavior. Best practice is to design applications to handle both successful renewals and lease expiration or non-renewable responses gracefully.
- A. Correct.
Correct. Dynamic secrets such as database credentials are issued with a lease ID, and lease-based secrets are renewed using the lease renewal operation, not by rewriting the secret. In practice, the team can use the CLI (
vault lease renew) or the/sys/leases/renewAPI flow, depending on the client. They must also account for the fact that not every lease is renewable; Vault may deny renewal based on backend behavior, max TTL, or lease settings. If the lease cannot be renewed further, the application should request new credentials. - B. Incorrect.
Incorrect. Renewing a client token extends the token's own lifetime if the token is renewable, but it does not automatically renew all secret leases created with that token. Tokens and dynamic secret leases are related but managed separately. This is a common misconception because both use TTLs and renewals, but secret leases must be renewed by lease ID when the backend supports it.
- C. Incorrect.
Incorrect. The KV secrets engine stores static key-value data and does not manage lease renewal for dynamic database credentials. Writing to a KV path would not affect the lifetime of a lease issued by the database secrets engine. Someone might choose this if they confuse static secrets storage with dynamic secret lifecycle management.
- D. Incorrect.
Incorrect. Clients cannot arbitrarily extend a lease after issuance simply by asking for a longer TTL in the application logic. Vault enforces lease duration based on mount tuning, role configuration, backend limits, and max TTL. Renewal must go through the proper lease renewal mechanism, and even then Vault may cap or refuse the extension.