HashiCorp Vault Associate (003) Question 110
Single answer4b Describe how to renew leasesA team runs a long-lived application that reads dynamic PostgreSQL credentials from Vault using the database secrets engine. The application authenticates to Vault with AppRole and stores the secret's lease ID after each read. During a maintenance review, you notice the application only renews its AppRole token and does not renew the database credentials lease. To keep the existing database username and password valid for as long as Vault allows, what should the application do?
- A
Call Vault's lease renewal API using the database secret's lease ID before the lease expires, and handle the case where the lease is not renewable or hits its max TTL
- B
Re-authenticate with AppRole whenever the database credentials are close to expiring; Vault will automatically extend the existing database credentials lease
- C
Use token renewal on the AppRole token; renewing the client token also renews all dynamic secret leases created under that token
- D
Write the lease ID back to the database secrets engine role endpoint with a longer TTL to convert the current credentials into a non-expiring lease
Show answer and explanation
Correct answer: A
Explanation
In Vault, leases for dynamic secrets and TTLs for tokens are related but distinct concepts. A database secrets engine credential is returned with a lease ID, lease duration, and renewable flag. If the lease is renewable, the client can call Vault's renew lease API/CLI using that lease ID to extend the lifetime of the existing credential. However, renewal is bounded by the lease's renewability and configured TTL limits such as engine or role max TTL. Renewing the AppRole token does not automatically renew database credential leases. If a lease cannot be renewed further, the application should request a new set of credentials and update its connections accordingly. This aligns with Vault documentation and best practices around lease management, including using lease IDs for secret renewal and treating token renewal and secret lease renewal as separate operations.
- A. Correct.
Correct. Dynamic secrets such as database credentials are issued with their own lease and are renewed separately from the client token. The application should renew the secret lease by calling the renew endpoint/API with the lease ID before expiration. It must also account for practical limits: some leases are not renewable, and renewable leases still cannot be extended beyond configured maximum TTLs. When renewal is no longer possible, the application should fetch new credentials.
- B. Incorrect.
Incorrect. Re-authenticating with AppRole gets a new or renewed token, but it does not automatically extend an already issued dynamic secret lease. This is a common misconception because both tokens and secrets have TTLs, but they are managed independently in Vault.
- C. Incorrect.
Incorrect. Renewing a token extends the token's validity if the token is renewable and within its max TTL, but it does not renew separate leases for dynamic secrets like database credentials. Applications must renew those leases explicitly or request new secrets when needed.
- D. Incorrect.
Incorrect. There is no workflow in Vault where you send an issued lease ID back to a secrets engine role endpoint to make a lease non-expiring. TTL behavior for dynamic secrets is controlled by the secrets engine and role configuration, and leases remain subject to Vault's renewal rules and max TTL constraints.