HashiCorp Vault Associate (003) Question 86
Single answer3d Explain the impact of time-to-liveA team uses Vault's database secrets engine to issue dynamic PostgreSQL credentials for an application running in a Kubernetes deployment. The security team reduces the role's default time-to-live (TTL) from 24 hours to 15 minutes to limit how long leaked credentials remain valid. Soon after, the application begins failing because it opens connections at startup and keeps using them for long periods without re-authenticating or renewing leases. Which change would best address the failures while preserving the security benefit of the shorter TTL?
- A
Modify the application or Vault Agent integration to renew leases or fetch new dynamic credentials before the current lease expires
- B
Increase the PostgreSQL server-side idle connection timeout so Vault-issued credentials remain valid longer than the TTL
- C
Convert the dynamic database role to a static database credential so the application does not need to handle expiration
- D
Disable lease revocation in Vault for the database secrets engine so existing connections continue working after the TTL expires
Show answer and explanation
Correct answer: A
Explanation
In Vault, time-to-live (TTL) defines how long a token, lease, or secret remains valid. Shorter TTLs reduce the blast radius of compromised credentials because the secret expires sooner. The operational tradeoff is that clients must handle expiration correctly by renewing renewable leases or requesting fresh secrets before expiry. This is especially important with dynamic secrets from engines such as the database secrets engine, where Vault can create and later revoke credentials automatically. Best practice is to design applications and integrations for lease renewal and credential rotation rather than relying on long-lived credentials. HashiCorp Vault documentation on leases, TTLs, tokens, and dynamic secrets emphasizes that TTL, max TTL, and renewability directly affect how long clients can continue using issued credentials.
- A. Correct.
Correct. TTL controls how long a leased secret is valid before expiration unless it is renewed, subject to the lease's renewability and max TTL limits. For dynamic database credentials, a shorter TTL reduces the exposure window if credentials are leaked, but clients must be designed to renew the lease or retrieve new credentials before expiration. In practice, this often means using Vault Agent, the Vault API, or application logic to rotate credentials and reconnect gracefully.
- B. Incorrect.
Incorrect. PostgreSQL idle connection timeout settings do not override Vault lease expiration. TTL is enforced by Vault's lease system, and when the lease expires or is revoked, Vault can revoke the dynamic credentials at the database. Extending database timeout settings may change connection behavior, but it does not make Vault-issued credentials valid beyond their lease duration.
- C. Incorrect.
Incorrect. Static credentials may reduce application changes, but they remove much of the security benefit of dynamic secrets and short-lived leases. The scenario specifically asks for a solution that preserves the security benefit of the shorter TTL. Replacing dynamic credentials with static ones addresses the symptom by weakening the security model rather than adapting the client to Vault best practices.
- D. Incorrect.
Incorrect. Vault's value for dynamic secrets comes from leasing and revocation. Disabling revocation would undermine the purpose of TTL and is not the right operational fix. Even if existing connections appeared to survive temporarily in some environments, this would create inconsistent and less secure behavior rather than a reliable solution.