HashiCorp Vault Associate (003) Question 108
Single answer4a Explain the purpose of a lease IDA platform team uses Vault's database secrets engine to generate dynamic PostgreSQL credentials for an application during deployments. After one deployment is rolled back, the team wants to immediately invalidate only the credentials issued to that failed deployment without affecting other applications using the same database role. Which piece of information should they use for this task, and why?
- A
The lease ID returned when Vault generated the dynamic credentials, because it uniquely identifies that issued secret instance for renewal or revocation
- B
The auth token accessor, because it directly identifies the database username and is required to revoke database credentials
- C
The mount path of the database secrets engine, because revoking the mount path invalidates only the credentials from the rolled-back deployment
- D
The policy name attached to the application's token, because revoking a policy removes previously issued dynamic secrets for that application
Show answer and explanation
Correct answer: A
Explanation
The purpose of a lease ID in Vault is to uniquely identify a leased secret, especially dynamic secrets such as database credentials. Vault returns the lease ID with leased secrets so clients or operators can later renew or revoke that exact secret instance. This is important in real-world operations where teams need fine-grained control over credential lifecycles, such as invalidating credentials from one failed deployment without impacting other consumers of the same role. According to Vault documentation on leases and dynamic secrets, lease metadata includes items such as the lease ID, duration, and renewability, and the lease ID is used in lease management operations like renewal and revocation.
- A. Correct.
Correct. When Vault issues a dynamic secret, it typically returns a lease ID along with lease duration and renewability information. The lease ID is the identifier used to track that specific leased secret instance. In practice, the team can use the lease ID to renew or revoke just that set of generated database credentials, which matches the requirement to invalidate credentials from only the failed deployment.
- B. Incorrect.
Incorrect. A token accessor is related to a Vault token, not to a specific leased database credential. Accessors can be used for certain token management workflows, but they do not directly identify a dynamic database secret lease for revocation. This option reflects the common confusion between authentication artifacts and secret leases.
- C. Incorrect.
Incorrect. The mount path identifies where the secrets engine is enabled, not a single issued credential. Actions at the mount level would affect the engine configuration or broad sets of secrets, not just one deployment's credentials. This confuses the secret engine location with the identifier for an individual leased secret.
- D. Incorrect.
Incorrect. Policies define what a token is allowed to do in Vault; they are authorization rules, not handles for specific generated secrets. Changing or revoking a policy does not selectively revoke one previously issued dynamic database credential. This distractor targets the misconception that policy changes retroactively invalidate individual leased secrets.