VA-003 Utilize Vault CLI and API Practice Test 4 — 15 Questions

Question 1

A user with this policy wants to delete secrets under the 'team/' path. Which additional capability must be added?

Accepted Answer

delete. The user's policy grants 'create' and 'update' capabilities on 'team/*', but not 'delete'. In Vault's ACL policy system, each operation (create, read, update, delete, list, sudo) must be explicitly allowed. Since 'delete' is missing, the user cannot delete secrets under 'team/'. Adding the 'delete' capability to the policy is required.

Answer

sudo

Answer

list

Answer

patch

Question 2

A DevOps engineer runs `vault token lookup s.abc123` and receives a permission denied error. The engineer has a valid token with the default policy attached. What is the most likely cause?

Accepted Answer

The default policy does not grant permission to look up other tokens. The default policy in Vault is intentionally restrictive and does not include the `token/lookup` capability for tokens other than the caller's own token. Since the engineer is attempting to look up a specific token ID (`s.abc123`) rather than their own token, the default policy denies this action. The permission denied error is expected because the default policy only allows basic operations like reading system capabilities and managing the caller's own token, not inspecting other tokens.

Answer

The token does not have an attached policy that allows 'token/lookup'

Answer

The token is expired or revoked

Answer

The engineer used the token accessor instead of the token ID

Question 3

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. Option C is correct because `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 4

A security team needs to automate the rotation of a database password stored in Vault. The password is currently written as a static secret at 'database/creds/prod'. They want to use the Vault API to read and rewrite the secret, ensuring that the previous version is preserved for audit. The script must handle the case where the secret path may not exist. Which approach should they use?

Accepted Answer

Use POST to write a new version at the secret path, which automatically preserves previous versions. Option C is correct because using the POST method on the KV v2 secret path returns the data and version metadata, allowing the script to preserve history. Option A is wrong because PUT would overwrite without preserving previous version if not used with CAS. Option B is wrong because DELETE would remove the secret. Option D is wrong because the secret engine is KV v2, not v1.

Answer

Use GET on the secret path, then PUT with the new data including the old version's data

Answer

Use DELETE to remove the old secret, then POST to create a new one

Answer

Use PUT to write the new password directly, then use GET to verify

Question 5

An operator runs `vault lease renew -increment=3600 database/creds/readonly/abc123` and gets an error: 'Error renewing lease: Error making API request. URL: PUT https://vault.example.com/v1/sys/leases/renew. Code: 400. Errors: * invalid lease ID'. What is the most likely cause?

Accepted Answer

The lease ID is incomplete; it should include the full path like 'database/creds/readonly/abc123'. Option C is correct because the error 'invalid lease ID' indicates that the lease ID provided to the `vault lease renew` command is malformed or incomplete. In Vault, a lease ID for dynamic secrets like database credentials is a full path that includes the mount point, role name, and a unique UUID (e.g., `database/creds/readonly/abc123/xyz789`). The command only passed `database/creds/readonly/abc123`, which is the role path, not the full lease ID. The correct lease ID can be retrieved from the initial secret response or via `vault list sys/leases/lookup/database/creds/readonly`.

Answer

The lease has already expired and cannot be renewed

Answer

The increment value is too large and exceeds the maximum TTL

Answer

The operator does not have permission to renew leases

Question 6

An application needs to read a secret using the Vault API after authenticating with an AppRole RoleID and SecretID. The application has already obtained a Vault token. Which API endpoint should be called to read a secret at 'secret/data/myapp' with the token?

Accepted Answer

GET /v1/secret/data/myapp. Option D is correct because after authentication, the application already has a Vault token and needs to read a secret from the KV v2 secrets engine. The correct API endpoint for reading a secret from the KV v2 engine is GET /v1/secret/data/myapp, where 'secret' is the mount path and 'data' is the sub-path for KV v2 operations. The token is passed in the X-Vault-Token header, not in the URL.

Answer

GET /v1/secret/metadata/myapp

Answer

POST /v1/auth/approle/login

Answer

GET /v1/secret/myapp

Question 7

A Vault cluster has a performance secondary cluster replicating from a primary. An administrator needs to generate a one-time password (OTP) for an SSH target. They are on the secondary cluster. They run `vault write ssh/otp/otp_role ip=10.0.0.1 username=admin`. What is the expected behavior?

Accepted Answer

The request succeeds because the SSH secret engine is a local mount that exists on the secondary. Option C is correct because the SSH secret engine is a local mount, meaning it is not replicated from the primary to the performance secondary cluster. Local mounts exist independently on each cluster, so the secondary can write data to its own local SSH engine. The `vault write ssh/otp/otp_role` command is syntactically correct and will succeed on the secondary as long as the role and engine are configured locally.

Answer

The request fails because the CLI command syntax is wrong

Answer

The request fails because secondary clusters cannot write any data

Answer

The request fails because the SSH secret engine must be replicated to the secondary

Question 8

Which TWO of the following are valid methods to authenticate to Vault using the CLI without using a token? (Choose two.)

Accepted Answer

vault login -method=userpass username=joe password=pass. Option A is correct because the `vault login -method=userpass` command authenticates to Vault using the userpass auth method via the CLI, which does not require a pre-existing token. Instead, it directly exchanges the provided username and password for a client token from the Vault server. This is a standard tokenless authentication flow for the userpass method.

Answer

vault auth -method=ldap username=joe password=pass

Answer

vault write auth/userpass/login/joe password=pass

Answer

vault token create -policy=default

Question 9

Which TWO of the following are valid uses of the Vault API for managing leases? (Choose two.)

Accepted Answer

PUT /v1/sys/leases/revoke with body {"lease_id": "abc123"}. Option A is correct because the Vault API uses a PUT request to `/v1/sys/leases/revoke` with a JSON body containing the `lease_id` to revoke a specific lease. This is the standard method for lease revocation as documented in the Vault API specification. Option D is correct because renewing a lease also requires a PUT request to `/v1/sys/leases/renew` with the `lease_id` in the request body, matching the expected API pattern for state-changing operations.

Answer

GET /v1/sys/leases/renew/abc123

Answer

POST /v1/sys/leases/renew/abc123

Answer

GET /v1/sys/leases/revoke/abc123

Question 10

Which THREE of the following are true about using the Vault API with response wrapping? (Choose three.)

Accepted Answer

The wrapping token can only be used once to unwrap the response. Option B is correct because the Vault API's response wrapping feature is designed for one-time use: the wrapping token can be used only once to unwrap the response. After the client successfully calls the sys/wrapping/unwrap endpoint with the wrapping token, the token is immediately revoked, and the wrapped secret is deleted from the cubbyhole. This ensures that the secret is delivered securely and cannot be retrieved again with the same token.

Answer

The wrapping token never expires

Answer

The original token used to make the wrapped request is required to unwrap the response

Question 11

A company runs a monolithic application that reads database credentials from Vault KV v2 secrets engine at path 'app/db'. The application authenticates using an AppRole with a periodic token that renews automatically. Recently, the application started failing with permission denied errors when reading the secret. The administrator checks the AppRole's secret-id and token but they are valid. The administrator then runs `vault token capabilities $(cat /tmp/token) app/db/data` and gets an empty list. The administrator knows that the token has the 'app-policy' policy attached. They also run `vault read sys/policy/app-policy` and see the policy rules. The policy allows explicit 'read' on 'app/db/data'. What could be the issue?

Accepted Answer

The policy path is incorrect because KV v2 requires granting access to 'app/db/data' but the policy might be written for KV v1 syntax. The issue is that KV v2 secrets engine requires a different policy path than KV v1. For KV v2, the data path is 'app/db/data', but the policy must grant access to 'app/db/data/*' or 'app/db/+/data' (depending on the version) because the actual secret is stored under 'app/db/data' and the policy path must match the full path including the 'data' prefix. The administrator's policy likely uses 'app/db/data' without the wildcard or correct syntax, causing the capabilities check to return an empty list despite the token being valid.

Answer

The secret at 'app/db/data' does not exist

Answer

The token has expired and needs to be renewed

Answer

The Capabilities command does not work with AppRole tokens

Question 12

A team is migrating from a monolithic application to microservices. Each microservice needs to authenticate to Vault using its own AppRole. The security team wants to enforce that each AppRole can only read secrets from its own dedicated path (e.g., service-a can only read from 'services/service-a/*', service-b from 'services/service-b/*'). They have created the AppRoles and policies. However, during testing, they notice that service-a can read secrets from service-b's path. The administrator checks the policy for service-a and sees it has a 'capabilities' list on 'services/service-a/*' and also 'services/service-b/*' by mistake. They correct the policy, but the issue persists. What is the most likely reason that service-a still has access?

Accepted Answer

The token was issued before the policy was corrected and still carries the old policy version; it must be replaced or renewed to get the updated permissions. Vault tokens are immutable once issued; they carry a snapshot of the policies at the time of creation. Correcting the policy on the Vault server does not retroactively update existing tokens. Service-a's token was issued before the policy fix and still contains the old policy that granted access to 'services/service-b/*'. The token must be replaced (revoked and re-issued) or renewed to pick up the updated policy permissions.

Answer

The policy still contains an error that grants access to the wrong path

Answer

The policy update has not been applied to the Vault cluster yet

Answer

The service-a token has a second policy attached that grants access to service-b

Question 13

A new administrator is tasked with setting up a Vault development environment. They installed Vault and started the server in dev mode. They want to use the CLI to write and read a secret without authentication. They run `vault kv put secret/hello value=world` but get an error: 'Error writing data to secret/data/hello: Error making API request. URL: PUT https://127.0.0.1:8200/v1/secret/data/hello Code: 403. Errors: * permission denied'. What should they do first to resolve this?

Accepted Answer

Login with the root token that was output when the server started. Option D is correct because Vault dev mode starts with an initial root token displayed in the output. The CLI and API require authentication for all operations, including writing secrets. The error 403 indicates the request lacks a valid token. Logging in with the root token via `vault login <root-token>` authenticates the CLI session, allowing subsequent `vault kv put` commands to succeed.

Answer

Use the API directly with curl instead of the CLI

Answer

Enable the KV secret engine at a different path

Answer

Change the path to 'secret/hello' without 'data'

Question 14

An organization uses Vault's AWS secret engine to dynamically generate IAM credentials. The application uses the API to request credentials by calling 'POST /v1/aws/creds/my-role'. Recently, the application started receiving '400 Bad Request' with error 'invalid role ARN'. The role 'my-role' is defined in Vault and has been working for months. The administrator checks the role configuration and confirms the ARN is correct and that the associated IAM policy exists in AWS. The Vault server logs show no connectivity issues with AWS. The application code has not changed. What is the most likely cause?

Accepted Answer

The IAM role's trust policy has been modified to not allow Vault's AWS account to assume the role. The error 'invalid role ARN' from Vault's AWS secret engine indicates that Vault is unable to assume the IAM role during credential generation. Since the role ARN is confirmed correct in Vault and the IAM policy exists, the most likely cause is that the IAM role's trust policy no longer permits Vault's AWS account (or the external ID used by Vault) to assume the role. This would cause AWS to reject the sts:AssumeRole call, returning an error that Vault interprets as an invalid ARN, even though the ARN string itself is correct.

Answer

The Vault token used for the API call has expired

Answer

The role ARN has been changed in AWS but not updated in Vault

Answer

The application is calling the wrong API endpoint

Question 15

A DevOps engineer is troubleshooting a script that uses the Vault CLI to authenticate and read a secret. The script works when run manually from a terminal, but fails when executed by a CI/CD pipeline. The engineer has verified that the same environment variables (VAULT_ADDR, VAULT_TOKEN) are set in both environments. Which two of the following are likely causes of the failure? (Choose two.)

Accepted Answer

The pipeline does not have the VAULT_ADDR variable set correctly.. Option B is correct because if VAULT_ADDR is not set correctly, the CLI cannot reach the server. Option D is correct because network restrictions can block API access. Option A is wrong because the same VAULT_TOKEN is set, so it's not expired/revoked. Option C is wrong because CLI version differences rarely cause permission errors. Option E is wrong because a missing PATH would cause 'command not found', not CLI failure.

Answer

The pipeline's VAULT_TOKEN is expired or revoked.

Answer

The pipeline uses a different version of the Vault CLI.

Answer

The pipeline's shell does not have the vault binary in the PATH.

VA-003 Utilize Vault CLI and API Practice Test 4 — 15 Questions

Exhibit

VA-003 Utilize Vault CLI and API Practice Test 4 — 15 Questions

Exhibit