Skip to content
Cheat sheets

003 · Domain 3: Vault tokens · 15% of the exam

Task 3.4: Explain the impact of time-to-live

TTL and max TTL from the system, the mount and the role, renewals that cannot pass the max, explicit max TTLs, periodic tokens, and what expiry revokes.

Study it

  • Time-to-live: TTL, max TTL, explicit max TTL and periodic tokens

    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

Tokens from the approle mount start with a 1-hour TTL. The role sets token_max_ttl to 24 hours, but the approle mount was tuned with a max lease TTL of 8 hours. The application renews its token every 30 minutes. What happens?

  1. ARenewals work for 24 hours, because the role's token_max_ttl overrides the mount's tuned value
  2. BRenewals work until about 8 hours after login, and then a new login is needed
  3. CRenewals work for 32 days, the system max TTL
  4. DEvery renewal fails, because the role's max TTL exceeds the mount's
Show the answer and why

  • ARenewals work for 24 hours, because the role's token_max_ttl overrides the mount's tuned value

    Incorrect

    The value an auth method suggests is never allowed to exceed the mount's max TTL.

  • BRenewals work until about 8 hours after login, and then a new login is needed

    Correct

    A role's max TTL may be lower than the mount's but not higher, so the 8-hour mount limit caps the token's life.

  • CRenewals work for 32 days, the system max TTL

    Incorrect

    The mount's tuned max replaces the system default for tokens from that mount.

  • DEvery renewal fails, because the role's max TTL exceeds the mount's

    Incorrect

    Vault does not reject the renewals; it limits the lifetime to the lower value.

The effective max TTL comes from the system max, the mount's tuned max and the auth method's value: the mount's value replaces the system max, and the auth method's value can only lower it.

HashiCorp documentation

Task 3.4Report a problem with this question

Question 2 · choose 1

A long-running service holds a token created with -period=24h and no other TTL options. The service renews it once a day. The server uses the default system max TTL of 32 days. What is the token's state on day 60?

  1. AIt was revoked on day 32, when the system max TTL was reached
  2. BIt was revoked after the first 24 hours, because the period is its max TTL
  3. CIt still works, and its TTL has grown by 24 hours with every renewal
  4. DIt still works; each renewal resets its TTL to 24 hours with no max TTL
Show the answer and why

  • AIt was revoked on day 32, when the system max TTL was reached

    Incorrect

    Periodic tokens escape the normal max TTL mechanism; the system max does not end them.

  • BIt was revoked after the first 24 hours, because the period is its max TTL

    Incorrect

    The period is the TTL granted at each renewal, not a limit on the token's total life.

  • CIt still works, and its TTL has grown by 24 hours with every renewal

    Incorrect

    Renewal resets the TTL to the period; it does not add the period to the time remaining.

  • DIt still works; each renewal resets its TTL to 24 hours with no max TTL

    Correct

    A periodic token's TTL is set back to the period at every renewal, and without an explicit max TTL it never expires while renewed.

Periodic tokens suit long-running services that renew regularly: they stay valid as long as each renewal arrives within the period.

HashiCorp documentation

Task 3.4Report a problem with this question

Question 3 · choose 1

Security wants no token or lease anywhere in the cluster to live longer than 7 days unless a mount is deliberately tuned otherwise, instead of the built-in 32-day system limit. Where is this set?

  1. Amax_lease_ttl = "168h" in the server configuration of each node
  2. Bvault auth tune -max-lease-ttl=168h token/
  3. Ctoken_max_ttl=168h on every role of every auth method
  4. Ddefault_lease_ttl = "168h" in the server configuration of each node
Show the answer and why

  • Amax_lease_ttl = "168h" in the server configuration of each node

    Correct

    max_lease_ttl sets the maximum lease duration for tokens and secrets server-wide; individual mounts can still override it by tuning.

  • Bvault auth tune -max-lease-ttl=168h token/

    Incorrect

    This limits only tokens issued by the token mount; other auth methods and secrets engines keep the system limit.

  • Ctoken_max_ttl=168h on every role of every auth method

    Incorrect

    Role settings apply only to tokens from those roles; secrets engines and roles created later would not be covered.

  • Ddefault_lease_ttl = "168h" in the server configuration of each node

    Incorrect

    default_lease_ttl is the starting duration; tokens and leases could still be renewed up to the maximum.

