HashiCorp Vault Associate (003) Question 118
Single answer4c Describe how to revoke leasesA security team discovers that an application server may be compromised. The server was using Vault database dynamic credentials generated from the database secrets engine, and the team wants to invalidate only the credentials currently leased to that server as quickly as possible without disabling the entire secrets engine or affecting other applications. Which action should the Vault operator take?
- A
Use the lease ID returned when the credentials were issued and revoke that lease with Vault's lease revocation API/command.
- B
Delete the database role from the database secrets engine so Vault automatically revokes only the compromised server's active credentials.
- C
Revoke the application's token, because revoking a token never affects any leases that were created with it.
- D
Tune the database secrets engine's default TTL to a lower value so the compromised credentials are immediately invalidated.
Show answer and explanation
Correct answer: A
Explanation
Vault dynamic secrets are associated with leases, and Vault provides lease revocation operations to invalidate those secrets before their natural expiration. In a targeted incident response scenario, the best practice is to revoke the specific lease ID tied to the compromised credentials rather than disable the secrets engine or change role configuration broadly. Vault documentation for lease, renew, and revoke workflows describes using the sys/leases endpoints or equivalent CLI commands to revoke individual leases. Token revocation is related but distinct: revoking a token can also revoke leases created through that token, which is why option 3 is incorrect as written. Adjusting TTLs is useful for reducing future exposure windows, but it does not immediately invalidate active leases.
- A. Correct.
Correct. Dynamic secrets such as database credentials are issued with a lease ID. If you need to invalidate a specific set of credentials, the appropriate action is to revoke that lease directly, for example with the relevant Vault CLI command or the sys/leases revoke API. This targets the compromised credentials without broadly impacting other clients or the entire secrets engine.
- B. Incorrect.
Incorrect. Deleting a database role changes future issuance behavior and can disrupt all consumers of that role. It is not the precise operational step for revoking one specific active lease tied to one compromised server. This option reflects a common misconception that changing or deleting role configuration is the same as revoking already-issued credentials.
- C. Incorrect.
Incorrect. Revoking the application's token can revoke leases that were created through that token, so the statement in this option is wrong. Also, the scenario specifically asks for revoking the leased credentials themselves. Token revocation may be part of a broader incident response, but the claim that token revocation never affects leases is factually incorrect.
- D. Incorrect.
Incorrect. TTL tuning affects how long newly issued secrets can live before expiration; it does not immediately revoke an already-issued lease. Lowering TTL can be a preventive hardening step for the future, but it is not the right immediate action to invalidate an existing compromised credential.