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

Question 1

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 2

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 3

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 4

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

Accepted Answer

Lookup token properties. 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 ` and `vault token revoke -accessor `). These operations do not require the actual token value, preserving security while enabling token management.

Answer

Wrap the token

Answer

Create a child token

Answer

Renew the token

Question 5

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

Accepted Answer

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

Answer

Renewable

Answer

TTL

Question 6

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

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 7

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?

Accepted Answer

The token is a batch token. 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.

Answer

The token is a service token and has expired

Answer

The token is a periodic token and its period has expired

Answer

The token is an orphan token

Question 8

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 9

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

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 10

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 11

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.

Question 12

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?

Accepted Answer

If the team stored token accessors at creation time, use the accessors to revoke the tokens via the /auth/token/revoke-accessor endpoint.. 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.

Answer

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

Answer

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

Answer

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

Question 13

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?

Accepted Answer

The developer added the 'admin' policy directly to the token role before creating the token.. 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'.

Answer

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

Answer

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

Answer

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.

Question 14

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?

Accepted Answer

The token reached its 'explicit_max_ttl' of 24 hours, and renewal is no longer possible.. 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.

Answer

The token was created by a root token and root tokens are not subject to periodic renewal.

Answer

The token was a batch token and batch tokens cannot be renewed at all.

Answer

The token was an orphan token and cannot be renewed more than a few times.

Question 15

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?

Accepted Answer

The Kubernetes service account that the pod uses has been deleted or its token has been invalidated, causing Vault to revoke derived tokens.. 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.

Answer

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

Answer

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

Answer

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