Utilize Vault CLI and API practice questions

Read only

Why wrong: Read only is incorrect because the default policy does not grant read permission on this path.

Create, read, update, delete, list

Why wrong: Create, read, update, delete, list is incorrect as the default policy grants no such permissions.

Read and list only

Why wrong: Read and list only is incorrect because the default policy does not grant read or list permissions on this path.

LIST /v1/secret/data/myapp/

Why wrong: Listing is done on the metadata path, not data.

POST /v1/secret/metadata/myapp/

Why wrong: Listing requires GET, not POST.

GET /v1/secret/myapp/

Why wrong: This endpoint is for reading a secret at the data path, not listing.

vault kv put secret/data/team api_key=abc123

Why wrong: Incorrect because the mount path is 'secret/', so the full path becomes 'secret/team' (the 'data/' is automatically inserted by Vault).

vault write secret/data/team api_key=abc123

Why wrong: Incorrect; 'vault write' is not the recommended way for KV v2, and the path is redundant.

vault write secret/team api_key=abc123

Why wrong: Incorrect command; 'vault write' is generic and not recommended for KV v2. Also, the path should be 'secret/data/team'.

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auths

Why wrong: Incorrect; the correct path is /v1/sys/auth, not /v1/sys/auths.

curl -X POST -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth

Why wrong: Incorrect; listing auth methods requires GET, not POST.

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/auth

Why wrong: Incorrect; /v1/auth is not a valid path for listing auth methods.

GET /v1/auth/userpass/login/jdoe with header "password: p@ssw0rd"

Why wrong: Incorrect; login requires POST and password in body.

PUT /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}

Why wrong: Incorrect; login endpoint uses POST, not PUT.

POST /v1/auth/userpass/login/jdoe?password=p@ssw0rd

Why wrong: Incorrect; password should be in request body, not query parameter.

vault write auth/token/create policies=read-only ttl=1h

Why wrong: Incorrect. `vault write auth/token/create` uses the API endpoint and expects different parameter syntax (e.g., `policies=["read-only"]`).

vault create token -policy=read-only -ttl=1h

Why wrong: Incorrect. `vault create` is not a valid Vault command.

curl -X POST -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws/

Why wrong: Incorrect; trailing slash may cause issues; the correct path is without trailing slash.

curl -X PUT -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws

Why wrong: Incorrect; the correct HTTP method is POST for enabling auth methods.

curl -X POST -H "X-Vault-Token: s.abc" -d '{"method":"aws"}' https://vault:8200/v1/sys/auth/aws

Why wrong: Incorrect; the JSON key should be 'type', not 'method'.

vault auth -method=token token=s.abc

Why wrong: Invalid; 'vault auth' is not a command; use 'vault login'.

vault authenticate -method=userpass username=jdoe

Why wrong: Invalid; 'vault authenticate' is not a command.

Setting environment variable VAULT_AUTH=s.abc

Why wrong: Invalid; the correct environment variable is VAULT_TOKEN.

The API path is /v1/secret/mysecret

Why wrong: Incorrect; that path is for KV v1.

The HTTP method used is POST

Why wrong: Incorrect; POST is for creating/updating secrets.

vault read -field=api_key secret/team

Why wrong: Incorrect; path should be 'secret/data/team' for KV v2.

vault read -field=api_key secret/data/team

Why wrong: Incorrect; api_key is nested under data, so you need 'data.api_key'.

vault read secret/data/team

Why wrong: Incorrect; this would output the full JSON, not just the api_key value.

The developer's user entry is disabled. The admin should enable it using 'vault write auth/userpass/users/<username>/enable'.

Why wrong: Incorrect; the user entry is not disabled as per the scenario.

The developer's password has expired. The admin should update the password with a new one.

Why wrong: Incorrect; userpass passwords do not have an expiration by default.

The developer's password hash is corrupted. The admin should delete and recreate the user entry.

Why wrong: Incorrect; password reset worked, so hash is not corrupted.

