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

Question 1

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?

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

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 2

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 3

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 4

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 5

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

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 10

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 11

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

Question 12

A token is created with policies 'default' and 'web-app'. Later, a parent token's policy is updated to add 'logging'. The child token's policies are not updated. What will happen when the child token is used?

Accepted Answer

The child token will still have only 'default' and 'web-app' policies. In Vault, child tokens inherit the policies of their parent at the time of creation, but subsequent changes to the parent's policies do not propagate to existing child tokens. The child token retains its original policy set ('default' and 'web-app') because policies are evaluated based on the token's own metadata, not the parent's current state. This behavior is by design to ensure token immutability and prevent unintended privilege escalation.

Answer

The child token will be automatically renewed to pick up the new policy

Answer

The child token will automatically gain the 'logging' policy

Answer

The child token will be invalidated due to policy mismatch

Question 13

Which TWO of the following are true about token accessors?

Accepted Answer

Accessors should be used in audit logs instead of token values. Token accessors are designed to be used in audit logs as a safe alternative to the actual token value. This prevents sensitive token data from being exposed in logs while still allowing correlation of events to a specific token. Option C is correct because an accessor is a unique identifier that references a token without revealing the token's secret value.

Answer

Accessors are the token value

Answer

Accessors can be used to renew the token

Question 14

Which TWO statements are true about batch tokens?

Accepted Answer

Batch tokens cannot be renewed or revoked. Option B is correct because batch tokens are designed as lightweight, self-contained tokens that cannot be renewed or revoked once issued; they simply expire at the end of their fixed TTL. Option C is correct because batch tokens are not persisted in Vault's storage backend—they are encrypted blobs whose validity is verified without a storage lookup, which is what makes them scalable and cheap to create. Option A is incorrect because batch tokens have a fixed lifetime and cannot be renewed, unlike service tokens. Option D is incorrect because batch tokens cannot be looked up via the lookup endpoint; lookup operations require a storage-backed token, which batch tokens are not.

Answer

Batch tokens can be renewed to extend their lifetime

Answer

Batch tokens can be looked up using the lookup endpoint

Question 15

A token with the above policy attempts to look up its own token by calling the accessor endpoint. What will happen?

Accepted Answer

The operation fails with a permission denied error. Vault's token accessor endpoint requires the 'read' capability on the token's accessor path (auth/token/accessor or the token's own accessor path). A token cannot use its own accessor to read itself unless it explicitly has that capability; by default, tokens lack the capability to read their own accessor, so the request is denied. The policy shown does not grant accessor read rights, resulting in a permission denied error.

Answer

The operation succeeds because the token can read its own token

Answer

The operation succeeds because sudo allows all accessor operations

Answer

The operation fails because the token lacks any capabilities