Courseiva

CCNA Assess Vault tokens Questions

58 questions · Assess Vault tokens · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQhard

A Vault operator runs 'vault token lookup s.abc123' and sees that the token type is 'service', renewable is true, but the ttl is 30m and creation_ttl is 1h. The token has num_uses set to 0. What is the most likely explanation for the discrepancy between ttl and creation_ttl?

A.The token has renewable set to false
B.The token type is service, so it cannot be renewed
C.30 minutes have elapsed since the token was created
D.The token has been used and num_uses decremented
AnswerC

The ttl field reports remaining time, while creation_ttl records the original lifetime. A ttl of 30m against a creation_ttl of 1h means 30 minutes have elapsed since issuance, so the token is simply counting down from its initial hour.

Why this answer

The token's current TTL (30m) is shorter than its creation_ttl (1h) because 30 minutes have already elapsed since the token was issued. The TTL dynamically decreases as time passes, while creation_ttl remains fixed at the original value set at token creation. This is normal behavior for a renewable service token with num_uses=0.

Exam trap

HashiCorp often tests the distinction between creation_ttl (static) and ttl (dynamic), trapping candidates who confuse a reduced TTL with a non-renewable token or usage decrement.

How to eliminate wrong answers

Option A is wrong because the token's renewable attribute is explicitly shown as true in the lookup output, so it cannot be the cause of a reduced TTL. Option B is wrong because service tokens are fully renewable by default; the token type does not prevent renewal. Option D is wrong because num_uses is set to 0, meaning the token has no usage limit and does not decrement; the TTL reduction is purely time-based, not usage-based.

Practice this question →
2
MCQhard

An administrator receives an access denied error when trying to use the token accessor to revoke a token. The administrator's token has the following policy capabilities: path "auth/token/revoke-accessor" { capabilities = ["create", "update"] }. What is the issue?

A.The administrator lacks the 'sudo' capability on that path
B.The administrator's token does not have any capabilities on the path
C.The path requires 'create' and 'update' but not 'sudo'
D.The accessor path is incorrect; it should be auth/token/accessors/revoke
AnswerA

Revoking a token via its accessor requires the `sudo` capability on `auth/token/revoke-accessor`, regardless of `create` or `update` grants. Vault's token store enforces this elevated privilege because accessor-based revocation bypasses knowledge of the token ID itself, so the policy must explicitly include `sudo` to satisfy that constraint.

Why this answer

The `auth/token/revoke-accessor` endpoint requires the `sudo` capability in addition to `create` or `update`. In Vault, certain sensitive token management operations, such as revoking a token by its accessor, are protected by the `sudo` privilege to prevent unauthorized revocation. Without `sudo`, the administrator receives an access denied error even though they have `create` and `update` capabilities on the path.

Exam trap

A common misconception is that having 'create' and 'update' capabilities on a path is sufficient for all operations on that path, but in Vault certain sensitive endpoints like 'auth/token/revoke-accessor' also require the 'sudo' capability.

How to eliminate wrong answers

Option B is wrong because the administrator's token does have capabilities on the path (`create` and `update`), so the issue is not a complete lack of capabilities. Option C is wrong because the path does require `sudo` in addition to `create` and `update`; the statement that it does not require `sudo` is incorrect. Option D is wrong because the accessor path is correct as `auth/token/revoke-accessor`; the suggested path `auth/token/accessors/revoke` does not exist in Vault's API.

Practice this question →
3
MCQhard

A token with a policy that explicitly denies 'read' on 'secret/engineering/private' is issued. The same token also has another policy that grants 'read' on 'secret/engineering/*'. What is the result when the token tries to read 'secret/engineering/private'?

A.The read succeeds because the grant from the wildcard policy is more permissive
B.The read fails because the policies conflict and Vault defaults to deny
C.The read succeeds because the token has a separate policy that grants read
D.The read fails because the explicit deny on the specific path takes precedence
AnswerD

