vault lease renew and sys/leases/renew, the increment measured from now, limits set by the engine and the max TTL, and checking the returned duration.
Study it
Renewing leases: increments, limits and returned durations
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
A database role issues credentials with a default TTL of 1 hour and a max TTL of 4 hours. Three and a half hours after a credential was issued, the application runs vault lease renew -increment=2h with its lease ID. What lease duration does Vault return?
A2 hours, since the increment is counted from the renewal
BNone, because Vault rejects an increment that would pass the max TTL
C1 hour, the role's default TTL, because renewals ignore the increment
DAbout 30 minutes, the time left before the 4-hour max TTL
Show the answer and why
A2 hours, since the increment is counted from the renewal
Incorrect
The increment is counted from now, but the max TTL still caps the result.
BNone, because Vault rejects an increment that would pass the max TTL
Incorrect
Vault does not reject the request; it returns a shorter lease that stays within the limit.
C1 hour, the role's default TTL, because renewals ignore the increment
Incorrect
Engines try to honor the increment within their limits rather than resetting to the default.
DAbout 30 minutes, the time left before the 4-hour max TTL
Correct
The increment is advisory and counted from now; the engine limits it so the lease cannot pass its max TTL.
Always read the duration a renewal returns: the requested increment starts at the time of renewal, but the engine and the max TTL decide what is granted. Near the max TTL, request a new credential instead.
A PostgreSQL role creates users with VALID UNTIL '{{expiration}}'. When an application renews its credential's lease, the DBA wants the user's expiry in the database to move along with it. Which role parameter holds the statements Vault runs at renewal?
Arenew_statements
Brevocation_statements
Crollback_statements
Ddefault_ttl
Show the answer and why
Arenew_statements
Correct
These are the database statements Vault executes to renew a user, for plugins that support them.
Brevocation_statements
Incorrect
These run when a lease is revoked or expires, to remove the user.
Crollback_statements
Incorrect
These undo a create operation that failed part-way.
Ddefault_ttl
Incorrect
This sets the lease length Vault grants; it runs nothing in the database.
If a role leaves its statements out, Vault inserts generic ones that may not suit the database, so production roles define each set explicitly.
A Python service renews its database credential's lease through POST /v1/sys/leases/renew. It tries the same endpoint to renew the service token it got from an AppRole login, and the call is rejected. Which request should it send for the token?
APOST /v1/sys/leases/renew with the token's accessor instead of a lease ID
BPOST /v1/auth/approle/login again, passing the current token
CPOST /v1/auth/token/renew-self, authenticated with that token
DPOST /v1/sys/leases/renew-prefix with the auth/approle/ prefix
Show the answer and why
APOST /v1/sys/leases/renew with the token's accessor instead of a lease ID
Incorrect
This endpoint does not renew token leases, whichever identifier is sent.
BPOST /v1/auth/approle/login again, passing the current token
Incorrect
A new login issues a new token; it does not renew the existing one.
CPOST /v1/auth/token/renew-self, authenticated with that token
Correct
Token leases are renewed through the token endpoints, such as auth/token/renew-self or auth/token/renew.
DPOST /v1/sys/leases/renew-prefix with the auth/approle/ prefix
Incorrect
sys/leases offers prefix revocation, not prefix renewal, and token leases cannot be renewed through sys/leases at all.
The leases endpoint documents that it cannot renew token leases and points to the token endpoints instead.