HashiCorp Vault Associate (003) Question 89
Single answer3d Explain the impact of time-to-liveA team uses Vault's database secrets engine to generate dynamic PostgreSQL credentials for an application. The security team wants credentials to expire quickly if leaked, but the application currently keeps a database connection open for many hours without re-authenticating to Vault. After the role's time-to-live (TTL) is reduced from 24 hours to 1 hour, the application begins failing several hours after startup. What is the most likely explanation?
- A
The dynamic database credentials issued by Vault expire after their lease TTL, so the application must renew or fetch new credentials before the lease ends.
- B
Reducing the TTL causes Vault to delete the database role itself after 1 hour, so no new credentials can be generated.
- C
TTL only affects the Vault token used by administrators, not leased secrets from the database secrets engine.
- D
The shorter TTL forces PostgreSQL to restart hourly to rotate the generated user passwords.
Show answer and explanation
Correct answer: A
Explanation
In Vault, time-to-live (TTL) defines how long a token or leased secret remains valid. For dynamic secrets from engines like the database secrets engine, Vault returns credentials with a lease duration. Shorter TTLs improve security by reducing the time a leaked credential can be abused, but they also require applications to either renew leases when renewable or request new credentials before expiration. If the application is not designed for lease renewal or credential rotation, reducing TTL can lead to outages or authentication failures after the lease expires. This aligns with Vault best practices: use short-lived credentials where possible, but ensure clients can handle renewal and reauthentication workflows. Relevant Vault documentation covers leases, TTL behavior, token lifecycle, and dynamic secrets from the database secrets engine.
- A. Correct.
Correct. For dynamic secrets such as database credentials, Vault issues the secret with a lease that has a TTL. When that lease expires, the credentials are no longer valid and may be revoked by Vault. If an application holds credentials for longer than the TTL without renewing the lease or requesting fresh credentials, it can start failing once the credentials expire. This is the practical impact of shortening TTL: reduced exposure window, but applications must handle renewal or rotation correctly.
- B. Incorrect.
Incorrect. TTL applies to leased secrets and tokens, not to deleting the Vault role configuration itself. The database role remains configured unless an operator changes or removes it. A shorter TTL changes how long issued credentials are valid, not whether Vault can issue future credentials.
- C. Incorrect.
Incorrect. TTL is not limited to administrator tokens. In Vault, TTL is a core concept for tokens and leased secrets, including dynamic credentials generated by secrets engines such as the database secrets engine. A common misconception is that only login sessions expire, but secret leases have their own expiration behavior as well.
- D. Incorrect.
Incorrect. Vault can revoke or expire dynamic database credentials, but that does not require PostgreSQL to restart. This distractor reflects a misunderstanding of how credential rotation works. The issue is with the validity period of the generated credentials, not the database server lifecycle.