Token management is a system for controlling short-term access passes that expire and can be cancelled at any moment. It solves the problem of giving a computer or a person the exact amount of permission they need, for exactly as long as they need it, without leaving the door open forever. For the VA-003 exam, understanding token creation, renewal, and revocation is crucial because tokens are the primary way Vault authenticates users and machines, and exam questions will test your ability to keep them secure and short-lived.
Jump to a section
A simple way to picture Token Lifecycle and Management
A busy public library with a strict librarian at the front desk. You walk up and ask for a specific book from a locked reference section. The librarian doesn't hand you the book directly. Instead, she issues you a temporary borrowing card, stamped with today's date and an expiry time of two hours later. This card is your token. It has your name, the book's shelf number, and the librarian's official stamp. For the next two hours, you can flash that card to any assistant in the library and they will fetch the book, bring it to your reading table, and let you use it. You do not have to ask the head librarian again.
But if you leave the library for lunch and come back after the card has expired, the assistants will refuse. The card is dead. You must go back to the head librarian, return the expired card, and request a new one. If you accidentally drop your card in a puddle and the ink smudges, the assistants cannot read it, so it is as if it never existed. The head librarian can also revoke your card early if she catches you trying to sneak a book into your bag. The entire system works because the card is temporary, specific, and must be renewed or replaced when it runs out. The library does not trust you permanently; it trusts you for two hours at a time.
A token in HashiCorp Vault is a digital pass that proves an entity (a person, an application, or a machine) has been authenticated. Authentication is the process of verifying who you are. A token is the result of that verification. Think of it as a keycard for a building: you swipe your ID badge at the door (authentication), and the system hands you a keycard (the token) that grants access to certain rooms for a set period.
Tokens have a lifecycle: they are created, they live for a while, and then they die. The most important rule for the VA-003 exam is that tokens should be short-lived. A short-lived token is one that expires in minutes or hours, not days or years. If a token lasts a very long time, it is called a long-lived token, and that is generally considered a security risk because if someone steals it, they have access for a very long time.
Token creation happens when a user or a machine logs into Vault. Vault can authenticate through many methods. These methods are called auth methods. Each auth method verifies identity in a different way. For example, the username and password auth method checks a username and a password. The token auth method lets you create tokens directly. The LDAP auth method checks against a company directory. The Kubernetes auth method verifies that a pod in Kubernetes is who it claims to be. When authentication succeeds, Vault creates a token, assigns it a unique ID (a long random string), attaches a time limit called a Time To Live (TTL), and gives it a maximum lifetime called a Max TTL. The TTL is how long the token is valid for a single session. The Max TTL is the absolute longest the token can ever exist, even if you renew it.
Token renewal is the act of asking Vault to keep the token alive for longer. You can renew a token before it expires. Vault will extend the TTL from the moment of renewal, but it can never go past the Max TTL. This is a key exam concept. For example, if a token has a TTL of 1 hour and a Max TTL of 24 hours, you can renew it every 30 minutes. Each time you renew, the clock resets to 1 hour. But after 24 hours total, the token cannot be renewed anymore. It must die. This prevents tokens from living forever.
Token revocation is the immediate destruction of a token. Anyone with sufficient permission, usually an administrator, can revoke a token. When a token is revoked, it stops working instantly. Any child tokens, which are tokens that were created using a parent token, are also revoked by default. This is called a revocation cascade. If a security team detects a compromised token, they revoke it, and all access granted through that token is cut off immediately.
Tokens also have roles, called token roles, which are templates that define default settings for tokens. A token role can set default TTL, Max TTL, allowed policies, and other constraints. Policies are rules that define what a token is allowed to do, like read a secret or write a path. Every token is assigned one or more policies at creation time.
Leases are similar to tokens but are attached to dynamic secrets. A dynamic secret is a credential that Vault generates on demand, such as a database password or an AWS access key. Leases track the lifetime of that generated credential. The lease has an ID, a TTL, and a Max TTL. When a lease expires, Vault automatically revokes the dynamic secret. You can also manually revoke or renew a lease. Lease management is the process of tracking, renewing, and revoking these leases to ensure secrets are not left lying around.
In a real system, if a developer needs a database password for one hour, an admin configures a role that issues a lease for 1 hour. The developer authenticates, Vault creates a token, the developer uses that token to request the database password, and Vault returns the password along with a lease ID. The developer uses the password. After one hour, the lease expires, and Vault automatically rotates the password so the old one no longer works. The developer never sees the password again. This is far more secure than writing the same password in a config file and leaving it there for years.
Token management also includes looking up information about a token, called token lookup, which tells you the token's TTL, Max TTL, policies, and creation time. You can also reattach a token to different policies using token update, but this is rare in practice.
Authentication
The entity (user or machine) presents credentials to an auth method (e.g., username/password, Kubernetes service account, LDAP). Vault verifies the identity. If successful, Vault creates a token. This is the entry point for the entire lifecycle.
Token Creation
Vault generates a token with a unique ID, attaches policies, sets a TTL and Max TTL, and may assign a token role. The entity receives this token. The token is now active and can be used to access secrets.
Token Usage
The entity presents the token to Vault for any API call, such as reading a secret, generating a dynamic credential, or creating child tokens. Each usage is logged in the audit log. The token is valid only if its TTL has not expired and it has not been revoked.
Token Renewal
Before the TTL expires, the entity can send a renewal request to Vault. Vault checks the current time against the token's Max TTL. If the total lifetime has not exceeded Max TTL, Vault resets the TTL to its original value. Renewal can be automated by the client application.
Token Expiry or Revocation
If the token reaches its Max TTL without renewal, it expires automatically. Alternatively, an administrator can manually revoke the token at any time. Upon revocation, Vault invalidates the token, revokes all child tokens, and revokes all leases created by that token, ending all access through it.
Lease Management (if dynamic secrets were generated)
When a dynamic secret is created, a lease is issued with its own TTL and Max TTL. The lease must be renewed separately from the parent token. When the lease expires, Vault automatically rotates the secret. This step is critical for secrets that rotate credentials like database passwords.
An IT security engineer at a fintech company called PayFlow needs to give a new payment processing microservice access to a database containing transaction data. The microservice runs in a Kubernetes cluster and needs a database password that changes frequently for security reasons.
First, the engineer enables the database secrets engine in Vault. A secrets engine is a component that generates or stores secrets, such as database passwords, AWS keys, or SSH keys. She configures a role called 'payflow-payment-db' that tells Vault how to generate a read-only username and password for the PostgreSQL database, with a default TTL of 30 minutes and a Max TTL of 2 hours.
Next, she enables the Kubernetes auth method so the microservice can authenticate without a human typing a password. She configures a role that maps the microservice's Kubernetes service account to a token policy. The policy grants permission only to read the 'payflow-payment-db' role in the database secrets engine.
When the microservice starts, it authenticates against the Kubernetes auth method. Vault verifies the microservice's identity by checking its Kubernetes service account token and issues a Vault token. This token has a TTL of 1 hour and a Max TTL of 24 hours. The microservice now holds a Vault token.
The microservice then uses that token to request a database credential from the 'payflow-payment-db' role. Vault generates a temporary database username and password, returns them as a dynamic secret, and assigns a lease ID with a TTL of 30 minutes. The microservice connects to the database using these credentials.
After 25 minutes, the microservice realises the lease is about to expire. It sends a lease renewal request to Vault. Vault checks that the Max TTL of 2 hours has not been exceeded. It extends the lease for another 30 minutes. This can continue until the lease has been alive for 2 hours, at which point Vault refuses renewal.
If the security team detects a vulnerability in the microservice, they can revoke the microservice's token immediately. This causes a cascade: the token is revoked, all dynamic secrets created with that token are revoked, and the microservice loses access to the database. The database password is automatically changed, so even if an attacker had stolen the password, it no longer works.
The engineer also sets up monitoring to alert if a token is older than 12 hours, as a safety measure. She uses Vault's audit logging to record every token creation and revocation, which is required for compliance with financial regulations.
In daily operations, the engineer uses the command 'vault token revoke <token-id>' to manually revoke tokens of compromised users. She uses 'vault token renew <token-id>' to extend tokens for batch jobs that run longer than expected. She uses 'vault token lookup <token-id>' to check why a token is not working. These are the three most common token management tasks in real IT work.
The VA-003 exam tests Token Lifecycle and Management heavily. Expect around 5 to 8 questions on this objective, both single-answer multiple choice and multiple-select. The exam loves to test your understanding of TTL versus Max TTL. A classic trap question: 'A token has a TTL of 1 hour and a Max TTL of 4 hours. After 3 hours, the user renews the token. What is the new TTL?' The correct answer is 1 hour, because renewal resets the TTL to its original value, but the token will expire after 4 hours total. Many candidates incorrectly assume the TTL stacks or extends from the current time in a linear way.
Another frequent trap asks about the difference between a token and a lease. The exam might say: 'You generate an AWS IAM credential from Vault. Which of the following is managed by a lease?' The answer is the generated AWS credential, not the Vault token used to request it. A token is used to authenticate to Vault; a lease tracks the lifetime of a dynamic secret created by Vault.
The exam also tests token revocation cascading. A question might state: 'An admin revokes a parent token. What happens to child tokens created by that parent?' The correct answer is that all child tokens are also revoked, unless they were created with an explicit 'no-cascade' option, which is rare. The trap is thinking that child tokens survive independently.
Key concepts to memorise for the exam:
TTL (Time To Live): How long a token is valid from creation or last renewal.
Max TTL: The absolute maximum lifetime of a token, regardless of renewals.
Token role: A template that sets default TTL, Max TTL, and allowed policies for tokens.
Orphan token: A token that is not a child of any other token; revoking its parent does not affect it. The exam may ask when you would create an orphan token (answer: when you want a token to survive its parent's revocation).
Periodic token: A token that never reaches its Max TTL because it can be renewed indefinitely. Used for long-running services. The exam tests that periodic tokens are explicitly created and require permission.
Explicit Max TTL versus system Max TTL: The actual Max TTL of a token is the lesser of the role's Max TTL, the mount's Max TTL, and the system's Max TTL. The exam loves to test that the most restrictive value wins.
Question types to expect:
Scenario-based: 'A developer needs a token that lasts exactly one month. What should the admin configure?' Answer: A periodic token, because Max TTL cannot be extended beyond the default system limits without periodic tokens.
Definition matching: Match the term (token, lease, TTL, Max TTL) to its description.
True/false: 'A token's TTL is always equal to its Max TTL.' Answer: False. TTL is the initial validity; Max TTL is the upper bound.
Command output interpretation: The exam may show partial output of 'vault token lookup' and ask what the remaining time is.
Traps to avoid:
Confusing renewal (extend token life) with re-authentication (get a brand new token). Renewal does not require re-entering credentials.
Assuming all tokens are revoked when the auth method is disabled. Disabling an auth method does not revoke existing tokens; you must revoke them manually.
Thinking that revoking a token revokes the secrets it accessed. It only revokes the token. The secrets engine may still have the secret; the lease is what actually gets revoked for dynamic secrets.
A token authenticates a user or machine to Vault, while a lease tracks the lifetime of a dynamic secret generated by Vault.
TTL sets the initial validity of a token or lease, and Max TTL is the absolute upper limit that cannot be exceeded even with renewals.
Renewal resets the TTL to its original value, not adding it to the remaining time, and the token cannot outlive its Max TTL.
Revoking a parent token cascades to all child tokens and leases created with that token, instantly cutting off access.
A periodic token can be renewed indefinitely and never reaches its Max TTL, making it suitable for long-running services.
When multiple Max TTL limits apply (role, mount, system), the most restrictive value is the one that takes effect.
Always use short-lived tokens with automated renewal cycles to minimise the blast radius if a token is compromised.
Orphan tokens are created with the 'orphan' flag and are not affected when their parent token is revoked.
These come up on the exam all the time. Here's how to tell them apart.
Token
Authenticates the entity to Vault itself
Has a TTL and Max TTL that control access to Vault APIs
Used to make any Vault API call
Lease
Tracks the lifetime of a generated dynamic secret
Has its own independent TTL and Max TTL separate from the token
Used only to manage the specific secret's validity
TTL (Time To Live)
Duration a token or lease is valid from creation or last renewal
Can be reset by renewing before it expires
Example: 1 hour means the token lasts 1 hour after each renewal
Max TTL
Absolute maximum lifetime from initial creation
Cannot be exceeded even with repeated renewals
Example: 4 hours means the token can never exist longer than 4 hours total
Parent Token
Created first and used to create child tokens
Has authority to create child tokens with different policies
Its revocation cascades to child tokens
Child Token
Created by a parent token, inheriting some properties
Exists independently but is tied to parent for revocation
Destroyed when parent token is revoked (unless orphan)
Periodic Token
Has no effective Max TTL and can be renewed indefinitely
Requires explicit creation with the 'period' flag or token role
Used for long-running services like batch jobs
Regular Token
Has a strict Max TTL that cannot be bypassed
Created by default from auth methods
Used for short-lived tasks and human users
Mistake
Tokens are permanent and last forever unless manually deleted.
Correct
Tokens have a TTL and Max TTL and expire automatically if not renewed. They are designed to be short-lived.
Many beginners come from a world of static passwords and API keys that are set once and forgotten. The concept of a credential that dies by itself is unfamiliar.
Mistake
Renewing a token adds the TTL on top of the remaining time, so a token can live forever by renewing early.
Correct
Renewal resets the TTL from the moment of renewal, but the total lifetime cannot exceed the Max TTL. You cannot bypass the Max TTL by renewing frequently.
This sounds logical: if you keep extending, why would it ever stop? Beginners do not understand that Max TTL is a hard ceiling enforced by Vault.
Mistake
A lease and a token are the same thing.
Correct
A token authenticates you to Vault. A lease tracks the lifetime of a generated dynamic secret. They are separate objects with separate TTLs and Max TTLs.
Both have IDs, both expire, and both can be renewed. The terminology overlap confuses beginners who think 'lease' is just a fancy word for a token tied to a secret.
Mistake
Revoking a token only revokes that token, not any secrets it might have generated.
Correct
Revoking a token triggers a cascade that revokes all leases and child tokens created with that token. Dynamic secrets become invalid immediately.
New users think of tokens as isolated keys. They do not realise Vault tracks the parent-child relationship and the lease chain to enforce complete revocation.
Mistake
You can set a token's TTL to any value, like 10 years, and Vault will honour it.
Correct
The system Max TTL is a global limit. Even if you set a high TTL, if it exceeds the system Max TTL (usually 32 days by default), Vault will cap it. You must use a periodic token for long-lived access.
Beginners assume they are in full control. They do not know about the system Max TTL limit that acts as a safety net.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The token remains active on the Vault server until it expires or is revoked. Closing the browser does not revoke the token. You must explicitly log out or wait for it to expire.
No. The Max TTL is a hard limit. You cannot extend a token past it. However, you can create a periodic token that has no effective Max TTL and can be renewed indefinitely.
Revocation is an immediate manual or programmatic action that kills the token right now. Expiry is a natural event when the token's TTL or Max TTL is reached. Both result in the token being unusable.
No. Many Vault client libraries automatically renew tokens before they expire. You often configure the renewal interval. Manual renewal is possible but not required for well-written applications.
For static secrets (like a fixed password stored in Vault), revoking the token does not change the secret. For dynamic secrets (like a generated database password), the lease is revoked, and Vault rotates the password so the old one no longer works.
Yes. Tokens created with the 'orphan' flag are not children of any token. They survive the revocation of the token that created them. This is useful for admin tokens that must outlive their creator.
Use the command 'vault token lookup' or call the /v1/auth/token/lookup-self API endpoint. The output shows 'ttl' which is the remaining time in seconds.
You've finished Token Lifecycle and Management. Continue through the VA-003 study guide to build a complete picture of the exam.
Done with this chapter?