Manage Vault leases →mediumMultiple Choice

VA-003 Manage Vault leases Practice Question

A platform team runs Vault with a transit secrets engine mount at transit/. An application requests a new data encryption key with a 30-minute TTL, and the returned lease_id is recorded by the app. Twenty minutes later, the app calls the renew endpoint for that lease. The mount was configured with max_lease_ttl of 1h. What is the maximum TTL the lease can be extended to by this renewal?

⚠ Common exam trap

The trap here is assuming a renewal adds a fresh TTL interval from the renewal moment instead of counting against the mount's cumulative max_lease_ttl.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The lease can be renewed up to 1 hour total from its original creation time, because the mount's max_lease_ttl caps the cumulative lease lifetime.

A renewable lease is bounded by the mount's max_lease_ttl, which acts as a cumulative ceiling measured from lease creation. Renewal can extend the lease's expiration toward that ceiling but never beyond it. With a 1-hour max and 20 minutes already elapsed, the lease can be renewed only to the 1-hour mark, after which it must be reissued.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The lease can be renewed indefinitely as long as the client keeps renewing before expiration, because transit keys have no maximum lifetime.
Why it's wrong here
Vault enforces max_lease_ttl for renewable leases; renewal does not grant infinite lifetime. Even if the client renews diligently, the lease will fail to renew once it reaches the mount's maximum cumulative TTL. Transit keys are subject to the same lease ceiling as other dynamic secrets unless the mount is explicitly configured otherwise.
✗
The lease can be renewed only up to the original 30-minute TTL, because transit leases cannot be extended beyond creation TTL.
Why it's wrong here
Transit leases are renewable like most secrets engine leases, so the renewal is not capped at the initial 30-minute TTL. The cap is the mount's max_lease_ttl, not the original requested TTL. Claiming transit leases cannot be extended beyond creation TTL misstates how the lease renewal endpoint behaves for this engine.
✓
The lease can be renewed up to 1 hour total from its original creation time, because the mount's max_lease_ttl caps the cumulative lease lifetime.
Why this is correct
Vault caps a lease's total lifetime at the mount's max_lease_ttl, which here is 1h. Renewal can extend the remaining time, but it cannot push the lease past that cumulative limit from creation. Since the lease was created 20 minutes ago, a renewal can extend it only to the 1-hour mark, after which it expires and must be re-created.
✗
The lease can be renewed to 30 minutes from the moment of the renewal call, giving it a total lifetime of 50 minutes.
Why it's wrong here
This describes an increment relative to the renewal time rather than a cumulative cap. Vault tracks the lease's total age against max_lease_ttl, so the renewal cannot simply add a fresh 30 minutes on top of the elapsed 20 minutes. The resulting total would exceed the configured 1-hour ceiling only if the increment were larger, but here the ceiling is what governs.

Go deeper

VA-003 Manage Vault leases Practice Question

Why each option matters

Option-by-option breakdown

Related to this question