HashiCorp Vault Associate (003) Question 101
Single answer4 Vault leasesA team uses Vault's database secrets engine to generate short-lived PostgreSQL credentials for an application. The app authenticates with AppRole, reads database credentials, and stores the returned username/password in memory. After several hours, the app begins failing to connect to the database because the generated credentials have expired. The team wants the application to keep using dynamically generated credentials without manual intervention and without increasing the role's TTLs. Which approach is the most appropriate?
- A
Have the application renew the lease for the generated database credentials before the lease expires, and handle cases where renewal is not allowed by fetching new credentials
- B
Renew the AppRole Secret ID lease only, because renewing the authentication material automatically extends all secret leases created by that client
- C
Increase the token TTL on the AppRole login token, because secret leases inherit their lifetime from the client token and will extend automatically
- D
Tune the database secrets engine mount with a longer default_lease_ttl so existing issued credentials become renewable for a longer period
Show answer and explanation
Correct answer: A
Explanation
Vault leases are central to how dynamic secrets are managed. When a secrets engine such as the database secrets engine issues credentials, Vault returns lease metadata including a lease ID, duration, and whether the lease is renewable. For long-running applications, best practice is to renew renewable leases before expiration and to be prepared to fetch a new secret if renewal is denied or unsupported. This is distinct from token renewal: renewing an auth token or AppRole Secret ID does not automatically renew dynamic secret leases. Likewise, changing mount TTL settings is not a retroactive fix for already-issued credentials and would not meet the requirement to avoid longer TTLs. HashiCorp Vault documentation for leases, lease renewal, and dynamic secrets emphasizes explicit lease lifecycle management by the client or by Vault Agent patterns where appropriate.
- A. Correct.
Correct. Dynamic secrets such as database credentials are returned with a lease. The client should track the lease duration and renew the lease before it expires when the backend supports renewal. If the lease is not renewable or renewal fails, the correct fallback is to request a fresh set of credentials and update the application to use them. This is the practical pattern for long-running applications that rely on leased dynamic secrets.
- B. Incorrect.
Incorrect. Secret ID is part of AppRole authentication, not the lease on the generated database credentials. Renewing or replacing authentication material does not automatically renew unrelated secret leases. Secret leases must be renewed directly, and some may not be renewable depending on backend behavior and lease settings.
- C. Incorrect.
Incorrect. A client token's lifetime and a secret's lease are related operationally, but renewing the token does not automatically renew every leased secret obtained with that token. Dynamic secrets have their own lease IDs and renewal semantics. The application must explicitly renew the secret lease or request new credentials.
- D. Incorrect.
Incorrect. Mount tuning affects leases issued after the change, not credentials that have already been issued. Also, making the mount's default TTL longer is contrary to the scenario requirement to avoid increasing TTLs. It does not solve the need for ongoing lease management in the application.