HashiCorp Vault Associate (003) Question 85
Single answer3d Explain the impact of time-to-liveA platform team configures a Vault database secrets engine role for an application that runs batch jobs every 10 hours. The role issues dynamic database credentials with a default TTL of 1 hour and a max TTL of 24 hours. The application fetches credentials only once when the job starts and does not renew leases. During a long-running job, database connections begin failing with authentication errors after about an hour. What is the most likely explanation, and what is the best Vault-focused fix?
- A
The dynamic credentials are expiring after their lease TTL, so the application must either renew the lease during the job or use a longer-lived TTL that safely covers the job duration.
- B
Vault revokes database credentials only when the token that created them expires, so increasing the client token TTL will prevent the database authentication failures.
- C
The max TTL means the credentials will remain valid for 24 hours automatically, even if the default TTL is 1 hour.
- D
TTL applies only to the Vault token, not to dynamic secrets from the database secrets engine, so the failures are unrelated to Vault lease expiration.
Show answer and explanation
Correct answer: A
Explanation
In Vault, time-to-live (TTL) determines how long a token or leased secret remains valid before expiration. For dynamic secrets such as database credentials, TTL has a direct operational impact: when the lease expires, Vault revokes the secret, which can break running applications if they do not renew the lease or fetch new credentials. In this scenario, a 10-hour batch job using 1-hour database credentials without renewal will predictably fail once the lease expires. The key applied concept is that the default TTL is the initial lease duration, while max TTL is only the maximum allowed lifetime or renewal limit, not the automatic duration granted. Best practice is to align secret TTL and renewal behavior with workload duration while keeping leases as short as practical for security. This matches Vault documentation and best practices around tokens, leases, renewal, and dynamic secrets.
- A. Correct.
Correct. Dynamic secrets issued by Vault, including database credentials, are leased and have a TTL. If the application gets credentials with a 1-hour lease and does not renew them, Vault will revoke the credentials when the lease expires. For database secrets, revocation typically means Vault removes or disables the generated database user according to the database plugin behavior, causing authentication failures. The practical fix is to renew the lease while the job is running if the secret is renewable, or adjust TTL settings so the issued credentials remain valid long enough for the workload while staying within security requirements.
- B. Incorrect.
Incorrect. This reflects a common confusion between the client token TTL and the secret lease TTL. Although a valid token is needed to interact with Vault, dynamic secrets have their own leases and can expire independently. Simply extending the token TTL does not automatically extend the lease on already-issued database credentials. The application must renew the secret lease, re-read credentials, or receive credentials with an appropriate TTL.
- C. Incorrect.
Incorrect. The max TTL is an upper bound, not the duration automatically assigned to every lease. With a default TTL of 1 hour, the lease will typically be issued for 1 hour unless a longer allowed TTL is explicitly requested and permitted by the role and mount settings. Many candidates mistake max TTL for the actual TTL in effect, but Vault uses max TTL to limit how far a lease can be extended.
- D. Incorrect.
Incorrect. TTL in Vault applies to more than just authentication tokens. Dynamic secrets, including database credentials, PKI certificates, and other leased secrets, also have TTLs. When those leases expire, Vault can revoke the secret. In this scenario, the timing of the failures strongly matches lease expiration, so Vault TTL is directly relevant.