VA-003 Assess Vault tokens — Timed 30 Questions

Question 1

A large enterprise runs a microservices architecture on Kubernetes. Each microservice authenticates to Vault using the Kubernetes auth method with a service account token. The Vault administrator configured a role 'microservice-role' with a TTL of 24h and a max TTL of 48h. The microservices renew their tokens every 12 hours via a sidecar. Recently, the security team noticed that some tokens are still valid after 72 hours, causing a security concern. The audit logs show that the tokens were renewed successfully multiple times. The administrator reviews the role configuration and sees that 'token_renewable' is set to true. What is the most likely reason the tokens are exceeding the intended 48h max TTL?

30 minute time limit — choose an answer to begin.

Accepted Answer

The Kubernetes auth method's default TTL overrides the role's max TTL. In Vault, when using the Kubernetes auth method, the token's max TTL is determined by the minimum of the role's max TTL and the auth method's default max TTL. However, if the role's max TTL is not explicitly set to a value lower than the auth method's default max TTL, the auth method's default can effectively become the limiting factor. In this case, the administrator set the role's max TTL to 48h, but if the Kubernetes auth method's default max TTL is higher (e.g., 72h or unlimited), and the role's max TTL is not properly enforced due to a configuration oversight, the token may remain valid beyond 48h. Option B correctly identifies that the auth method's default TTL (specifically default TTL or max TTL) can override the role's intended max TTL if not carefully configured.

Answer

The sidecar renewal interval is too short, causing the token to be renewed before the max TTL is checked

Answer

The Vault role's max TTL is not propagated to the token because the token was created with a different policy

Answer

The Kubernetes service account token used for authentication is long-lived, allowing the Vault token to be renewed indefinitely

Question 2

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 3

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 4

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 5

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 6

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?

Accepted Answer

The AWS secret engine is disabled. 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.

Answer

The IAM role trust policy was not updated after credential rotation

Answer

The Vault token TTL expired

Answer

The client token used for AWS auth is revoked

Question 7

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>

Question 8

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?

Accepted Answer

Set a TTL on the token. 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.

Answer

Enable token renewal to keep it alive

Answer

Use a periodic token and revoke it manually

Answer

Use a batch token to limit its lifetime

Question 9

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?

Accepted Answer

Set explicit max TTL on the token to 24h. 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.

Answer

Use a periodic token with a period of 24h

Answer

Create an orphan token with a TTL of 24h

Answer

Use a batch token

Question 10

Which TWO of the following are valid methods to revoke a Vault token?

Accepted Answer

vault token revoke . `vault token revoke ` is the direct command to revoke a specific Vault token by its token value. This invalidates the token immediately, preventing any further use. Option D is correct because `vault token revoke -accessor ` revokes a token using its accessor, which is a non-sensitive identifier that can be used to manage tokens without exposing the token itself.

Answer

vault secrets disable <path>

Answer

vault auth disable <path>

Answer

vault policy delete <name>

Question 11

Which THREE of the following are true about batch tokens?

Accepted Answer

They have a TTL that must be set at creation. Batch tokens in Vault are designed to be lightweight, non-renewable tokens that must have a Time-To-Live (TTL) set at creation. They are not renewable, meaning once they expire, they cannot be renewed or extended. This makes them ideal for short-lived, high-volume workloads where token lifecycle management is automated.

Answer

They can be created as orphan tokens

Answer

They are always root tokens

Question 12

Which TWO of the following are valid token states?

Accepted Answer

Revoked. 'Revoked' is a valid token state in Vault. Tokens can be explicitly revoked, rendering them unusable. Option E is correct because 'Active' is the initial state of a token when it is created and remains valid until it expires or is revoked. Options A, B, and C are not valid token states in Vault: 'Expired' is a result of TTL expiry but not a distinct state; 'Orphan' describes a token whose parent is gone, but it is still considered active if not revoked; 'Suspended' is not a Vault token state.

Answer

Expired

Answer

Orphan

Answer

Suspended

Question 13

Which THREE of the following are valid sources of token TTL?

Accepted Answer

System default TTL. Vault has a system default TTL that applies to tokens when no other TTL source is specified. This default is typically 32 days (2764800 seconds) and serves as the maximum possible TTL for a token unless overridden by a shorter TTL from another source. The system default TTL is defined in the Vault server configuration and acts as a fallback to ensure tokens do not live indefinitely.

Answer

Mount path configuration

Answer

Policy TTL

Question 14

A DevOps team is using Vault tokens with short TTLs for CI/CD jobs. They notice that some jobs fail intermittently with 'permission denied' errors even though the token policy grants the required capabilities. The token is created with a TTL of 10 minutes and renewed automatically by the client library. What is the most likely cause of the failures?

Accepted Answer

The token's max_ttl has been exceeded, causing renewal to fail.. Vault tokens have both a TTL (time-to-live) and a max_ttl (maximum time-to-live). When a token is renewed, its TTL is reset to the original TTL (10 minutes) but only if the cumulative lifetime has not exceeded the max_ttl. If the max_ttl is reached, renewal fails, the token expires, and subsequent operations using that token return 'permission denied' errors, even though the policy itself grants the required capabilities.

Answer

The token's parent token has been revoked.

Answer

The token's max_ttl is being reset each time the token is renewed.

Answer

The token's TTL is too short and the client library is not renewing in time.

Question 15

Which TWO of the following scenarios require the use of a periodic token?

Accepted Answer

