Manage Vault leases practice questions

The lease is not renewable.

Why it fails: The output shows lease_renewable: true.

The mount's max_lease_ttl is set to 1h.

Why it fails: This could also limit renewal, but the role's max_ttl is more likely.

The developer does not have permission to renew the lease.

Why it fails: The renewal command succeeded, so permission is not an issue.

Increase the default lease TTL for the KV v2 mount to 1 hour.

Why it fails: This affects secret leases, not token leases.

Implement a renewal loop in each service to renew tokens every 10 minutes.

Why it fails: This adds complexity and may not fix the root cause if tasks exceed 15 minutes.

Use periodic tokens with a period of 1 hour for all services.

Why it fails: Periodic tokens can cause orphaned tokens and increase lease count.

Remove the TTL entirely so that credentials never expire.

Why it fails: Removing the TTL entirely makes dynamic credentials permanent, eliminating Vault's automatic rotation and revocation, which breaks the security model. Non-expiring credentials suit static, long-lived service accounts where rotation is handled externally, not dynamic secrets requiring lease-based lifecycle management.

Decrease the default lease TTL from 1 hour to 30 minutes.

Why it fails: Shortening the TTL to 30 minutes doubles renewal frequency, worsening the performance problem rather than reducing it. Shorter leases suit high-security environments needing rapid credential rotation, where renewal overhead is acceptable; here the team explicitly wants fewer renewal calls.

Increase the maximum TTL for the role to 24 hours.

Why it fails: Raising the maximum TTL to 24 hours caps how long a lease can be extended, but the default lease TTL of 1 hour still governs initial issuance and renewal intervals, so renewal frequency is unchanged. Long maximum TTLs suit batch jobs needing credentials to outlive a single short lease.

Call the sys/leases/list endpoint to disable a lease.

Why it fails: The sys/leases/list endpoint enumerates leases under a prefix; revocation is performed via sys/leases/revoke or revoke-prefix. It is tempting because listing leases is a genuine lease-management operation used for auditing and bulk cleanup, but the stem asks for the operation that disables a lease, which listing does not perform.

Call the sys/leases/extend endpoint to increase the lease duration.

Why it fails: The sys/leases/extend endpoint is not a Vault API path; lease duration is increased by calling sys/leases/renew against the lease ID. It is tempting because extending a lease is a real lease-management operation and the endpoint name sounds plausible, but Vault exposes renewal, not extension, at that path.

Call the sys/leases/rotate endpoint to rotate the secret associated with a lease.

Why it fails: No sys/leases/rotate endpoint exists; rotating the underlying secret is performed by the secrets engine's own rotate operation, such as pki/root/rotate. It is tempting because rotation is central to lease management and the naming parallels other sys endpoints, but this path is not part of Vault's API.

Revoke the lease and request a new credential with a longer TTL.

Why it fails: Incorrect. Revoking the lease and requesting a new credential with a longer TTL does not solve the root cause; the application must renew the lease to maintain the credential for its full duration.

Increase the TTL of the database role to 2 hours.

Why it fails: Extending the role TTL to two hours does not stop revocation; the lease was revoked because the application never renewed it before expiry. It is tempting because a longer TTL appears to grant more time, but the fix is enabling lease renewal in the application, not lengthening the role's maximum TTL.

Set the default lease TTL on the database mount to 1 hour.

Why it fails: The default lease TTL applies to all secrets without a specific role TTL; but the role TTL overrides the default. Also, the default lease TTL is already 24h, but changing it to 1h would affect other roles that might need longer leases.

Increase the system's default lease TTL to 48 hours to give applications more flexibility.

Why it fails: Raising the engine's default lease TTL to 48 hours lengthens credential exposure, directly opposing the goal of prompt revocation. It tempts because longer defaults reduce renewal overhead, and would be correct where applications need stable, long-lived credentials rather than short one-hour leases.

Manually revoke leases after each application finishes using them.

Why it fails: Manual revocation depends on operators remembering after every run, so leases persist up to the 24-hour default when they forget. It tempts as direct control, and would be correct for rare, unpredictable one-off jobs where automation cannot determine completion.

default_lease_ttl = 1h

Why it fails: Without max, renewals could extend the lease beyond 1h.

token_ttl = 1h

Why it fails: Token TTL affects token lifecycle, not secret lease TTL.

max_lease_ttl = 1h

Why it fails: Without default_lease_ttl, the initial TTL may be longer than 1h.

Increase the mount's max_lease_ttl to 2h.

Why it fails: Mount's max_lease_ttl is a global cap but does not override role's max_ttl.

Renew the lease with a TTL of 2h.

Why it fails: Renewal TTL cannot exceed the role's max_ttl; if max_ttl is 30m, the renewal will be capped.

Request a new credential with a TTL of 2h.

Why it fails: The credential request does not accept a TTL parameter; TTL is determined by the role.

'list' on sys/leases/.

Why it fails: Listing sys/leases/ only enumerates existing leases; it grants no ability to extend one, so the renew call still fails. It is tempting because lease administration often needs visibility of active leases, and 'list' would be correct for auditing or revoking leases held by other tokens.

'renew' on the secret path.

Why it fails: Renewal in Vault is governed by the lease's own path and the token's permissions there, not by a 'renew' capability on the secret path; no such capability exists in the policy grammar. It is tempting because renewing a lease intuitively sounds like an action performed against the secret that issued it.

'sudo' on sys/leases/.

Why it fails: 'sudo' on sys/leases/ permits manipulating other tokens' leases, not renewing your own; the renew endpoint checks the token's lease permissions instead. It is tempting because sudo on sys/leases/ is genuinely required when an operator must revoke or inspect leases belonging to other clients.

The token lacks permission.

