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. `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. Vault's KV Secrets Engine (version 2) uses POST to create a new version of a secret at a given path, automatically preserving previous versions for audit. This approach ensures the password is rotated without data loss, and the API handles non-existent paths by creating the secret if it does not exist, satisfying the requirement to handle missing paths gracefully.

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'. 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. 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. 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. 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"}. 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. 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 secret at 'app/db/data' does not exist. The policy explicitly allows 'read' on 'app/db/data', so the issue is not a policy path mismatch. The empty capabilities list from `vault token capabilities` suggests that the secret at 'app/db/data' does not exist, and Vault returns an empty capabilities list for non-existent paths when no policy grants access to that exact path. Since the application receives permission denied errors, the most likely cause is that the secret has not been created or has been deleted.

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

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. 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' occurs when Vault attempts to call sts:AssumeRole but AWS rejects the request. Since the role ARN is confirmed correct in Vault and the associated IAM policy exists in AWS, the most likely cause is that the IAM role's trust policy has been modified to no longer allow Vault's AWS account (or the external ID) to assume the role. A token expiration would result in a 403 Forbidden, not a 400 with 'invalid role ARN'. Changing the ARN in AWS without updating Vault would cause Vault to use a stale ARN, but the administrator confirmed the ARN is correct. The endpoint is correct as the request has been working for months. Thus, option B 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.. Even though the engineer verified that VAULT_ADDR is set in both environments, the CI/CD pipeline might have a different value or a typo in the variable definition. The Vault CLI uses the VAULT_ADDR environment variable to determine the endpoint for API calls; if it points to a wrong or unreachable address, authentication and secret retrieval will fail. This is a common misconfiguration when environment variables are injected differently in pipeline contexts versus manual shells.

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.