The server configuration file holds the cluster-wide lease limits: default_lease_ttl for the starting duration and max_lease_ttl for the ceiling.

HashiCorp documentation

Task 3.4Report a problem with this question

Question 4 · choose 1

vault token lookup shows creation_ttl 1h and ttl 12m for a renewable service token. What does the ttl value mean?

  1. AThe token can be renewed for 12 more minutes in total
  2. BThe token is valid for 12 more minutes unless it is renewed
  3. CThe token was created 12 minutes ago
  4. DThe token's max TTL is 12 minutes
Show the answer and why

  • AThe token can be renewed for 12 more minutes in total

    Incorrect

    ttl is the time left, not a budget of renewals.

  • BThe token is valid for 12 more minutes unless it is renewed

    Correct

    The TTL is the current validity counted from creation or the last renewal, whichever is more recent.

  • CThe token was created 12 minutes ago

    Incorrect

    Elapsed time is not what ttl reports.

  • DThe token's max TTL is 12 minutes

    Incorrect

    The max TTL is not shown as ttl; it is computed at renewal time.

creation_ttl records the TTL given at issue; ttl counts down until a renewal or the end of the token.

HashiCorp documentation

Task 3.4Report a problem with this question

Question 5 · choose 1

An operator sets token_ttl=90 on an AppRole role, meaning 90 minutes. Tokens from the role stop working after about a minute and a half. Why?

  1. AValues without a unit are rejected, so the mount's default TTL applies instead
  2. BAppRole caps token_ttl at the role's secret_id_ttl, which is 90 seconds
  3. CTTLs under one hour are rounded down to the smallest supported value
  4. DA number without a unit is read as seconds, so the TTL is 90 seconds
Show the answer and why

  • AValues without a unit are rejected, so the mount's default TTL applies instead

    Incorrect

    Vault accepts a bare number; it does not fall back to the mount default.

  • BAppRole caps token_ttl at the role's secret_id_ttl, which is 90 seconds

    Incorrect

    secret_id_ttl limits how long SecretIDs are valid, not the tokens a login returns.

  • CTTLs under one hour are rounded down to the smallest supported value

    Incorrect

    Vault does not round TTLs; the number is used as given, in seconds.

  • DA number without a unit is read as seconds, so the TTL is 90 seconds

    Correct

    Vault's duration format treats a number with no unit suffix as seconds; 90m would mean 90 minutes.

Write durations with a unit, such as 90m or 1h30m, so nobody has to remember that bare numbers mean seconds.

HashiCorp documentation

Task 3.4Report a problem with this question

Question 6 · choose 1

A token was created with explicit_max_ttl=72h. Two days later the mount's max TTL is lowered to 24h. What is the token's limit now?

  1. A24 hours from creation, since the new mount max now applies to it
  2. B24 hours from the change, applied at the next renewal
  3. CStill 72 hours from creation; mount changes do not touch it
  4. DNone, because the mount change removes the explicit max
Show the answer and why

  • A24 hours from creation, since the new mount max now applies to it

    Incorrect

    Per the token API, updates to the system or mount max TTL have no effect at renewal on a token with an explicit max TTL.

  • B24 hours from the change, applied at the next renewal

    Incorrect

    Mount max TTL changes are ignored at renewal for this token.

  • CStill 72 hours from creation; mount changes do not touch it

    Correct

    Updates to the system or mount max TTL have no effect on a token with an explicit max TTL.

  • DNone, because the mount change removes the explicit max

    Incorrect

    The explicit max cannot be changed after issue.

explicit_max_ttl is encoded into the token when it is created and never changes afterwards.

HashiCorp documentation

Task 3.4Report a problem with this question

Practice domain 3 →Practice all domains →