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

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The path in the policy needs to be 'secret/data/team-alpha/*'. Option B is correct because in Vault's KV v2 secrets engine, the API path includes the 'data/' segment between the mount point and the secret path, so a policy granting read on 'secret/team-alpha/*' does not match the actual request path 'secret/data/team-alpha/db-creds'; the policy must be written as 'secret/data/team-alpha/*' to authorize the read. Option C is correct because Vault policies are additive and deny-by-default, and a token created as a child of another token inherits the intersection of its own policies and those of its parent; if the parent token lacks read capability on that path (or has an explicit deny), the child token cannot read the secret regardless of its own policy. Option A is wrong because the token accessor is only an identifier used for lookup, renewal, and revocation operations, not an authentication credential for reading secrets. Option D is wrong because KV v2 tuning options (such as max_versions, cas_required, and delete_version_after) do not include a setting that disables read operations. Option E is wrong because tokens do not need to be children of the root token to read secrets; any token with a matching policy granting read capability can perform the read.

Answer

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

Answer

The secret engine is not tuned to allow reads

Answer

The token is not a child of the root token

Question 2

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

Accepted Answer

It will expire in 12 hours. 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.

Answer

It can be renewed indefinitely if used

Answer

It will expire when the number of uses reaches 0

Answer

It will expire immediately because it was not used within 12 hours

Question 3

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

Accepted Answer

Yes, because the first path grants read on all secrets under 'secret/data/engineering/'. Vault policies are additive and use longest-prefix matching, but a more specific path does not override a broader grant unless it explicitly denies. The first policy grants 'read' on 'secret/data/engineering/*', which includes 'secret/data/engineering/special'. The second policy only adds create/update capabilities on that specific path and does not revoke the read capability already granted, so the read succeeds.

Answer

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

Answer

Yes, because the second path implicitly allows read

Answer

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

Question 4

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

Accepted Answer

The token's policy does not grant read on that path. 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.

Answer

The secret engine is not enabled

Answer

The token is a root token

Answer

The token has expired

Question 5

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?

Accepted Answer

T2 becomes an orphan token and continues to work until its TTL expires. 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.

Answer

T2 expires immediately

Answer

T2 is also revoked immediately

Answer

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

Question 6

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?

Accepted Answer

Use the identity/entity endpoint to revoke all tokens associated with the user's entity. 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.

Answer

Revoke each token individually using its accessor

Answer

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

Answer

Restart the Vault server

Question 7

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

Accepted Answer

Periodic token. 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.

Answer

Root token

Answer

Orphan token

Answer

Batch token

Question 8

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?

Accepted Answer

The token has reached its explicit max TTL. 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.

Answer

The token's num_uses has reached zero

Answer

The token is a batch token

Answer

The token's parent was revoked

Question 9

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?

Accepted Answer

Use the 'cascade=true' parameter when revoking the parent token. 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.

Answer

Use the 'force' parameter when revoking the parent token

Answer

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

Answer

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

Question 10

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

Accepted Answer

Period. In Vault, a token's period (A) is fixed at creation time and cannot be changed afterward, since it defines the recurring renewal interval baked into the token's lease. Policies (B) are also immutable after creation — to change a token's policies you must create a new token, because the policy set is bound at issuance. Max TTL (D) is likewise set at token creation and cannot be modified later, as it caps the total lifetime the token can reach through renewals. By contrast, the renewable flag (C) and the TTL (E) are not immutable: a token's TTL can be adjusted via renewal (up to the max TTL), and renewability can be affected by renewal operations, so neither is permanently fixed at creation.

Answer

Renewable

Answer

TTL

Question 11

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.)

Accepted Answer

The token has expired. Option A is correct because when a token's TTL elapses, Vault revokes it and removes its lease from the expiration manager, so a renewal attempt returns a 'lease not found' or 'token not found' error since there is nothing left to renew. Option E is correct because batch tokens are not persisted in Vault's storage and have no lease or renewal capability, so attempting to renew one fails with a 'lease not found'/'token not found' error. Option B is incorrect because num_uses set to 0 means unlimited uses, not an invalid or non-renewable token. Option C is incorrect because exceeding max TTL does not itself cause a renewal failure — renewal is capped at max TTL, and the token is only revoked once that limit is reached, at which point it falls under the expired case rather than being a distinct renewal error. Option D is incorrect because orphan tokens are fully renewable; being orphaned only means the token has no parent, which does not prevent renewal.

Answer

The token has num_uses set to 0

Answer

The token has exceeded its max TTL

Answer

The token is an orphan token

Question 12

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?

Accepted Answer

The token has already been renewed up to its max TTL, so further renewal would exceed the max. 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.

Answer

The token's parent token has been revoked, making it an orphan

Answer

The token is a batch token and cannot be renewed

Answer

The token's num_uses has reached zero

Question 13

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?

Accepted Answer

Configure the AppRole with 'token_allowed_policies' to restrict which policies child tokens can use. Vault's 'token_allowed_policies' parameter on an AppRole (or any token role) restricts which policies a child token can be created with, preventing a token from escalating privileges by minting a child token with broader policies. This is the built-in mechanism for enforcing that child tokens cannot exceed the parent's policy scope, directly addressing the privilege escalation described.

Answer

Regularly audit and revoke tokens that violate policy

Answer

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

Answer

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

Question 14

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

Accepted Answer

An accessor can be used to revoke a token without having the token ID.. 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.

Answer

An accessor is the same as the token ID.

Answer

Accessors are unique only within a namespace.

Answer

An accessor is required to look up token properties.

Answer

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

Question 15

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?

Accepted Answer

The tokens have a shorter max TTL than the period, causing them to expire before they can be renewed.. 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.

Answer

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

Answer

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

Answer

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