Knowledge + Practice

CCNA Assess Vault tokens Questions

75 of 92 questions · Page 1/2 · Assess Vault tokens · Answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

A developer creates a token using the 'token create' command with the 'period=24h' flag. What type of token is created?

A.Root token

B.Periodic token

C.Orphan token

D.Batch token

AnswerB

The period flag creates a periodic token.

Why this answer

The 'token create' command with the 'period=24h' flag creates a periodic token. Periodic tokens have a TTL that is automatically renewed by the client before expiration, but they do not have a maximum lifetime beyond the period itself. This is distinct from normal tokens, which have both a TTL and a max TTL, and root tokens, which are exempt from TTL enforcement.

Exam trap

HashiCorp often tests the distinction between the 'period' flag and the 'ttl' or 'max_ttl' flags; the trap here is that candidates confuse periodic tokens with normal tokens that have a TTL, or assume that 'period' sets a maximum lifetime rather than a renewal interval.

How to eliminate wrong answers

Option A is wrong because a root token is created using the 'root token generation' process (e.g., via operator init or recovery keys), not via the 'token create' command, and it has no TTL or period restrictions. Option C is wrong because an orphan token is created by using the 'orphan=true' flag with 'token create', not the 'period' flag; orphan tokens are not attached to a parent token but still have a TTL/max TTL. Option D is wrong because a batch token is created using the 'batch' flag (or via 'token create -type=batch'), not the 'period' flag; batch tokens are lightweight, non-renewable, and have no associated lease or period.

Practice this question →

2

MCQmedium

An application using a service token fails to renew it, receiving an error 'permission denied'. The token has policies that include 'path "auth/token/renew-self" { capabilities = ["update"] }'. The token is not expired and has remaining TTL. What is a likely cause?

A.The token's num_uses has reached zero

B.The token is a batch token

C.The token's parent was revoked

D.The token has reached its explicit max TTL

AnswerD

Renewal is denied if it would exceed max TTL.

Why this answer

The token's explicit max TTL has been reached, preventing any further renewals even though the token still has remaining TTL. Option A is incorrect because num_uses=0 means unlimited uses, not that it has reached zero. Option B is incorrect because a batch token cannot be renewed at all, but the token's policy includes renew-self capability, indicating it is a service token.

Option C is incorrect because if the parent token were revoked, the token itself would be revoked and invalid, not just failing to renew with a permission denied error.

Practice this question →

3

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

TTL shows remaining time; creation_ttl was 1h, so 30m have passed.

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 →

4

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 by accessor requires sudo.

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 →

5

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's ACL model gives deny precedence over allow.

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 →

6

MCQhard

A large enterprise uses Vault with multiple namespaces for different business units. The security team has implemented a policy that requires all tokens to be created with a bounded set of allowed policies defined in a token role. The token role allows policies 'app-dev', 'app-staging', and 'app-prod' for the development namespace. The token role has token_type set to 'service'. A developer attempts to create a token using this role but specifies an additional policy 'admin' in the creation request. The Vault administrator expects this request to fail because 'admin' is not in the allowed policies list. However, the token is created successfully with only the allowed policies applied. Why did the request succeed?

A.The token role's 'token_type' was set to 'batch', which ignores policy restrictions.

B.The token role had 'allowed_policies_glob' set to 'app-*', which matched 'admin' as well.

C.Vault ignores the 'allowed_policies' list when the token creation request includes policies, as long as one of the requested policies is in the allowed list.

D.The developer added the 'admin' policy directly to the token role before creating the token.

AnswerD

Correct. The developer must have added 'admin' to the token role's allowed policies before creating the token, which would then allow the request to succeed.

Why this answer

In Vault, token roles enforce a strict policy: the policies requested during token creation must be a subset of the allowed policies (or match allowed_policies_glob). If a requested policy like 'admin' is not in the allowed list, the request should fail. The only way the developer's request could succeed is if the 'admin' policy was added to the token role's allowed policies before the request was made.

Option D correctly identifies this: the developer added the 'admin' policy directly to the token role, making it allowed. Options A and C contradict Vault's known behavior, and option B's glob pattern 'app-*' does not match 'admin'.

Practice this question →

7

MCQeasy

A user receives this error when trying to read a secret. What is the most likely cause?

A.The secret engine is not enabled

B.The token is a root token

C.The token has expired

D.The token's policy does not grant read on that path

AnswerD

Permission denied indicates the token lacks the necessary capability.

Why this answer

Vault uses a policy-based authorization model. When a token attempts to read a secret, Vault checks the token's associated policies to determine if the action is permitted on that specific path. If the policy does not include a `read` capability (or a broader capability like `sudo` or `update` that implies read) for the secret's path, Vault denies the request with a permission denied error, regardless of the token's validity or the secret engine's status.

Exam trap

HashiCorp Vault often tests the distinction between authentication errors (expired token, invalid token) and authorization errors (permission denied), and the trap here is that candidates may confuse a token's validity with its authorization scope, assuming any valid token can read any secret.

How to eliminate wrong answers

Option A is wrong because if the secret engine were not enabled, Vault would return a 'path not found' or 'no handler for route' error, not a permission denied error. Option B is wrong because a root token has unrestricted access to all paths and capabilities, so it would never receive a permission denied error when reading a secret. Option C is wrong because an expired token would cause Vault to return an 'invalid token' or 'token expired' error, not a permission denied error; the error message specifically indicates the token is valid but lacks authorization.

Practice this question →

8

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 are non-renewable, non-revocable, and ideal for high-volume short-lived tokens.

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 →

9

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

This is a security best practice to avoid exposing tokens.

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 →

10

MCQmedium

A security audit reveals that many Vault tokens in an organization are orphan tokens (tokens with no parent). The tokens were created using a batch token creation script that did not set an explicit parent. The security team is concerned about these orphan tokens because they cannot be managed through the usual parent-child hierarchy. They want to revoke all orphan tokens created more than 30 days ago. However, the team does not have a list of token IDs for these tokens. Which approach should the team take to revoke the orphan tokens?

A.Reinitialize Vault and restore from a snapshot taken before the orphan tokens were created.

B.If the team stored token accessors at creation time, use the accessors to revoke the tokens via the /auth/token/revoke-accessor endpoint.

C.Use the token's parent token (the batch token creation script's token) to recursively revoke all children, which includes orphan tokens.

D.Revoke the batch token creation script's token and all its children, which will indirectly revoke orphan tokens associated with that script.

AnswerB

Correct: Accessors allow revocation without the token ID, making them ideal for orphan tokens if accessors were captured.

Why this answer

Token accessors are non-sensitive identifiers that can be used to revoke tokens without needing the token ID itself. If the team stored the accessors when the batch tokens were created, they can call the `/auth/token/revoke-accessor` endpoint to revoke each orphan token individually. This approach directly addresses the lack of a token ID list while respecting the security requirement to revoke only orphan tokens older than 30 days.

