HashiCorp Vault Associate (003) Question 87
Single answer3d Explain the impact of time-to-liveA team stores short-lived database credentials in HashiCorp Vault using the database secrets engine. An application authenticates to Vault, reads dynamic database credentials, and then keeps using those credentials for several hours without renewing anything. Recently, the team reduced the role's credential TTL from 8 hours to 30 minutes to limit risk if credentials are exposed. After the change, the application begins failing with database authentication errors about 40 minutes after startup, even though the Vault token used to fetch the credentials is still valid. Which explanation best describes the impact of the TTL change?
- A
The dynamic database credentials expired based on their lease TTL, so the application must renew or re-read credentials before the lease expires.
- B
The Vault token automatically shortened to match the database role TTL, so the application lost access to Vault after 30 minutes.
- C
Reducing the role TTL only affects newly generated credentials after a Vault server restart, so the failures are unrelated to TTL.
- D
TTL on dynamic database credentials only controls when Vault rotates the root database user, not when issued credentials stop working.
Show answer and explanation
Correct answer: A
Explanation
In Vault, time-to-live (TTL) determines how long a token, lease, or secret remains valid. For dynamic secrets from the database secrets engine, Vault issues credentials with a lease duration. When that lease expires, Vault revokes the secret, which typically removes or disables the generated database credentials. Shorter TTLs reduce the window of exposure if a secret is leaked, but they also increase the need for applications to renew leases when supported or fetch new credentials before expiration. A key exam concept is that token TTL and secret lease TTL are distinct: a valid Vault token does not keep previously issued dynamic credentials alive. This aligns with Vault documentation and best practices around leases, renewals, and dynamic secrets lifecycle management.
- A. Correct.
Correct. Dynamic secrets such as database credentials are leased and have a time-to-live. When the lease TTL expires, Vault revokes the credentials, and the underlying database account or password is no longer valid. If the application continues using the old credentials without renewing the lease or requesting fresh credentials, authentication failures are expected after expiration. This scenario highlights the operational impact of shorter TTLs: lower exposure window, but applications must handle renewal or rotation properly.
- B. Incorrect.
Incorrect. A Vault token and leased dynamic credentials are related but separate. The token used to authenticate to Vault has its own TTL and lifecycle, while the database credentials returned by the database secrets engine have their own lease TTL. The application can still have a valid Vault token while the database credentials it previously fetched have already expired.
- C. Incorrect.
Incorrect. TTL changes on a database role affect credentials issued after the change; they do not require a Vault restart to take effect. Suggesting a restart is a common misconception based on traditional application configuration patterns, but Vault role configuration updates are applied by Vault directly. In this case, the timing of the failures aligns with newly issued credentials expiring sooner.
- D. Incorrect.
Incorrect. The TTL on dynamic database credentials governs the lifetime of the issued secret's lease, not root credential rotation. Root credential rotation is a separate administrative action and concept. Someone might pick this option if they confuse secret lease expiration with backend credential management tasks.