VA-003 Timed Practice Test 3 — 10 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?

10 minute time limit — choose an answer to begin.

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

Drag and drop the steps to set up Vault's Transit secrets engine for encryption/decryption into the correct order.

Accepted Answer

Enable the transit secrets engine, create a key, encrypt data, decrypt data, rotate the key. The correct order is to first enable the Transit secrets engine, then create a key, use the key to encrypt and decrypt data, and finally rotate the key for security. Enabling creates the path, key creation provides the encryption material, and rotation updates the key without interrupting operations.

Answer

Create a key, enable the transit secrets engine, encrypt data, decrypt data, rotate the key

Answer

Enable the transit secrets engine, create a key, rotate the key, encrypt data, decrypt data

Answer

Enable the transit secrets engine, encrypt data, create a key, decrypt data, rotate the key

Question 3

A DevOps team needs to encrypt large files (several GB) using Vault's transit engine. What is the recommended approach?

Accepted Answer

Use Vault's datakey endpoint to get a data encryption key, encrypt locally, then wrap with Vault. The transit engine is designed for encrypting small data payloads (typically a few KB), not multi-GB files. The recommended approach is to use the `/transit/datakey/plaintext` endpoint to generate a data encryption key (DEK), encrypt the large file locally with that DEK using a symmetric algorithm like AES-256-GCM, and then wrap (encrypt) the DEK with Vault using the transit engine. This keeps the large file out of Vault while still leveraging Vault for key management and audit logging.

Answer

Use Vault's batch encryption

Answer

Use Vault's seal-wrapping feature

Answer

Encrypt the file directly with Vault's transit encrypt API

Answer

Split the file into chunks and encrypt each chunk via transit

Question 4

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 5

An administrator configures AppRole with a RoleID and SecretID. They want to ensure that each SecretID can be used only once. Which configuration should they use?

Accepted Answer

Set secret_id_num_uses=1 in the role.. Setting `secret_id_num_uses=1` in the AppRole role configuration ensures that each SecretID can be used only once to obtain a token. Once the SecretID is used for login, it is automatically revoked and cannot be reused. This directly satisfies the requirement of single-use SecretIDs.

Answer

Set token_num_uses=1 in the role.

Answer

Set bound_cidr_list to a specific IP.

Answer

Set secret_id_ttl=1s in the role.

Question 6

Drag and drop the steps to configure Vault's audit logging to a file into the correct order.

Accepted Answer

Enable audit device, then perform operations to generate log entries, then verify the audit log.. The correct sequence for configuring Vault's audit logging to a file is: first enable the audit device (e.g., 'vault audit enable file file_path=...'), then perform operations (e.g., read/write secrets) to generate audit log entries, and finally verify the log file to confirm entries are being recorded. Common mistakes include enabling after generating logs, verifying too early, or skipping the generation step.

Answer

Perform operations to generate log entries, then enable audit device, then verify the audit log.

Answer

Verify audit log, then enable audit device, then perform operations to generate log entries.

Answer

Enable audit device, then verify the audit log, then perform operations to generate log entries.

Question 7

An administrator wants to write a secret 'myapp' with value 'password=pass123' to the KV v2 secret engine mounted at 'secret/'. Which command should they use?

Accepted Answer

vault kv put secret/myapp password=pass123. `vault kv put` is the proper command to write or update a secret in the KV v2 secrets engine. The KV v2 engine requires the `put` subcommand to create or overwrite a secret at the specified path, and the syntax `vault kv put secret/myapp password=pass123` correctly writes the key-value pair to the path `secret/myapp` under the mounted engine at `secret/`.

Answer

vault kv write secret/myapp password=pass123

Answer

vault kv create secret/myapp password=pass123

Answer

vault write secret/myapp password=pass123

Question 8

An admin creates a token with TTL=48h and explicit_max_ttl=120h. The token is renewed every 24h. After 10 days, will the token still be valid?

Accepted Answer

No, because the total lifetime cannot exceed the explicit_max_ttl of 120h.. The token's total lifetime is capped by the `explicit_max_ttl` of 120 hours (5 days). Even though the token is renewed every 24 hours, the cumulative time since creation cannot exceed the explicit maximum TTL. After 10 days (240 hours), the token will have long surpassed the 120-hour limit and will be invalid.

Answer

Yes, because TTL refreshes to 48h on each renewal.

Answer

Yes, if renewed before TTL expires, it can persist indefinitely.

Answer

No, because tokens cannot be renewed more than 5 times.

Question 9

Refer to the exhibit. A user has a token with a policy that grants 'read' on 'secret/*'. The user attempts to read the secret at 'secret/data/app' using `vault kv get secret/data/app` but receives a '404 Not Found' error. The user can successfully list the engine at 'secret/' with `vault secrets list`. What is the most likely cause of the 404 error?

Accepted Answer

The secrets engine is KV v1, but the user is using the KV v2 path format with '/data/'.. The KV v2 secrets engine requires the path format `secret/data/` for reading secret data, while KV v1 uses `secret/` directly. The user is using `vault kv get secret/data/app`, which is the correct command for KV v2, but the error indicates the engine is actually KV v1. Since KV v1 does not have a `/data/` prefix, the path `secret/data/app` does not exist, resulting in a 404 Not Found error. The successful `vault secrets list` confirms the engine is enabled at `secret/`, ruling out option D.

Answer

The user's policy does not cover the sub-path 'secret/data/app'.

Answer

The secret path is mistyped; it should be 'secret/application'.

Answer

The secret engine at 'secret/' is not enabled.

Question 10

A developer needs to manually revoke a token but only knows its accessor. Which Vault API endpoint can be used to revoke the token using only the accessor?

Accepted Answer

auth/token/revoke-accessor. The `auth/token/revoke-accessor` endpoint is specifically designed to revoke a token when only its accessor is known. The accessor is a non-sensitive identifier that Vault uses to perform token operations without exposing the actual token ID, making this endpoint the appropriate choice for revocation by accessor.

Answer

auth/token/accessors

Answer

auth/token/renew-accessor

Answer

auth/token/revoke