Courseiva

CCNA Assess Vault tokens Questions

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

Practice these questionsDomain overviewAll questions
76
MCQhard

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

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

Explicit max TTL cannot be exceeded by renewal.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
77
MCQmedium

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

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

TTL ensures the token expires automatically.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
78
MCQmedium

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

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

Batch tokens are not renewable and return a 'no matching lease' error.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
79
MCQmedium

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

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

Accessor is a non-sensitive reference for token operations.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
80
MCQeasy

A development team needs tokens that can be renewed automatically as long as they are still in use, up to a maximum lifetime of 72 hours. Which token type and configuration should be used?

A.Periodic token with a TTL of 72h
B.Orphan token with a TTL of 1h
C.Batch token with a TTL of 72h
D.Service token with a TTL of 1h and max TTL of 72h
AnswerD

Service tokens can be renewed until max TTL is reached.

Why this answer

A service token with a TTL of 1 hour and a max TTL of 72 hours allows automatic renewal as long as the token is still in use, up to the maximum lifetime of 72 hours. This configuration ensures that the token's TTL is extended on each use, preventing expiration during active sessions while enforcing an absolute upper limit.

Exam trap

A common trap in Vault exams is that candidates confuse a fixed TTL with automatic renewal, assuming any token with a 72-hour TTL will renew itself, when only service tokens with a max TTL can do so.

How to eliminate wrong answers

Option A is wrong because a periodic token with a TTL of 72 hours does not support automatic renewal; it has a fixed lifetime and will expire after 72 hours regardless of continued use. Option B is wrong because an orphan token with a TTL of 1 hour is designed for short-lived, non-renewable use cases and cannot be automatically renewed, nor does it have a max TTL to extend its lifetime. Option C is wrong because a batch token with a TTL of 72 hours is intended for non-interactive, one-time use and does not support automatic renewal based on continued usage.

Practice this question →
81
MCQhard

An organization uses Vault with AWS IAM auth. After rotating the AWS IAM role credentials, users are unable to authenticate with Vault. The Vault audit logs show 'permission denied' for the AWS auth method. What is the most likely cause?

A.The IAM role trust policy was not updated after credential rotation
B.The Vault token TTL expired
C.The client token used for AWS auth is revoked
D.The AWS secret engine is disabled
AnswerD

Correct. If the AWS secret engine is disabled, Vault cannot process AWS authentication requests, resulting in 'permission denied'.

Why this answer

After rotating AWS IAM role credentials, the most likely cause of authentication failure is that the AWS secret engine was disabled during the rotation process. The 'permission denied' error in audit logs indicates the auth method is not enabled. While credential rotation itself does not directly cause engine disablement, it is possible that maintenance activities disabled it.

Options A, B, and C are unrelated: trust policies do not contain credentials, token TTL and revocation affect client tokens, not the auth method.

Exam trap

Candidates often mistakenly think credential rotation requires updating IAM trust policies, but trust policies never contain credential material. The real issue could be an inadvertently disabled secret engine.

How to eliminate wrong answers

Option B is wrong because a Vault token TTL expiry would cause authentication failures for subsequent requests using that token, not for the initial AWS auth method login itself, and the audit log would show a different error (e.g., 'token expired'). Option C is wrong because the client token used for AWS auth is the temporary token returned by the AWS auth method after successful login; if it were revoked, the error would occur after authentication, not during the AWS auth method call. Option D is wrong because if the AWS secret engine were disabled, the audit log would show an 'engine disabled' or 'path not found' error, not a 'permission denied' error specific to the AWS auth method.

Practice this question →
82
MCQmedium

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

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

Correct: Periodic tokens cannot exceed explicit_max_ttl; after 24 hours, renewal fails and token expires.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
83
MCQmedium

The token was created 12 hours ago and has not been used yet. What will happen if the token is not used or renewed?

A.It can be renewed indefinitely if used
B.It will expire when the number of uses reaches 0
C.It will expire immediately because it was not used within 12 hours
D.It will expire in 12 hours
AnswerD

The current TTL is 12h, so without renewal, it expires in 12 hours.

Why this answer

Vault tokens have a configurable Time-To-Live (TTL) and a maximum TTL. If a token is not used within its TTL, it will expire. Since the token was created 12 hours ago and has not been used, and the default TTL for many token types in Vault is 24 hours, the token will expire in 12 hours (the remaining TTL).

This is because the token's TTL begins counting down from creation, not from first use.

Exam trap

A common misconception is that tokens expire after a fixed period of non-use, but in Vault the TTL counts down from creation, and non-use simply means the token will not be renewed or its TTL extended.

How to eliminate wrong answers

Option A is wrong because a token cannot be renewed indefinitely; it has a maximum TTL (often 24 hours by default) beyond which it cannot be renewed, even if used. Option B is wrong because tokens do not have a 'number of uses' counter that determines expiration; they have a TTL and an explicit max uses parameter (if set), but expiration is primarily time-based. Option C is wrong because the token does not expire immediately after 12 hours of non-use; it expires when its TTL (e.g., 24 hours) elapses, which would be 12 hours from now.