Why it fails: The token's attached policy does not grant the capability required on that path, so Vault denies the request. It is tempting because tokens are the usual suspect, and would be correct if the exhibit showed a 403 with a policy mismatch rather than the specific error displayed.

The secret engine was disabled.

Why it fails: Disabling a secrets engine returns a 404 or mount-not-found error, not the permission denied message shown. It is tempting because a disabled engine does make paths unreachable, and would be correct if the exhibit showed an unknown mount path rather than an authorisation failure on an existing path.

The lease has expired.

Why it fails: An expired lease invalidates a dynamic secret's credentials, producing an authentication failure against the target system, not a Vault API permission error. It is tempting because leases do expire, and would be correct if the exhibit showed a database rejecting a stale username and password.

The database role's max TTL is being enforced, but the default TTL is shorter.

Why it fails: Max TTL caps total lifetime but does not force expiry before the default TTL; the 1h default is what governs initial credential life. This is tempting because max TTL genuinely truncates leases, and it would be correct if the role's max TTL were set below the default TTL, causing earlier expiry.

The Vault server's clock is skewed, causing early expiry.

Why it fails: Clock skew shifts timestamps but does not shorten a lease's TTL; Vault computes expiry from its own monotonic clock, so credentials would not expire early. It is tempting because time drift causes odd behaviour, but early expiry typically stems from a shorter TTL set on the credential request itself.

The application is renewing the lease too frequently, causing Vault to reset the TTL.

Why it fails: Renewal extends a lease's lifetime; it never resets or shortens the TTL, so frequent renewals cannot cause early expiry. This option is tempting because renewal is a genuine Vault lease operation, and it would be the right answer if credentials were failing after their maximum TTL was reached without renewal being permitted.

vault lease revoke aws/creds/myrole/ -prefix

Why it fails: Incorrect syntax; '-prefix' should come before the prefix string.

vault lease revoke aws/creds/myrole

Why it fails: Passing the path alone revokes one lease whose ID matches that string, not the set of leases issued for the role. Prefix-based revocation is required to clear all leases under aws/creds/myrole; a bare path cannot match the individual lease identifiers.

vault lease revoke -path aws/creds/myrole

Why it fails: Revoking the path itself targets a single lease, not every lease issued against that role, so the IAM user's other credentials survive. The -prefix flag is what expands revocation across all leases sharing the path; without it, only one lease is removed.

vault read sys/leases/lookup/<lease_id>

Why it fails: This path is for listing leases under a mount, not for a specific lease.

vault lease list <lease_id>

Why it fails: vault lease list is used to list leases under a prefix, not to lookup a single lease.

vault lease renew -increment=0 <lease_id>

Why it fails: This attempts to renew the lease with zero increment, which may not show remaining TTL.

The lease revocation process is failing due to network issues.

Why it fails: Network issues could cause revocation failures, but tidy is designed to handle such cases.

The database rotation statement is incorrect, causing Vault to not properly revoke credentials.

Why it fails: Rotation statement is for periodic password changes, not revocation.

The role's max_ttl is set too high, allowing leases to live longer.

Why it fails: High max_ttl does not prevent revocation on expiry; it only extends potential lifespan.

vault lease renew -increment=0 <lease_id>

Why it fails: Incorrect. `vault lease renew -increment=0` attempts to renew with zero increment, which is not a valid way to force expiration; it may result in an error.

vault lease expire <lease_id>

Why it fails: Incorrect. `vault lease expire` is not a valid Vault command.

The renewable flag is set to false on the role.

Why it fails: Setting renewable to false prevents renewal at any point, so the first renewal attempt would fail immediately, not after ten minutes. This flag would be the cause if users could never renew a lease regardless of elapsed time.

The user's token does not have permission to renew leases.

Why it fails: Vault returns a permissions error only when the token's policy lacks the renew capability on the lease path; the stem describes a renewal error after ten minutes, which points to TTL limits rather than authorisation. Missing renew permissions would be the cause if the token could never renew from the outset.

The max_ttl of 30m is reached, but the OTP has already been used.

Why it fails: The max_ttl of 30 minutes cannot be reached at ten minutes, and OTP single-use affects authentication, not lease renewal. This would be the cause if renewals failed at 30 minutes, or if a consumed OTP were replayed for a second SSH login.

vault write sys/leases/list lease_id=<mount_path>

Why it fails: You cannot list leases by writing; you must use a read or list operation.

vault lease list -prefix <mount_path>

Why it fails: There is no 'vault lease list' command; the correct command is 'vault list'.

vault read sys/leases/list/<mount_path>

Why it fails: Correct path is sys/leases/lookup/ or sys/leases/prefix/, not sys/leases/list/.

The requesting token's TTL

Why it fails: Token TTL does not affect lease TTL.

The backend's rotation period

Why it fails: Rotation period is for periodic password changes, not lease TTL.

vault sys/leases/revoke-force <prefix>

Why it fails: Incorrect path; there is no revoke-force endpoint.

vault token revoke -mode=orphan <token>

Why it fails: Orphan mode revokes the token but leaves its leases intact; not suitable for revoking leases.

vault lease revoke <lease_id>

Why it fails: Only revokes a single lease, not all associated with a policy.

2 hours

Why it fails: The max_ttl is 1h, not 2h.

90 minutes

Why it fails: The lease is renewed at the halfway point of its duration, so the maximum total lifespan is 60 minutes, not 90. The 90-minute figure tempts because it looks like one full renewal cycle added to the original term, but DHCPv6 renewal occurs at T1, giving 30 minutes plus a 30-minute extension.

30 minutes

Why it fails: Thirty minutes is the maximum duration of a single lease renewal, not the total lifespan, which accumulates across renewals up to the blob's limit. A single lease term is the right figure when the question asks how long one renewal lasts.