VA-003 Assess Vault tokens Practice Test 6 — 15 Questions

Question 1

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?

Accepted Answer

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

Answer

Periodic tokens

Answer

Batch tokens

Answer

Orphan tokens

Question 2

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?

Accepted Answer

No, because the total lifetime cannot exceed the explicit_max_ttl of 120h.. 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.

Answer

Yes, because TTL refreshes to 48h on each renewal.

Answer

Yes, if renewed before TTL expires, it can persist indefinitely.

Answer

No, because tokens cannot be renewed more than 5 times.

Question 3

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

Accepted Answer

Batch tokens. 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.

Answer

Service tokens

Answer

Periodic tokens

Answer

Orphan tokens

Question 4

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?

Accepted Answer

Fails because the token needs an explicit policy for "secret/data/prod/".. 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.

Answer

Fails with a system error.

Answer

Succeeds because token has read capability on all secrets.

Answer

Succeeds because the token can list and read any path.

Question 5

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

Accepted Answer

It is the starting TTL for a periodic token and is refreshed on each renewal.. 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.

Answer

It defines the maximum lifetime of a token.

Answer

It defines the number of uses before token expires.

Answer

It is the time after which the token is revoked if not used.

Question 6

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

Accepted Answer

`vault list auth/token/accessors`. `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.

Answer

There is no way to list all tokens.

Answer

`vault token list`

Answer

Both A and B

Question 7

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?

Accepted Answer

Unlimited (as long as it keeps renewing). 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.

Answer

72h

Answer

48h

Answer

24h

Question 8

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

Accepted Answer

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

Answer

The renewal will fail because the token has exceeded its explicit max TTL.

Answer

The token will be renewed for another 12h and can be renewed indefinitely.

Answer

The token will be renewed for 12h, but the total lifetime cannot exceed 24h.

Question 9

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

Accepted Answer

Read a secret at "secret/data/engineering/db-pass". 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.

Answer

Update a secret at "secret/data/engineering/config"

Answer

List secrets at "secret/data/finance/"

Answer

Delete a secret at "secret/data/finance/budget"

Question 10

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?

Accepted Answer

The secrets were from a KV v1 engine that does not use leases. 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.

Answer

The token had sudo capabilities on the path

Answer

The token was a root token and cannot be revoked

Answer

The token was an orphan token and therefore immune to revocation

Question 11

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

Accepted Answer

Create a policy that allows read on secret/engineering/* and attach it to the token. 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.

Answer

Create a token with a short TTL so it expires quickly

Answer

Create a token with the default policy only

Answer

Use the root token and restrict usage with a low TTL

Question 12

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?

Accepted Answer

The policy path should be 'secret/data/team-alpha/*' for KV v2. 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.

Answer

The token is not a root token

Answer

The token's TTL has expired

Answer

The token has a conflicting policy from a parent token

Question 13

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

Accepted Answer

Use token accessors in audit logs. 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.

Answer

Enable audit logging without any modifications

Answer

Use the token lookup API for each audit event

Answer

Use response wrapping to encapsulate tokens

Question 14

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

Accepted Answer

The token is revoked and all its leases are revoked. 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.

Answer

The token becomes invalid but can be renewed within a grace period

Answer

The token is automatically renewed for another period

Answer

The token remains active but read-only

Question 15

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'?

Accepted Answer

The read fails because the explicit deny on the specific path takes precedence. 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/*'.

Answer

The read succeeds because the grant from the wildcard policy is more permissive

Answer

The read fails because the policies conflict and Vault defaults to deny

Answer

The read succeeds because the token has a separate policy that grants read