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

Question 1

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?

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

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 2

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.. The request succeeded because the 'admin' policy was added directly to the token role's allowed policies list before the token creation. When a token role is created or updated, the 'allowed_policies' parameter defines the set of policies that can be attached to tokens generated by that role. If 'admin' is added to this list, then specifying it in the token creation request is valid, and the token will be created with both 'app-dev', 'app-staging', 'app-prod', and 'admin' (unless the role also has 'disallowed_policies' that exclude it). The scenario states that the administrator expected failure because 'admin' was not in the allowed list, but the actual reason for success is that the developer modified the role to include 'admin' in its allowed policies. This is a configuration change, not a flaw in Vault's enforcement.

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 3

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.

Question 4

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?

Accepted Answer

The token will be revoked immediately.. In Vault, explicit_max_ttl sets a hard limit on the total lifetime of a token, regardless of its creation_ttl or any renewals. When the token's age reaches the explicit_max_ttl (10 hours in this case), Vault automatically revokes the token. This revocation is immediate and cannot be overridden by renewal or by the longer creation_ttl.

Answer

The token will be automatically renewed by Vault.

Answer

The token will remain valid until the creation_ttl expires.

Answer

The token will have its TTL extended to 24h.

Question 5

An application is using a Vault token with a TTL of 1 hour and a max TTL of 24 hours. The application renews the token every 30 minutes. After 12 hours, the application attempts to renew the token but fails. What is the most likely cause?

Accepted Answer

The token's parent was revoked, causing this token to be revoked.. A token renewal can fail if the token has been revoked, often due to its parent being revoked. In this case, the token was being renewed successfully for 12 hours, so it was renewable and within max TTL. The sudden failure indicates that the token was revoked, likely because its parent token was revoked, which cascades to all child tokens.

Answer

The token's TTL has expired because 12 hours have passed since creation.

Answer

The token has reached its max TTL and cannot be renewed further.

Answer

The token is not renewable because it was created without the renewable flag.

Question 6

A developer has a Vault token with a TTL of 30 minutes and a max TTL of 1 hour. The token is used to create a child token with a TTL of 45 minutes and no explicit max TTL. What is the effective maximum TTL of the child token?

Accepted Answer

30 minutes. When a child token is created, its maximum TTL is limited by the remaining TTL of the parent token. The parent token has a TTL of 30 minutes and a max TTL of 1 hour, but since it has not been renewed, its remaining TTL is 30 minutes. The child token's requested TTL of 45 minutes exceeds this, so the effective maximum TTL is capped at 30 minutes.

Answer

45 minutes

Answer

1 hour

Answer

15 minutes

Question 7

An administrator is designing a token strategy and needs to document the properties that distinguish batch tokens from service tokens in Vault. Which two statements correctly describe batch tokens? (Choose two.)

Accepted Answer

Batch tokens are not persisted to Vault's storage backend, so they cannot be listed or looked up after creation.. Batch tokens are lightweight, non-persisted tokens intended for high-volume, short-lived use. Because they are not written to storage, they cannot be listed, looked up, or revoked individually, and they do not support renewal. In exchange, they can be issued at much greater scale with lower overhead than service tokens, which is their defining trade-off.

Answer

Batch tokens can be revoked individually by their accessor before their TTL expires.

Answer

Batch tokens inherit an absolute maximum lifetime equal to the parent token's remaining TTL.

Answer

Batch tokens can be made renewable by setting token_period at creation time.

Question 8

A Vault administrator is configuring token renewal behavior for a set of tokens used by long-running applications. The applications need to renew their tokens periodically to maintain access. Which two parameters must be set when creating a token to allow it to be renewed indefinitely? (Choose two.)

Accepted Answer

Set a periodic token using `-period=<duration>`.. To allow a token to be renewed indefinitely, it must be renewable and either periodic or have no explicit max TTL that would cap its total lifetime. Setting `-renewable=true` ensures the token can be renewed, and setting a period with `-period` creates a periodic token that can be renewed perpetually. Together, these parameters enable long-running applications to maintain access without interruption.

Answer

Set an explicit max TTL using `-explicit-max-ttl=<duration>`.

Answer

Set a very long TTL using `-ttl=8760h`.

Answer

Set the token type to batch using `-type=batch`.

Question 9

A platform team wants to create a Vault token that can be used for a maximum of 10 hours, but they also want the token to be renewable so that it can be extended if needed, up to that 10-hour limit. Which command correctly creates such a token?

Accepted Answer

vault token create -ttl=10h -explicit-max-ttl=10h. To create a token that can be renewed but has a hard maximum lifetime of 10 hours, the correct parameters are -ttl=10h to set the initial TTL and -explicit-max-ttl=10h to set the absolute cap. The token is renewable by default, and renewals are allowed as long as the total lifetime does not exceed the explicit max TTL. This ensures the token cannot be used beyond 10 hours, satisfying the requirement.

Answer

vault token create -ttl=10h -renewable=false

Answer

vault token create -ttl=10h -max-ttl=10h

Answer

vault token create -ttl=10h -period=10h

Question 10

A Vault administrator is designing a token strategy for a batch job that runs every night for 2 hours. The job needs to authenticate to Vault and retrieve secrets. The administrator wants to minimize the risk of token leakage and ensure the token cannot be renewed indefinitely. Which token configuration best meets these requirements?

Accepted Answer

Create a token with a TTL of 2 hours and an explicit max TTL of 2 hours.. The best configuration is a token with a TTL of 2 hours and an explicit max TTL of 2 hours. This makes the token renewable, allowing the batch job to renew if it runs slightly longer, but the explicit max TTL prevents the token from being renewed beyond 2 hours total. This minimizes the window of exposure and ensures the token cannot be renewed indefinitely. It also aligns with the job's runtime, reducing the risk of leakage.

Answer

Create a token with a TTL of 4 hours and -explicit-max-ttl=24h.

Answer

Create a token with a TTL of 2 hours and -renewable=false.

Answer

Create a periodic token with a period of 2 hours.

Question 11

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?

Accepted Answer

Use periodic tokens with a short period and allow renewal. 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.

Answer

Use batch tokens for better performance

Answer

Create orphan tokens so they don't expire with the parent

Answer

Increase the default TTL on the token auth method

Question 12

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?

Accepted Answer

Set a short TTL on the token and do not allow renewal. 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.

Answer

Use a revocation script that runs periodically

Answer

Set explicit max TTL on the token

Answer

Use a periodic token with a long period

Question 13

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?

Accepted Answer

Create a policy with read capability on 'secret/data/production' and attach it to the token. 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.

Answer

Set the token's metadata to restrict access

Answer

Use a root token and restrict its use via a policy

Answer

Set the token type to service and it will automatically restrict access

Question 14

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?

Accepted Answer

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

Answer

Service tokens with explicit max TTL

Answer

Periodic tokens

Answer

Batch tokens

Question 15

A Vault user wants to check the capabilities of their token on a specific path. Which command should they use?

Accepted Answer

vault token capabilities <path>. 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.

Answer

vault token list

Answer

vault policy capabilities

Answer

vault token lookup <token>