Vault evaluates all attached policies together, and an explicit deny always overrides any grant. The deny on secret/engineering/private therefore wins over the wildcard read on secret/engineering/*, so the read request fails despite the broader grant.

Why this answer

D is correct because Vault's policy evaluation uses a deny-overrides model: any explicit deny on a specific path takes precedence over any allow, even if the allow is more permissive or from a wildcard. The explicit deny on 'secret/engineering/private' blocks the read, regardless of the broader grant on 'secret/engineering/*'.

Exam trap

Vault uses a deny-overrides model: any explicit deny on a specific path takes precedence over any allow, even if the allow is more permissive or from a wildcard. The explicit deny on 'secret/engineering/private' blocks the read, regardless of the broader grant on 'secret/engineering/*'.

How to eliminate wrong answers

Option A is wrong because Vault does not use a 'most permissive wins' model; explicit denies always override allows, even wildcard allows. Option B is wrong because Vault does not default to deny on policy conflict; it explicitly evaluates denies first and denies the action. Option C is wrong because the token does have a grant, but the explicit deny on the exact path overrides that grant, causing the read to fail.

Practice this question →
4
MCQeasy

A new engineer authenticates to Vault and receives a token. The engineer's manager asks which policies are attached to that token and when it will expire, so the team can plan a permissions review. Which command should the engineer run to display this information about their own token?

A.vault auth list
B.vault token lookup
C.vault secrets list
D.vault token create
AnswerB

vault token lookup with no argument inspects the token currently in use and returns its policies, TTL, creation time, renewability, and accessor. This gives the engineer exactly the policy list and expiry details the manager requested. It is a read-only operation that requires no special privileges beyond possessing the token.

Why this answer

Token inspection is performed with vault token lookup, which returns the token's policies, TTL, renewability, and accessor when run against the current token. That directly supplies the policy list and expiration information needed for the review, without creating new tokens or querying unrelated auth and secrets mounts.

Exam trap

The trap here is reaching for commands that list auth methods or secrets engines, which describe mount configuration rather than the attributes of a specific token.

Practice this question →
5
MCQmedium

A CI/CD pipeline needs to generate thousands of short-lived tokens each day for jobs that run for at most 5 minutes. The tokens should not be renewable or revocable individually. Which token type should be used?

A.Orphan tokens
B.Service tokens
C.Batch tokens
D.Periodic tokens
AnswerC

Batch tokens suit this pipeline because they are non-renewable and cannot be individually revoked, matching the stated constraint. They are issued by a batch token role, are not persisted to storage, and carry a fixed TTL, so thousands of short-lived five-minute job tokens can be generated cheaply without per-token lifecycle management overhead.

Why this answer

Batch tokens are designed for high-volume, short-lived workloads where tokens are generated in batches and have a configurable TTL (time-to-live). They cannot be renewed or revoked individually, making them ideal for CI/CD pipelines that need thousands of tokens per day for jobs lasting at most 5 minutes.

Exam trap

The Vault exam often tests the distinction between token types by emphasizing 'short-lived' and 'non-renewable'—candidates may confuse batch tokens with periodic tokens because both can have short TTLs, but periodic tokens are renewable and individually revocable, while batch tokens are not.

How to eliminate wrong answers

Option A is wrong because orphan tokens are not a standard Vault token type; the term refers to tokens that have lost their parent due to revocation, which is not a design pattern for generating short-lived tokens. Option B is wrong because service tokens are long-lived tokens used for machine-to-machine authentication and are renewable and revocable individually, which contradicts the requirement for non-renewable, non-revocable tokens. Option D is wrong because periodic tokens are designed to be renewed automatically at set intervals and are revocable individually, making them unsuitable for short-lived, non-renewable use cases.

Practice this question →
6
Multi-Selectmedium

Which TWO of the following are true about token accessors?

Select 2 answers
A.Accessors are the token value
B.Accessors should be used in audit logs instead of token values
C.Accessors are unique identifiers for tokens
D.Accessors can be used to renew the token
AnswersB, C

Token accessors are one-way hashes derived from token values, so they uniquely identify a token without exposing its secret. Logging accessors satisfies the audit requirement to trace token issuance and use while preventing credential leakage, since the original token cannot be reconstructed from the hash.

Why this answer

Token accessors are designed to be used in audit logs as a safe alternative to the actual token value. This prevents sensitive token data from being exposed in logs while still allowing correlation of events to a specific token. Option C is correct because an accessor is a unique identifier that references a token without revealing the token's secret value.

Exam trap

A common misconception is that an accessor is the token value itself or that it can perform token lifecycle operations like renewal, when in reality it is only a read-only reference for identification and auditing.

Practice this question →
7
MCQmedium

An application team is using a batch token to authenticate to Vault for a long-running data processing job. The token was created with a TTL of 8 hours and no explicit max TTL. After 4 hours, the application attempts to renew the token but receives an error. What is the most likely reason for the renewal failure?

A.The token's max TTL is less than 8 hours.
B.The token's TTL has already expired.
C.The token is a batch token, which cannot be renewed.
D.The token does not have a renewable flag set.
AnswerC

Batch tokens are designed to be lightweight and stateless; they do not support renewal. Once issued, they remain valid until their TTL expires, but they cannot be extended. In this scenario, the application's attempt to renew a batch token fails because batch tokens are inherently non-renewable, regardless of the remaining TTL.

Why this answer

Batch tokens are a special type of Vault token that are not persisted to storage and are designed for high scalability. They are not renewable, meaning they cannot be extended beyond their initial TTL. In this scenario, the application's attempt to renew the batch token fails because batch tokens do not support renewal, regardless of the remaining TTL.

Exam trap

The trap here is assuming that any token with a TTL can be renewed if it has not expired, but batch tokens are an exception.

Practice this question →
8
MCQmedium

A token has the properties shown in the exhibit. A user attempts to use this token to write a secret to 'secret/data/myapp'. The token fails with a permission denied error. What is the most likely cause?

A.The token has an explicit max TTL of 0s, which prevents write operations.
B.The token's policies do not grant write capability on the target path.
C.The token is a service token but the write operation requires a batch token.
D.The token is orphaned, so it cannot be used for write operations.
AnswerB

The token’s attached policies lack a `create` or `update` capability on `secret/data/myapp`, so Vault denies the write despite valid authentication. Vault authorises every request by evaluating the token’s policies against the exact path and operation; without a matching rule granting write, the request fails with permission denied.

Why this answer

The token's policies define the access control rules for paths in Vault. Since the user received a permission denied error when attempting to write to 'secret/data/myapp', the most likely cause is that the token's attached policies do not include a 'write' or 'create' capability on that specific path. Policies are evaluated based on the path and the requested operation, and without the appropriate capability, the request is denied regardless of other token properties.

Exam trap

HashiCorp often tests the misconception that token properties like TTL, type, or parentage affect permissions, when in reality only the attached policies determine what operations a token can perform on a given path.

How to eliminate wrong answers

Option A is wrong because a max TTL of 0s does not prevent write operations; it means the token has no explicit maximum lifetime, or it may be set to use the system default, but TTL does not affect permission to write. Option C is wrong because both service tokens and batch tokens can perform write operations if their policies allow it; the token type does not inherently restrict write capability. Option D is wrong because an orphaned token (one with no parent) can still be used for write operations as long as its policies grant the required capabilities; being orphaned does not revoke permissions.

Practice this question →
9
MCQmedium

A user's token was revoked by an administrator, but the user can still read secrets from a KV v1 secrets engine. What is the most likely reason?

A.The token had sudo capabilities on the path
B.The token was a root token and cannot be revoked
C.The token was an orphan token and therefore immune to revocation
D.The secrets were from a KV v1 engine that does not use leases
AnswerD

Correct. KV v1 does not use leases, so after reading a secret, the client may cache it or the engine does not require a valid token for subsequent reads of the same data. Token revocation only stops new lease-based operations, but KV v1 reads are not lease-based.

Why this answer

KV v1 secrets engines do not issue leases for read operations, so token revocation does not affect access to previously read secrets. The token itself was revoked, but the user's ability to read secrets from KV v1 persists because the engine does not enforce lease-based expiration or revocation checks on stored data.

Exam trap

The trap here is that candidates assume token revocation immediately blocks all access to any previously read secrets, but KV v1's lack of leases means the client can continue using cached data without needing a valid token for the read operation itself.

How to eliminate wrong answers

Option A is wrong because sudo capabilities on a path allow a token to bypass ACL path restrictions, but they do not make a token immune to revocation; a revoked token cannot perform any operations regardless of sudo privileges. Option B is wrong because root tokens can be revoked; they are not immune to revocation, though they have unrestricted access until explicitly revoked. Option C is wrong because orphan tokens are not immune to revocation; they lack a parent token in the lineage, but they can still be revoked by an administrator or through token revocation operations.

Practice this question →
10
MCQmedium

A platform team runs a nightly batch job that authenticates to Vault with the AppRole auth method and receives a token with a 30-minute TTL. The job occasionally overruns and hits 'permission denied' errors mid-run. The team wants the token to stay valid as long as the job keeps working, without the job re-authenticating. Which token attribute should the AppRole role be configured with when the token is issued?

A.Set token_explicit_max_ttl to 24h on the AppRole role
B.Set token_period to 30m on the AppRole role so the token is a periodic token
C.Increase the token_ttl to 24h and disable renewal on the AppRole role
D.Set token_no_default_policy to true on the AppRole role
AnswerB

A periodic token has no absolute lifetime cap and can be renewed indefinitely as long as it is renewed before each period elapses. Setting token_period on the AppRole role issues tokens of that period, letting the batch job renew continuously without re-authenticating. This directly matches the requirement that the token stay valid as long as the job keeps working.

Why this answer

The requirement is a token that stays valid as long as it keeps being renewed, which is exactly the behavior of a periodic token. Configuring token_period on the AppRole role makes issued tokens periodic, so the nightly job can renew indefinitely before each period lapses instead of being cut off by a fixed TTL or an absolute maximum lifetime.

Exam trap

The trap here is assuming that a longer token_ttl or an explicit_max_ttl makes a token effectively unlimited, when only a periodic token removes the absolute lifetime cap.

Practice this question →
11
MCQeasy

Refer to the exhibit. A token has this policy. Which action can the token perform?

A.Update a secret at "secret/data/engineering/config"
B.Read a secret at "secret/data/engineering/db-pass"
C.List secrets at "secret/data/finance/"
D.Delete a secret at "secret/data/finance/budget"
AnswerB

The policy grants read capability on the secret/data/engineering/db-pass path, so the token can retrieve that secret's data. Reading requires the read capability on the exact path, which this policy explicitly permits, satisfying the stem's action requirement.

Why this answer

The token's policy grants 'read' capability on 'secret/data/engineering/*' via the 'data' path. Since 'secret/data/engineering/db-pass' falls under that wildcard, the token can read it. The policy does not allow 'update', 'list', or 'delete' actions on the specified paths.

Exam trap

A common misconception is that a wildcard path like 'secret/data/engineering/*' implies all capabilities (create, read, update, delete, list) on that path, when in fact only the explicitly listed capabilities are allowed.

How to eliminate wrong answers

Option A is wrong because the policy only grants 'read' capability on 'secret/data/engineering/*', not 'update' or 'create' (which require 'create' or 'update' capabilities). Option C is wrong because listing secrets at 'secret/data/finance/' requires 'list' capability on that path, which the policy does not grant. Option D is wrong because deleting a secret at 'secret/data/finance/budget' requires 'delete' capability on that path, which the policy does not grant.

Practice this question →
12
MCQmedium

A platform team uses Vault to issue short-lived tokens to external contractors. The security policy requires that every contractor token must be traceable back to the contractor's identity, and that a token can never be renewed beyond its initial TTL. The team creates tokens with the default settings. A contractor later reports that their token stopped working after its TTL expired, but they were able to renew it several times before that. Which token parameter should the team have configured to enforce the policy?

A.Set the token's explicit max TTL to the same value as its initial TTL.
B.Create the token with the display-name parameter set to the contractor's identity and an explicit max TTL equal to the initial TTL.
C.Set the token's period to a fixed value and enable renewal.
D.Create the token with the no-default-policy option and attach a custom policy.
AnswerB

The display-name parameter allows operators to associate a human-readable identity with the token, satisfying traceability. Setting an explicit max TTL equal to the initial TTL ensures that even if the token is renewed, it cannot be renewed past that maximum lifetime. Together, these settings enforce both the traceability and the non-renewal-beyond-initial-TTL requirements described in the policy.

Why this answer

To enforce the policy, the token must be traceable to the contractor and must not be renewable beyond its initial TTL. The display-name parameter provides traceability by linking the token to a specific identity. An explicit max TTL set to the same value as the initial TTL caps the total lifetime, so renewals cannot extend it.

Other parameters like period or no-default-policy do not satisfy both requirements simultaneously.

Exam trap

The trap here is assuming that setting a max TTL alone satisfies traceability, or that periodic tokens can be used to enforce a hard lifetime limit.

Practice this question →
13
MCQeasy

A Vault administrator needs to delegate the ability to create tokens to a user without granting full administrative privileges. Which token type should the administrator create for the user to allow them to create tokens with specific policies?

A.A batch token
B.A service token with a policy that includes the 'create' capability on the 'auth/token/create' path.
C.An orphan token
D.A root token
AnswerB

A service token is a standard Vault token that can be assigned policies. By attaching a policy that allows the 'create' capability on the 'auth/token/create' path, the user can create tokens with specific policies (as allowed by the policy). This delegates token creation without granting full administrative privileges, adhering to least privilege.

Why this answer

Delegating token creation requires a token that can be assigned policies allowing the creation of tokens. A service token with a policy that permits the 'create' capability on the token creation endpoint enables the user to create tokens with specified policies. This approach follows the principle of least privilege by limiting the user's abilities to exactly what is needed.

Exam trap

The trap here is assuming that any token type can create tokens, but batch tokens cannot have children and root tokens are too privileged.

Practice this question →
14
MCQmedium

Which token type should be used for short-lived credentials that do not need to be renewed?

A.Service tokens
B.Periodic tokens
C.Batch tokens
D.Orphan tokens
AnswerC

Batch tokens are lightweight, non-renewable credentials designed for short-lived, ephemeral workloads such as CI jobs. They cannot be renewed, so they satisfy the stem's constraint of credentials that do not need renewal, unlike service tokens, which support renewal and carry heavier storage overhead.

Why this answer

Batch tokens in HashiCorp Vault are designed for short-lived, non-renewable credentials. They have a fixed Time-to-Live (TTL) and cannot be renewed or revoked individually; once the TTL expires, the token is automatically invalidated. This makes them ideal for batch jobs or one-time tasks where credential renewal is unnecessary.

Exam trap

A common pitfall is confusing periodic tokens (which are renewable) with batch tokens (which are non-renewable), as both can have a short TTL but differ fundamentally in renewal behavior.

How to eliminate wrong answers

Option A is wrong because service tokens are long-lived and can be renewed, making them unsuitable for short-lived credentials that do not need renewal. Option B is wrong because periodic tokens have a renewable TTL and are intended for long-running processes that require periodic re-authentication, not for non-renewable short-lived use. Option D is wrong because orphan tokens are tokens that have lost their parent due to revocation but still function; they are not a token type designed for short-lived or non-renewable credentials.

Practice this question →
15
MCQhard

A security engineer is troubleshooting why a Vault token cannot be renewed. The token was created with a TTL of 4 hours and is renewable. After 2 hours, the engineer attempts to renew it using `vault token renew <token>` but receives the error: "lease not found". The engineer confirms the token is still valid and not expired. Which of the following is the most likely cause?

A.The token's TTL has been exceeded, causing Vault to delete the lease record.
B.The token's lease was revoked or expired, possibly due to a parent token revocation or lease cleanup, even though the token itself remains valid.
C.The token was created with the -no-default-policy flag, which disables renewal.
D.The token was created with a period but no explicit max TTL, and the period has not yet elapsed.
AnswerB

In Vault, tokens and their leases are related but distinct. A token can remain valid while its lease record is removed due to parent revocation, manual lease revocation, or a bug in lease management. The "lease not found" error indicates that Vault cannot find the lease to renew. This can happen if the token's parent was revoked, causing the child token's lease to be cleaned up, but the token itself might still be usable until its TTL expires. The engineer should check for revoked parent tokens or lease revocation events.

Why this answer

The "lease not found" error during token renewal typically means the lease record for the token is no longer present in Vault's storage. This can occur if the token's parent was revoked, which cascades to revoke child tokens and their leases, or if the lease was manually revoked or expired due to a separate lease ID. The token itself may still be within its TTL and appear valid, but without a lease, renewal is impossible.

The engineer should investigate recent revocations or lease cleanup operations.

Exam trap

The trap here is assuming that a valid token always has a renewable lease, but leases can be revoked independently, leading to "lease not found" even when the token is not expired.

Practice this question →
16
MCQeasy

What is the purpose of a token's "period" attribute?

A.It is the starting TTL for a periodic token and is refreshed on each renewal.
B.It defines the maximum lifetime of a token.
C.It defines the number of uses before token expires.
D.It is the time after which the token is revoked if not used.
AnswerA

A periodic token's period sets the initial TTL and is reset to that value on every renewal, so the token survives indefinitely provided it is renewed within each window. Without renewal it expires, satisfying the periodic-token behaviour the question describes.

Why this answer

The 'period' attribute in Vault tokens defines the starting TTL (time-to-live) for a periodic token. When a periodic token is renewed, its TTL is reset to this period value, allowing the token to exist indefinitely as long as it is renewed before the period expires. This is distinct from a non-periodic token, which has a fixed maximum TTL that cannot be extended beyond its original lifetime.

Exam trap

The Vault exam often tests the distinction between 'period' and 'explicit_max_ttl' — candidates mistakenly think 'period' sets a maximum lifetime, when in fact it sets a renewable interval that allows indefinite token life if renewed on time.

How to eliminate wrong answers

Option B is wrong because the 'period' attribute does not define the maximum lifetime of a token; that is the role of the 'explicit_max_ttl' attribute or the system's default max TTL. Option C is wrong because Vault tokens do not have a 'number of uses' attribute; token usage is controlled by TTL and renewal policies, not a use count. Option D is wrong because the 'period' attribute does not cause revocation after a period of inactivity; that behavior is associated with the 'explicit_max_ttl' or 'ttl' attributes, and Vault does not automatically revoke tokens based on idle time unless configured with a specific TTL.

Practice this question →
17
MCQeasy

Where can you view a list of all active tokens in Vault?

A.There is no way to list all tokens.
B.`vault token list`
C.`vault list auth/token/accessors`
D.Both A and B
AnswerC

`vault list auth/token/accessors` queries the token store's accessor index, returning every active token's accessor ID without exposing the tokens themselves. This directly satisfies the stem's requirement to view all active tokens, since accessors enumerate the full set of live tokens in Vault's token auth method.

Why this answer

`vault list auth/token/accessors` retrieves token accessors, which are unique identifiers for active tokens. While you cannot directly list tokens for security reasons, listing accessors is the standard way to view active tokens. Option A is false because there is a way to list tokens via their accessors.

Option B is false because `vault token list` is not a valid command. Option D is false because both A and B are not true.

Exam trap

Candidates often believe there is no way to list tokens or that `vault token list` is valid. The actual command is `vault list auth/token/accessors`, which returns accessors, not the tokens themselves.

How to eliminate wrong answers

Option A is wrong because it is actually correct in stating there is no way to list all active tokens (the token values themselves), but the question asks for the correct answer among the options, and since A is part of the correct pair, it is not wrong in isolation. Option B is wrong because `vault token list` is not a valid Vault CLI command; the correct command to list token accessors is `vault list auth/token/accessors`. Option C is wrong because `vault list auth/token/accessors` lists token accessors, not the active tokens themselves, and the question asks for viewing a list of all active tokens, which is not possible.

Practice this question →
18
MCQeasy

A DevOps engineer needs to create a token that can only read secrets under the path 'secret/engineering'. What is the recommended approach?

A.Create a token with a short TTL so it expires quickly
B.Create a token with the default policy only
C.Use the root token and restrict usage with a low TTL
D.Create a policy that allows read on secret/engineering/* and attach it to the token
AnswerD

A least-privilege policy granting read on secret/engineering/* restricts the token to exactly that path subtree, then attaching it to the token scopes access accordingly. This satisfies the read-only, single-path constraint without granting broader capabilities elsewhere in the secrets engine.

Why this answer

Vault's recommended approach for granting least-privilege access is to create a policy that explicitly defines the allowed actions and paths, then attach that policy to the token. A policy with `path "secret/engineering/*" { capabilities = ["read"] }` ensures the token can only read secrets under that specific path, adhering to the principle of least privilege.

Exam trap

In Vault exams, a common trap is confusing time-based restrictions with proper policy-based access control. TTL limits duration but does not restrict which paths a token can access; a policy is required for that.

How to eliminate wrong answers

Option A is wrong because a short TTL only limits the token's lifespan, not its permissions; the token could still have excessive privileges (e.g., root or default policy) and read other paths while active. Option B is wrong because the default policy grants broad read access to many paths (like `secret/*`), which would allow reading secrets outside `secret/engineering`. Option C is wrong because using a root token, even with a low TTL, violates security best practices—root tokens have unrestricted superuser access and should never be used for routine operations; a low TTL does not restrict the token's capabilities.

Practice this question →
19
MCQhard

A token is created with policies 'default' and 'web-app'. Later, a parent token's policy is updated to add 'logging'. The child token's policies are not updated. What will happen when the child token is used?

A.The child token will still have only 'default' and 'web-app' policies
B.The child token will be automatically renewed to pick up the new policy
C.The child token will automatically gain the 'logging' policy
D.The child token will be invalidated due to policy mismatch
AnswerA

Consul tokens inherit a copy of their parent's policies at creation time; later changes to the parent do not propagate. The child therefore retains only 'default' and 'web-app', and the newly added 'logging' policy never applies to it.

Why this answer

In Vault, child tokens inherit the policies of their parent at the time of creation, but subsequent changes to the parent's policies do not propagate to existing child tokens. The child token retains its original policy set ('default' and 'web-app') because policies are evaluated based on the token's own metadata, not the parent's current state. This behavior is by design to ensure token immutability and prevent unintended privilege escalation.

Exam trap

A common misconception is that policy changes to a parent token propagate to existing child tokens, similar to group membership updates in some systems. However, Vault decouples parent and child policies after token creation; child tokens retain their original policy set indefinitely.

How to eliminate wrong answers

Option B is wrong because Vault does not automatically renew or update child tokens when parent policies change; token renewal only extends the TTL and does not alter policy associations. Option C is wrong because policy inheritance is a one-time snapshot at token creation; the child token cannot gain new policies without explicit re-issuance or a policy update applied directly to the child. Option D is wrong because there is no policy mismatch check that invalidates a child token; the child remains valid with its original policies as long as it has not expired or been revoked.

Practice this question →
20
MCQhard

An admin creates a token with TTL=48h and explicit_max_ttl=120h. The token is renewed every 24h. After 10 days, will the token still be valid?

A.Yes, because TTL refreshes to 48h on each renewal.
B.Yes, if renewed before TTL expires, it can persist indefinitely.
C.No, because the total lifetime cannot exceed the explicit_max_ttl of 120h.
D.No, because tokens cannot be renewed more than 5 times.
AnswerC

Vault caps every token's cumulative lifetime at explicit_max_ttl, regardless of how often it is renewed. Renewals extend the TTL but cannot push total age past 120h, so after 10 days (240h) the token is long expired.

Why this answer

The token's total lifetime is capped by the `explicit_max_ttl` of 120 hours (5 days). Even though the token is renewed every 24 hours, the cumulative time since creation cannot exceed the explicit maximum TTL. After 10 days (240 hours), the token will have long surpassed the 120-hour limit and will be invalid.

Exam trap

In HashiCorp Vault, the explicit_max_ttl sets an absolute upper bound on token lifetime regardless of renewals. Candidates often mistakenly think that renewals reset the clock, but the total time since token creation cannot exceed explicit_max_ttl.

How to eliminate wrong answers

Option A is wrong because the TTL refreshes to 48h on each renewal, but the explicit_max_ttl overrides this behavior and limits the total lifetime from creation, not per-renewal. Option B is wrong because indefinite renewal is not possible when an explicit_max_ttl is set; the token will be revoked once the total lifetime exceeds that limit. Option D is wrong because Vault does not impose a hard limit on the number of renewals; the constraint is based on time, not count.

Practice this question →
21
MCQhard

An application uses a Vault token with a policy that grants read access to secrets. The security team wants to ensure that if the application is compromised, the token cannot be used after a certain time even if the attacker has the token. What is the best approach?

A.Use a revocation script that runs periodically
B.Set explicit max TTL on the token
C.Use a periodic token with a long period
D.Set a short TTL on the token and do not allow renewal
AnswerD

A short TTL with renewal disabled forces Vault to revoke the token automatically once it expires, so a stolen token becomes useless after that window regardless of attacker possession. This directly satisfies the requirement that compromise cannot extend token usability.

Why this answer

Setting a short TTL on the token and disallowing renewal ensures that the token automatically expires after a fixed, short duration. Even if an attacker compromises the token, they cannot extend its lifetime, limiting the window of exposure. This directly meets the security requirement of preventing token use beyond a certain time without relying on external revocation mechanisms.

Exam trap

HashiCorp often tests the distinction between TTL and renewal behavior; the trap here is that candidates confuse 'max TTL' (which still allows renewal) with 'short TTL + no renewal' (which enforces absolute expiry), leading them to incorrectly select Option B.

How to eliminate wrong answers

Option A is wrong because a revocation script that runs periodically introduces a window of vulnerability between revocation checks; the token remains valid until the script executes, and the script itself adds operational complexity and potential failure points. Option B is wrong because setting an explicit max TTL on the token does not prevent the token from being renewed up to that max TTL; if renewal is allowed, an attacker could keep the token alive for the entire max TTL duration, which may be longer than desired. Option C is wrong because a periodic token with a long period is designed for long-lived, renewable access; it can be renewed indefinitely as long as the parent policy allows, which contradicts the requirement to limit token lifetime after compromise.

Practice this question →
22
MCQeasy

An administrator needs to revoke a token but wants to keep all child tokens that were created using this token as the parent. Which revocation operation should be used?

A.Orphan token revocation
B.Immediate token revocation
C.Sudo token revocation
D.Self token revocation
AnswerA

Orphan revocation removes the token from the hierarchy but preserves children.

Why this answer

Orphan token revocation is the correct operation because it revokes the parent token while preserving all child tokens that were created using it. This is achieved by removing the parent token's accessor and its associated policies, but leaving the child tokens' hierarchy intact so they continue to function independently. In Vault, this is done via the `vault token revoke -orphan` command or the corresponding API endpoint.

Exam trap

A common trap in Vault exams is confusing 'orphan' revocation with 'immediate' revocation. Candidates may incorrectly assume that all token revocations are recursive, forgetting that the -orphan flag specifically preserves child tokens. Some may also mistakenly think 'sudo' revocation is required for this operation.

How to eliminate wrong answers

Option B (Immediate token revocation) is wrong because it revokes the token and all its child tokens recursively, which would delete the child tokens the administrator wants to keep. Option C (Sudo token revocation) is wrong because 'sudo' is not a valid revocation operation in Vault; it refers to a policy capability, not a token revocation mode. Option D (Self token revocation) is wrong because it only revokes the token used to authenticate the request (the caller's own token), not a specific parent token while preserving children.

Practice this question →
23
MCQmedium

A DevOps team is using Vault tokens for authentication in CI/CD pipelines. They notice that tokens are often expired before the pipeline completes, causing failures. Which Vault feature should they use to address this without manual intervention?

A.Use batch tokens for better performance
B.Use periodic tokens with a short period and allow renewal
C.Create orphan tokens so they don't expire with the parent
D.Increase the default TTL on the token auth method
AnswerB

Periodic tokens are exempt from the standard max TTL: they carry no absolute expiry and can be renewed indefinitely, provided each renewal occurs within the period. This satisfies the stem's requirement for unattended pipelines, where long-running jobs outlive fixed-TTL tokens and no operator is present to re-authenticate.

Why this answer

Periodic tokens are designed for long-running processes like CI/CD pipelines. They have no maximum TTL and can be renewed indefinitely as long as the renewal occurs before the current token's TTL expires. By using a periodic token with a short period and enabling automatic renewal in the pipeline, the token stays valid without manual intervention, solving the expiration issue.

Exam trap

HashiCorp often tests the misconception that increasing TTL or using orphan tokens solves indefinite expiration, but the key is that periodic tokens are the only token type designed for renewable, long-lived use without a hard upper limit.

How to eliminate wrong answers

Option A is wrong because batch tokens are stateless and cannot be renewed; they have a fixed TTL and are unsuitable for long-running pipelines. Option C is wrong because orphan tokens are detached from their parent but still have a finite TTL and must be renewed; they do not inherently prevent expiration. Option D is wrong because increasing the default TTL on the token auth method only extends the initial validity but does not allow indefinite renewal; the token will still eventually expire, and manual intervention would be needed to re-authenticate.

Practice this question →
24
MCQeasy

A company runs multiple microservices in a Kubernetes cluster. Each microservice authenticates to Vault using a service token created via the token auth method. The tokens are created with a default TTL of 72h, a max TTL of 168h, and renewable set to true. The services are configured to renew their tokens when the remaining TTL drops below 24h. Recently, some tokens have been expiring prematurely, causing service outages. Upon investigation, you find that the expired tokens were created with a role that includes explicit_max_ttl = 72h. The services see the TTL decreasing normally, but then it jumps to zero even though the services attempted renewal. What is the most likely cause and correct action?

A.Configure the services to renew the token when TTL drops below 48h.
B.Remove the explicit_max_ttl setting from the role or set it to 0.
C.Increase the default TTL on the token auth mount to 168h.
D.Set max_ttl on the role to 72h.
AnswerB

explicit_max_ttl caps a token's total lifetime regardless of renewal, so tokens die at 72h even though renewal is attempted. Removing it or setting it to 0 lets the role's max_ttl govern, satisfying the stem's premature-expiry constraint.

Why this answer

The `explicit_max_ttl` setting on the role overrides the token's renewable property. When a token has an `explicit_max_ttl` of 72h, it cannot be renewed beyond that absolute lifetime, regardless of the `renewable = true` setting. The services attempt renewal, but Vault enforces the hard limit, causing the TTL to jump to zero at the 72-hour mark.

Removing `explicit_max_ttl` or setting it to 0 allows the token to be renewed up to the system's `max_ttl` (168h), preventing premature expiration.

Exam trap

In HashiCorp Vault, the distinction between `max_ttl` (which can be extended by renewal up to the mount's limit) and `explicit_max_ttl` (which is an absolute, non-renewable cap) is crucial. Candidates often overlook that `explicit_max_ttl` overrides the renewable property, causing premature token expiration.

How to eliminate wrong answers

Option A is wrong because increasing the renewal threshold to 48h does not address the root cause; the token will still hit the `explicit_max_ttl` hard limit and expire at 72h regardless of when renewal is attempted. Option C is wrong because increasing the default TTL on the token auth mount to 168h does not override the role's `explicit_max_ttl` of 72h; the explicit maximum takes precedence and still caps the token's lifetime. Option D is wrong because setting `max_ttl` on the role to 72h would actually enforce the same hard limit as `explicit_max_ttl`, making the problem worse or identical, not fixing it.

Practice this question →
25
MCQhard

Refer to the exhibit. A developer reports that a token they created using `vault token create -policy=my-policy -ttl=2h` is no longer working after 1 hour. The token lookup output shows the token details. What is the most likely cause?

A.The token's max_ttl was set to 1h when created, and the token reached its max_ttl.
B.The token has num_uses set to 0, meaning it can only be used once.
C.The token is a service token and cannot be renewed.
D.The token is an orphan token and requires the parent token to be valid.
AnswerA

A token's lifetime is capped by max_ttl regardless of the requested ttl. If max_ttl was set to 1h at creation, the token expires after one hour even though ttl was 2h, matching the reported failure and the lookup output.

Why this answer

The token was created with a `-ttl=2h` but the token lookup output shows `max_ttl=1h`. The `max_ttl` is an upper limit enforced by the token's configuration or the system's maximum TTL setting. Even though the requested TTL was 2 hours, the token's effective lifetime is capped by the lower of the two values, so it expired after 1 hour.

Exam trap

HashiCorp often tests the distinction between `ttl` and `max_ttl`, where candidates mistakenly assume the token will last for the full `ttl` value without checking the overriding `max_ttl` limit.

How to eliminate wrong answers

Option B is wrong because `num_uses` set to 0 means the token has unlimited uses, not that it can be used only once. Option C is wrong because service tokens can be renewed unless explicitly configured with `explicit_max_ttl` or a non-renewable flag; the issue here is TTL expiration, not renewability. Option D is wrong because orphan tokens do not depend on a parent token for validity; they are standalone tokens that are not revoked when the parent is revoked.

Practice this question →
26
Multi-Selecteasy

Which TWO of the following are valid uses of a token accessor? (Select exactly 2 options.)

Select 2 answers
A.Wrap the token
B.Create a child token
C.Renew the token
D.Lookup token properties
E.Revoke the token
AnswersD, E

A token accessor is a reference handle that lets you query a token's metadata, such as its policies, TTL, and creation time, without exposing the token itself. Lookup operations accept the accessor in place of the token ID.

Why this answer

A token accessor is a special value returned alongside a token in HashiCorp Vault that allows limited operations on that token without possessing the token itself. Option D is correct because the accessor can be used with commands like 'vault token lookup -accessor' to retrieve the token's properties (policies, TTL, metadata) without exposing the token string. Option E is correct because the accessor enables revoking the token via 'vault token revoke -accessor', which is a key use case for auditing and cleanup without handling the raw token.

Options A, B, and C are not valid uses: wrapping a token is done via response wrapping, creating a child token requires the parent token itself (or a token with appropriate permissions), and renewing a token requires the token value, not just its accessor.

Exam trap

Candidates often mistakenly think that a token accessor can be used for all token management operations, when in reality it is strictly limited to lookup and revocation, and cannot be used for wrapping, renewal, or child token creation.

Practice this question →
27
MCQhard

An administrator wants to audit token usage without exposing the actual token IDs to auditors. Which approach should they use?

A.Enable audit logging without any modifications
B.Use token accessors in audit logs
C.Use the token lookup API for each audit event
D.Use response wrapping to encapsulate tokens
AnswerB

Token accessors are non-secret references that map to tokens without exposing them, so audit logs can record accessor values for usage tracking. Auditors correlate activity while the actual token IDs remain hidden, meeting the stem's constraint.

Why this answer

Token accessors are non-sensitive, randomly generated identifiers that are mapped one-to-one with actual Vault tokens. By logging the accessor instead of the token ID, administrators can audit token usage (e.g., lookup, renewal, revocation) without exposing the token itself, which could be used to authenticate. This approach satisfies the requirement of auditing without compromising security.

Exam trap

The trap here is that candidates confuse token accessors with response wrapping, thinking both are used to 'hide' tokens, but response wrapping is a delivery mechanism, not an audit anonymization feature.

How to eliminate wrong answers

Option A is wrong because enabling audit logging without modifications logs the actual token IDs, which directly exposes sensitive credentials to auditors. Option C is wrong because using the token lookup API for each audit event would require the token ID to be present in the audit context, defeating the purpose of hiding it, and it is not a scalable or real-time auditing mechanism. Option D is wrong because response wrapping is used to securely deliver secrets or tokens to a client via a one-time unwrap operation, not to anonymize token IDs in audit logs.

Practice this question →
28
MCQeasy

A token with the above policy attempts to look up its own token by calling the accessor endpoint. What will happen?

A.The operation succeeds because the token can read its own token
B.The operation fails with a permission denied error
C.The operation succeeds because sudo allows all accessor operations
D.The operation fails because the token lacks any capabilities
AnswerB

The token's policy lacks the `read` capability on the token accessor path, so the lookup is rejected before any data returns. Vault evaluates the request against the policy attached to the token itself, and without that explicit permission the accessor endpoint denies the call.

Why this answer

Vault's token accessor endpoint requires the 'read' capability on the token's accessor path (auth/token/accessor or the token's own accessor path). A token cannot use its own accessor to read itself unless it explicitly has that capability; by default, tokens lack the capability to read their own accessor, so the request is denied. The policy shown does not grant accessor read rights, resulting in a permission denied error.

Exam trap

VA-003 often tests the misconception that a token can always read its own accessor, confusing token ownership with ACL permission.

How to eliminate wrong answers

Option A is wrong because a token having an accessor does not automatically grant it permission to read that accessor; capabilities must be explicitly granted in the policy. Option C is wrong because sudo (root-protected) capabilities are not implied by token ownership and are not granted by default; sudo allows operations on root-protected paths, not blanket accessor access. Option D is wrong because the token does have some capabilities (otherwise it couldn't authenticate at all), but it specifically lacks the accessor read capability, so the failure is due to missing that specific permission, not total lack of capabilities.

Practice this question →
29
MCQhard

An operator creates a batch token for a one-time database migration. The migration finishes, and the operator wants the token to be unusable immediately, even before its TTL expires, and wants to confirm the token no longer appears in the token list. Which Vault command accomplishes this?

A.vault token renew <token_id>
B.vault token revoke <token_id>
C.vault token revoke -self
D.vault token lookup <token_id>
AnswerB

vault token revoke with the specific token ID immediately invalidates that token and any child tokens it created, independent of remaining TTL. After revocation the token disappears from token list and any request using it returns permission denied. This precisely meets the requirement to make the migration token unusable right away and confirm its removal.

Why this answer

Revocation is the only operation that immediately invalidates a token before its TTL elapses. Using vault token revoke with the specific token ID destroys that token and its descendants, so subsequent requests fail and the token no longer appears in token listings. Renewal extends life, self-revocation targets the caller, and lookup is read-only.

Exam trap

The trap here is confusing token renewal with token revocation, or using -self and accidentally revoking the operator's own session instead of the target token.

Practice this question →
30
MCQhard

Refer to the exhibit. A user attempts to renew the token after 20 hours. What will happen?

A.The renewal will fail because the token has exceeded its explicit max TTL.
B.The token will be renewed for another 12h and can be renewed indefinitely.
C.The token will be renewed for 12h, but the total lifetime cannot exceed 24h.
D.The token will be renewed for another 4h, after which it will expire.
AnswerD

Vault's renewal increments the TTL by the token's original period, not to the full max. With 4h remaining before hitting the max TTL ceiling, the token renews for 4h and then expires, since it cannot exceed that limit.

Why this answer

The token was created with a TTL of 12h and an explicit max TTL of 24h. After 20 hours, only 4 hours remain before the max lifetime is reached, so Vault renews the token for the remaining 4h and then it expires. Vault caps any renewal at the explicit max TTL, so the token cannot be extended beyond 24h total.

Exam trap

The trap here is confusing the renewable TTL (12h) with the explicit max TTL (24h) — candidates often assume renewal always grants the full TTL again, ignoring the hard cap.

How to eliminate wrong answers

Option A is wrong because renewal does not fail outright at 20h — the token is still within its 24h max TTL and can be renewed for the remaining time. Option B is wrong because Vault tokens with an explicit max TTL cannot be renewed indefinitely; the max TTL is a hard cap. Option C is wrong because the renewal is limited to the remaining 4h (24h − 20h), not a full 12h period.

Practice this question →
31
MCQmedium

An operator runs `vault token create -policy=app -ttl=1h -explicit-max-ttl=2h` and then checks the token's properties with `vault token lookup`. The token is renewable. A developer asks whether the token can be kept alive indefinitely by renewing it every 30 minutes. What should the operator tell the developer?

A.The token can be renewed indefinitely because the default max TTL of 32 days overrides the explicit max TTL.
B.The token can be renewed indefinitely because it has a TTL and is renewable.
C.The token can be renewed only until its explicit max TTL of 2 hours is reached; after that, renewal fails and the token expires.
D.The token cannot be renewed at all because an explicit max TTL disables renewal.
AnswerC

The explicit max TTL sets a hard limit on the token's total lifetime. Even though the token is renewable, Vault will not allow renewal beyond that 2-hour window. The operator should tell the developer that renewing every 30 minutes works only until the explicit max TTL is reached; after that, the token cannot be renewed and must be replaced. This is the intended behavior for bounding token lifetime.

Why this answer

The token was created with an explicit max TTL, which acts as a hard cap on its total lifetime. Renewals are permitted only while the token's age is less than the explicit max TTL. Once that limit is reached, Vault refuses further renewals and the token expires.

The developer cannot keep the token alive indefinitely by renewing it; they must obtain a new token. This behavior ensures that tokens cannot outlive their configured maximum lifetime.

Exam trap

The trap here is assuming that a renewable token can always be renewed forever, overlooking that an explicit max TTL creates an absolute expiration ceiling.

Practice this question →
32
MCQmedium

A developer needs to manually revoke a token but only knows its accessor. Which Vault API endpoint can be used to revoke the token using only the accessor?

A.auth/token/accessors
B.auth/token/renew-accessor
C.auth/token/revoke-accessor
D.auth/token/revoke
AnswerC

Vault's auth/token/revoke-accessor endpoint revokes a token by its accessor rather than the token itself, which is exactly the identifier available here. The accessor is a non-secret reference, so revocation succeeds without needing the original token value.

Why this answer

The `auth/token/revoke-accessor` endpoint is specifically designed to revoke a token when only its accessor is known. The accessor is a non-sensitive identifier that Vault uses to perform token operations without exposing the actual token ID, making this endpoint the appropriate choice for revocation by accessor.

Exam trap

HashiCorp Vault often tests the distinction between endpoints that operate on the token ID versus those that operate on the accessor, and the trap here is that candidates might confuse `auth/token/revoke` (which needs the token ID) with `auth/token/revoke-accessor` (which uses the accessor), or think that listing accessors (Option A) is sufficient for revocation.

How to eliminate wrong answers

Option A is wrong because `auth/token/accessors` is used to list token accessors, not to revoke a token. Option B is wrong because `auth/token/renew-accessor` is used to renew a token's lease using its accessor, not to revoke it. Option D is wrong because `auth/token/revoke` requires the actual token ID or a token's accessor via a different endpoint, and using it with only an accessor would fail or require additional parameters.

Practice this question →
33
MCQeasy

A Vault user wants to check the capabilities of their token on a specific path. Which command should they use?

A.vault token list
B.vault token capabilities <path>
C.vault policy capabilities <policy_name> <path>
D.vault token lookup <token>
AnswerB

`vault token capabilities <path>` queries the token's effective capabilities on that exact path, returning a permission list such as read, create or sudo. It satisfies the stem's constraint of checking one token against one specific path, unlike `vault capabilities`, which inspects the calling token only.

Why this answer

The `vault token capabilities` command is specifically designed to check what operations (e.g., read, create, update, delete, list) a given token is allowed to perform on a particular path. It evaluates the token's attached policies against the path and returns the effective capabilities, making it the correct tool for this task.

Exam trap

HashiCorp often tests the distinction between commands that inspect token metadata (`vault token lookup`) versus commands that evaluate policy-based permissions on a specific path (`vault token capabilities`), and candidates may confuse `vault policy capabilities` (which does not exist) with the correct command.

How to eliminate wrong answers

Option A is wrong because `vault token list` displays all tokens that exist in the token store (for tokens with appropriate permissions), not the capabilities of a specific token on a path. Option C is wrong because `vault policy capabilities` is not a valid Vault command; the correct command to check a policy's effect on a path is `vault token capabilities` (which uses the token's policies), and `vault policy read` is used to view policy rules. Option D is wrong because `vault token lookup` shows metadata about a token (such as creation time, TTL, and attached policies), but does not evaluate or display capabilities on a specific path.

Practice this question →
34
MCQmedium

A developer authenticates with the userpass auth method and receives a token. The developer needs to perform a sensitive operation but the token lacks the required policy. Before asking an administrator, the developer wants to determine whether their current token is permitted to update the secret at secret/data/payments. Which command should the developer run?

A.vault kv get secret/data/payments
B.vault token lookup
C.vault token capabilities secret/data/payments
D.vault policy read default
AnswerC

vault token capabilities reports the actions the calling token is allowed to perform on the given path. Run without an explicit token argument, it evaluates the current token and returns the permitted capabilities, such as create, read, or update. This directly answers whether the developer can update the payments secret without exposing or altering any data.

Why this answer

The capabilities endpoint is designed to answer exactly this question: it returns the set of actions the current token may perform on a specified path. Running vault token capabilities against secret/data/payments reveals whether update is allowed, without reading the secret or requiring administrator involvement.

Exam trap

The trap here is assuming that listing a token's policies or reading a policy file proves what the token can do on a specific path, when effective capabilities require evaluating all policies together.

Practice this question →
35
MCQeasy

A security team wants to ensure that tokens can be revoked immediately if a compromised token is detected, even if the token ID is unknown. Which token feature should they use?

A.Periodic tokens
B.Batch tokens
C.Token accessors
D.Orphan tokens
AnswerC

Token accessors are unique identifiers that reference a token without revealing it, enabling revocation by accessor lookup. This satisfies the stem's constraint of revoking a compromised token immediately even when the token ID itself is unknown to the security team.

Why this answer

Token accessors allow revocation of a token without knowing the token ID. They are specifically designed for this purpose.

Practice this question →
36
MCQeasy

An administrator creates a service token with a TTL of 1 hour and a max TTL of 24 hours. The token is renewed once after 55 minutes. What happens to the token after 24 hours from creation?

A.The token expires and cannot be renewed
B.The token is revoked by the system
C.The token's TTL is automatically extended by 1 hour
D.The token becomes an orphan token
AnswerA

Vault enforces the max TTL as an absolute ceiling from creation; renewal cannot extend a token beyond it. Once 24 hours elapse, the token is revoked and further renewal attempts fail, so it expires permanently.

Why this answer

The token's TTL was set to 1 hour with a max TTL of 24 hours. After the first renewal at 55 minutes, the token's TTL resets to 1 hour, but the max TTL remains 24 hours from creation. Once 24 hours have passed from creation, the token reaches its max TTL and expires permanently; it cannot be renewed because the max TTL is a hard upper limit enforced by Vault's token lifecycle logic.

Exam trap

The trap here is that candidates often confuse the current TTL with the max TTL, thinking that renewing the token resets the overall lifetime, but Vault enforces the max TTL as a hard deadline from creation, not from the last renewal.

How to eliminate wrong answers

Option B is wrong because Vault does not actively revoke tokens upon reaching max TTL; instead, the token simply expires and becomes unusable, with no explicit revocation action. Option C is wrong because the token's TTL is not automatically extended; Vault only extends the TTL upon explicit renewal, and only up to the max TTL, which is already reached at 24 hours. Option D is wrong because an orphan token is one whose parent is expired or revoked, but this token is not orphaned—it simply expires due to max TTL, and orphan tokens still have their own TTL and can be renewed if within limits.

Practice this question →
37
MCQmedium

A DevOps team is using Vault tokens with short TTLs for CI/CD jobs. They notice that some jobs fail intermittently with 'permission denied' errors even though the token policy grants the required capabilities. The token is created with a TTL of 10 minutes and renewed automatically by the client library. What is the most likely cause of the failures?

A.The token's max_ttl has been exceeded, causing renewal to fail.
B.The token's parent token has been revoked.
C.The token's max_ttl is being reset each time the token is renewed.
D.The token's TTL is too short and the client library is not renewing in time.
AnswerA

Renewal cannot extend a token beyond its max_ttl, regardless of the client library's automatic renewal. Once the token's total lifetime hits that ceiling, renewal fails and subsequent requests return permission denied, matching the intermittent failures described.

Why this answer

Vault tokens have both a TTL (time-to-live) and a max_ttl (maximum time-to-live). When a token is renewed, its TTL is reset to the original TTL (10 minutes) but only if the cumulative lifetime has not exceeded the max_ttl. If the max_ttl is reached, renewal fails, the token expires, and subsequent operations using that token return 'permission denied' errors, even though the policy itself grants the required capabilities.

Exam trap

HashiCorp often tests the distinction between TTL and max_ttl, trapping candidates who assume that automatic renewal indefinitely extends token validity without considering the hard upper limit imposed by max_ttl.

How to eliminate wrong answers

Option B is wrong because revoking the parent token would immediately invalidate all child tokens, causing consistent failures, not intermittent ones, and the scenario describes intermittent failures. Option C is wrong because the max_ttl is a hard upper bound and is never reset or extended by renewal; only the current TTL is reset. Option D is wrong because the client library is described as renewing automatically, and a 10-minute TTL is generally sufficient for CI/CD jobs; the issue is the cumulative lifetime exceeding max_ttl, not the renewal timing.

Practice this question →
38
MCQhard

A security engineer creates a service token with a TTL of 1 hour and a max TTL of 4 hours. The token is used by an application that renews it every 30 minutes. After 3 hours, the engineer revokes the token using its accessor. What happens to the token's child tokens?

A.Child tokens are revoked only if they have no other parent.
B.Child tokens are orphaned and become root tokens.
C.All child tokens are immediately revoked.
D.Child tokens remain valid until their own TTLs expire.
AnswerC

When a token is revoked, all of its child tokens are also revoked by default. This cascading revocation ensures that any tokens created by the revoked token are invalidated, preventing unauthorized access. In this scenario, revoking the parent token using its accessor will immediately revoke all child tokens, regardless of their individual TTLs.

Why this answer

Revoking a token in Vault triggers a cascading revocation of all its child tokens. This behavior ensures that compromised or expired parent tokens do not leave valid child tokens that could be used for unauthorized access. The accessor allows revocation without knowing the token ID, but the effect on children remains the same.

Exam trap

The trap here is thinking that child tokens might survive parent revocation if they have their own TTL, but Vault revokes them immediately.

Practice this question →
39
MCQmedium

A security engineer needs to create a batch token that will be used by an external system for a one-time operation. The token must be self-contained and not stored in Vault's storage backend. Which token type should be used, and what is a key limitation of that token type?

A.Periodic token; it can be renewed indefinitely but is stored in Vault's storage backend.
B.Root token; it is not stored in Vault's storage backend and can be used for any operation.
C.Batch token; it cannot be renewed or revoked, and it is not stored in Vault's storage backend.
D.Service token; it cannot be renewed or revoked individually.
AnswerC

Batch tokens are self-contained, not persisted in Vault's storage, and therefore cannot be renewed or revoked individually. They are ideal for ephemeral, one-time operations where the client does not need to manage the token's lifecycle. This matches the requirement for a token that is not stored and used for a single operation.

Why this answer

Batch tokens are designed to be lightweight and self-contained, meaning they are not persisted in Vault's storage backend. This makes them suitable for ephemeral use cases where the token will not be renewed or revoked. The key limitation is that they cannot be renewed or revoked individually, which is acceptable for a one-time operation.

Exam trap

The trap here is assuming that batch tokens can be revoked like service tokens, when in fact they are not stored and thus cannot be individually revoked.

Practice this question →
40
Drag & Dropmedium

Drag and drop the steps to initialize and unseal a Vault server for the first time into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence for initializing and unsealing a Vault server for the first time is: start the server, initialize Vault (which generates unseal keys), distribute the unseal keys to key holders, unseal the Vault using a threshold of keys, then verify the Vault is unsealed. This ensures proper security and operational readiness.

Practice this question →
41
Multi-Selecteasy

Which TWO statements are true about batch tokens?

Select 2 answers
A.Batch tokens can be renewed to extend their lifetime
B.Batch tokens cannot be renewed or revoked
C.Batch tokens are not stored in Vault's storage backend
D.Batch tokens can be looked up using the lookup endpoint
AnswersB, C

Batch tokens are stateless and cannot be renewed or revoked individually; revocation only occurs by letting them expire or by rotating the signing key. This satisfies the stem's requirement for a true statement about batch token lifecycle limitations.

Why this answer

Option B is correct because batch tokens are designed as lightweight, self-contained tokens that cannot be renewed or revoked once issued; they simply expire at the end of their fixed TTL. Option C is correct because batch tokens are not persisted in Vault's storage backend—they are encrypted blobs whose validity is verified without a storage lookup, which is what makes them scalable and cheap to create. Option A is incorrect because batch tokens have a fixed lifetime and cannot be renewed, unlike service tokens.

Option D is incorrect because batch tokens cannot be looked up via the lookup endpoint; lookup operations require a storage-backed token, which batch tokens are not.

Exam trap

The Vault exam often tests the misconception that all Vault tokens support renewal and lookup, but batch tokens are explicitly excluded from these operations due to their stateless, non-persistent nature.

Practice this question →
42
MCQmedium

A security team wants to audit all tokens created by a specific authentication method. They need to list all tokens and retrieve details such as creation time, TTL, and policies. Which Vault command should they use?

A.vault token create -list
B.vault list auth/token/accessors
C.vault token lookup
D.vault read auth/token/accessors
AnswerB

`vault list auth/token/accessors` lists all token accessors, which can then be used with `vault token lookup` to retrieve details for each token. This is the standard way to enumerate tokens and audit their properties. It provides a list of accessors without exposing the tokens themselves, which is a security best practice.

Why this answer

To audit tokens, administrators can list all token accessors using `vault list auth/token/accessors`. Each accessor can then be used with `vault token lookup` to retrieve detailed information about the corresponding token. This approach avoids exposing the actual token IDs while still allowing comprehensive auditing of token properties such as creation time, TTL, and policies.

Exam trap

The trap here is confusing the command to list token accessors with the command to read a specific token's details, or attempting to use a non-existent flag like `-list`.

Practice this question →
43
MCQeasy

A developer created a token and wants to ensure that the token can only be used to read secrets from the 'secret/data/production' path. Which policy attachment approach should be used?

A.Set the token's metadata to restrict access
B.Use a root token and restrict its use via a policy
C.Create a policy with read capability on 'secret/data/production' and attach it to the token
D.Set the token type to service and it will automatically restrict access
AnswerC

Attaching a policy granting only read capability on 'secret/data/production' to the token scopes its permissions to that exact path, satisfying the least-privilege constraint. Vault evaluates the token's attached policies, so no broader capability is inherited.

Why this answer

Vault uses policies to define fine-grained access control, and the only way to restrict a token to read secrets from a specific path is to create a policy with the appropriate capabilities (e.g., 'read' on 'secret/data/production') and attach that policy to the token at creation time. Tokens themselves do not inherently carry path restrictions; they inherit permissions solely from attached policies.

Exam trap

HashiCorp often tests the misconception that token metadata or token type can enforce access restrictions, when in fact only policies attached to the token define what paths and operations are allowed.

How to eliminate wrong answers

Option A is wrong because token metadata is used for audit and identity purposes, not for enforcing access control; Vault does not evaluate metadata to allow or deny API requests. Option B is wrong because a root token has unrestricted access to all paths and policies cannot restrict a root token—root tokens bypass all policy checks by design. Option D is wrong because the token type (service vs. batch) determines lifecycle and revocation behavior, not access permissions; a service token still requires an attached policy to define what it can read.

Practice this question →
44
MCQmedium

A Vault administrator wants to allow a CI/CD pipeline to create short-lived tokens for deployment jobs. The pipeline itself authenticates with a periodic token. Which token type should the pipeline use to create tokens for jobs, considering the jobs need to be independent and not affected by the pipeline token's lifecycle?

A.Service tokens with explicit max TTL
B.Orphan tokens
C.Periodic tokens
D.Batch tokens
AnswerB

Orphan tokens have no parent, so they survive independently of the pipeline token's expiry or revocation. This satisfies the requirement that job tokens remain unaffected by the pipeline token's lifecycle, unlike child tokens, which are revoked with their parent.

Why this answer

Orphan tokens are the correct choice because they allow the CI/CD pipeline to create child tokens that are not tied to the parent token's lifecycle. When a periodic token creates an orphan token, the child token remains valid even if the parent token is revoked or expires, ensuring deployment jobs are independent and not affected by the pipeline token's lifecycle.

Exam trap

HashiCorp often tests the misconception that all child tokens are automatically orphaned or that periodic tokens can create independent child tokens, but the trap is that only explicitly orphaned tokens break the parent-child chain, while default token creation maintains a hierarchical dependency.

How to eliminate wrong answers

Option A is wrong because service tokens with explicit max TTL are still parent-child tokens; if the parent token is revoked, the child token is also revoked, so the jobs would be affected by the pipeline token's lifecycle. Option C is wrong because periodic tokens are used for long-lived, renewable tokens with a fixed lifetime, not for creating short-lived tokens for jobs; they also create parent-child relationships by default. Option D is wrong because batch tokens are lightweight, non-renewable tokens that cannot create child tokens at all, so they cannot be used to generate tokens for deployment jobs.

Practice this question →
45
Multi-Selectmedium

A Vault administrator is reviewing token behaviors and needs to understand which actions are possible with a token's accessor. Which two statements about token accessors are true? (Choose two.)

Select 2 answers
A.An accessor can be used to create child tokens with the same policies.
B.An accessor can be used to revoke the token.
C.An accessor can be used to renew the token if the token is renewable.
D.An accessor can be used to authenticate to Vault and access secrets.
E.An accessor can be used to look up the token's properties, such as its policies and TTL.
AnswersB, E

Vault allows revocation of a token using its accessor. This is a powerful feature for administrators who need to revoke a token without knowing the token string itself. For example, if a token is leaked, an administrator can use the accessor to revoke it, provided they have the necessary permissions. The accessor provides a way to manage tokens without exposing the token value, balancing security and control.

Why this answer

Token accessors provide a way to manage tokens without exposing the token string. They can be used to look up a token's metadata and to revoke the token. They cannot be used to renew the token, create child tokens, or authenticate to Vault.

This design allows administrators to audit and revoke tokens while minimizing the risk of token leakage. The correct statements are that an accessor can be used for lookup and for revocation.

Exam trap

The trap here is assuming that an accessor grants the same capabilities as the token itself, but an accessor is only for lookup and revocation, not for authentication or renewal.

Practice this question →
46
Matchingmedium

Match each Vault auth method to its authentication mechanism.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

RoleID and SecretID

Username/password against LDAP server

Static or periodic tokens

Service account token

JSON Web Token / OpenID Connect

Why these pairings

Token auth uses a single-use token; Userpass uses username/password; AppRole uses RoleID/SecretID. Common confusions involve swapping these definitions.

Practice this question →
47
MCQmedium

A token with a policy granting 'write' on 'secret/team-alpha/*' is unable to write to 'secret/team-alpha/db-creds' in a KV v2 engine. What is the most likely cause?

A.The token is not a root token
B.The token's TTL has expired
C.The token has a conflicting policy from a parent token
D.The policy path should be 'secret/data/team-alpha/*' for KV v2
AnswerD

KV v2 inserts a `data/` segment into every API path, so a policy written against the v1 layout never matches the request. The token's `secret/team-alpha/*` rule therefore grants nothing on `secret/data/team-alpha/db-creds`, producing the permission denial. Rewriting the path as `secret/data/team-alpha/*` restores the required write capability.

Why this answer

D is correct because in Vault's KV v2 engine, the actual data path is prefixed with 'data/' after the mount path. A policy granting 'write' on 'secret/team-alpha/*' targets the metadata path, not the data path. To write secrets, the policy must use 'secret/data/team-alpha/*' to match the correct API endpoint.

Exam trap

The trap here is that candidates assume the policy path should match the mount path directly, overlooking the mandatory 'data/' prefix in KV v2, which HashiCorp Vault tests to ensure understanding of Vault's path structure differences between engines.

How to eliminate wrong answers

Option A is wrong because a root token is not required to write to a KV v2 path; a properly scoped policy with the correct path is sufficient. Option B is wrong because an expired TTL would cause a permission denied error due to token invalidity, not a path mismatch, and the question states the token is unable to write, not that it is expired. Option C is wrong because conflicting policies from a parent token would result in a denial based on the most restrictive policy, but the core issue here is the incorrect path, not a policy conflict.

Practice this question →
48
Multi-Selectmedium

An administrator is reviewing Vault token policies and wants to ensure that tokens created by a specific application cannot be renewed and have a fixed lifetime. Which two token configurations should be applied?

Select 2 answers
A.Set max_ttl on the role to a very large value.
B.Set renewable to false.
C.Set ttl on the token to 0.
D.Set explicit_max_ttl on the token to match the desired TTL.
E.Set no_default_policy to true.
AnswersB, D

Setting renewable to false prevents any client from extending the token's life via renewal, so the token expires at its initial TTL. This directly satisfies the fixed-lifetime constraint, since no renewal path exists to push expiry beyond the issued duration.

Why this answer

Option B is correct because setting renewable to false on the token (or its role) prevents the token from being renewed, directly satisfying the requirement that tokens cannot be renewed. Option D is correct because setting explicit_max_ttl to match the desired TTL caps the token's total lifetime at a fixed value, ensuring a fixed lifetime even if renewal were otherwise possible. Together, renewable=false and explicit_max_ttl enforce both non-renewability and a hard expiration.

Option A is wrong because a very large max_ttl would extend, not fix, the token's lifetime. Option C is wrong because a ttl of 0 typically means no expiration or default behavior, not a fixed lifetime. Option E is wrong because no_default_policy only controls whether the default policy is attached, which is unrelated to renewal or lifetime.

Exam trap

In HashiCorp Vault, candidates often confuse `ttl` with `explicit_max_ttl` on token roles. Setting `ttl` to 0 means the token uses a system default, not a fixed lifetime, while `explicit_max_ttl` enforces an absolute ceiling that cannot be overridden by renewal.

Practice this question →
49
MCQeasy

A user forgets to renew their token before it expires. What happens to the token and its associated leases?

A.The token becomes invalid but can be renewed within a grace period
B.The token is revoked and all its leases are revoked
C.The token is automatically renewed for another period
D.The token remains active but read-only
AnswerB

Expiry automatically revokes the token, and Microsoft Entra ID propagates that revocation to every lease issued against it, so no lease outlives its parent token. This satisfies the stem's forgotten-renewal scenario: without renewal, the token lapses and all associated leases are revoked together, preventing orphaned leases.

Why this answer

When a Vault token expires, it is immediately revoked by the system, and all associated leases (e.g., dynamic secrets, wrapped responses) are also revoked. There is no grace period for renewal after expiration; the token must be renewed before its TTL expires. This behavior is enforced by Vault's lease management system, which ties secret lifetimes directly to token validity.

Exam trap

HashiCorp often tests the misconception that Vault provides a grace period or automatic renewal for tokens, but in reality, token expiration is absolute and requires explicit client-side renewal before the TTL ends.

How to eliminate wrong answers

Option A is wrong because Vault does not provide a grace period for token renewal after expiration; once the TTL is exceeded, the token is immediately revoked and cannot be renewed. Option C is wrong because Vault never automatically renews tokens; renewal must be explicitly requested by the client or a renewal process (e.g., via the API or a sidecar). Option D is wrong because an expired token is revoked entirely, not placed into a read-only state; Vault has no 'read-only' token mode after expiration.

Practice this question →
50
MCQhard

An administrator wants to ensure that a token created by a user cannot be used after 24 hours, even if the user tries to renew it. What should the administrator do?

A.Use a periodic token with a period of 24h
B.Create an orphan token with a TTL of 24h
C.Use a batch token
D.Set explicit max TTL on the token to 24h
AnswerD

Setting an explicit max TTL of 24h caps the token's total lifetime regardless of renewal attempts, satisfying the requirement that it cannot be used beyond 24 hours. Renewals cannot extend past the max TTL, unlike a renewable TTL alone.

Why this answer

Setting an explicit max TTL on the token to 24h ensures that the token's lifetime cannot be extended beyond 24 hours, even if the user attempts to renew it. In Vault, the `explicit_max_ttl` parameter overrides any renewal requests, enforcing a hard upper limit on the token's validity. This directly addresses the requirement that the token cannot be used after 24 hours, regardless of renewal attempts.

Exam trap

The trap here is that candidates confuse TTL (time-to-live, which can be extended via renewal) with explicit max TTL (which sets a hard, non-renewable expiration), leading them to choose periodic or orphan tokens that allow indefinite renewal.

How to eliminate wrong answers

Option A is wrong because a periodic token with a period of 24h can be renewed indefinitely as long as the renewal occurs within the period, allowing the token to exist beyond 24 hours. Option B is wrong because an orphan token with a TTL of 24h can still be renewed before expiration, extending its lifetime beyond the initial 24-hour window. Option C is wrong because a batch token is designed for high-throughput, short-lived operations and does not inherently enforce a hard maximum lifetime; it can be renewed or have its TTL extended unless explicitly constrained.

Practice this question →
51
MCQmedium

A security analyst discovers that a token used by a legacy application is still active long after the application was decommissioned. Which Vault feature should have been used to automatically expire tokens when the application is no longer running?

A.Enable token renewal to keep it alive
B.Use a periodic token and revoke it manually
C.Set a TTL on the token
D.Use a batch token to limit its lifetime
AnswerC

A token TTL enforces a maximum lifetime, after which Vault automatically revokes the token regardless of whether the legacy application still runs. This directly satisfies the requirement to expire credentials without manual intervention, closing the exposure window left when a decommissioned application's token remained active indefinitely.

Why this answer

Setting a Time-To-Live (TTL) on the token ensures it automatically expires after a specified duration, even if the application is decommissioned. This prevents orphaned tokens from remaining active indefinitely, which is a security risk. Vault's TTL mechanism is designed to enforce token lifetime limits without requiring manual intervention.

Exam trap

The trap here is that candidates confuse token renewal (which extends lifetime) with TTL-based expiration, or they assume manual revocation is sufficient for automated lifecycle management, missing the need for automatic expiry via TTL.

How to eliminate wrong answers

Option A is wrong because enabling token renewal keeps the token alive indefinitely by renewing its lease, which is the opposite of what is needed to automatically expire the token. Option B is wrong because a periodic token has no fixed TTL and requires manual revocation, which does not provide automatic expiration when the application stops running. Option D is wrong because batch tokens are designed for high-throughput, non-renewable workloads but still require an explicit TTL or explicit revocation; they do not inherently limit lifetime based on application lifecycle.

Practice this question →
52
MCQmedium

Refer to the exhibit. A developer tries to renew a token and receives this error. The token was created using 'vault token create -type=batch'. What is the most likely cause of this error?

A.The token is a service token and has expired
B.The token is a batch token
C.The token is a periodic token and its period has expired
D.The token is an orphan token
AnswerB

Batch tokens in HashiCorp Vault are not renewable: they carry a fixed, pre-computed lifetime and cannot be renewed via the renew-self endpoint, unlike service tokens. Since the stem specifies creation with `-type=batch`, the renewal attempt fails because that token type inherently lacks renewal capability.

Why this answer

Batch tokens are non-persistent and do not have associated lease IDs, so they cannot be renewed. The error occurs because the developer attempted to renew a batch token using 'vault token renew', which is only valid for service tokens that have a lease and can be extended. The exhibit shows a renewal failure, and since the token was created with 'vault token create -type=batch', the most likely cause is that batch tokens are inherently non-renewable.

Exam trap

HashiCorp Vault often tests the distinction between batch and service tokens by presenting a renewal error, and the trap here is that candidates may assume all tokens can be renewed or confuse batch tokens with periodic tokens, which are a subtype of service tokens that do support renewal.

How to eliminate wrong answers

Option A is wrong because service tokens can be renewed even after expiration if within the grace period, and the error is specific to batch token behavior, not expiration. Option C is wrong because periodic tokens are a type of service token that can be renewed indefinitely as long as the token is still valid, and their period expiration does not prevent renewal. Option D is wrong because orphan tokens are a property related to parent-child relationships, not renewability; orphan tokens can be service or batch tokens, and the error is due to the batch type, not the orphan status.

Practice this question →
53
MCQmedium

A security audit requires tracking token usage without exposing the token value itself. Which token attribute should be logged?

A.Token value
B.Creation TTL
C.Token accessor
D.Policy list
AnswerC

The token accessor is a unique, non-secret identifier that references a token without revealing its value, allowing audit logs to correlate token usage while keeping the credential confidential. Logging the token itself would expose it to anyone reading the audit trail.

Why this answer

The token accessor is a non-sensitive reference to a Vault token that can be used for token lifecycle operations (e.g., lookup, renewal, revocation) without exposing the actual token value. Logging the accessor satisfies audit requirements for tracking token usage while maintaining security, as the accessor cannot be used to authenticate requests.

Exam trap

HashiCorp Vault often tests the distinction between a token's sensitive value and its non-sensitive metadata, and the trap here is that candidates confuse the token accessor with the token value itself or assume that any attribute like TTL or policy list can serve as a tracking identifier.

How to eliminate wrong answers

Option A is wrong because logging the token value directly would expose the secret credential, violating the security audit's requirement to avoid exposing the token value. Option B is wrong because the Creation TTL (time-to-live) is a configuration parameter that indicates the token's initial lifetime, not a unique identifier for tracking individual token usage. Option D is wrong because the policy list defines the token's associated access policies but does not provide a unique, non-sensitive identifier for tracking token usage across operations.

Practice this question →
54
MCQeasy

An administrator creates a token with the following parameters: `vault token create -ttl=1h -explicit-max-ttl=2h`. The token is then renewed once for 1 hour. What is the maximum remaining time the token can be renewed for after this first renewal?

A.3 hours
B.1 hour
C.2 hours
D.0 hours (token cannot be renewed further)
AnswerB

The token's explicit max TTL is 2 hours. After the initial creation, the token has 1 hour of TTL. When renewed for 1 hour, the total elapsed time becomes 1 hour, leaving 1 hour until the explicit max TTL is reached. Therefore, the maximum remaining renewal time is 1 hour.

Why this answer

The explicit max TTL is a hard limit on the total lifetime of a token from its creation. After the token is created with a TTL of 1 hour, it is renewed for another hour, making the total elapsed time 1 hour. The remaining time before hitting the explicit max TTL of 2 hours is 1 hour.

Thus, the token can be renewed for at most 1 more hour.

Exam trap

The trap here is confusing the explicit max TTL with the initial TTL and assuming that renewals can extend the token beyond the explicit max TTL.

Practice this question →
55
MCQmedium

A company uses Vault to issue tokens for short-lived tasks. They have configured a token role with 'period' set to 30 minutes and 'explicit_max_ttl' set to 24 hours. Tokens are created using the role and are expected to be renewed every 30 minutes by the tasks. However, after a few renewals, the Vault audit logs show that a token was renewed but then immediately expired. The task that was using the token failed. What is the most likely reason for this behavior?

A.The token reached its 'explicit_max_ttl' of 24 hours, and renewal is no longer possible.
B.The token was created by a root token and root tokens are not subject to periodic renewal.
C.The token was a batch token and batch tokens cannot be renewed at all.
D.The token was an orphan token and cannot be renewed more than a few times.
AnswerA

The token's explicit_max_ttl caps its total lifetime at 24 hours regardless of periodic renewal. Once cumulative renewals exhaust that ceiling, Vault permits one final renewal but sets the token's TTL to zero, so it expires immediately afterwards. This matches the audit log showing a successful renewal followed by instant expiry, satisfying the 24-hour constraint.

Why this answer

The token role has an 'explicit_max_ttl' of 24 hours, which sets an absolute hard limit on the token's lifetime regardless of the shorter 'period' of 30 minutes. When the token is renewed, its total lifetime cannot exceed the explicit_max_ttl. Once that limit is reached, Vault rejects any further renewal, causing the token to expire immediately and the task to fail.

Exam trap

Vault often tests the distinction between 'period' (renewal interval) and 'explicit_max_ttl' (absolute lifetime cap), leading candidates to mistakenly think that periodic renewal can continue indefinitely as long as the token is renewed within the period.

How to eliminate wrong answers

Option B is wrong because root tokens are not subject to most TTL restrictions, but the token in question was created using a token role, not by a root token directly, and the issue is about explicit_max_ttl enforcement, not root token behavior. Option C is wrong because batch tokens cannot be renewed at all, but the audit logs show the token was successfully renewed several times before failing, indicating it was a service token, not a batch token. Option D is wrong because orphan tokens have no parent and can be renewed indefinitely up to their TTL limits; there is no restriction on the number of renewals for orphan tokens.

Practice this question →
56
MCQhard

An application uses a periodic token with period=24h. The application renews every 12h. After 48h, the token is still valid. After 72h, the token is still valid. What is the maximum lifetime of this periodic token?

A.Unlimited (as long as it keeps renewing)
B.72h
C.48h
D.24h
AnswerA

Periodic tokens have no fixed maximum lifetime; each renewal resets the validity window rather than counting toward an absolute expiry. Because the application renews every 12h against a 24h period, the token stays valid indefinitely, so the lifetime is effectively unlimited while renewals continue.

Why this answer

A periodic token with a defined period (e.g., 24h) has no maximum lifetime; it remains valid indefinitely as long as it is renewed before the period expires. In this scenario, the token is renewed every 12h (well within the 24h period), so after 48h and 72h it is still valid because each renewal resets the token's lifetime, effectively giving it an unlimited lifespan. This behavior is inherent to periodic tokens in Vault, which are designed for long-lived sessions with regular re-authentication.

Exam trap

The trap here is that candidates confuse the token's period (the renewal window) with a maximum lifetime, assuming the token expires after the period even if renewed, when in fact periodic tokens can be renewed indefinitely as long as the renewal occurs before the period ends.

How to eliminate wrong answers

Option B (72h) is wrong because it assumes a fixed maximum lifetime, but periodic tokens have no hard upper limit—they can be renewed indefinitely. Option C (48h) is wrong because it incorrectly interprets the renewal interval as the token's maximum lifetime, whereas the token's validity depends on the period (24h) and renewal before expiry. Option D (24h) is wrong because it confuses the token's period (the window for renewal) with a maximum lifetime; the token does not expire after 24h if renewed within that window.

Practice this question →
57
MCQhard

A Vault cluster has a token with the following policy: path "secret/data/dev/*" { capabilities = ["read", "list"] }. The token is used to read a secret at "secret/data/dev/password". The read succeeds. Later, the token tries to read "secret/data/prod/password". What happens?

A.Fails with a system error.
B.Succeeds because token has read capability on all secrets.
C.Succeeds because the token can list and read any path.
D.Fails because the token needs an explicit policy for "secret/data/prod/".
AnswerD

Vault policies are deny by default, so the token's capabilities apply only to paths matching `secret/data/dev/*`. Reading `secret/data/prod/password` falls outside that glob, and no other policy grants access, so the request is denied. The stem's constraint — a single dev-scoped policy — makes the prod read fail.

Why this answer

Vault policies are path-based and deny by default. The token's policy only grants 'read' and 'list' capabilities on paths matching 'secret/data/dev/*', so any attempt to access 'secret/data/prod/password' is not covered by that policy. Without an explicit policy allowing access to the 'prod' path, the request is denied by Vault's default deny behavior.

Exam trap

A common misconception is that a token with read capability on one path can read any secret, but Vault's policy model requires explicit path matching for each access attempt.

How to eliminate wrong answers

Option A is wrong because a denied request due to missing policy does not produce a system error; Vault returns a permission denied response (HTTP 403). Option B is wrong because Vault tokens do not have implicit read capability on all secrets; capabilities are strictly defined by attached policies. Option C is wrong because the token's 'list' and 'read' capabilities are scoped only to the 'secret/data/dev/*' path, not to any arbitrary path.

Practice this question →
58
Drag & Dropmedium

Drag and drop the steps to perform a Vault disaster recovery using the replication feature into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Initialize clusters, enable primary replication, generate token, enable secondary, promote if needed.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Assess Vault tokens questions.

Start 20-question session