HashiCorp Vault Associate (003) Question 88
Single answer3d Explain the impact of time-to-liveA team uses Vault to issue dynamic database credentials for an application. The database secrets engine role is configured with a default TTL of 1 hour and a max TTL of 24 hours. The application authenticates once at startup, receives database credentials, and then runs for several days without renewing anything. After about an hour, the application begins failing to connect to the database. What is the most likely explanation, and what should the team do?
- A
The dynamic database credentials expired after their lease TTL, so the application must renew the lease or request new credentials before expiration
- B
The Vault token expired, but the database credentials remain valid indefinitely until manually revoked, so only the token needs renewal
- C
The max TTL of 24 hours means the credentials should automatically remain valid for 24 hours even if the 1-hour TTL is not renewed
- D
TTL only affects Vault audit log retention, not the lifetime of dynamic secrets returned by the database secrets engine
Show answer and explanation
Correct answer: A
Explanation
In Vault, time-to-live (TTL) directly affects how long tokens and leased secrets remain usable. For dynamic secrets, such as database credentials from the database secrets engine, Vault returns a lease duration. When that TTL expires, the credentials may be revoked automatically, which commonly causes application failures if the app does not renew or rotate them. The default TTL is the initial lifetime given at issuance, while max TTL is the maximum total lifetime allowed through renewals; it does not mean the secret automatically lasts that long. Best practice for long-running services is to use a Vault client or agent that can renew renewable leases and tokens, or to re-authenticate and fetch fresh credentials before expiry. This behavior is described in Vault documentation on leases, TTLs, token lifecycle, and dynamic secrets.
- A. Correct.
Correct. Dynamic database credentials are issued with a lease and are valid only for their TTL unless they are renewed, if renewable, or re-issued. With a default TTL of 1 hour, credentials can expire after about an hour if the client does nothing. In practice, long-running applications should either renew renewable leases before expiration or fetch new credentials using a still-valid authentication method.
- B. Incorrect.
Incorrect. This reflects a common misunderstanding between token lifetime and secret lease lifetime. While the Vault token's TTL matters for the client's ability to interact with Vault, dynamic database credentials themselves also have their own lease TTL and are not valid indefinitely. When the lease expires, Vault can revoke the credentials at the database, causing connection failures.
- C. Incorrect.
Incorrect. Max TTL is an upper bound, not an automatic granted lifetime. A secret issued with a 1-hour default TTL does not silently last for 24 hours. Renewal can extend the lease up to limits such as the role and mount configuration, but the client must renew before expiry and cannot assume the max TTL is applied automatically.
- D. Incorrect.
Incorrect. TTL in Vault is central to the lifetime of tokens, leases, and many generated secrets. It is not about audit log retention. For dynamic secrets such as database credentials, TTL determines how long the issued credentials remain valid before Vault revokes or expires them.