HashiCorp Vault Associate (003) Question 117
Single answer4c Describe how to revoke leasesA security team discovers that an application server may be compromised. The server has been using Vault to generate dynamic PostgreSQL credentials from the database secrets engine, and you need to invalidate the currently issued credentials for that server as quickly as possible without disabling the entire secrets engine. Which action should you take in Vault?
- A
Use the lease revoke endpoint or
vault lease revoke <lease_id>for the specific lease associated with the compromised credentials - B
Delete the policy attached to the application's token so the existing database credentials immediately stop working
- C
Tune the database secrets engine to a shorter default lease TTL so the compromised credentials are revoked right away
- D
Seal and unseal Vault so all active dynamic database credentials are invalidated
Show answer and explanation
Correct answer: A
Explanation
The best answer is to revoke the specific lease tied to the compromised dynamic secret. In Vault, many dynamic secrets are associated with lease IDs, and explicit lease revocation is the proper mechanism to invalidate them before natural expiration. For database secrets engines, revocation typically triggers cleanup of the generated credential in the target database according to the engine's configured revocation statements. By contrast, changing token policies or TTL settings does not immediately invalidate a secret that has already been issued, and sealing Vault is not a targeted lease-revocation mechanism. This aligns with Vault documentation and best practices around lease management: use lease revocation for immediate invalidation of dynamic secrets, and reserve broader actions like disabling a mount or sealing Vault for more extreme situations.
- A. Correct.
Correct. Dynamic secrets such as database credentials are issued with leases, and Vault supports explicit lease revocation. Revoking the specific lease causes Vault to attempt revocation of the underlying secret, such as removing or disabling the generated database user, depending on the secrets engine's revocation behavior. This is the most targeted response when you want to invalidate a known set of issued credentials without affecting the whole mount.
- B. Incorrect.
Incorrect. Removing or changing a policy affects future access decisions for the token, but it does not retroactively invalidate already issued dynamic database credentials. The database username and password already exist outside Vault, so policy changes alone do not revoke that secret.
- C. Incorrect.
Incorrect. Changing the mount's lease TTL affects newly issued leases and possibly renewal behavior, but it does not immediately revoke an already issued lease. This is a common misconception: TTL configuration influences expiration timing, not immediate invalidation of an active leased secret.
- D. Incorrect.
Incorrect. Sealing Vault stops Vault operations until unsealed, but it does not inherently revoke previously issued dynamic secrets in external systems like PostgreSQL. This is also operationally disruptive and far broader than necessary for revoking one application's leased credentials.