Practice this question →
84
MCQhard

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

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

Periodic tokens have no max TTL and can be renewed indefinitely.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
85
MCQeasy

A developer needs a token that can be used only 5 times and must expire after 24 hours, regardless of the number of uses. Which token creation method should be used to enforce these constraints?

A.Create a token directly with num_uses=5
B.Use a token role with num_uses=5 and ttl=24h
C.Create a token directly with ttl=24h
D.Create a periodic token with period set to 24h
AnswerB

Token roles allow explicit limits on both number of uses and time-to-live.

Why this answer

A token role with both `num_uses=5` and `ttl=24h` enforces both constraints: the token can be used only 5 times and will expire after 24 hours, regardless of which limit is reached first. Creating a token directly with only `num_uses` or only `ttl` would miss one constraint, and a periodic token ignores the `num_uses` limit entirely.

Exam trap

A common misconception is that a token created directly with `num_uses` or `ttl` alone can satisfy both constraints, or that periodic tokens can enforce a fixed use limit, when in fact only a token role with both parameters set achieves the combined behavior.

How to eliminate wrong answers

Option A is wrong because creating a token directly with `num_uses=5` sets a use limit but does not enforce a time-based expiration, so the token could remain valid indefinitely if not fully consumed. Option C is wrong because creating a token directly with `ttl=24h` sets a time-based expiration but does not limit the number of uses, allowing unlimited usage within the 24-hour window. Option D is wrong because a periodic token with `period=24h` extends the token's lifetime indefinitely as long as it is renewed before expiry, and it does not support a `num_uses` constraint, so it cannot enforce a fixed use limit.

Practice this question →
86
MCQeasy

An engineer wants to list all tokens associated with a specific token accessor. Which API endpoint should be used?

A.auth/token/lookup-accessor
B.auth/token/accessors/
C.auth/token/lookup
D.auth/token/list
AnswerA

This returns token details for the given accessor.

Why this answer

The correct endpoint is `auth/token/lookup-accessor`. This endpoint is used to retrieve the details of a single token given its accessor. A token accessor is a non-sensitive reference that allows operations like lookup and revocation without exposing the token ID.

The other options are incorrect: `auth/token/accessors/` is not a valid Vault endpoint; `auth/token/lookup` retrieves token details using the token itself or its accessor, but not specifically by accessor; and `auth/token/list` lists all token accessors but does not retrieve details for a specific accessor.

Exam trap

The Vault exam often tests the distinction between `auth/token/lookup` (which retrieves token details by token ID or accessor) and `auth/token/lookup-accessor` (which retrieves token details specifically by accessor). Candidates may confuse the two or incorrectly think that `lookup-accessor` returns a list of tokens, but it actually returns details of a single token.

How to eliminate wrong answers

Option B is wrong because `auth/token/accessors/` is not a valid Vault API endpoint; the correct path uses `lookup-accessor` as a sub-action. Option C is wrong because `auth/token/lookup` retrieves token properties (like policies and TTL) for a given token or accessor, but does not list all tokens associated with a specific accessor. Option D is wrong because `auth/token/list` lists all token accessors in the token store, not those associated with a particular accessor.

Practice this question →
87
MCQhard

A company uses HashiCorp Vault in production to manage secrets for its microservices. One microservice, 'order-svc', authenticates via AppRole and receives a service token with a TTL of 24 hours and a max TTL of 48 hours. Over the past few days, operations teams report that 'order-svc' fails to renew its token after approximately 23 hours, causing authentication failures. The token lookup shows the token is still alive with about 1 hour of TTL remaining, but renewal attempts return a 'permission denied' error. The Vault audit logs show the renewal request is reaching Vault and being denied. The token's policies include 'path "auth/token/renew-self" { capabilities = ["update"] }'. The token was created with the default options. What is the most likely cause of this failure?

A.The token's parent token has been revoked, making it an orphan
B.The token is a batch token and cannot be renewed
C.The token has already been renewed up to its max TTL, so further renewal would exceed the max
D.The token's num_uses has reached zero
AnswerC

The max TTL of 48 hours has been nearly reached after multiple renewals, so the next renewal is denied.

Why this answer

The token's max TTL of 48 hours has been reached after repeated renewals. Each renewal extends the token's TTL up to the max TTL, and once that limit is hit, further renewal attempts are denied with a 'permission denied' error, even if the current TTL still shows remaining time. The token lookup showing 1 hour of TTL left indicates the token is still valid, but the renewal is blocked because it would exceed the configured max TTL.

Exam trap

A common trap in HashiCorp Vault exams is the distinction between a token's current TTL (remaining lifetime) and its max TTL (cumulative lifetime), leading candidates to believe a token with remaining TTL can always be renewed, when in fact the max TTL is the binding constraint.

How to eliminate wrong answers