Exam trap

The trap here is that candidates assume orphan tokens can be managed through a parent-child hierarchy, forgetting that orphan tokens have no parent, making recursive revocation impossible.

How to eliminate wrong answers

Option A is wrong because reinitializing Vault and restoring from a snapshot is a drastic, disruptive action that would affect all data and tokens, not just orphan tokens, and it does not provide a targeted way to revoke only tokens older than 30 days. Option C is wrong because orphan tokens have no parent by definition, so there is no parent token to use for recursive revocation; the batch token creation script's token is not the parent of orphan tokens. Option D is wrong because revoking the batch token creation script's token and its children will only affect tokens that have that script's token as a parent, but orphan tokens have no parent, so they would not be included in the recursive revocation.

Practice this question →

11

Multi-Selecthard

Which THREE factors influence the maximum TTL of a token?

Select 3 answers

A.The TTL set on the token role.

B.The max TTL of the auth method or mount.

C.The token's current TTL.

D.The max TTL set on the token role.

E.The system's default max TTL (usually 32 days).

AnswersB, D, E

The auth method's max TTL imposes a limit.

Why this answer

The maximum TTL of a token is capped by the max TTL configured on the auth method or mount path. Even if a role or system default allows a longer TTL, the auth mount's max TTL acts as an upper boundary that cannot be exceeded. This ensures that each mount path enforces its own security limits independent of role-level settings.

Exam trap

Candidates often confuse the role's TTL (initial lifetime) with the role's max TTL (upper bound), leading them to incorrectly select the role's TTL as a factor influencing the maximum TTL of a token.

Practice this question →

12

Multi-Selectmedium

Which TWO of the following are valid methods to revoke a Vault token?

Select 2 answers

A.vault token revoke <token>

B.vault secrets disable <path>

C.vault auth disable <path>

D.vault token revoke -accessor <accessor>

E.vault policy delete <name>

AnswersA, D

This revokes the specified token.

Why this answer

`vault token revoke <token>` is the direct command to revoke a specific Vault token by its token value. This invalidates the token immediately, preventing any further use. Option D is correct because `vault token revoke -accessor <accessor>` revokes a token using its accessor, which is a non-sensitive identifier that can be used to manage tokens without exposing the token itself.

Exam trap

The trap here is that candidates confuse disabling an auth method or secrets engine with token revocation, not realizing that disabling only prevents new operations but does not invalidate existing tokens.

Practice this question →

13

MCQmedium

Based on the exhibit, what is the maximum lifetime of this token?

A.720 hours

B.The max TTL is shown as 'ttl' and cannot exceed that

C.The token is valid indefinitely because it is renewable

D.The token will expire at expire_time unless renewed

AnswerD

The max TTL is not shown; the token behaves with current TTL and can be renewed.

Why this answer

The token will expire at the absolute timestamp shown in `expire_time` unless it is renewed before that time. While `max_ttl` (not displayed in the exhibit) defines the absolute maximum lifetime if the token is repeatedly renewed, the token's current expiration is `expire_time`. Therefore, given the options, the token will expire at that time unless renewed.

Exam trap

HashiCorp Vault often tests the distinction between `ttl` and `expire_time`, trapping candidates who assume the token's lifetime is solely based on the `ttl` value or that renewable tokens have no maximum lifetime.

How to eliminate wrong answers

Option A is wrong because the maximum lifetime is not a fixed 720 hours; it is defined by the `expire_time` field, which can vary based on token configuration and policies. Option B is wrong because the `ttl` field represents the remaining time-to-live, not the maximum lifetime, and the token's maximum lifetime is constrained by `expire_time`, not `ttl`. Option C is wrong because renewable tokens still have a maximum lifetime defined by `expire_time`; they cannot be renewed indefinitely beyond that absolute expiration.

Practice this question →

14

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 only has 'default' and 'my-policy' policies. Without a policy granting write on 'secret/data/myapp', the operation is 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 →

15

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 →

16

Multi-Selecteasy

A DevOps team is troubleshooting token access in Vault. They need to determine which of the following token operations require sudo capability. Which TWO operations require sudo capability?

Select 2 answers

A.Create a token

B.Renew a token

C.Read token accessor information

D.Revoke a token

E.Access a token's capabilities against a path

AnswersD, E

Revoking a token requires sudo capability because it destroys a token.

Why this answer

Revoking a token (Option D) requires sudo capability because it is a privileged operation that can disrupt access for users or services. By default, Vault's token revocation endpoints are protected by sudo policies to prevent accidental or unauthorized revocation of tokens, which could lead to denial of service.

Exam trap

HashiCorp often tests the misconception that all token management operations require sudo, but only destructive or highly privileged actions like revocation and capability access (which can reveal policy details) need it, while creation, renewal, and read operations do not.

Practice this question →

17

Multi-Selecthard

Which THREE of the following are true about batch tokens?

Select 3 answers

A.They can be created as orphan tokens

B.They have a TTL that must be set at creation

C.They are non-renewable

D.They are always root tokens

E.They are lightweight and have no storage cost

AnswersB, C, E

Batch tokens require a TTL.

Why this answer

Batch tokens in Vault are designed to be lightweight, non-renewable tokens that must have a Time-To-Live (TTL) set at creation. They are not renewable, meaning once they expire, they cannot be renewed or extended. This makes them ideal for short-lived, high-volume workloads where token lifecycle management is automated.

Exam trap

HashiCorp often tests the misconception that batch tokens can be orphaned or renewed, when in fact they are non-renewable and cannot be created as orphans, which are properties exclusive to service tokens.

Practice this question →

18

MCQhard

An administrator creates a token role with 'allowed_policies' and tries to create a child token. What does this error indicate?

A.The token has been revoked too many times

B.The token's TTL is too short

C.The token's policy is not allowed by the role

D.The token role's token_count_limit has been reached

AnswerD

The token_count_limit restricts the number of tokens a role can create.

Why this answer

The error 'token count per user (3) exceeded' indicates that the number of tokens issued for that entity (user or role) has exceeded the maximum allowed, which is controlled by the 'token_count_limit' parameter in the token role. Option D correctly identifies this limit as the cause. Option A is irrelevant because revocation count is not involved.

Option B is incorrect because the error is about token count, not TTL. Option C is incorrect because the error is about quantity, not policy permissions.

Practice this question →