vault set

Why wrong: 'vault set' is not a valid Vault CLI command.

vault put

Why wrong: 'vault put' is not a valid Vault CLI command.

vault push

Why wrong: 'vault push' is not a valid Vault CLI command.

vault kv put secret/data/app/config password=newpass

Why wrong: 'vault kv put' overwrites the entire secret; 'username' would be lost.

vault update secret/data/app/config password=newpass

Why wrong: 'vault update' is not a valid Vault CLI command.

vault write secret/data/app/config password=newpass

Why wrong: 'vault write' also overwrites the entire secret data, similar to 'vault kv put'.

The Vault token has been revoked.

Why wrong: The stem explicitly states the token is valid and unexpired.

Network connectivity to Vault is intermittent, causing timeouts.

Why wrong: Network timeouts produce different error messages like 'connection refused' or 'timeout'.

The secret engine at that path has not been enabled.

Why wrong: Missing engine typically returns a 'path not found' error, not a generic API request error.

Increase the secret ID TTL to 60 days so the application can re-authenticate less frequently.

Why wrong: The secret ID is used only for initial login; the token TTL is the issue.

Set the token TTL to 0 (unlimited) so the token never expires.

Why wrong: Unlimited TTL is not a security best practice and may violate policy.

Have the application re-authenticate with the AppRole using the same secret ID after the token expires.

Why wrong: Re-authentication is possible but less efficient than renewal; the secret ID may still be valid, but the application would need to handle re-login logic.

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

Why wrong: This is incorrect because the transit secrets engine must be enabled before any key can be created within it.

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

Why wrong: This is incorrect because rotating a key before using it for encryption defeats the purpose; encryption and decryption should happen before rotation.

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

Why wrong: This is incorrect because a key must exist before encryption can occur; you cannot encrypt without first creating a key.

create: Allows reading data at the path.

Why wrong: Incorrect — 'create' capability does not grant read access; that is the role of 'read'.

read: Allows creating data at the path.

Why wrong: Incorrect — 'read' capability does not grant create access; that is the role of 'create'.

vault token create -policy=ldap

Why wrong: Incorrect. vault token create is used to generate new tokens, not to authenticate with LDAP. The -policy flag specifies policies for the token, but does not perform LDAP login.

vault write auth/ldap/login username=john

Why wrong: Incorrect. vault write auth/ldap/login is the raw API endpoint for LDAP login, but the correct CLI command is vault login -method=ldap. The CLI provides a more user-friendly interface.

vault auth enable ldap

Why wrong: Incorrect. vault auth enable ldap enables the LDAP authentication method in Vault, but does not perform authentication. It is a prerequisite for using LDAP, not the command to log in.

POST /v1/auth/token/roles/web-app with body {"default_ttl":"24h"}

Why wrong: Incorrect. The endpoint for creating a token role uses PUT method, not POST. POST /auth/token/roles/<role_name> is not the correct syntax.

POST /v1/auth/token/create/web-app with body {"default_ttl":"24h"}

Why wrong: Incorrect. The endpoint /auth/token/create/<role_name> is used to create a token using an existing role, not to create the role itself.

PUT /v1/auth/token/role/web-app with body {"default_ttl":"24h"}

Why wrong: Incorrect. The path uses 'role' (singular) instead of 'roles' (plural). The correct endpoint is /auth/token/roles/<role_name>.

The user is not authenticated.

Why wrong: The user is authenticated because the token is valid and the policy allows read/list on the path. A write attempt fails due to missing capabilities, not due to lack of authentication.

The secret engine is not mounted.

Why wrong: If the secret engine were not mounted, Vault would return a different error (e.g., 'no handler for route'). The error 'permission denied' indicates an authorization failure, not a missing mount.

The token is expired.

Why wrong: An expired token would cause an authentication error (e.g., 'token is expired or cannot be used'), not a 'permission denied' error. The token is valid, but lacks necessary capabilities.