Skip to content
Cheat sheets

003 · Domain 4: Vault leases · 7% of the exam

Task 4.3: Describe how to revoke leases

Revoking one lease, a prefix or everything a token created, the -force and -sync options, and what revocation does to the secret at its source.

Study it

  • Revoking leases: one lease, a prefix, or everything a token made

    Lesson coming

Sample questions

Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.

Question 1 · choose 1

The database behind the database/ mount was decommissioned before its leases were revoked. vault lease revoke -prefix database/creds now fails because Vault cannot reach the database to drop the users, and the leases stay in Vault. The team accepts that the users are already gone and wants Vault to discard those leases. Which command does it?

  1. Avault lease revoke -force database/creds/app/<lease_id> for each lease
  2. Bvault lease revoke -sync -prefix database/creds
  3. Cvault write -f sys/leases/tidy
  4. Dvault lease revoke -force -prefix database/creds
Show the answer and why

  • Avault lease revoke -force database/creds/app/<lease_id> for each lease

    Incorrect

    -force is accepted only together with -prefix, so a single lease ID does not work.

  • Bvault lease revoke -sync -prefix database/creds

    Incorrect

    The engine call would still fail, so the leases would stay.

  • Cvault write -f sys/leases/tidy

    Incorrect

    Tidy revokes leases that lack a valid token, and those revocations still go through the unreachable database.

  • Dvault lease revoke -force -prefix database/creds

    Correct

    -force deletes the leases even when the engine's revocation fails, and it must be used with -prefix.

Forced revocation ignores backend errors, so Vault stops tracking secrets it could not clean up. Use it only when the secrets are known to be gone.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 2 · choose 2

An application received a credential from the role app of the database secrets engine. Which two actions revoke that credential's lease? (Choose TWO.)

  1. ARotating the connection's root credential with database/rotate-root
  2. BRequesting another credential from the same role
  3. CRevoking the Vault token the application used to request it
  4. DInspecting the lease with vault lease lookup
  5. ERunning vault lease revoke -prefix on the role's credentials path
Show the answer and why

  • ARotating the connection's root credential with database/rotate-root

    Incorrect

    rotate-root changes the password Vault itself uses on the connection; issued leases stay valid.

  • BRequesting another credential from the same role

    Incorrect

    Each request creates a new credential with its own lease; the earlier lease is untouched.

  • CRevoking the Vault token the application used to request it

    Correct

    When a token is revoked, Vault revokes every lease created with that token.

  • DInspecting the lease with vault lease lookup

    Incorrect

    lookup only reads the lease's properties, such as its expiry.

  • ERunning vault lease revoke -prefix on the role's credentials path

    Correct

    A prefix revocation of the role's credentials path revokes every lease issued from that role, this one included.

Leases end by expiry, by explicit revocation of the lease or its prefix, or by revocation of the token that created them.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 3 · choose 1

An operator who mainly uses the Vault UI must revoke a single lease. Where is that done?

  1. AIn Secrets engines, by deleting the role that issued it
  2. BIn the Policies page, by removing the lease's policy
  3. CIn the Access section, under Leases
  4. DNowhere; the UI cannot revoke leases
Show the answer and why

  • AIn Secrets engines, by deleting the role that issued it

    Incorrect

    Deleting a role is not lease revocation.

  • BIn the Policies page, by removing the lease's policy

    Incorrect

    Leases have no policies of their own.

  • CIn the Access section, under Leases

    Correct

    Leases can be revoked through the API, the CLI, or the UI under the Access tab.

  • DNowhere; the UI cannot revoke leases

    Incorrect

    The UI offers lease revocation under Access.

The CLI equivalent is vault lease revoke with the lease ID.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 4 · choose 1

A cleanup script runs vault lease revoke database/creds/app/<lease_id>, which reports success, and at once queries the database for the user. For a few seconds the user still exists. Why, and how can the script wait for the revocation to finish?

  1. ARevocations are queued in the background by default; add -sync to wait
  2. BThe database caches users; the script must flush its connection pool
  3. CVault revokes the lease but leaves dropping the user to the DBA
  4. DThe user is dropped only when the lease's TTL ends; revoke again with -prefix
Show the answer and why

  • ARevocations are queued in the background by default; add -sync to wait

    Correct

    -sync makes the operation synchronous instead of queuing the revocation to be done in the background.

  • BThe database caches users; the script must flush its connection pool

    Incorrect

    The delay comes from Vault queuing the revocation, not from the database.

  • CVault revokes the lease but leaves dropping the user to the DBA

    Incorrect

    Revocation drops the user through the engine; it is only queued, not skipped.

  • DThe user is dropped only when the lease's TTL ends; revoke again with -prefix

    Incorrect

    Revocation does not wait for the TTL, and -prefix only widens which leases are matched.

By default vault lease revoke queues the revocation and returns; scripts that check the target system right away should use -sync.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 5 · choose 1

An operator disables the database secrets engine at database/ while applications still hold credentials from it. What happens to those credentials?

  1. AThey move to a holding mount until an operator restores it
  2. BThey stay valid until their leases expire
  3. CThey keep working, but can no longer be renewed
  4. DTheir leases are revoked and the mount's data deleted
Show the answer and why

  • AThey move to a holding mount until an operator restores it

    Incorrect

    Disabled mounts are removed with their data.

  • BThey stay valid until their leases expire

    Incorrect

    Disabling revokes the secrets rather than waiting for expiry.

  • CThey keep working, but can no longer be renewed

    Incorrect

    The credentials are revoked, not just made non-renewable.

  • DTheir leases are revoked and the mount's data deleted

    Correct

    Disabling an engine revokes its secrets where supported and deletes its data in storage.

Disable an engine only when its consumers have moved off it.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 6 · choose 1

An operator moves the engine at database/ to db-prod/ with vault secrets move. What happens to credentials issued before the move?

  1. ATheir lease IDs are renamed to db-prod/ and stay valid
  2. BThey are revoked; leases are tied to the original path
  3. CThey stay valid but can only be renewed at database/
  4. DNothing, since moving only changes the configuration
Show the answer and why

  • ATheir lease IDs are renamed to db-prod/ and stay valid

    Incorrect

    Lease IDs are not rewritten; the old leases are revoked.

  • BThey are revoked; leases are tied to the original path

    Correct

    Moving revokes all secrets because leases are tied to the path where they were created; configuration persists.

  • CThey stay valid but can only be renewed at database/

    Incorrect

    The old path no longer exists after the move, and the secrets are revoked.

  • DNothing, since moving only changes the configuration

    Incorrect

    Configuration persists, but secrets are revoked.

Plan mount moves like outages for dynamic secrets: consumers must request new credentials afterwards.

HashiCorp documentation

Task 4.3Report a problem with this question

Practice domain 4 →Practice all domains →