19

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 allows read on engineering/*.

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 →

20

Matchingmedium

Match each Vault seal type to its description.

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

Concepts

Matches

Split key into shares

Use AWS Key Management Service

Use Azure Key Vault

Use Google Cloud KMS

Use hardware security module

Why these pairings

The correct matches are: Shamir seal uses secret sharing; AWS KMS seal uses AWS KMS; HSM seal uses a hardware module. Common confusions involve swapping cloud-based seals with Shamir or HSM.

Practice this question →

21

Multi-Selectmedium

Which TWO methods can be used to revoke a token without knowing the token ID?

Select 2 answers

A.Using the token's role name if it has one.

B.Using `vault token revoke -mode path` on the auth mount.

C.Using the token's policy name.

D.Using the token's creation time.

E.Using the token accessor.

AnswersB, E

This revokes all tokens created by that mount path without needing individual IDs.

Why this answer

`vault token revoke -mode path` allows revocation of all tokens issued by a specific auth mount (e.g., `userpass/` or `ldap/`) without needing individual token IDs. This method uses the mount's accessor path to revoke all tokens associated with that mount, effectively cleaning up tokens in bulk when their IDs are unknown.

Exam trap

The trap here is that candidates confuse the token accessor (a separate, revocable identifier) with the token ID itself, or assume that policy names or roles can be used to target tokens for revocation, when in fact Vault only supports revocation by token ID, accessor, or mount path.

Practice this question →

22

MCQhard

A Vault administrator wants to ensure that when a parent token is revoked, all child tokens are also automatically revoked. Which option should they use?

A.Use the 'force' parameter when revoking the parent token

B.Revoke the parent token using the 'revoke-orphan' endpoint

C.Set the parent token's orphan property to 'false'

D.Use the 'cascade=true' parameter when revoking the parent token

AnswerD

Cascade revokes all child tokens recursively.

Why this answer

Vault's token revocation system supports a 'cascade' parameter that, when set to 'true', ensures that revoking a parent token also revokes all its child tokens. This is the intended mechanism for hierarchical token cleanup, as child tokens are tracked via the parent token's accessor and are recursively invalidated.

Exam trap

The trap here is that candidates confuse the 'cascade' parameter with the 'force' parameter or mistakenly think that setting an 'orphan' property on a token can retroactively change its parent-child relationship, when in fact orphan status is determined at creation and is immutable.

How to eliminate wrong answers

Option A is wrong because the 'force' parameter in Vault's token revocation API is used to bypass certain checks (e.g., revoking a token that is already expired) and does not affect child token revocation. Option B is wrong because the 'revoke-orphan' endpoint is specifically designed to revoke a token while leaving its child tokens orphaned (i.e., not revoked), which is the opposite of the desired behavior. Option C is wrong because tokens in Vault do not have an 'orphan' property that can be set to 'false'; the orphan status is determined at token creation time via the 'no_parent' flag, and it is immutable after creation.

Practice this question →

23

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 non-renewable and have a limited TTL, suitable for short-lived use.

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 →

24

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

Correct description of period for periodic tokens.

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 →

25

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

This is correct. `vault list auth/token/accessors` lists token accessors, which represent active tokens.

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 →

26

MCQmedium

A periodic token is created with a TTL of 30 days. After 60 days, the token is still in use but suddenly stops working. What is the most likely reason?

A.The token exceeded its max TTL of 60 days

B.The token reached its default max TTL of 32 days

C.The token's explicit_max_ttl was set to a value less than 60 days

D.The token was revoked manually or by an administrator

AnswerD

Periodic tokens can be revoked at any time; the most likely cause after 60 days is revocation.

Why this answer

The token's TTL (time-to-live) of 30 days determines how long it is valid from its creation or last renewal, but it does not set an absolute maximum lifetime. After 60 days, the token would have been renewed or used periodically, so it should still be valid unless an external action invalidated it. Manual revocation by an administrator or via a revocation endpoint is the most likely cause for a token that was working but suddenly stops, as it overrides any TTL-based expiration.

Exam trap

The exam often tests the distinction between TTL (renewal period) and max TTL (absolute lifetime) for periodic tokens. Candidates may mistakenly assume that a periodic token's TTL alone determines its total lifespan, ignoring that such tokens can be renewed indefinitely unless a max TTL or manual revocation intervenes.

How to eliminate wrong answers

Option A is wrong because a token's TTL does not have a hard max of 60 days; the TTL is 30 days, and periodic renewal can extend its life indefinitely unless a max TTL is explicitly set. Option B is wrong because there is no default max TTL of 32 days in Vault; the default max TTL is typically 32 days only for certain token types like periodic tokens if not explicitly configured, but the question states the token is periodic with a 30-day TTL, and after 60 days it would have been renewed, so a 32-day max would have blocked it earlier. Option C is wrong because if explicit_max_ttl were set to less than 60 days, the token would have expired at that limit, not suddenly stop working after 60 days; the token was still in use until day 60, indicating no max TTL was hit.

Practice this question →

27

MCQhard

A cloud-native application uses Vault's Kubernetes auth method to inject tokens into pods. Each pod receives a Vault token with a TTL of 1 hour, renewable. The application is designed to renew tokens before they expire. However, after a recent update, some pods are failing to authenticate with Vault, reporting 'token not found' errors. The operations team checks the Vault audit logs and sees that tokens associated with these pods are being revoked immediately after creation. The pods have not performed any revocation. What is the most likely cause?

A.The Kubernetes auth method's 'kubernetes_ca_cert' has expired, causing Vault to invalidate all tokens.

B.The Kubernetes service account that the pod uses has been deleted or its token has been invalidated, causing Vault to revoke derived tokens.

C.The Vault tokens are being created as batch tokens and are immediately revoked due to a misconfiguration.

D.The pods are attempting to renew tokens too frequently, exceeding a rate limit.

AnswerB

Correct: Vault automatically revokes tokens when the underlying identity (service account) is removed or the JWT becomes invalid.

Why this answer

Vault's Kubernetes auth method creates a derived token that is tied to the Kubernetes service account token used during login. If the Kubernetes service account is deleted or its token is invalidated (e.g., due to rotation or expiration), Vault immediately revokes all derived tokens. The audit logs confirm revocation without pod action, and the TTL/renewal design points to an external dependency failure, not a Vault-side issue.

Exam trap

Hashicorp often tests the dependency between Kubernetes service account tokens and Vault-derived tokens, trapping candidates who assume the issue is with Vault's token configuration (TTL, batch, or renewal) rather than the upstream identity source.

How to eliminate wrong answers

Option A is wrong because the 'kubernetes_ca_cert' is used to validate the Kubernetes API server's TLS certificate during auth method configuration; its expiration would prevent new logins entirely, not cause immediate revocation of already-issued tokens. Option C is wrong because batch tokens are non-renewable and have a fixed lifetime, but they are not automatically revoked upon creation; the 'token not found' error and immediate revocation suggest a parent token invalidation, not a batch token misconfiguration. Option D is wrong because Vault does not enforce a rate limit on token renewal that would cause revocation; exceeding a rate limit would result in a 429 HTTP response or throttling, not token revocation.

Practice this question →

28

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 custom policy with minimal privileges follows the principle of least privilege.

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 →

29

MCQeasy

A DevOps team uses Vault to manage secrets for a microservices application. The application authenticates to Vault using AppRole, and each service obtains a periodic token with a TTL of 24 hours and a period of 1 hour. The tokens are used to read secrets from a path. Recently, the team noticed that some services are unable to read secrets after a few hours, with error messages indicating that the token is not authorized or has expired. Upon investigation, the team finds that the tokens are being renewed properly but still fail after some time. What is the most likely cause of this issue?

A.The Vault server's maximum number of tokens per client has been exceeded.

B.The tokens are not being renewed correctly due to a bug in the renewal logic.

C.The tokens have a shorter max TTL than the period, causing them to expire before they can be renewed.

D.The AppRole secret ID is being revoked, causing tokens to become invalid.

AnswerC

Correct: Periodic tokens have a max TTL that caps total lifetime; if max TTL is less than the period, the token will expire and cannot be renewed.

Why this answer

The tokens have a period of 1 hour and a TTL of 24 hours, but the max TTL (maximum allowed lifetime) for the token or the role is likely set to a value shorter than the period. In Vault, the period controls how often the token must be renewed, while the max TTL is the absolute upper limit on the token's lifetime. If the max TTL is less than the period (e.g., 30 minutes), the token will expire before the next renewal attempt, even if renewal logic is correct.

Exam trap

The trap here is that candidates assume 'renewed properly' means the token is indefinitely valid, overlooking that Vault's max TTL can override periodic renewal and cause silent expiration.

How to eliminate wrong answers

Option A is wrong because Vault does not enforce a hard limit on the number of tokens per client by default; token exhaustion would cause creation failures, not post-renewal authorization errors. Option B is wrong because the scenario explicitly states tokens are being renewed properly, so a renewal logic bug is not the cause. Option D is wrong because revoking the AppRole secret ID would prevent new token creation but would not affect already-issued tokens that are being renewed successfully.

Practice this question →

30

MCQhard

A token with this policy attempts to read the secret at path 'secret/data/engineering/special'. Will the read succeed?

A.Yes, because the first path grants read on all secrets under 'secret/data/engineering/'

B.No, because the token needs an additional policy to read from that specific path

C.Yes, because the second path implicitly allows read

D.No, because the second path is more specific and only allows create/update

AnswerA

The wildcard includes 'special'.

Why this answer

The first path grants read on secret/data/engineering/*, which includes 'special'. The second path grants create/update on a different path (without 'data' prefix) and does not deny read. Vault merges capabilities, so read is allowed.

Option B is wrong because ACL merging does not cause one statement to override another unless there is an explicit deny. Option C is wrong because the token already has a policy covering that path. Option D is wrong because the second path does not grant read but also does not deny it.

Exam trap

A common trap is thinking that a more specific path overrides a less specific one. In Vault, ACL policies are additive; permissions are merged unless there is an explicit denial.

Practice this question →

31

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

Token policies are set at creation and do not change.

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 →

32

MCQmedium

A team needs to issue unique tokens to each of 100 microservices, each with its own policy, and ensure that revoking one token does not affect others. Which token feature should they use?

A.Periodic tokens

B.Orphan tokens

C.Token accessors

D.Token roles with distinct policies

AnswerD

Token roles enable creation of tokens with specific policies, providing isolation.

Why this answer

Vault token roles allow you to define distinct policies per token, ensuring each microservice gets a unique token with its own policy. When a token is revoked, only that specific token is invalidated, leaving all others unaffected. This satisfies the requirement for independent revocation without impacting other services.

Exam trap

Vault often tests the misconception that token accessors (Option C) provide policy isolation, but accessors are merely handles for token management and do not control policy assignment or revocation independence.

How to eliminate wrong answers

Option A is wrong because periodic tokens are designed for long-lived access with automatic renewal, not for ensuring independent revocation; revoking one periodic token does not inherently isolate others, but the feature does not address policy uniqueness per microservice. Option B is wrong because orphan tokens are tokens whose parent has been revoked, leaving them without a valid lineage; this is a security risk and does not provide a mechanism for distinct policies or isolated revocation. Option C is wrong because token accessors are identifiers used to perform token operations without exposing the token ID itself; they do not assign policies or guarantee that revoking one token does not affect others.

Practice this question →

33

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

Explicit_max_ttl caps the total lifetime regardless of renewals.

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 →

34

Multi-Selecthard

Which THREE of the following are valid parameters when creating a token via the API?

Select 3 answers

A.num_uses

B.ttl

C.policies

D.accessor

E.max_ttl

AnswersA, B, C

num_uses is a valid parameter for token creation; it limits the number of times the token can be used.

Why this answer

When creating a token via the Vault API, valid parameters include `num_uses` to set the number of times the token can be used, `ttl` to set the time-to-live, and `policies` to attach policies. `max_ttl` is not a direct input parameter; it is a property that may be inherited from the role or mount configuration. `accessor` is a read-only field returned in the response, not an input parameter.

Exam trap

Candidates often mistake the `max_ttl` field as an input parameter for token creation, but it is not settable at creation time. They may also incorrectly consider `accessor` as an input parameter, but it is only returned in the response.

Practice this question →

35

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 ensures the token expires quickly.

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 →

36

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 →

37

MCQmedium

Refer to the exhibit. An admin wants to ensure this token can be used for 60 hours total. Which action should be taken?

A.Increase the creation_ttl to 60h.

B.The token will expire after 48h, so increase explicit_max_ttl to 60h on the current token.

C.Create a new token with explicit_max_ttl=60h.

D.The token already can be used for 60h because it is renewable.

AnswerC

A new token with appropriate max TTL is required.

Why this answer

The token's current `explicit_max_ttl` is set to 48h, and the `creation_ttl` (24h) cannot be increased beyond that bound. To achieve a total lifetime of 60 hours, a new token must be created with `explicit_max_ttl=60h`, which overrides the default or role-based TTL limits and sets the absolute maximum lifetime for the token.

Exam trap

HashiCorp Vault exams often test the misconception that `explicit_max_ttl` can be modified on an existing token or that renewal alone can extend a token's lifetime beyond its `explicit_max_ttl`.

How to eliminate wrong answers

Option A is wrong because increasing `creation_ttl` to 60h would be capped by the existing `explicit_max_ttl` of 48h, so the token would still expire at 48h. Option B is wrong because `explicit_max_ttl` cannot be changed on an existing token; it is a creation-time parameter and is immutable after issuance. Option D is wrong because the token is renewable, but renewal only extends the token's lifetime up to the `explicit_max_ttl` (48h), not beyond it, so it cannot reach 60 hours total.

Practice this question →

38

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 can be renewed before expiration as long as they are within max TTL.

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 →

39

Multi-Selecteasy

Which TWO of the following are valid token states?

Select 2 answers

A.Expired

B.Orphan

C.Suspended

D.Revoked

E.Active

AnswersD, E

A revoked token is invalid.

Why this answer

'Revoked' is a valid token state in Vault. Tokens can be explicitly revoked, rendering them unusable. Option E is correct because 'Active' is the initial state of a token when it is created and remains valid until it expires or is revoked.

Options A, B, and C are not valid token states in Vault: 'Expired' is a result of TTL expiry but not a distinct state; 'Orphan' describes a token whose parent is gone, but it is still considered active if not revoked; 'Suspended' is not a Vault token state.

Exam trap

HashiCorp often tests the distinction between token lifecycle states and token properties (like orphan status) to confuse candidates who may think 'orphan' or 'suspended' are official states, when in fact only 'Active' and 'Revoked' are the primary valid token states in Vault.

Practice this question →

40

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

Removing explicit_max_ttl allows tokens to be renewed up to the max TTL of 168h.

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 →

41

MCQhard

A large enterprise runs Vault in a production environment with hundreds of applications. Each application uses a unique Vault token with a 30-day TTL. The tokens are created by a central CI/CD pipeline using Vault's token auth method. Recently, the security team noticed that several tokens with suspicious activity have been created with a 90-day TTL, and the tokens appear to be long-lived and not revoked after use. The CI/CD pipeline logs show no anomalies. The audit logs reveal that the tokens in question were created by a human user 'jdoe' using a token with the 'admin' policy. The 'admin' policy grants '*' capabilities on all paths. The Vault token accessor shows that the suspicious tokens have a 'creation_ttl' of 2160h (90 days) and 'explicit_max_ttl' of 0s. The Vault configuration uses a default lease TTL of 24h and a max lease TTL of 720h (30 days). Which action should the security team take to prevent such incidents in the future without breaking existing applications?

A.Remove the 'admin' policy from all human users and require them to use a different authentication method.

B.Implement a Sentinel policy that blocks token creation by any user except the CI/CD pipeline.

C.Create a dedicated token role with a max TTL of 720h (30 days) and restrict token creation to that role; revoke the 'admin' policy's create permission on auth/token/create.

D.Reduce the system max lease TTL to 720h (30 days) and enforce that all tokens must have explicit_max_ttl set.

AnswerC

This enforces a TTL limit on tokens and restricts who can create tokens, preventing unauthorized long-lived tokens.

Why this answer

The root cause is that the 'admin' policy grants unrestricted token creation permissions, allowing a human user to bypass the intended CI/CD pipeline controls and create tokens with a 90-day TTL. By creating a dedicated token role with a max TTL of 720h (30 days) and revoking the 'admin' policy's create permission on 'auth/token/create', the team enforces a maximum TTL of 30 days for all tokens created via the token auth method, matching the system's max lease TTL and preventing long-lived tokens without breaking existing applications that use the CI/CD pipeline.

Exam trap

HashiCorp often tests the misconception that reducing the system max lease TTL alone will prevent long-lived tokens, but the trap here is that tokens with 'explicit_max_ttl' set to 0s or tokens created via roles with higher max TTLs can bypass this limit, so the correct solution is to restrict token creation permissions and enforce TTLs at the role level.

How to eliminate wrong answers

Option A is wrong because removing the 'admin' policy from human users does not address the underlying issue of unrestricted token creation permissions; human users could still create tokens with excessive TTLs using other policies or authentication methods, and it would break legitimate administrative workflows. Option B is wrong because implementing a Sentinel policy that blocks token creation by any user except the CI/CD pipeline would prevent human users from creating tokens entirely, which is overly restrictive and would break legitimate use cases where human users need to create tokens (e.g., for emergency access or break-glass scenarios). Option D is wrong because reducing the system max lease TTL to 720h (30 days) would not affect tokens that already have an 'explicit_max_ttl' of 0s, as the system max lease TTL only applies to tokens without an explicit max TTL; the suspicious tokens already bypassed this by having no explicit max TTL, so this change would not prevent future incidents.

Practice this question →

42

Multi-Selectmedium

A DevOps engineer is troubleshooting an issue where a token cannot read a secret from the KV v2 engine at path 'secret/team-alpha/db-creds'. The token's policy includes the following: path "secret/team-alpha/*" { capabilities = ["read"] }. Which TWO reasons could explain the failure?

Select 2 answers

A.The user needs to use the token's accessor to read the secret

B.The path in the policy needs to be 'secret/data/team-alpha/*'

C.The token may have an additional restrictive policy from a parent token

D.The secret engine is not tuned to allow reads

E.The token is not a child of the root token

AnswersB, C

KV v2 requires the 'data' prefix in policy paths for secret access.

Why this answer

KV v2 engine requires the path prefix 'data/' after the mount path to access the actual secret data. The policy path 'secret/team-alpha/*' only covers the metadata and sub-paths, not the data endpoint. To read a secret, the policy must specify 'secret/data/team-alpha/*' with 'read' capability, as the actual secret retrieval occurs via the 'data/' sub-path.

Exam trap

Hashicorp Vault often tests the distinction between KV v1 and KV v2 path structures, specifically that KV v2 requires the 'data/' prefix in policies, which candidates frequently overlook.

Practice this question →

43

MCQmedium

A DevOps team generates a large number of short-lived tokens for automated deployments. They want to minimize storage overhead and avoid the need for token revocation. Which token type should they use?

A.Periodic tokens

B.Orphan tokens

C.Service tokens

D.Batch tokens

AnswerD

Batch tokens are not stored and have no revocation, ideal for short-lived automated tasks.

Why this answer

Batch tokens are the correct choice because they are designed for high-frequency, short-lived workloads where storage overhead and revocation are concerns. They are created by a parent token, have a configurable TTL (often minutes), and are never stored in Vault's storage backend, eliminating the need for revocation and reducing storage footprint.

Exam trap

The trap here is that candidates confuse 'batch tokens' with 'service tokens' or assume all tokens require revocation, but the exam tests the specific understanding that batch tokens are stateless and avoid storage overhead, a key differentiator for high-volume automation scenarios.

How to eliminate wrong answers

Option A is wrong because 'Periodic tokens' are not a standard Vault token type; the correct term is 'periodic service tokens' which are long-lived and require explicit renewal, not suited for short-lived automated deployments. Option B is wrong because 'Orphan tokens' are tokens that have lost their parent relationship but still exist in storage and can be revoked, offering no storage or revocation benefit. Option C is wrong because 'Service tokens' are the default token type in Vault, which are stored in the backend and require revocation, thus increasing storage overhead and management complexity.

Practice this question →

44

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

If max_ttl is less than the requested TTL, the token will expire at max_ttl, causing it to stop working after 1 hour.

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 →

45

Multi-Selecthard

Which TWO of the following scenarios require the use of a periodic token?

Select 2 answers

A.A token that never expires and has a TTL of 0.

B.A human operator who needs a token that can be used for multiple sessions.

C.A batch job that must continue running even if the parent token is revoked.

D.A token that should not be revoked when the token that created it is revoked.

E.A long-running application that needs a token that can be renewed indefinitely.

AnswersC, E

Periodic tokens are not children of a parent token; they are created by sudo users and are independent.

Why this answer

A periodic token is designed to allow a child token (e.g., for a batch job) to continue operating even after its parent token is revoked. This is achieved by setting the token's period to a finite duration, which decouples the child token's lifecycle from the parent's, enabling the batch job to run to completion without interruption.

Exam trap

HashiCorp often tests the distinction between periodic tokens and renewable tokens, trapping candidates who think periodic tokens are for multi-session human use or that they require a TTL of 0, when in fact periodic tokens are for automated, long-lived processes that must outlive their parent.

Practice this question →

46

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

The accessor can be used to lookup token metadata.

Why this answer

A token accessor is a non-sensitive reference to a Vault token that allows certain operations without exposing the token ID itself. The `lookup` and `revoke` operations are valid uses of a token accessor because they can be performed using the accessor via the Vault API or CLI (e.g., `vault token lookup -accessor <accessor>` and `vault token revoke -accessor <accessor>`). These operations do not require the actual token value, preserving security while enabling token management.

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 →

47

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 safe for logging and can be used to revoke or look up metadata without the token ID.

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 →

48

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 policy does not cover the accessor endpoint.

Why this answer

The policy grants sudo on 'auth/token/lookup', but the endpoint for lookup by accessor is 'auth/token/lookup-accessor', which is a different path. Therefore, this policy does not allow that operation. Option A is wrong because the path is different.

Option C is wrong because the policy does not have read or create on the correct path. Option D is wrong because the token has capabilities, just not on the required path.

Practice this question →

49

Multi-Selecthard

Which TWO of the following are valid reasons for a token renewal to fail with a 'lease not found' or 'token not found' error? (Select exactly 2 options.)

Select 2 answers

A.The token has expired

B.The token has num_uses set to 0

C.The token has exceeded its max TTL

D.The token is an orphan token

E.The token is a batch token

AnswersA, E

An expired token will return token not found.

Why this answer

A Vault token that has expired is no longer valid for renewal. When a token's lease expires, the auth backend or secret engine removes the lease entry, so any renewal attempt returns 'lease not found' or 'token not found'. Option E is correct because batch tokens are designed to be non-renewable; they have no associated lease, so any renewal attempt results in a 'token not found' error.

This is a fundamental behavior of Vault's lease lifecycle: expired tokens and batch tokens cannot be renewed and must be re-authenticated.

Exam trap

HashiCorp Vault exams often test the distinction between token expiration (which removes the lease) and other token properties like num_uses or orphan status, leading candidates to incorrectly select options that describe valid tokens that are still renewable.

Practice this question →

50

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

The remaining time until max TTL is 4h, so renewal grants a 4h TTL.

Why this answer

The explicit max TTL is 24h. After 20h, the remaining time until max TTL is 4h. Renewal will set the token duration to the minimum of the requested TTL (12h) and the remaining max TTL (4h), resulting in a 4h TTL.

After that, the token expires.

Practice this question →

51

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

This endpoint revokes the token associated with the accessor.

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 →

52

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

This shows what actions the current token can perform on the path.

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 →

53

Multi-Selectmedium

Which THREE of the following token properties are immutable after token creation? (Select exactly 3 options.)

Select 3 answers

A.Period

B.Policies

C.Renewable

D.Max TTL

E.TTL

AnswersA, B, D

Period is immutable. It defines the renewal period and cannot be changed after token creation.

Why this answer

In Vault, certain token properties are set at creation and cannot be changed later. The immutable properties are: Period (the renewal period), Policies (the list of policies attached to the token), and Max TTL (the maximum time-to-live). These are fixed in the token's metadata.

In contrast, the Renewable flag, though set at creation, is not considered immutable because it can be effectively changed by renewing the token or by updating the token's role policies that affect renewal behavior. TTL is the current time-to-live and decreases over time, so it is mutable.

Exam trap

A common pitfall is assuming that Renewable is immutable because it is set at creation. However, in Vault, the renewable property can be effectively changed through token renewal or role updates, making it mutable. The truly immutable properties are Period, Policies, and Max TTL.

Practice this question →

54

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 enable revocation by providing the accessor instead of the token ID.

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 →

55

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

Once max TTL is reached, the token expires and renewal is not possible.

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 →

56

Multi-Selectmedium

Which THREE of the following are valid sources of token TTL?

Select 3 answers

A.System default TTL

B.Mount path configuration

C.Policy TTL

D.Explicit TTL set during token creation

E.Role TTL in an auth method

AnswersA, D, E

Vault has a default TTL for tokens.

Why this answer

Vault has a system default TTL that applies to tokens when no other TTL source is specified. This default is typically 32 days (2764800 seconds) and serves as the maximum possible TTL for a token unless overridden by a shorter TTL from another source. The system default TTL is defined in the Vault server configuration and acts as a fallback to ensure tokens do not live indefinitely.

Exam trap

HashiCorp often tests the misconception that policies can set TTL values, but policies only define permissions, not token lifetimes; candidates may confuse policy with role configuration in auth methods.

Practice this question →

57

MCQhard

Refer to the exhibit. A token was created with a creation_ttl of 24h, explicit_max_ttl of 10h, and a current ttl of 12h. What will happen when the token reaches its explicit_max_ttl?

A.The token will be automatically renewed by Vault.

B.The token will remain valid until the creation_ttl expires.

C.The token will be revoked immediately.

D.The token will have its TTL extended to 24h.

AnswerC

explicit_max_ttl is an absolute deadline; the token is revoked exactly at that time.

Why this answer

The explicit_max_ttl overrides any other TTL settings. When the token reaches its explicit_max_ttl (10h from creation), it will be revoked by Vault regardless of renewable or creation_ttl. Options suggesting renewal or extension are incorrect.

Practice this question →

58

MCQmedium

A DevOps engineer notices that a long-running application using a Vault token fails after 24 hours. The token was created with a TTL of 48h. The token role has a default TTL of 48h and a max TTL of 72h. What is the most likely cause of the failure?

A.The token was manually revoked by an administrator.

B.The token was revoked due to a policy violation.

C.The token is a batch token and cannot be renewed.

D.The mount's max TTL for the token is 24h, overriding the role's setting.

AnswerD

The mount's max TTL is applied first and can cause early expiration.

Why this answer

The most likely cause is that the mount's max TTL for the token is set to 24h, which overrides the role's max TTL of 72h. In Vault, the effective TTL of a token is the minimum of the role's TTL, the mount's max TTL, and the system's max TTL. Since the token fails exactly after 24 hours, the mount's max TTL of 24h is the limiting factor, causing the token to expire even though the role allows up to 48h.

Exam trap

Candidates often mistakenly assume the role's TTL is the sole determinant, ignoring that mount-level and system-level TTLs can override it.

How to eliminate wrong answers

Option A is wrong because there is no evidence of manual revocation; the failure occurs precisely at the 24-hour mark, which aligns with a TTL expiration rather than an administrative action. Option B is wrong because a policy violation would typically cause immediate revocation or denial of operations, not a delayed failure after 24 hours. Option C is wrong because batch tokens cannot be renewed, but they still have a TTL; if the token were a batch token, it would expire based on its TTL, but the question states the token was created with a TTL of 48h, and the failure at 24h points to a mount-level override, not the batch token's non-renewability.

Practice this question →

59

Multi-Selecthard

Which THREE statements about token accessors are true?

Select 4 answers

A.They can be used to look up token metadata without the token ID

B.They can be used to renew the token

C.They can be used to revoke the token

D.They are human-readable strings

E.They are unique identifiers for each token

AnswersA, B, C, E

Correct. The lookup-accessor endpoint retrieves token metadata using the accessor without needing the token ID.

Why this answer

Token accessors have multiple capabilities. Option A is correct because accessors allow lookup of token metadata without the token ID via the lookup-accessor endpoint. Option B is correct because the renew-accessor endpoint allows token renewal using only the accessor.

Option C is correct because the revoke-accessor endpoint allows token revocation using the accessor. Option E is correct because each token has a unique accessor generated at creation. Option D is incorrect because accessors are UUID strings, not human-readable.

Exam trap

A common misconception is that token accessors cannot perform renewal, but Vault actually provides a dedicated renew-accessor endpoint. However, note that renewal via accessor may require appropriate permissions.

Practice this question →

60

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

If the token's lifetime exceeds max_ttl, renewal is denied and the token becomes invalid.

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 →

61

Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

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 →

62

MCQeasy

Your company uses Vault to manage secrets for a fleet of microservices running on Kubernetes. Each microservice has a service account that authenticates to Vault using the Kubernetes auth method and receives a token with a policy granting access to its secrets. Recently, the team noticed that some tokens are being revoked prematurely, causing services to lose access to secrets. The tokens are created with a TTL of 24 hours and are set to be renewable. The Vault servers are configured with a default max_ttl of 24 hours. The tokens are renewed by the client libraries every 12 hours. Despite this, tokens are sometimes invalid before 24 hours. What should the team do to prevent this issue?

A.Set the token's num_uses to a high number to prevent premature revocation.

B.Change the tokens to periodic tokens so they never expire.

C.Decrease the token TTL to 12 hours so that renewal happens before the max_ttl is reached.

D.Increase the max_ttl on the token role to 48 hours to allow renewal beyond 24 hours.

AnswerD

By increasing max_ttl, tokens can be renewed and remain valid for a longer period, preventing premature expiration.

Why this answer

The tokens are being revoked prematurely due to the Vault server's default max_ttl of 24 hours. Even though the token TTL is 24 hours and the client renews every 12 hours, the max_ttl caps the total lifetime of the token, including renewals. By increasing the max_ttl on the token role to 48 hours, the token can be renewed beyond the initial 24-hour window, preventing premature invalidation.

Exam trap

HashiCorp often tests the distinction between TTL and max_ttl, and the trap here is that candidates assume renewing a token resets its entire lifetime, not realizing that max_ttl imposes a hard cap on total token duration.

How to eliminate wrong answers

Option A is wrong because setting num_uses to a high number controls the number of times a token can be used, not its lifetime; premature revocation here is a TTL issue, not a usage count issue. Option B is wrong because periodic tokens never expire only if they are continually renewed before their period ends, but they still respect max_ttl unless explicitly set to not expire, which is not the default behavior and would introduce security risks. Option C is wrong because decreasing the token TTL to 12 hours would cause the token to expire before the 12-hour renewal interval, leading to even more frequent loss of access; the renewal happens every 12 hours, so a 12-hour TTL would not allow a successful renewal before expiration.

Practice this question →

63

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

They have a fixed lifetime and cannot be changed.

Why this answer

Batch tokens are designed to be lightweight and do not support renewal or revocation. They are not persisted in Vault's storage backend; instead, they are generated on-the-fly using a keyed hash (HMAC) and validated by the server without storing them. This makes them ideal for high-frequency, short-lived workloads where the overhead of managing a full token lifecycle is undesirable.

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 →

64

Multi-Selectmedium

An administrator needs to issue tokens that are automatically renewable by the client (so they can stay alive as long as renewed) but must expire no later than 30 days. Which TWO token parameters should be configured on the token role?

Select 2 answers

A.renewable

B.ttl

C.max_ttl

D.period

E.num_uses

AnswersC, D

Max_ttl enforces an absolute maximum lifetime.

Why this answer

(max_ttl) is correct because it enforces the absolute maximum lifetime of the token, ensuring it expires no later than 30 days regardless of renewals. Option D (period) is correct because setting a period makes the token automatically renewable by the client, allowing it to stay alive as long as it is renewed before the period expires. Together, period enables automatic renewal behavior and max_ttl caps the total lifespan at 30 days.

Exam trap

A common mistake in Vault is confusing 'ttl' with 'period'. Candidates often think 'ttl' enables automatic renewal, but only 'period' provides that behavior with a sliding window.

Practice this question →

65

MCQmedium

A security team wants to enforce that all tokens created by a specific AppRole can only be used to read secrets from the path 'secret/data/team-a/*'. They have configured the AppRole with token_policies that include that path. However, a developer uses the token created from this AppRole to create a child token with broader policies, granting access to 'secret/data/team-b/*'. The security team wants to prevent such privilege escalation. Which action should be taken to ensure that child tokens cannot have broader policies than the parent?

A.Regularly audit and revoke tokens that violate policy

B.Configure the AppRole with 'token_allowed_policies' to restrict which policies child tokens can use

C.Use a root token to create all tokens and distribute them securely

D.Set the parent token's 'orphan' property to 'true'

AnswerB

Configuring the AppRole's token_allowed_policies metadata restricts which policies a child token can be assigned. By setting allowed_policies on the parent token, or on the AppRole via token_allowed_policies, child tokens can only have those specific policies, preventing broader policy assignment.

Why this answer

In Vault, when a token creates a child token, the child can be assigned any policies that the parent token has access to, including broader policies, unless the parent token has an `allowed_policies` metadata that restricts which policies the child can use. By configuring the AppRole with `token_policies` and setting `allowed_policies` on the generated token (or on the AppRole itself via `token_allowed_policies`), the parent token can only create child tokens with those specific policies, preventing privilege escalation. Option A is reactive and does not prevent escalation.

Option C is incorrect because root tokens can create any token without restriction. Option D is incorrect because setting `orphan=true` makes the token independent but does not restrict child token policies.

Practice this question →

66

MCQhard

A root token creates token T1 with a TTL of 1 hour. T1 then creates token T2 with a TTL of 2 hours. After 30 minutes, T1 is revoked without using the 'cascade' option. What happens to T2?

A.T2 expires immediately

B.T2 becomes an orphan token and continues to work until its TTL expires

C.T2 is also revoked immediately

D.T2's TTL is reduced to match T1's remaining TTL

AnswerB

Children of revoked tokens become orphans and remain functional.

Why this answer

When a root token creates T1 and T1 creates T2, T2 is a child token of T1. Revoking T1 without the 'cascade' option only revokes T1 itself and its immediate leases, but does not propagate revocation to descendant tokens. T2 becomes an orphan token, meaning it loses its parent but continues to function independently until its own TTL of 2 hours expires.

This behavior is by design in Vault to allow token hierarchies without forced cascading revocation.

Exam trap

The trap here is that candidates often assume token revocation always cascades to all descendants, confusing the default behavior with the optional 'cascade' flag, which must be explicitly set to propagate revocation.

How to eliminate wrong answers

Option A is wrong because T2 does not expire immediately; it continues to work as an orphan token until its own TTL expires. Option C is wrong because T2 is not revoked immediately; only T1 is revoked, and without the cascade flag, child tokens are not affected. Option D is wrong because T2's TTL remains unchanged at 2 hours; it is not reduced to match T1's remaining TTL, as Vault does not adjust child token TTLs upon parent revocation.

Practice this question →

67

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

Policies define access; attaching the policy grants the token those permissions.

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 →

68

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 are not revoked when the parent expires.

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 →

69

MCQeasy

A security policy requires that all tokens are revoked when a user leaves the organization. What is the most efficient way to revoke all tokens issued to that user?

A.Use the identity/entity endpoint to revoke all tokens associated with the user's entity

B.Revoke each token individually using its accessor

C.Use the auth/token/revoke-prefix endpoint with the user's token path

D.Restart the Vault server

AnswerA

Entity-based revocation revokes all tokens linked to the entity.

Why this answer

Vault associates all tokens issued to a user with their entity identity. Using the identity/entity endpoint to revoke the entity's tokens is the most efficient method, as it leverages Vault's identity system to revoke all tokens linked to that entity in a single API call, rather than requiring individual token lookups or path-based revocation.

Exam trap

Candidates may confuse the auth/token/revoke-prefix endpoint as a user-specific tool when it actually operates on token creation paths, not user identities. Vault's identity-based revocation via the identity/entity endpoint is the correct method.

How to eliminate wrong answers

Option B is wrong because revoking each token individually using its accessor is inefficient and impractical when a user has many tokens, requiring enumeration of all tokens and multiple API calls. Option C is wrong because the auth/token/revoke-prefix endpoint revokes tokens based on a path prefix (e.g., auth/token/create), not by user identity, so it would revoke tokens from multiple users sharing that path, not just the specific user. Option D is wrong because restarting the Vault server does not revoke tokens; tokens are persisted in storage and would remain valid after a restart, and this approach is disruptive and not a targeted revocation method.

Practice this question →

70

Multi-Selectmedium

Which TWO of the following are true about Vault token accessors?

Select 1 answer

A.An accessor is the same as the token ID.

B.An accessor can be used to revoke a token without having the token ID.

C.Accessors are unique only within a namespace.

D.An accessor is required to look up token properties.

E.An accessor can be used to renew a token without having the token ID.

AnswersB

Correct: The accessor can be used to revoke a token without having the token ID, providing a secure way to manage tokens.

Why this answer

Vault token accessors allow token revocation without the token ID itself. The accessor is a separate, non-sensitive reference that can be used to perform token revocation. Option E is incorrect because Vault does not provide a renew-accessor endpoint; token renewal requires the actual token ID.

Exam trap

A common misconception is that the accessor can be used to renew a token, but Vault does not provide a renew-accessor endpoint; accessors only support token revocation and lookup.

Practice this question →

71

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 →

72

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 secrets are accessed under the 'data' sub-path.

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 →

73

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 the token from being renewed.

Why this answer

Setting `renewable` to `false` on the token role explicitly prevents the token from being renewed, ensuring it cannot have its lifetime extended. Option D is correct because `explicit_max_ttl` on the token overrides any system or role defaults, enforcing a fixed, non-extendable lifetime that matches the desired TTL. Together, these two configurations guarantee that the token has a fixed lifetime and cannot be renewed.

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 →

74

MCQhard

An organization uses Vault's token auth method to issue tokens for long-running services. They want to ensure that tokens are automatically revoked after 30 days, even if the service repeatedly renews them. Which token role configuration achieves this?

A.Set ttl to 720h without setting max_ttl

B.Set explicit_max_ttl to 720h on the token role

C.Set period to 720h without setting max_ttl

D.Set max_ttl to 720h on the token role

AnswerD

max_ttl imposes a hard limit on the token's total lifetime, regardless of renewals.

Why this answer

Setting `max_ttl` to 720h (30 days) on the token role enforces an absolute upper lifetime for the token, regardless of how many times it is renewed. This ensures the token is automatically revoked after 30 days, even if the service repeatedly renews it before the current TTL expires.

Exam trap

The trap here is confusing `ttl` (which resets on renewal) with `max_ttl` (which enforces an absolute lifetime), leading candidates to choose Option A, thinking a long TTL alone will expire the token after 30 days.

How to eliminate wrong answers

Option A is wrong because setting only `ttl` to 720h without `max_ttl` allows the token to be renewed indefinitely, as each renewal resets the TTL, so the token could live far beyond 30 days. Option B is wrong because `explicit_max_ttl` is not a valid token role parameter in Vault; the correct parameter for enforcing an absolute lifetime is `max_ttl`. Option C is wrong because setting `period` to 720h without `max_ttl` creates a periodic token that can be renewed indefinitely as long as it is renewed before the period expires, which does not enforce a hard 30-day limit.

Practice this question →

75

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

Expiration leads to revocation of the token and its 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 →

Page 1 of 2 · 92 questions totalNext →

Ready to test yourself?

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

Start 20-question session