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

Question 1

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?

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

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 2

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 3

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 4

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 5

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.

Question 6

Drag and drop the steps to initialize and unseal a Vault server for the first time into the correct order.

Accepted Answer

Start the server, then initialize Vault, then distribute the unseal keys, then unseal the Vault, then verify the status.. The correct sequence for initializing and unsealing a Vault server for the first time is: start the server, initialize Vault (which generates unseal keys), distribute the unseal keys to key holders, unseal the Vault using a threshold of keys, then verify the Vault is unsealed. This ensures proper security and operational readiness.

Answer

Initialize Vault, then start the server, then distribute the unseal keys, then unseal the Vault, then verify the status.

Answer

Start the server, then initialize Vault, then unseal the Vault, then distribute the unseal keys, then verify the status.

Answer

Start the server, then distribute the unseal keys, then initialize Vault, then unseal the Vault, then verify the status.

Question 7

Drag and drop the steps to perform a Vault disaster recovery using the replication feature into the correct order.

Accepted Answer

Step 1: Initialize clusters, Step 2: Enable primary replication, Step 3: Generate secondary activation token, Step 4: Enable secondary replication, Step 5: Promote secondary to primary if needed. Initialize clusters, enable primary replication, generate token, enable secondary, promote if needed.

Answer

Step 1: Generate secondary activation token, Step 2: Enable primary replication, Step 3: Enable secondary replication, Step 4: Initialize clusters, Step 5: Promote secondary to primary if needed

Answer

Step 1: Enable primary replication, Step 2: Enable secondary replication, Step 3: Initialize clusters, Step 4: Generate secondary activation token, Step 5: Promote secondary to primary if needed

Answer

Step 1: Enable secondary replication, Step 2: Enable primary replication, Step 3: Initialize clusters, Step 4: Generate secondary activation token, Step 5: Promote secondary to primary if needed

Question 8

Match each Vault auth method to its authentication mechanism.

Accepted Answer

Token: A single-use token generated at login. Token auth uses a single-use token; Userpass uses username/password; AppRole uses RoleID/SecretID. Common confusions involve swapping these definitions.

Answer

Token: Username and password authentication

Answer

Userpass: Role ID and Secret ID

Answer

AppRole: A single-use token generated at login

Question 9

Match each Vault seal type to its description.

Accepted Answer

Shamir seal: Uses Shamir's secret sharing to split the master key into key shares distributed to operators. The correct matches are: Shamir seal uses secret sharing; AWS KMS seal uses AWS KMS; HSM seal uses a hardware module. Common confusions involve swapping cloud-based seals with Shamir or HSM.

Answer

Shamir seal: Uses AWS KMS to encrypt/decrypt the master key

Answer

AWS KMS seal: Uses Shamir's secret sharing to split the master key into shares

Question 10

A DevOps team generates a large number of short-lived tokens for automated deployments. They want to minimize storage overhead and avoid the need for token revocation. Which token type should they use?

Accepted Answer

Batch tokens. Batch tokens are the correct choice because they are designed for high-frequency, short-lived workloads where storage overhead and revocation are concerns. They are created by a parent token, have a configurable TTL (often minutes), and are never stored in Vault's storage backend, eliminating the need for revocation and reducing storage footprint.

Answer

Periodic tokens

Answer

Orphan tokens

Answer

Service tokens

Question 11

An administrator needs to revoke a token but wants to keep all child tokens that were created using this token as the parent. Which revocation operation should be used?

Accepted Answer

Orphan token revocation. Orphan token revocation is the correct operation because it revokes the parent token while preserving all child tokens that were created using it. This is achieved by removing the parent token's accessor and its associated policies, but leaving the child tokens' hierarchy intact so they continue to function independently. In Vault, this is done via the `vault token revoke -orphan` command or the corresponding API endpoint.

Answer

Immediate token revocation

Answer

Sudo token revocation

Answer

Self token revocation

Question 12

An application's token is failing to renew, and the logs show 'token not renewable'. The token was created with a TTL of 24h and no explicit max TTL. What is the most likely cause?

Accepted Answer

The token was created with the renewable flag set to false. The error 'token not renewable' occurs when a token is created with the `renewable` flag explicitly set to `false`. Even though the token has a TTL of 24h and no explicit max TTL, the absence of the renewable flag means the token cannot be renewed at all. Vault tokens are renewable by default, but if the application or operator sets `renewable=false` during creation, the token will expire after its TTL and cannot be extended.

Answer

The token has been renewed too many times, exceeding its TTL

Answer

The token accessor is invalid

Answer

The token's max TTL has been reached

Question 13

A security audit requires tracking token usage without exposing the token value itself. Which token attribute should be logged?

Accepted Answer

Token accessor. The token accessor is a non-sensitive reference to a Vault token that can be used for token lifecycle operations (e.g., lookup, renewal, revocation) without exposing the actual token value. Logging the accessor satisfies audit requirements for tracking token usage while maintaining security, as the accessor cannot be used to authenticate requests.

Answer

Token value

Answer

Creation TTL

Answer

Policy list

Question 14

A development team needs tokens that can be renewed automatically as long as they are still in use, up to a maximum lifetime of 72 hours. Which token type and configuration should be used?

Accepted Answer

Service token with a TTL of 1h and max TTL of 72h. A service token with a TTL of 1 hour and a max TTL of 72 hours allows automatic renewal as long as the token is still in use, up to the maximum lifetime of 72 hours. This configuration ensures that the token's TTL is extended on each use, preventing expiration during active sessions while enforcing an absolute upper limit.

Answer

Periodic token with a TTL of 72h

Answer

Orphan token with a TTL of 1h

Answer

Batch token with a TTL of 72h

Question 15

An administrator receives an access denied error when trying to use the token accessor to revoke a token. The administrator's token has the following policy capabilities: path "auth/token/revoke-accessor" { capabilities = ["create", "update"] }. What is the issue?

Accepted Answer

The administrator lacks the 'sudo' capability on that path. The `auth/token/revoke-accessor` endpoint requires the `sudo` capability in addition to `create` or `update`. In Vault, certain sensitive token management operations, such as revoking a token by its accessor, are protected by the `sudo` privilege to prevent unauthorized revocation. Without `sudo`, the administrator receives an access denied error even though they have `create` and `update` capabilities on the path.

Answer

The administrator's token does not have any capabilities on the path

Answer

The path requires 'create' and 'update' but not 'sudo'

Answer

The accessor path is incorrect; it should be auth/token/accessors/revoke