Option A is wrong because revoking the parent token does not cause a 'permission denied' error on renewal; it would instead cause the token to become orphaned and renewal might fail with a different error (e.g., 'token not found' or 'invalid token'), not a permission denied. Option B is wrong because batch tokens cannot be renewed at all and would fail immediately with a 'permission denied' or 'not a renewable token' error, but the token in question is a service token (which is renewable by default) and the audit logs show the renewal request is reaching Vault and being denied, not rejected outright. Option D is wrong because if the token's num_uses had reached zero, the token would be immediately invalidated and lookup would show it as expired or revoked, not still alive with 1 hour of TTL remaining.

Practice this question →
88
MCQmedium

A security team wants to issue tokens that can be used for exactly 10 API calls, after which they must be renewed. Which two token parameters should be set on the token role?

A.period and num_uses
B.ttl and renewable
C.ttl and num_uses
D.num_uses and renewable
AnswerB

Correct: ttl and renewable allow the token to be used for a duration and then be renewed, though it does not enforce exactly 10 uses.

Why this answer

To meet the requirement that tokens can be used for exactly 10 API calls and then be renewed, you must avoid setting `num_uses` because tokens with `num_uses` set cannot be renewed. Instead, set `ttl` to a short duration (e.g., 1 minute) and `renewable` to true. This allows the token to be used for a limited time (though not exactly 10 calls) and be renewed repeatedly.

While this does not enforce exactly 10 calls, it aligns with the constraint that `num_uses` prevents renewal, making this the only viable pair among the options.

Exam trap

Candidates often assume that `num_uses` combined with `renewable` allows renewal after use count exhaustion. However, in Vault, setting `num_uses` makes a token non-renewable regardless of the `renewable` flag. The correct pair to allow renewal (while sacrificing exact use count) is `ttl` and `renewable`.

How to eliminate wrong answers

Option A is wrong because `period` is used for periodic tokens (e.g., time-based rotation) and does not limit the number of uses; combining `period` and `num_uses` would create a token that expires after a time period or after a number of uses, but it does not prevent renewal. Option B is wrong because `ttl` sets a time-to-live, not a use count, and `renewable` alone does not cap the number of API calls; a token with a long TTL and renewable=true could be used indefinitely. Option C is wrong because while `num_uses` limits the call count, `ttl` only adds a time constraint; without setting `renewable` to false, the token could be renewed before the TTL expires, allowing more than 10 uses.

Practice this question →
89
Multi-Selecteasy

Which TWO statements about batch tokens are true?

Select 2 answers
A.They are lightweight and support a high creation rate.
B.They cannot be used with a use-limit.
C.They support explicit max TTL.
D.They have a TTL.
E.They are renewable.
AnswersA, B

Correct. Batch tokens are lightweight and optimized for high creation rates.

Why this answer

Batch tokens are designed to be lightweight and support a high creation rate, ideal for ephemeral workloads. Option B is correct because batch tokens cannot be used with a use-limit; use-limits are only supported by service tokens. Options C, D, and E are incorrect: batch tokens do not support explicit max TTL (C), they do not have a TTL as they derive their lifetime from the parent token (D), and they are not renewable (E).

Exam trap

A common misconception is that batch tokens are fully featured like service tokens, but they lack support for explicit max TTL, renewal, and individual revocation, making them suitable only for specific use cases.

Practice this question →
90
MCQhard

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

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

The token's policy only covers "dev/*", not "prod/*".

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
91
MCQhard

An application's token is failing to renew, and the logs show 'token not renewable'. The token was created with a TTL of 24h and no explicit max TTL. What is the most likely cause?

A.The token was created with the renewable flag set to false
B.The token has been renewed too many times, exceeding its TTL
C.The token accessor is invalid
D.The token's max TTL has been reached
AnswerA

If renewable=false, Vault rejects renewal requests.

Why this answer

The error 'token not renewable' occurs when a token is created with the `renewable` flag explicitly set to `false`. Even though the token has a TTL of 24h and no explicit max TTL, the absence of the renewable flag means the token cannot be renewed at all. Vault tokens are renewable by default, but if the application or operator sets `renewable=false` during creation, the token will expire after its TTL and cannot be extended.

Exam trap

In HashiCorp Vault, the 'token not renewable' error indicates the token was created with `renewable=false`. A common trap is confusing this with max TTL or expiration, but the renewable flag is a separate attribute that must be set to true for renewal to be allowed.

How to eliminate wrong answers

Option B is wrong because the error message 'token not renewable' is not related to the number of renewals; a token can be renewed many times as long as its max TTL (which defaults to 32 days if not set) has not been reached. Option C is wrong because an invalid token accessor would produce an error like 'invalid accessor' or 'token not found', not 'token not renewable'. Option D is wrong because the token has no explicit max TTL, so the default max TTL (32 days) applies, and a 24h TTL token would not hit that limit after a single renewal failure.

Practice this question →
92
Drag & Dropmedium

Drag and drop the steps to perform a Vault disaster recovery using the replication feature 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

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

Practice this question →
← PreviousPage 2 of 2 · 92 questions total

Ready to test yourself?

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

Start 20-question session