A batch job that must continue running even if the parent token is revoked.. A periodic token is designed to allow a child token (e.g., for a batch job) to continue operating even after its parent token is revoked. This is achieved by setting the token's period to a finite duration, which decouples the child token's lifecycle from the parent's, enabling the batch job to run to completion without interruption.

Answer

A token that never expires and has a TTL of 0.

Answer

A human operator who needs a token that can be used for multiple sessions.

Answer

A token that should not be revoked when the token that created it is revoked.

Question 16

Refer to the exhibit. A developer reports that a token they created using `vault token create -policy=my-policy -ttl=2h` is no longer working after 1 hour. The token lookup output shows the token details. What is the most likely cause?

Accepted Answer

The token's max_ttl was set to 1h when created, and the token reached its max_ttl.. The token was created with a `-ttl=2h` but the token lookup output shows `max_ttl=1h`. The `max_ttl` is an upper limit enforced by the token's configuration or the system's maximum TTL setting. Even though the requested TTL was 2 hours, the token's effective lifetime is capped by the lower of the two values, so it expired after 1 hour.

Answer

The token has num_uses set to 0, meaning it can only be used once.

Answer

The token is a service token and cannot be renewed.

Answer

The token is an orphan token and requires the parent token to be valid.

Question 17

Your company uses Vault to manage secrets for a fleet of microservices running on Kubernetes. Each microservice has a service account that authenticates to Vault using the Kubernetes auth method and receives a token with a policy granting access to its secrets. Recently, the team noticed that some tokens are being revoked prematurely, causing services to lose access to secrets. The tokens are created with a TTL of 24 hours and are set to be renewable. The Vault servers are configured with a default max_ttl of 24 hours. The tokens are renewed by the client libraries every 12 hours. Despite this, tokens are sometimes invalid before 24 hours. What should the team do to prevent this issue?

Accepted Answer

Increase the max_ttl on the token role to 48 hours to allow renewal beyond 24 hours.. The tokens are being revoked prematurely due to the Vault server's default max_ttl of 24 hours. Even though the token TTL is 24 hours and the client renews every 12 hours, the max_ttl caps the total lifetime of the token, including renewals. By increasing the max_ttl on the token role to 48 hours, the token can be renewed beyond the initial 24-hour window, preventing premature invalidation.

Answer

Set the token's num_uses to a high number to prevent premature revocation.

Answer

Change the tokens to periodic tokens so they never expire.

Answer

Decrease the token TTL to 12 hours so that renewal happens before the max_ttl is reached.

Question 18

A DevOps team is troubleshooting token access in Vault. They need to determine which of the following token operations require sudo capability. Which TWO operations require sudo capability?

Accepted Answer

Revoke a token. Revoking a token (Option D) requires sudo capability because it is a privileged operation that can disrupt access for users or services. By default, Vault's token revocation endpoints are protected by sudo policies to prevent accidental or unauthorized revocation of tokens, which could lead to denial of service.

Answer

Create a token

Answer

Renew a token

Answer

Read token accessor information

Question 19

A token has the properties shown in the exhibit. A user attempts to use this token to write a secret to 'secret/data/myapp'. The token fails with a permission denied error. What is the most likely cause?

Accepted Answer

The token's policies do not grant write capability on the target path.. The token's policies define the access control rules for paths in Vault. Since the user received a permission denied error when attempting to write to 'secret/data/myapp', the most likely cause is that the token's attached policies do not include a 'write' or 'create' capability on that specific path. Policies are evaluated based on the path and the requested operation, and without the appropriate capability, the request is denied regardless of other token properties.

Answer

The token has an explicit max TTL of 0s, which prevents write operations.

Answer

The token is a service token but the write operation requires a batch token.

Answer

The token is orphaned, so it cannot be used for write operations.

Question 20

A large enterprise runs Vault in a production environment with hundreds of applications. Each application uses a unique Vault token with a 30-day TTL. The tokens are created by a central CI/CD pipeline using Vault's token auth method. Recently, the security team noticed that several tokens with suspicious activity have been created with a 90-day TTL, and the tokens appear to be long-lived and not revoked after use. The CI/CD pipeline logs show no anomalies. The audit logs reveal that the tokens in question were created by a human user 'jdoe' using a token with the 'admin' policy. The 'admin' policy grants '*' capabilities on all paths. The Vault token accessor shows that the suspicious tokens have a 'creation_ttl' of 2160h (90 days) and 'explicit_max_ttl' of 0s. The Vault configuration uses a default lease TTL of 24h and a max lease TTL of 720h (30 days). Which action should the security team take to prevent such incidents in the future without breaking existing applications?

Accepted Answer

Create a dedicated token role with a max TTL of 720h (30 days) and restrict token creation to that role; revoke the 'admin' policy's create permission on auth/token/create.. The root cause is that the 'admin' policy grants unrestricted token creation permissions, allowing a human user to bypass the intended CI/CD pipeline controls and create tokens with a 90-day TTL. By creating a dedicated token role with a max TTL of 720h (30 days) and revoking the 'admin' policy's create permission on 'auth/token/create', the team enforces a maximum TTL of 30 days for all tokens created via the token auth method, matching the system's max lease TTL and preventing long-lived tokens without breaking existing applications that use the CI/CD pipeline.

Answer

Remove the 'admin' policy from all human users and require them to use a different authentication method.

Answer

Implement a Sentinel policy that blocks token creation by any user except the CI/CD pipeline.

Answer

Reduce the system max lease TTL to 720h (30 days) and enforce that all tokens must have explicit_max_ttl set.