Knowledge + Practice

CCNA Utilize Vault CLI and API Questions

62 questions · Utilize Vault CLI and API · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

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?

A.GET /v1/secret/metadata/myapp

B.POST /v1/auth/approle/login

C.GET /v1/secret/myapp

D.GET /v1/secret/data/myapp

AnswerD

This is the standard API path to read a KV v2 secret.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 API paths, specifically that KV v2 requires '/data/' in the path to read secrets, while KV v1 uses a flat path without '/data/'.

How to eliminate wrong answers

Option A is wrong because GET /v1/secret/metadata/myapp is used to read metadata (like version info) of a KV v2 secret, not the secret data itself. Option B is wrong because POST /v1/auth/approle/login is the endpoint for authenticating with AppRole RoleID and SecretID to obtain a Vault token, but the question states the application has already obtained a token, so this step is unnecessary. Option C is wrong because GET /v1/secret/myapp is the endpoint for the KV v1 secrets engine, which does not support versioning and uses a different path structure; the question implies KV v2 (since the path includes 'data'), and using KV v1 endpoint would fail or return incorrect data.

Practice this question →

2

MCQmedium

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?

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

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

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

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

AnswerD

Tokens inherit policies at creation time; updates to policies require new tokens or renewal depending on the auth method.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that policy updates are immediately enforced on all existing tokens, when in fact tokens carry a snapshot of policies at issuance and require re-issuance to reflect changes.

How to eliminate wrong answers

Option A is wrong because the administrator already corrected the policy, so the policy itself no longer contains the error; the issue is with the token's cached policies, not the current policy definition. Option B is wrong because policy updates in Vault are applied immediately to the server; there is no 'apply' step or propagation delay for policy changes. Option C is wrong because while a second policy could grant access, the question states the administrator checked the policy for service-a and corrected it, implying no other policy was mentioned; the most likely cause is the token's cached policies, not an additional attached policy.

Practice this question →

3

Multi-Selectmedium

A user wants to view information about their current token, including its policies and TTL. Which TWO CLI commands can be used?

Select 2 answers

A.vault read auth/token/lookup-self

B.vault token list

C.vault write auth/token/lookup

D.vault token info

E.vault token lookup

AnswersA, E

C is correct: reads the self-lookup API endpoint.

Why this answer

Option A is correct because `vault read auth/token/lookup-self` is a standard Vault CLI command that retrieves information about the current token, including its policies, Time-To-Live (TTL), and other metadata. This command uses the token lookup-self API endpoint, which is specifically designed for the calling token to inspect itself without needing explicit read permissions on its own token ID.

Exam trap

HashiCorp often tests the distinction between `vault token lookup` (which works for self-lookup without arguments) and `vault token info` (which does not exist), trapping candidates who assume a generic 'info' subcommand exists across all CLI tools.

Practice this question →

4

MCQmedium

Refer to the exhibit. A user with this policy attempts to read 'secret/data/team/admin'. What will happen?

A.Read succeeds because the first path allows read.

B.Read fails because the path does not exist.

C.Read fails because deny overrides the broader path.

D.Read succeeds if the user also has sudo capability.

AnswerC

B is correct: deny overrides any allow.

Why this answer

Option C is correct because Vault's policy evaluation uses a deny-by-default model where explicit deny rules override any allow rules. The policy first allows read on 'secret/data/team/*' but then explicitly denies read on 'secret/data/team/admin'. Since the deny rule is more specific and matches the exact path, it takes precedence, causing the read operation to fail.

Exam trap

HashiCorp often tests the misconception that broader allow rules automatically grant access to all sub-paths, but the trap here is that an explicit deny on a more specific path always overrides the broader allow, and candidates mistakenly think sudo can bypass deny rules.

How to eliminate wrong answers

Option A is wrong because it ignores the explicit deny rule; in Vault, a deny on a more specific path overrides a broader allow. Option B is wrong because the path 'secret/data/team/admin' does exist in the policy context; the failure is due to the deny rule, not a missing path. Option D is wrong because sudo capability in Vault allows bypassing ACL path restrictions but does not override explicit deny rules; sudo only applies to path capabilities, not to deny enforcement.

Practice this question →

5

MCQhard

Refer to the exhibit. A user authenticates via the userpass method. The token helper stores the token. The user's default policy grants read access to secret/data/engineering. The user attempts to read secret/data/engineering using `vault kv get secret/engineering`. The command fails with "permission denied". What is the most likely reason?

A.The token helper is interfering by providing an expired token.

B.The default policy does not include the path "secret/data/engineering".

C.The CLI command should use `vault read secret/data/engineering` instead.

D.The userpass authentication method requires a one-time password for each operation.

AnswerB

The default policy only grants capabilities for token management, not secret reading.

Why this answer

Option D is correct because the default policy typically does not include read access to secrets; it only allows token management. The command syntax is correct for KV v2, and the token is valid. Option A is wrong because the token is newly created and stored correctly.

Option B is wrong because the command `vault kv get` is the appropriate CLI command for KV v2. Option C is wrong because userpass does not require OTP.

Practice this question →

6

Multi-Selecteasy

Which TWO statements are true when troubleshooting a failed Vault CLI command?

Select 2 answers

A.Run 'vault token lookup' to verify the token is valid and has the expected policies.

B.Run 'vault write' to test if the token can write to a path.

C.Run 'vault login' to re-authenticate and obtain a new token if needed.

D.Run 'vault status' to check if the server is reachable.

E.Run 'vault read' to test if any secret is accessible.

AnswersA, C

This helps diagnose token-related issues.

Why this answer

Option A is correct because `vault token lookup` is the standard diagnostic command to inspect the current token's metadata, including its validity, creation time, TTL, and associated policies. If the token is expired, revoked, or lacks the necessary policies for the failed command, this command will reveal the issue directly without side effects.

Exam trap

HashiCorp often tests the misconception that `vault status` is the first troubleshooting step for any CLI failure, but it only verifies server reachability and seal state, not token or permission issues.

Practice this question →

7

MCQeasy

The CLI command returns a 403 error. What is the most likely cause?

A.The role 'readonly' does not exist

B.The database secrets engine is not mounted at 'database/'

C.The token does not have a policy allowing read on 'database/creds/readonly'

D.The field 'value' does not exist in the secret

AnswerC

403 is a permission denied error; the token's policy must grant read capability on that path.

Why this answer

A 403 Forbidden error from Vault indicates that the request was authenticated (the token is valid) but the token's policies do not grant permission for the requested action. Since the command attempts to read from 'database/creds/readonly', the most likely cause is that the token lacks a policy allowing read access on that path. This is a standard authorization failure, not an authentication or configuration issue.

Exam trap

HashiCorp often tests the distinction between authentication (401) and authorization (403) errors, where candidates mistakenly attribute a 403 to a missing mount or nonexistent role instead of recognizing it as a policy/permission issue.

How to eliminate wrong answers

Option A is wrong because a 403 error means the token was authenticated and the path exists; if the role 'readonly' did not exist, Vault would return a 404 (path not found) or a 400 (invalid role), not a 403. Option B is wrong because if the database secrets engine were not mounted at 'database/', Vault would return a 404 (path not found) or a 400 (invalid mount), not a 403. Option D is wrong because the field 'value' is irrelevant to a 403 error; a missing field would cause a 400 or 500 error during secret creation, not a permission-denied response on a read operation.

Practice this question →

8

MCQeasy

A user wants to log in using the userpass auth method with username 'jdoe' and password 'p@ssw0rd'. What is the correct API endpoint and request?

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

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

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

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

AnswerD

Correct; standard userpass login API call.

Why this answer

The userpass auth method in Vault requires a POST request to the login endpoint with the password provided in the JSON body. Option D correctly uses POST /v1/auth/userpass/login/jdoe with {"password":"p@ssw0rd"}, which matches the Vault API specification for authenticating against a userpass backend.

Exam trap

HashiCorp often tests the misconception that authentication requests can use GET or PUT methods or pass credentials in headers or query parameters, when Vault strictly requires POST with a JSON body for login endpoints.

How to eliminate wrong answers

Option A is wrong because it uses GET with a header, but Vault's userpass login endpoint requires a POST request, and the password must be sent in the JSON body, not as a header. Option B is wrong because it uses PUT, but Vault's login endpoints only accept POST requests for authentication. Option C is wrong because it passes the password as a query parameter, which is insecure and not supported by Vault's API; the password must be in the JSON body.

Practice this question →

9

MCQmedium

A user attempts to read a secret at path 'secret/data/app' and receives a 403 Forbidden error. What is the most likely cause?

A.The secret engine is not mounted at 'secret/'

B.The secret key does not exist

C.The token has expired

D.The token's policy does not grant read capability on that path

AnswerD

403 errors are caused by lack of permissions; the token's policy must allow 'read' on the path.

Why this answer

A 403 Forbidden error in Vault indicates that the token used for the request is valid and the path exists, but the token's attached policy does not grant the required 'read' capability on that specific path. This is a policy enforcement action by Vault's ACL system, which explicitly denies access when the policy lacks a matching 'read' rule for the path.

Exam trap

HashiCorp often tests the distinction between HTTP status codes in Vault: candidates confuse a 403 (policy denial) with a 404 (path not found) or assume an expired token always returns a 403, but the trap is that a 403 can also occur with a valid token lacking the correct policy, which is the most common scenario in practice.

How to eliminate wrong answers

Option A is wrong because if the secret engine were not mounted at 'secret/', the API would return a 404 Not Found error (path not found), not a 403. Option B is wrong because a missing secret key would also result in a 404 error (no value at path), not a 403, as the path itself is valid. Option C is wrong because an expired token would return a 403 Forbidden error, but the question asks for the 'most likely' cause; while an expired token can cause a 403, the scenario describes a user 'attempting to read' a secret, implying the token is still valid but lacks the necessary policy, which is the more common and direct cause in Vault's design.

Practice this question →

10

Multi-Selecthard

An operator needs to perform token lifecycle operations. Which THREE API endpoints are valid for token-related actions?

Select 3 answers

A.PUT /v1/auth/token/roles

B.POST /v1/auth/token/renew

C.DELETE /v1/auth/token/revoke

D.POST /v1/auth/token/create

E.GET /v1/auth/token/lookup

AnswersB, D, E

B is correct: renews a token's TTL.

Why this answer

Option B is correct because the `POST /v1/auth/token/renew` endpoint is the standard Vault API call to extend the Time-To-Live (TTL) of an existing token, which is a core token lifecycle operation. This endpoint accepts the token to renew in the request body and returns a new lease duration, adhering to Vault's token management design.

Exam trap

HashiCorp often tests the misconception that token revocation uses a DELETE HTTP method, but Vault's API consistently uses POST for all token lifecycle mutations, including revoke, renew, and create, to align with its idempotency and security design.

Practice this question →

11

MCQhard

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?

A.Use POST to write a new version at the secret path, which automatically preserves previous versions

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

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

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

AnswerA

POST is the correct method to create a new version in KV v2, preserving history.

Why this answer

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.

Practice this question →

12

MCQeasy

Which Vault CLI command is used to authenticate a user with a username and password to the userpass auth method?

A.vault login -method=userpass username=alice password=secret

B.vault auth userpass username=alice password=secret

C.vault token create -policy=userpass

D.vault authenticate userpass username=alice password=secret

AnswerA

This authenticates using the userpass method with provided credentials.

Why this answer

Option A is correct because `vault login -method=userpass` is the standard Vault CLI command to authenticate against the userpass auth method, passing the username and password as parameters. This command triggers the login endpoint (`/v1/auth/userpass/login/:username`) and returns a client token upon successful authentication.

Exam trap

HashiCorp often tests the exact CLI syntax, and the trap here is that candidates confuse `vault login` with non-existent commands like `vault auth` or `vault authenticate`, or misuse `vault token create` which is for generating tokens from an existing token, not for initial authentication.

How to eliminate wrong answers

Option B is wrong because `vault auth` is not a valid Vault CLI command; the correct subcommand for authentication is `vault login`. Option C is wrong because `vault token create -policy=userpass` creates a new token associated with a policy named 'userpass', not authenticating with a username and password. Option D is wrong because `vault authenticate` is not a valid Vault CLI command; the correct verb is `login`.

Practice this question →

13

MCQeasy

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?

A.Use the API directly with curl instead of the CLI

B.Enable the KV secret engine at a different path

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

D.Login with the root token that was output when the server started

AnswerD

Dev mode starts with a root token that is not automatically set.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that the CLI can operate without authentication in dev mode, or that the error is due to path syntax rather than missing credentials.

How to eliminate wrong answers

Option A is wrong because using curl directly would still require authentication (a valid token) and would result in the same 403 error without it. Option B is wrong because the KV secret engine is already enabled at the default path `secret/` in dev mode; enabling it at a different path does not resolve the authentication issue. Option C is wrong because the path `secret/hello` is automatically translated to `secret/data/hello` by the CLI for KV v2; changing the path does not bypass authentication.

Practice this question →

14

Multi-Selectmedium

Which TWO of the following Vault CLI commands can be used to write data to Vault?

Select 2 answers

A.vault set

B.vault put

C.vault push

D.vault write

E.vault kv put

AnswersD, E

'vault write' is a valid CLI command for writing data to any path, including KV secrets.

Why this answer

Option D is correct because `vault write` is the primary Vault CLI command for writing data directly to a specified path, including secrets, policies, or configuration. Option E is correct because `vault kv put` is the dedicated command for writing key-value pairs to the KV secrets engine, which is a common use case for storing secret data.

Exam trap

HashiCorp often tests the distinction between `vault write` and `vault kv put` by including plausible but nonexistent commands like `vault set` or `vault push`, leading candidates to confuse them with common Unix or Git commands.

Practice this question →

15

MCQeasy

An administrator wants to retrieve the value of a secret stored at the path 'kv/secret/mykey' using the Vault CLI. Which command should they use?

A.vault get kv/secret/mykey

B.vault retrieve kv/secret/mykey

C.vault show kv/secret/mykey

D.vault read kv/secret/mykey

AnswerD

'vault read' is the correct command to read a secret.

Why this answer

The correct command to retrieve a secret from Vault's KV secrets engine is `vault read`. This command is used to read data and metadata from a specified path. Option D is correct because `vault read kv/secret/mykey` will retrieve the value stored at that path, assuming the KV engine is mounted at `kv/`.

Exam trap

HashiCorp often tests the exact CLI verb (`read`) versus common but incorrect verbs like `get`, `retrieve`, or `show`, exploiting the fact that candidates may guess based on other tools (e.g., `curl`, `aws s3 cp`) rather than memorizing Vault's specific command set.

How to eliminate wrong answers

Option A is wrong because `vault get` is not a valid Vault CLI command; the correct verb is `read`. Option B is wrong because `vault retrieve` is not a valid Vault CLI command; Vault uses `read` for this operation. Option C is wrong because `vault show` is not a valid Vault CLI command; the command to read a secret is `vault read`.

Practice this question →

16

MCQmedium

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?

A.The lease has already expired and cannot be renewed

B.The increment value is too large and exceeds the maximum TTL

C.The lease ID is incomplete; it should include the full path like 'database/creds/readonly/abc123'

D.The operator does not have permission to renew leases

AnswerC

The lease ID must be the full ID, not just the suffix.

Why this answer

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

Exam trap

HashiCorp often tests the distinction between a role path and a lease ID, trapping candidates who assume the role path is the lease ID because it looks similar to the path used in `vault read` commands.

How to eliminate wrong answers

Option A is wrong because if the lease had already expired, the error would typically be 'lease not found' or 'lease expired', not 'invalid lease ID'. Option B is wrong because the increment value of 3600 seconds (1 hour) is within normal bounds and would only cause an error if it exceeded the backend's maximum TTL, which would produce a different error like 'TTL exceeds max TTL'. Option D is wrong because a permission error would return a 403 Forbidden status with an error like 'permission denied', not a 400 Bad Request with 'invalid lease ID'.

Practice this question →

17

MCQmedium

When running Vault in development mode, which storage backend is used by default?

A.Raft integrated storage

B.File system backend at /var/lib/vault

C.In-memory backend

D.Consul backend

AnswerC

Dev mode uses an in-memory backend by default.

Why this answer

When Vault is started in development mode using `vault server -dev`, it defaults to an in-memory storage backend. This is explicitly designed for local testing and development, as all data is stored in memory and lost when the process terminates. The in-memory backend requires no configuration and is automatically selected when no `-dev` flag overrides are provided.

Exam trap

HashiCorp often tests the distinction between development mode defaults and production mode defaults, trapping candidates who assume that Raft integrated storage (the production default) is also the development default, or who confuse the file system backend path with a default setting.

How to eliminate wrong answers

Option A is wrong because Raft integrated storage is the default for Vault in production mode (when no storage backend is explicitly configured), but not for development mode; development mode always uses the in-memory backend. Option B is wrong because the file system backend at /var/lib/vault is a common production storage backend but is never the default in development mode; it must be explicitly configured in the Vault configuration file. Option D is wrong because Consul backend is an external storage backend that requires a separate Consul cluster and is never the default in any Vault mode; it must be explicitly specified.

Practice this question →

18

MCQeasy

A user runs 'vault write secret/mydata value=hello' and gets a warning about missing metadata. They intended to store a simple key-value pair. What is the most likely issue?

A.The value must be JSON-encoded.

B.The token lacks write capability on that path.

C.The path is under KV v2 engine, which requires the data/ prefix.

D.The secret engine is not enabled.

AnswerC

B is correct: KV v2 expects path like secret/data/mydata.

Why this answer

The warning about missing metadata indicates the path is under a KV v2 secret engine, which requires the `data/` prefix before the path (e.g., `vault write secret/data/mydata value=hello`). KV v2 stores metadata and versioned data separately, so writing directly to `secret/mydata` triggers a warning because it expects the `data/` subpath. This is the most likely issue given the user's intent to store a simple key-value pair.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 path requirements, trapping candidates who assume all key-value engines use the same flat path structure without the `data/` prefix.

How to eliminate wrong answers

Option A is wrong because KV v2 accepts plain string values like `value=hello`; JSON encoding is optional and not required for simple key-value pairs. Option B is wrong because the warning specifically mentions missing metadata, not a permission error; if the token lacked write capability, the command would return a 403 Forbidden error, not a warning. Option D is wrong because if the secret engine were not enabled, the command would fail with an error like 'no secret engine mounted at secret/', not a warning about metadata.

Practice this question →

19

MCQmedium

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?

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

B.The token is expired or revoked

C.The engineer used the token accessor instead of the token ID

D.The default policy does not grant permission to look up other tokens

AnswerD

The default policy only allows self token lookup, not other tokens.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that the default policy grants broad token management capabilities, when in reality it only allows self-service operations and denies any cross-token inspection unless explicitly permitted via a custom policy with sudo capabilities.

How to eliminate wrong answers

Option A is wrong because the default policy does include the `token/lookup` capability for the caller's own token (via the `self` path), but the engineer is trying to look up a different token, which requires a policy that explicitly grants `token/lookup` on the specific token ID or a broader path. Option B is wrong because if the token were expired or revoked, the `vault token lookup` command would return an error like 'token not found' or 'bad token', not a permission denied error; permission denied indicates the token is valid but lacks authorization. Option C is wrong because the engineer used a token ID (starting with `s.`), not a token accessor (which starts with `a.`); using an accessor would also require specific policy permissions and would not cause a permission denied error in this context.

Practice this question →

20

MCQhard

A security team must automate periodic credential rotation for a database. The rotation script should run on a server that cannot have the Vault binary installed but can make HTTP requests. Which approach should they use?

A.Use the Vault CLI with curl to wrap commands.

B.Install Vault binary on the server and use CLI.

C.Use the Vault API with proper authentication.

D.Use Vault Agent to handle rotation.

AnswerC

C is correct: the API can be called via HTTP without the vault binary.

Why this answer

Option C is correct because the server can make HTTP requests, allowing it to interact with Vault's RESTful API directly without installing the Vault binary. The Vault API supports token-based authentication (e.g., using X-Vault-Token header) and can be used to programmatically rotate database credentials by calling the appropriate endpoint (e.g., POST /v1/database/rotate-root/:name). This approach satisfies the constraint of no binary installation while enabling secure, automated credential rotation.

Exam trap

HashiCorp often tests the distinction between using the Vault API directly versus relying on the Vault CLI or Agent, trapping candidates who assume that automation always requires the Vault binary or that Vault Agent is a lightweight alternative that doesn't need installation.

How to eliminate wrong answers

Option A is wrong because the Vault CLI is a binary that must be installed on the server, which violates the constraint that the server cannot have the Vault binary installed; wrapping CLI commands with curl does not eliminate the need for the binary. Option B is wrong because it explicitly requires installing the Vault binary on the server, which is prohibited by the scenario. Option D is wrong because Vault Agent is a separate binary that must be installed and configured on the server; it is not a solution for a server that cannot have the Vault binary installed.

Practice this question →

21

Multi-Selecthard

Which THREE API endpoints are valid for managing policies in Vault?

Select 3 answers

A.GET /v1/sys/policy/{name}

B.PUT /v1/sys/policy/{name}

C.PATCH /v1/sys/policy/{name}

D.DELETE /v1/sys/policy/{name}

E.POST /v1/sys/policy/{name}

AnswersA, D, E

GET retrieves the named policy.

Why this answer

The GET, DELETE, and POST endpoints are valid for managing policies in Vault. GET retrieves a policy, DELETE removes it, and POST creates or updates a policy. These correspond to the standard CRUD operations supported by Vault's sys/policy API.

Exam trap

HashiCorp often tests the misconception that PUT is the standard HTTP method for creating/updating resources in Vault, but Vault specifically uses POST for policy management, making PUT an invalid choice.

Practice this question →

22

MCQhard

You are a Vault administrator for a large organization. Your team uses a centralized Vault cluster with multiple auth methods enabled, including userpass, LDAP, and approle. Recently, a developer reported that they are unable to authenticate using their userpass credentials, receiving the error 'permission denied'. The developer confirms the username and password are correct. Other developers using userpass can authenticate successfully. The Vault audit logs show that the authentication request for this developer is reaching Vault but failing with 'invalid password'. You have verified that the password is correct by resetting it via the Vault CLI. The developer's userpass entry exists and is not disabled. Which of the following is the most likely cause and correct course of action?

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

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

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

D.The developer's account is locked due to too many failed login attempts. The admin should unlock the account using 'vault write auth/userpass/users/<username>/unlock'.

AnswerD

Correct; account lockout is a common cause of authentication failures after repeated failed attempts.

Why this answer

Option D is correct because Vault's userpass auth method supports account locking after a configurable number of failed login attempts (default is 0, meaning no lockout, but if set to a positive integer via `max_attempts`, the account becomes locked). The audit log shows 'invalid password' despite the password being verified as correct, and other users can authenticate, which points to a lockout rather than a password or user entry issue. The admin can unlock the account using `vault write auth/userpass/users/<username>/unlock` to restore access.

Exam trap

HashiCorp often tests the misconception that 'invalid password' always means the password is wrong, when in fact it can also indicate an account lockout, especially when the user confirms the password is correct and other users authenticate successfully.

How to eliminate wrong answers

Option A is wrong because the developer's user entry is confirmed to exist and not disabled; Vault userpass does not have an 'enable' endpoint—the correct command to enable a user would be `vault write auth/userpass/users/<username>/enable` does not exist; disabling is done via `vault write auth/userpass/users/<username>/disable` and re-enabling is not a standard operation. Option B is wrong because userpass passwords do not have an expiration mechanism by default; password expiry is not a feature of the userpass auth method unless custom TTL policies are applied, but the error 'invalid password' would not occur from expiry alone. Option C is wrong because password hash corruption is extremely unlikely in Vault's backend storage (which uses encrypted storage and integrity checks); deleting and recreating the user entry would be an unnecessary destructive action when the issue is lockout.

Practice this question →

23

Multi-Selectmedium

Which TWO of the following are valid methods to authenticate to Vault using the CLI?

Select 2 answers

A.vault auth -method=token token=s.abc

B.vault login -method=userpass username=jdoe

C.vault authenticate -method=userpass username=jdoe

D.Setting environment variable VAULT_AUTH=s.abc

E.vault login -method=ldap username=jdoe

AnswersB, E

Valid; userpass authentication via CLI.

Why this answer

Option B is correct because `vault login -method=userpass username=jdoe` is the valid CLI command to authenticate using the userpass auth method, which prompts for the password interactively. Option E is correct because `vault login -method=ldap username=jdoe` is the valid CLI command to authenticate using the LDAP auth method, also prompting for the password. Both commands follow the standard `vault login -method=<type>` syntax required by the Vault CLI.

Exam trap

HashiCorp often tests the distinction between the deprecated `vault auth` and the current `vault login` command, as well as the correct environment variable (`VAULT_TOKEN` vs. `VAULT_AUTH`), to catch candidates who rely on outdated documentation or assume generic naming conventions.

Practice this question →

24

MCQeasy

Refer to the exhibit. A user has a token that has the 'default' policy attached. What actions can the user perform on 'secret/data/team'?

A.No actions

B.Read only

C.Create, read, update, delete, list

D.Read and list only

AnswerD

Correct; default policy typically allows read and list on many paths.

Why this answer

The 'default' policy in Vault provides broad read and list capabilities across most paths, including 'secret/data/team'. It does not grant create, update, or delete permissions, which require explicit policy rules. Therefore, the user can only read and list secrets at that path.

Exam trap

HashiCorp often tests the misconception that the 'default' policy grants no permissions, when in fact it provides read and list access to most secret engines, leading candidates to incorrectly choose 'No actions' or 'Read only'.

How to eliminate wrong answers

Option A is wrong because the 'default' policy does grant read and list access, so the user is not restricted to no actions. Option B is wrong because the 'default' policy also allows list operations, not just read. Option C is wrong because create, update, and delete require explicit policy capabilities (e.g., 'create', 'update', 'delete') which are not included in the 'default' policy.

Practice this question →

25

MCQeasy

A developer wants to authenticate to Vault using LDAP credentials. Which CLI command should they use?

A.vault login -method=ldap username=john

B.vault token create -policy=ldap

C.vault write auth/ldap/login username=john

D.vault auth enable ldap

AnswerA

C is correct: vault login with -method=ldap prompts for password and authenticates.

Why this answer

Option A is correct because `vault login -method=ldap username=john` is the standard Vault CLI command to authenticate using LDAP credentials. This command triggers the LDAP auth method, prompting the user for their password (or accepting it via `-password` flag) and returning a Vault token upon successful authentication against the configured LDAP server.

Exam trap

The trap here is that candidates confuse the raw API endpoint (`vault write auth/ldap/login`) with the correct CLI login command (`vault login -method=ldap`), or mistake enabling the auth method for performing authentication.

How to eliminate wrong answers

Option B is wrong because `vault token create -policy=ldap` creates a new token with a specified policy, but it does not perform LDAP authentication; it requires an existing valid token and is used for token management, not for logging in with LDAP credentials. Option C is wrong because `vault write auth/ldap/login username=john` is an API-style command that would require the password to be passed in the request body (e.g., via `-password` flag or stdin), but the question specifies using the CLI, and the standard CLI command for login is `vault login -method=ldap`, not a raw write operation. Option D is wrong because `vault auth enable ldap` enables the LDAP auth method at a path (default `auth/ldap`), but it does not perform authentication; it is an administrative operation to configure the backend, not a login command.

Practice this question →

26

Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Enable, create key, encrypt, decrypt, rotate.

Practice this question →

27

MCQhard

A Vault agent is configured with auto-auth and is used to renew a long-running application's token. Which token type is best suited to minimize interruptions and avoid token renewal failures?

A.A root token

B.A periodic token

C.A service token with a short TTL

D.A batch token

AnswerB

Periodic tokens renew indefinitely as long as the TTL is not exceeded, reducing the risk of interruption.

Why this answer

A periodic token is best suited for long-running applications because it has a fixed lifetime that is automatically renewed by the Vault agent's auto-auth mechanism, and it does not require an associated entity or parent token to remain valid. This eliminates the risk of renewal failures due to parent token expiration or policy changes, ensuring uninterrupted operation.

Exam trap

HashiCorp often tests the misconception that service tokens with short TTLs are safer and more reliable for long-running processes, but the trap is that service tokens require a valid parent token or entity for renewal, which can expire or be revoked, whereas periodic tokens are self-renewing and independent.

How to eliminate wrong answers

Option A is wrong because a root token is a highly privileged, non-renewable token that bypasses all policies and ACLs; using it for a long-running application violates security best practices and it cannot be renewed via auto-auth without manual intervention. Option C is wrong because a service token with a short TTL requires frequent renewal and is tied to a parent token or entity; if the parent expires or the renewal fails, the token becomes invalid, causing interruptions. Option D is wrong because a batch token is stateless and cannot be renewed at all; it is designed for short-lived, one-shot operations and will expire after its TTL, making it unsuitable for long-running applications.

Practice this question →

28

MCQeasy

An administrator has created a policy file named 'app-policy.hcl'. Which command should they use to upload this policy to Vault?

A.vault write sys/policy/app-policy @app-policy.hcl

B.vault create policy app-policy app-policy.hcl

C.vault set policy app-policy app-policy.hcl

D.vault policy write app-policy app-policy.hcl

AnswerD

This is the correct CLI command to write a policy.

Why this answer

Option D is correct because the `vault policy write` command is the standard Vault CLI command to create or update a policy from a file. The syntax `vault policy write <name> <path>` reads the HCL or JSON policy definition from the specified file and writes it to Vault's policy storage.

Exam trap

HashiCorp often tests the exact CLI syntax for Vault policy management, and the trap here is that candidates confuse the generic `vault write` API call with the dedicated `vault policy write` command, or they invent non-existent commands like `vault create policy` or `vault set policy`.

How to eliminate wrong answers

Option A is wrong because `vault write sys/policy/app-policy @app-policy.hcl` uses the raw API endpoint but the correct CLI command for policy management is `vault policy write`, not a direct write to the sys/policy path. Option B is wrong because `vault create policy` is not a valid Vault CLI command; the correct command uses `vault policy write`. Option C is wrong because `vault set policy` does not exist in the Vault CLI; the correct verb is `write` for policy operations.

Practice this question →

29

MCQmedium

An engineer wants to list all secrets under the path 'myapp/' in a KV v2 secrets engine mounted at 'secret/'. Which API call should they make?

A.LIST /v1/secret/data/myapp/

B.POST /v1/secret/metadata/myapp/

C.GET /v1/secret/metadata/myapp/

D.GET /v1/secret/myapp/

AnswerC

This endpoint lists the secrets under the specified path in the metadata store.

Why this answer

Option C is correct because in Vault KV v2, the LIST operation for secrets under a path is performed using a GET request to the `/v1/secret/metadata/myapp/` endpoint. This endpoint returns the list of secrets (keys) at that path, as the metadata path is used for listing and managing secret metadata, including subkeys. The trailing slash is required to indicate a directory listing.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 API paths, and the trap here is that candidates confuse the data path (used for reading/writing secret values) with the metadata path (used for listing and managing secret metadata), leading them to select Option A or D.

How to eliminate wrong answers

Option A is wrong because `LIST /v1/secret/data/myapp/` uses the data path, which is for reading and writing secret data, not for listing; listing is done via the metadata path. Option B is wrong because `POST /v1/secret/metadata/myapp/` is used to create or update metadata (e.g., setting custom metadata), not to list secrets; listing requires a GET request. Option D is wrong because `GET /v1/secret/myapp/` is the legacy KV v1 API path; KV v2 requires the `/metadata/` or `/data/` prefix, and a GET to the root path without the version prefix would return an error or unexpected behavior.

Practice this question →

30

MCQhard

A security team needs to create a token with a custom TTL of 1 hour and associate it with a policy named 'read-only'. Which Vault CLI command accomplishes this?

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

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

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

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

AnswerA

Correct; vault token create creates a token with the specified policy and TTL.

Why this answer

Option A is correct because `vault token create -policy=read-only -ttl=1h` uses the correct Vault CLI syntax for creating a token with a custom TTL and associating it with a policy. The `-policy` flag specifies the policy name, and `-ttl=1h` sets the time-to-live to 1 hour, which is the standard format for duration in Vault CLI commands.

Exam trap

HashiCorp often tests the distinction between CLI syntax (`vault token create -policy=read-only -ttl=1h`) and API syntax (`vault write auth/token/create policies=["read-only"] ttl=1h`), leading candidates to confuse the two and select an option that mixes API parameters with CLI commands.

How to eliminate wrong answers

Option B is wrong because `vault write auth/token/create policies=read-only ttl=1h` uses the API path `auth/token/create` which is deprecated and requires the `policies` parameter to be a JSON array (e.g., `policies=read-only` is incorrect syntax; it should be `policies=["read-only"]`), and the `ttl` parameter expects a duration string like `1h` but the command structure is for the API, not the CLI. Option C is wrong because `vault token create -policy=read-only -ttl 1h` uses a space instead of an equals sign for the `-ttl` flag, which is incorrect syntax in Vault CLI; flags with values must use `=` (e.g., `-ttl=1h`) or be passed as separate arguments (e.g., `-ttl 1h` is actually valid in some contexts, but the standard and most reliable form is `-ttl=1h`; however, the key issue is that the `-policy` flag also uses `=` and the overall command is ambiguous—strictly, `-ttl 1h` is acceptable but inconsistent with the `-policy=read-only` format, making it less precise; the exam expects consistent `=` syntax). Option D is wrong because `vault create token -policy=read-only -ttl=1h` uses the incorrect subcommand `create` instead of `token create`; the correct Vault CLI command for token creation is `vault token create`, not `vault create token`.

Practice this question →

31

MCQhard

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

A.sudo

B.delete

C.list

D.patch

AnswerB

The 'delete' capability allows deletion of secrets.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that 'sudo' is a catch-all permission or that 'update' implies delete capability, but in Vault, each operation is explicitly scoped and 'delete' must be granted separately.

How to eliminate wrong answers

Option A is wrong because 'sudo' is a capability that bypasses ACL checks for certain privileged operations (e.g., enabling auth methods), not a generic permission to delete secrets; it would not grant delete access on 'team/*'. Option C is wrong because 'list' only allows listing keys at a path, not deleting them; it is a separate capability. Option D is wrong because 'patch' is not a standard Vault ACL capability; the correct capability for modifying existing secrets is 'update', and 'patch' is not defined in Vault's policy system.

Practice this question →

32

MCQhard

Refer to the exhibit. A user runs 'vault token renew -self' on this token. What is the expected behavior?

A.The token cannot be renewed because the token type is service.

B.The token TTL will reset to 72h from now.

C.The token will be renewed, but TTL cannot exceed 72h from issue time.

D.The token cannot be renewed because it is orphan.

AnswerB

A is correct: renew sets TTL to creation_ttl from current time.

Why this answer

The token's initial TTL was set to 72h, and the token has a renewable property (service tokens are renewable by default unless explicitly disabled). Running 'vault token renew -self' extends the token's lifetime by resetting the TTL to the original 72h from the current time, as long as the renewal does not exceed the token's maximum TTL (which is also 72h in this case). This behavior is defined by Vault's token lifecycle management, where renewable tokens can have their TTL reset to the initial value upon renewal.

Exam trap

HashiCorp often tests the misconception that service tokens cannot be renewed or that renewal is limited by the original issue time, when in fact renewal resets the TTL to the initial value from the current time, subject to the token's max TTL.

How to eliminate wrong answers

Option A is wrong because service tokens are renewable by default; the token type does not prevent renewal unless explicitly configured with 'renewable=false'. Option C is wrong because the TTL does not have a cap from the issue time; renewal resets the TTL to the initial 72h from the renewal time, not from the original issue time. Option D is wrong because being orphan (no parent token) does not affect renewability; orphan tokens can still be renewed as long as they are renewable and within their max TTL.

Practice this question →

33

MCQhard

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?

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

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

C.The token has expired and needs to be renewed

D.The Capabilities command does not work with AppRole tokens

AnswerB

KV v2 secrets require access to 'data' subpath; if the policy uses 'app/db' instead of 'app/db/data', it will fail.

Why this answer

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.

Exam trap

HashiCorp often tests the subtle difference between KV v1 and KV v2 path structures, where candidates mistakenly think the policy path is the same as the secret path without accounting for the 'data' prefix required by KV v2.

How to eliminate wrong answers

Option A is wrong because if the secret did not exist, the capabilities command would still return the allowed capabilities for the path (e.g., 'read' if the policy allows it), not an empty list. Option C is wrong because the token is described as a periodic token that renews automatically, and the administrator confirmed the token is valid; an expired token would not return an empty capabilities list but would fail authentication entirely. Option D is wrong because the `vault token capabilities` command works with any token, including AppRole tokens, as it queries the token's capabilities against a given path.

Practice this question →

34

MCQmedium

A DevOps engineer is troubleshooting a Vault CLI command that is failing with the error 'Error writing data: Error making API request'. The engineer has verified that the Vault token is valid and unexpired. Which of the following is the most likely cause of this error?

A.The Vault token has been revoked.

B.Network connectivity to Vault is intermittent, causing timeouts.

C.The secret engine at that path has not been enabled.

D.The policy attached to the token does not allow writing to the specified path.

AnswerD

A policy deny will cause a permission denied error, often reported as 'Error making API request'.

Why this answer

The error 'Error writing data: Error making API request' with a valid, unexpired token typically indicates an authorization failure. Vault enforces policy-based access control; if the token's attached policy does not include a 'write' or 'create' capability on the specified path, the API will reject the request with this generic error. Since the token is valid and not revoked, the most likely cause is insufficient permissions.

Exam trap

HashiCorp often tests the distinction between authentication (token validity) and authorization (policy permissions), leading candidates to mistakenly suspect network issues or missing secret engines when the real problem is a missing capability in the token's policy.

How to eliminate wrong answers

Option A is wrong because the engineer verified the token is valid and unexpired, so revocation is not the issue. Option B is wrong because intermittent network connectivity would typically produce timeout or connection refused errors, not a structured 'Error making API request' response from the Vault server. Option C is wrong because if the secret engine were not enabled, Vault would return a 404 'no handler for route' error, not a permission-related write error.

Practice this question →

35

MCQmedium

An operator needs to create a token role named 'web-app' with a default TTL of 24 hours. Which API request is correct?

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

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

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

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

AnswerC

B is correct: PUT on the roles endpoint creates the role.

Why this answer

Option C is correct because creating a token role in Vault requires a PUT request to the /v1/auth/token/roles/<role_name> endpoint, and the default_ttl parameter must be specified as a string with a time suffix (e.g., '24h'). The PUT method is used for creating or updating a role, and the path must include 'roles' (plural) followed by the role name.

Exam trap

HashiCorp often tests the distinction between creating a role (PUT /roles) and creating a token using a role (POST /create), and the trap here is that candidates mistakenly use the token creation endpoint or the wrong HTTP method for role creation.

How to eliminate wrong answers

Option A is wrong because it uses the POST method, but Vault's token role creation endpoint requires PUT; POST is used for other operations like token creation. Option B is wrong because it targets the /v1/auth/token/create/<role_name> endpoint, which is used for creating tokens using a role, not for creating the role itself. Option D is wrong because it uses 'role' (singular) in the path instead of 'roles' (plural), which is the correct API path for token role management.

Practice this question →

36

Multi-Selecthard

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

Select 3 answers

A.The wrapping token never expires

B.The wrapping token can only be used once to unwrap the response

C.The client can request response wrapping by setting the X-Vault-Wrap-TTL header

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

E.The wrapped response is stored in a cubbyhole secret engine

AnswersB, C, E

Single use is a key property.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that the wrapping token is reusable or that the original token is needed to unwrap, when in fact the wrapping token is single-use and self-contained for unwrapping.

Practice this question →

37

MCQhard

A user tries to renew their own token using 'vault token renew -self' and gets 'Error renewing token: Error making API request'. The token is still valid. What could be the cause?

A.The token was created with a period.

B.The token is not renewable.

C.The token's policy denies renewal.

D.The Vault server is unreachable.

AnswerB

A is correct: non-renewable tokens cannot be renewed.

Why this answer

The error 'Error renewing token: Error making API request' when using 'vault token renew -self' on a still-valid token indicates the token is not renewable. In Vault, tokens have a renewable flag; if set to false, the token cannot have its TTL extended, even if it is still valid. The error message is generic but the core issue is the token's non-renewable property, not a policy denial or server connectivity problem.

Exam trap

HashiCorp often tests the distinction between token validity and renewability, trapping candidates who assume a valid token can always be renewed, when in fact the renewable flag is a separate attribute checked before any policy or TTL logic.

How to eliminate wrong answers

Option A is wrong because a token created with a period (explicit TTL) can still be renewable if the renewable flag is set to true; the period does not inherently prevent renewal. Option C is wrong because policy denial would result in a permission denied error (403), not a generic 'Error making API request' message; the token's own renewable flag is checked before policy. Option D is wrong because if the Vault server were unreachable, the error would typically be a connection timeout or refused, not a specific 'Error making API request' response from the server.

Practice this question →

38

MCQhard

An admin wants to list all enabled authentication methods using the Vault API. Which curl command is correct?

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

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

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

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

AnswerB

Correct; GET to /v1/sys/auth returns all enabled auth methods.

Why this answer

Option B is correct because the Vault API endpoint to list all enabled authentication methods is a GET request to `/v1/sys/auth`. This endpoint returns a map of all enabled auth methods, and the command uses the correct HTTP method (GET) and the required `X-Vault-Token` header for authentication.

Exam trap

HashiCorp often tests the exact API endpoint path and HTTP method, so the trap here is confusing the `/v1/sys/auth` endpoint with the non-existent `/v1/sys/auths` or the incorrect `/v1/auth` path, or assuming a POST request is needed when a GET is correct.

How to eliminate wrong answers

Option A is wrong because `/v1/sys/auths` is not a valid Vault API endpoint; the correct path is `/v1/sys/auth` (without the trailing 's'). Option C is wrong because it uses `-X POST` instead of the required GET method; the `/v1/sys/auth` endpoint only supports GET and DELETE operations, not POST. Option D is wrong because `/v1/auth` is not a valid API path; the correct base path for listing auth methods is `/v1/sys/auth`.

Practice this question →

39

MCQmedium

An operator needs to create a periodic token with a period of 36 hours. Which command should they use?

A.vault token create -period=36h

B.vault token create -period=36h -explicit-max-ttl=36h

C.vault token create -ttl=36h

D.vault token create -explicit-max-ttl=36h

AnswerA

C is correct: -period creates a periodic token.

Why this answer

Option A is correct because the `vault token create -period=36h` command creates a periodic token with a specified renewal period of 36 hours. Periodic tokens have no explicit TTL; their lifetime is tied to the renewal period, and they can be renewed indefinitely as long as the parent token is valid. This matches the requirement for a token that automatically extends its lifetime every 36 hours.

Exam trap

HashiCorp often tests the distinction between `-period` (for periodic tokens) and `-ttl` (for fixed-lifetime tokens), leading candidates to confuse the two and incorrectly choose `-ttl` when a renewable periodic token is required.

How to eliminate wrong answers

Option B is wrong because adding `-explicit-max-ttl=36h` imposes a hard upper limit on the token's lifetime, which contradicts the purpose of a periodic token that should be renewable indefinitely without a fixed maximum. Option C is wrong because `-ttl=36h` creates a non-periodic token with a fixed TTL of 36 hours, after which it expires and cannot be renewed beyond that time. Option D is wrong because `-explicit-max-ttl=36h` alone creates a token with a hard maximum lifetime but no periodic renewal behavior, so it does not meet the requirement for a periodic token.

Practice this question →

40

Multi-Selectmedium

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

Select 2 answers

A.The pipeline does not have the VAULT_ADDR variable set correctly.

B.The pipeline's VAULT_TOKEN is expired or revoked.

C.The pipeline uses a different version of the Vault CLI.

D.The pipeline runs in a restricted network that cannot reach the Vault server.

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

AnswersA, D

Without correct VAULT_ADDR, the CLI cannot connect to Vault, causing failure.

Why this answer

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.

Practice this question →

41

MCQeasy

A DevOps engineer is tasked with automating the rotation of a static secret stored in Vault's KV secrets engine (version 2). The secret is currently stored at path 'secret/data/app/config' with keys 'username' and 'password'. The engineer wants to update the 'password' key using the Vault CLI from a CI/CD pipeline. The pipeline uses a token with a policy that grants 'create', 'update', and 'read' capabilities on 'secret/data/app/*'. Which CLI command should the engineer use to update only the 'password' key, leaving other keys unchanged?

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

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

C.vault kv patch secret/data/app/config password=newpass

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

AnswerC

'vault kv patch' performs a partial update; only the specified key is changed.

Why this answer

Option C is correct because `vault kv patch` is specifically designed for KV v2 secrets engines to update individual keys without overwriting other keys. It performs a read-modify-write operation under the hood, sending a PATCH request to the API, which only modifies the specified fields. The policy grants 'create', 'update', and 'read' on 'secret/data/app/*', which aligns with the required capabilities for patching.

Exam trap

HashiCorp often tests the distinction between `vault kv put` (full overwrite) and `vault kv patch` (partial update) in KV v2, and candidates mistakenly assume `vault write` or `vault kv put` can selectively update keys, not realizing they replace the entire secret data.

How to eliminate wrong answers

Option A is wrong because `vault kv put` performs a full write, which would overwrite the entire secret at 'secret/data/app/config', deleting the 'username' key if not included. Option B is wrong because `vault update` is not a valid Vault CLI command; the correct verb for writing data is `vault write`. Option D is wrong because `vault write` on a KV v2 path sends a PUT request that replaces the entire secret data, similar to `vault kv put`, and would remove the 'username' key.

Practice this question →

42

MCQeasy

A company uses Vault to manage secrets for multiple applications. A new security policy requires that all human users authenticate using LDAP and that all machine-to-machine authentication uses AppRole. An administrator has configured an LDAP auth method at 'ldap/' and an AppRole at 'approle/'. The administrator creates a role 'web-app' with a secret ID TTL of 30 days and a token TTL of 1 hour. After deploying the web application, the application successfully logs in using the AppRole role ID and secret ID, retrieves a token, and reads secrets. However, after 1 hour, the application begins receiving 'permission denied' errors when trying to read secrets. The application logs show that it is using the same token obtained during initial login. Which action should the administrator take to resolve this issue?

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

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

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

D.Configure the application to renew the token before it expires by calling the 'auth/token/renew' endpoint.

AnswerD

Token renewal extends the token's lifetime, preventing permission denied errors after TTL expiry.

Why this answer

Option D is correct because the application's token has a TTL of 1 hour, and once it expires, Vault will reject any further requests using that token. The application must renew the token before it expires by calling the 'auth/token/renew' endpoint, which extends the token's lifetime (up to the maximum TTL configured on the role). This is the standard pattern for long-running applications using short-lived tokens.

Exam trap

HashiCorp often tests the distinction between secret ID TTL and token TTL, leading candidates to confuse the two and incorrectly choose options that modify the secret ID or re-authenticate instead of renewing the token.

How to eliminate wrong answers

Option A is wrong because increasing the secret ID TTL does not affect the token's lifetime; the secret ID is only used during initial authentication to obtain a token, and the token's TTL is independent. Option B is wrong because setting the token TTL to 0 (unlimited) violates the security policy requiring short-lived tokens and is not a recommended practice; Vault's default maximum TTL also limits this. Option C is wrong because re-authenticating with the same secret ID after the token expires would work, but it is inefficient and unnecessary; the application should instead renew the existing token to avoid the overhead of re-authentication and to maintain a continuous session.

Practice this question →

43

MCQmedium

An administrator wants to mount the AWS secrets engine at 'aws' path using the API. Which request is correct?

A.PUT /v1/sys/mounts/aws with body {"type":"aws"}

B.POST /v1/sys/auth/aws with body {"type":"aws"}

C.POST /v1/sys/mounts/aws with body {"type":"aws"}

D.POST /v1/sys/mounts/aws with body {"type":"aws-secrets"}

AnswerC

A is correct: POST to mounts with type aws mounts the engine.

Why this answer

Option C is correct because mounting a secrets engine in Vault is performed via a POST request to the `/v1/sys/mounts/<path>` endpoint with a JSON body containing the `"type"` field set to the engine's type identifier. For the AWS secrets engine, the type is `"aws"`, and the path is specified in the URL as `aws`. The POST method is required for creating a new mount, while PUT is used for tuning an existing mount.

Exam trap

HashiCorp often tests the distinction between POST (create) and PUT (update/tune) for Vault API endpoints, and candidates confuse the mount path with auth method paths or use an incorrect type string like 'aws-secrets' instead of the official 'aws'.

How to eliminate wrong answers

Option A is wrong because it uses the PUT method, which is reserved for tuning an existing mount (e.g., updating configuration or adjusting default lease TTLs), not for creating a new mount; creating a mount requires POST. Option B is wrong because it targets the `/v1/sys/auth/aws` endpoint, which is used for enabling an auth method (like LDAP or AppRole), not for mounting a secrets engine; secrets engines are mounted under `/v1/sys/mounts/`. Option D is wrong because it specifies `"type":"aws-secrets"` in the body, but the correct type identifier for the AWS secrets engine is `"aws"`; `"aws-secrets"` is not a valid Vault engine type.

Practice this question →

44

MCQeasy

A team wants to retrieve a dynamic database credential from Vault. Which CLI command should be used?

A.vault list database/creds/readonly

B.vault generate database/creds/readonly

C.vault write database/creds/readonly

D.vault read database/creds/readonly

AnswerC

A is correct: write to the creds path generates new dynamic credentials.

Why this answer

Option C is correct because Vault uses the `vault write` command to generate dynamic credentials from a database secrets engine. The `database/creds/readonly` path triggers the generation of a new credential (username/password) for the configured role, and the response includes the lease ID, username, and password. Unlike static secrets, dynamic credentials are created on demand and require a write operation to the role path.

Exam trap

HashiCorp often tests the misconception that `vault read` is used for all secret retrieval, but dynamic secrets require a `vault write` because the operation creates a new credential rather than reading an existing one.

How to eliminate wrong answers

Option A is wrong because `vault list` is used to enumerate paths or keys under a given path, not to generate credentials; it would return a list of role names, not a credential. Option B is wrong because `vault generate` is not a valid Vault CLI command; the correct verb for generating dynamic secrets is `vault write`. Option D is wrong because `vault read` retrieves static secrets or configuration data, but for dynamic database credentials, a write operation is required to trigger credential creation and return the lease.

Practice this question →

45

MCQmedium

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?

A.The Vault token used for the API call has expired

B.The IAM role's trust policy has been modified to not allow Vault's AWS account to assume the role

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

D.The application is calling the wrong API endpoint

AnswerB

Vault assumes the role; if trust policy changes, it fails.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between a syntactically correct ARN and a role that is actually assumable, leading candidates to focus on the ARN string itself rather than the trust policy that governs cross-account access.

How to eliminate wrong answers

Option A is wrong because an expired Vault token would result in a '403 Forbidden' or 'permission denied' error, not a '400 Bad Request' with 'invalid role ARN', as token expiration is an authentication issue unrelated to the role ARN validation. Option C is wrong because if the role ARN had been changed in AWS but not updated in Vault, the error would likely be 'role not found' or a different AWS error, and the administrator confirmed the ARN is correct in Vault. Option D is wrong because calling the wrong API endpoint would result in a '404 Not Found' or '405 Method Not Allowed', not a '400 Bad Request' with a specific error about the role ARN.

Practice this question →

46

MCQmedium

An operator wants to enable the AWS auth method at the default path. Which curl command is correct?

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

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

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

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

AnswerD

Correct; POST to /v1/sys/auth/aws with type 'aws' enables the AWS auth method.

Why this answer

Option D is correct because enabling an auth method at the default path requires a POST request to the `/v1/sys/auth/aws` endpoint with a JSON payload containing the `type` field set to `"aws"`. The POST method is used to create a new mount, and the trailing slash is optional but accepted. The `X-Vault-Token` header provides the necessary authentication token.

Exam trap

HashiCorp often tests the distinction between the correct HTTP method (POST vs PUT) and the exact payload field name (`type` vs `method`), as candidates may confuse the API for enabling auth methods with other Vault operations that use PUT or different field names.

How to eliminate wrong answers

Option A is wrong because it includes a trailing slash in the URL (`/v1/sys/auth/aws/`), which is not the standard path for enabling auth methods; Vault API expects the path without a trailing slash for this operation. Option B is wrong because it uses the PUT method instead of POST; while Vault's API sometimes accepts PUT for updates, enabling a new auth method requires POST as per the official documentation. Option C is wrong because the payload uses `{"method":"aws"}` instead of `{"type":"aws"}`; the correct field name is `type`, not `method`, and using `method` would cause Vault to ignore the field or return an error.

Practice this question →

47

Multi-Selecteasy

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

Select 2 answers

A.vault login -method=userpass username=joe password=pass

B.vault login -method=ldap username=joe password=pass

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

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

E.vault token create -policy=default

AnswersA, B

This authenticates and sets the token for the CLI session.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between the `vault login` command (which performs tokenless authentication) and the `vault write` command (which requires an existing token), leading candidates to mistakenly choose D as a valid tokenless method because it appears to send credentials directly.

Practice this question →

48

MCQmedium

Refer to the exhibit. A developer ran the command and received the JSON output. Which command would retrieve only the value of 'api_key' in plain text?

A.vault read -field=api_key secret/team

B.vault read -field=api_key secret/data/team

C.vault read -field=data.api_key secret/data/team

D.vault read secret/data/team

AnswerC

Correct; -field=data.api_key extracts the nested value.

Why this answer

Option C is correct because the `vault read` command with `-field=data.api_key` uses dot notation to navigate the nested JSON structure returned by the KV v2 secrets engine at `secret/data/team`. The KV v2 engine wraps the actual data under a `data` key, so to extract the `api_key` value directly, you must specify the full path `data.api_key`. Without this, the command would either fail or return the entire JSON object.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 engines, and the trap here is that candidates forget the `data.` prefix required for KV v2, leading them to choose Option B which looks correct but fails due to the nested structure.

How to eliminate wrong answers

Option A is wrong because `secret/team` is the KV v1 path, but the exhibit shows a KV v2 engine (indicated by the `data` key in the JSON output), and using the v1 path would return a different structure or an error. Option B is wrong because `-field=api_key` without the `data.` prefix attempts to access `api_key` at the top level of the JSON, but in KV v2 the actual key is nested under `data`, so this would return nothing or an error. Option D is wrong because it omits the `-field` flag entirely, so it would print the full JSON output including metadata, not just the plain-text value of `api_key`.

Practice this question →

49

Matchingmedium

Match each Vault policy capability to its permission.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Allow creating data at a path

Allow reading data at a path

Allow modifying existing data

Allow deleting data

Allow listing keys

Why these pairings

These are the standard policy capabilities in Vault.

Practice this question →

50

Multi-Selectmedium

Which THREE are benefits of using Vault response wrapping?

Select 3 answers

A.Reduces the risk of secret exposure in transit

B.Supports unlimited unwraps

C.Ensures the secret is used only once

D.Increases the TTL of the secret

E.Enables delegation of access without sharing the actual token

AnswersA, C, E

The wrapped token contains the secret and is unwrapped only by the intended recipient.

Why this answer

Vault response wrapping is a feature that encapsulates a secret or token in a single-use, time-limited wrapping token. Option A is correct because the secret is never transmitted in plaintext over the wire; instead, the wrapping token is sent, and the actual secret is retrieved only by unwrapping it, which reduces the risk of secret exposure during transit. Option C is correct because the wrapping token is designed for a single unwrap operation—once unwrapped, the token is destroyed, ensuring the secret is used only once.

Option E is correct because response wrapping allows a user to delegate access to a secret by sharing the wrapping token instead of the actual token, enabling secure delegation without exposing the underlying credential.

Exam trap

HashiCorp often tests the misconception that response wrapping tokens can be unwrapped multiple times or that wrapping extends the secret's TTL, but the key trap is confusing the wrapping token's TTL with the secret's TTL—they are independent and wrapping does not alter the original secret's expiration.

Practice this question →

51

MCQhard

An administrator needs to securely provide a one-time use token to a remote service using Vault response wrapping. Which CLI flag or command should they use?

A.Use 'vault write -response-wrap auth/token/create'

B.Use 'vault unwrap' on the remote service

C.Use 'vault write -wrap-ttl=5m auth/token/create'

D.Use 'vault wrap auth/token/create'

AnswerC

This command generates a wrapped token with a 5-minute TTL, which is then unwrapped by the recipient.

Why this answer

Option C is correct because `vault write -wrap-ttl=5m auth/token/create` creates a one-time use token wrapped in a response-wrapping envelope with a specified TTL. The remote service can then unwrap the token using `vault unwrap` with the wrapping token, ensuring secure delivery without exposing the actual token in transit.

Exam trap

HashiCorp often tests the distinction between the `-wrap-ttl` flag used during `vault write` to create a wrapped response versus the `vault unwrap` command used to retrieve the secret, leading candidates to confuse the creation step with the retrieval step.

How to eliminate wrong answers

Option A is wrong because `-response-wrap` is not a valid flag; the correct flag is `-wrap-ttl` to set the TTL for the wrapping token. Option B is wrong because `vault unwrap` is the command used on the remote service to retrieve the original token, but it is not the CLI flag or command used to create the wrapped token. Option D is wrong because `vault wrap` is not a valid command; the correct approach is to use `vault write` with the `-wrap-ttl` flag to generate a wrapped response.

Practice this question →

52

MCQmedium

A DevOps engineer needs to write a new secret to the KV v2 engine at path 'secret/data/team' with key 'api_key' and value 'abc123'. Which Vault CLI command achieves this?

A.vault kv put secret/data/team api_key=abc123

B.vault kv put secret/team api_key=abc123

C.vault write secret/data/team api_key=abc123

D.vault write secret/team api_key=abc123

AnswerB

Correct command; 'vault kv put' writes to KV v2 engine at the specified path (mount path is 'secret/', the secret is 'team').

Why this answer

Option B is correct because the KV v2 engine automatically prefixes the path with 'data/' when using the 'vault kv put' command. The correct path for writing a secret to the KV v2 engine is 'secret/data/team', but the CLI command 'vault kv put secret/team api_key=abc123' handles this internally by appending '/data/' to the path. This is a key difference from the 'vault write' command, which requires the full path including 'data/'.

Exam trap

HashiCorp often tests the distinction between 'vault kv put' and 'vault write' for KV v2, where candidates mistakenly use the full API path with 'vault kv put' or the wrong command for the engine version.

How to eliminate wrong answers

Option A is wrong because it uses 'vault kv put' with the full path 'secret/data/team', which would result in a double 'data/' prefix (i.e., 'secret/data/data/team'), causing a 404 error. Option C is wrong because 'vault write' with path 'secret/data/team' is the correct raw API path for KV v2, but the question asks for the CLI command that 'achieves' this, and 'vault kv put' is the preferred and simpler CLI method; however, this option is technically correct for writing but not the best practice CLI command, and the exam expects the 'vault kv put' syntax. Option D is wrong because 'vault write secret/team' would target the KV v1 engine (or the metadata path in v2), not the data path, and would fail to write the secret correctly under KV v2.

Practice this question →

53

Multi-Selecthard

Which THREE of the following are correct about using the Vault API to read a secret from KV v2 engine?

Select 3 answers

A.The response JSON contains a 'data' key with the secret values

B.The HTTP method used is GET

C.The API path is /v1/secret/mysecret

D.The HTTP method used is POST

E.The API path is /v1/secret/data/mysecret

AnswersA, B, E

Correct; the secret data is nested under 'data.data'.

Why this answer

Option A is correct because the KV v2 engine returns secret data nested under a 'data' key in the JSON response. This is a deliberate design to separate metadata (e.g., version, created_time) from the actual secret values, which are placed under 'data.data'. The Vault API always uses GET for reading secrets from KV v2, making option B correct.

Option E is correct because the KV v2 engine requires the path to include '/data/' after the mount point (e.g., /v1/secret/data/mysecret) to distinguish read operations from metadata or delete operations.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 API paths, and the trap here is that candidates assume the bare path /v1/secret/mysecret works for both versions, forgetting that KV v2 requires the '/data/' segment for read operations.

Practice this question →

54

MCQhard

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?

A.The request fails because the CLI command syntax is wrong

B.The request fails because secondary clusters cannot write any data

C.The request succeeds because the SSH secret engine is a local mount that exists on the secondary

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

AnswerC

SSH secret engine is typically local, so it works on the secondary.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that performance secondary clusters are entirely read-only, but the trap here is that local mounts (like the SSH secret engine) are writable on the secondary, while only replicated mounts are read-only.

How to eliminate wrong answers

Option A is wrong because the CLI command syntax is correct; `vault write ssh/otp/otp_role ip=10.0.0.1 username=admin` is the proper format for generating an OTP for an SSH target. Option B is wrong because performance secondary clusters can write data to local mounts (like the SSH secret engine) and to certain replicated paths that allow writes (e.g., token creation), though they cannot write to replicated mounts from the primary. Option D is wrong because the SSH secret engine is a local mount by default and does not need to be replicated; in fact, replicating it would defeat the purpose of local SSH OTP generation.

Practice this question →

55

MCQhard

A DevOps engineer needs to create a token with a specific policy attached using the Vault API. Which API endpoint and request should they use?

A.POST /v1/auth/token/create with JSON body {"policies":["my-policy"]}

B.POST /v1/auth/token/create-orphan with JSON body {"policies":["my-policy"]}

C.POST /v1/token/create with JSON body {"policy":"my-policy"}

D.POST /v1/sys/token with JSON body {"policy":"my-policy"}

AnswerA

This creates a token with the specified policy.

Why this answer

Option A is correct because the Vault API endpoint for creating tokens with specific policies is POST /v1/auth/token/create, and the JSON body must include the 'policies' key as an array of strings. This endpoint is part of the token auth method and allows attaching policies at token creation time.

Exam trap

HashiCorp often tests the exact API path and JSON key naming conventions, tricking candidates who confuse 'policy' (singular) with 'policies' (array) or omit the 'auth' segment in the endpoint path.

How to eliminate wrong answers

Option B is wrong because POST /v1/auth/token/create-orphan creates an orphan token (not parented by the requesting token), but the question does not specify orphan behavior; the standard create endpoint suffices and the -orphan variant is not required. Option C is wrong because the correct path is /v1/auth/token/create, not /v1/token/create; the 'auth' segment is mandatory for the token auth method, and the JSON key must be 'policies' (array), not 'policy' (string). Option D is wrong because /v1/sys/token is not a valid endpoint; token creation is under /v1/auth/token/, and the JSON body must use 'policies' as an array, not 'policy' as a string.

Practice this question →

56

MCQhard

A user receives 'permission denied' when running 'vault write secret/data/myapp value=123'. The user's token has a policy that includes 'path "secret/data/*" { capabilities = ["read", "list"] }'. What is the most likely cause?

A.The user is not authenticated.

B.The path requires create or update capability.

C.The secret engine is not mounted.

D.The token is expired.

AnswerB

D is correct: write requires create or update, but policy only has read and list.

Why this answer

The user's policy grants only 'read' and 'list' capabilities on the path 'secret/data/*'. The 'vault write' command requires either 'create' or 'update' capability (or both) on the path. Since the policy lacks these capabilities, Vault returns a 'permission denied' error, even though the token is valid and the secret engine is mounted.

Exam trap

HashiCorp often tests the distinction between capabilities required for different operations (read/list vs. create/update/delete), leading candidates to assume that any valid token with any capabilities on the path can write, when in fact the policy must explicitly include 'create' or 'update'.

How to eliminate wrong answers

Option A is wrong because the user received a 'permission denied' error, not an 'authentication required' error; the token is present and valid, but lacks the necessary capabilities. Option C is wrong because if the secret engine were not mounted, the error would be 'no secret engine mounted at secret/' or 'path not found', not 'permission denied'. Option D is wrong because an expired token would return an 'invalid token' or 'token expired' error, not a 'permission denied' error.

Practice this question →

57

Multi-Selectmedium

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

Select 2 answers

A.PUT /v1/sys/leases/revoke with body {"lease_id": "abc123"}

B.GET /v1/sys/leases/renew/abc123

C.POST /v1/sys/leases/renew/abc123

D.PUT /v1/sys/leases/renew with body {"lease_id": "abc123"}

E.GET /v1/sys/leases/revoke/abc123

AnswersA, D

Correct endpoint and method.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between using path parameters versus request body for lease IDs, and the requirement for PUT over GET for state-changing operations, leading candidates to mistakenly select GET endpoints or incorrect URL patterns.

Practice this question →

58

MCQeasy

A junior administrator is writing a shell script that will be used by other team members to retrieve static secrets from Vault. The secrets are stored in the KV v2 secrets engine mounted at `secret/`. One particular secret, `credentials`, is located under the path `secret/data/credentials`. The administrator has already authenticated using the Vault CLI with a token that has read access specifically to that path. The environment variables `VAULT_ADDR` and `VAULT_TOKEN` are set correctly to point to the Vault server at `https://vault.example.com:8200` and the valid token. The script needs to run the correct command to retrieve the secret and output its key-value pairs for use by an application. Which command should the administrator include in the script?

A.vault kv get secret/data/credentials

B.vault read secret/data/credentials

C.vault read secret/credentials

D.vault kv get secret/credentials

AnswerD

Correct command; the CLI abstracts the /data/ prefix for KV v2 engines.

Why this answer

Option C is correct because `vault kv get secret/credentials` is the standard CLI command for retrieving secrets from a KV v2 engine. It automatically maps to the API path `secret/data/credentials`. Option A uses `vault read` with an incomplete path.

Option B is technically valid but not the idiomatic CLI command; the exam expects `vault kv get`. Option D appends an extra `/data/` resulting in a non-existent path.

Practice this question →

59

Multi-Selecteasy

A policy must allow a user to write a new version of an existing secret in a KV v2 secrets engine. Which TWO capabilities are required on the 'data/' path?

Select 2 answers

A.delete

B.list

C.read

D.update

E.create

AnswersD, E

C is needed to overwrite an existing secret.

Why this answer

To write a new version of an existing secret in a KV v2 secrets engine, the user needs the 'update' capability on the 'data/' path. This is because the KV v2 API uses a POST/PATCH request to the 'data/' endpoint to create a new version of an existing secret, and the 'update' capability grants permission to modify existing data. The 'create' capability is also required because if the secret does not exist, the same endpoint call will create it, and the policy must allow both creation and update for a seamless write operation.

Exam trap

HashiCorp often tests the misconception that 'write' is a separate capability in KV v2, but in reality, writing a new version requires both 'create' and 'update' because the same API call handles both new and existing secrets.

Practice this question →

60

MCQmedium

This Vault agent configuration section is incomplete. What is missing for the AWS auto-auth method to function correctly?

A.The configuration needs a 'region' parameter

B.The role name 'my-role' is invalid

C.The method type should be 'iam' instead of 'aws'

D.AWS credentials must be provided via environment variables or instance metadata

AnswerD

Vault's AWS auth method requires AWS credentials to authenticate to the AWS API.

Why this answer

Option D is correct because the AWS auth method in Vault requires valid AWS credentials to authenticate against AWS STS. These credentials can be provided via environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) or automatically retrieved from instance metadata when running on an EC2 instance. Without them, Vault cannot sign the STS request to verify the caller's identity, causing authentication to fail.

Exam trap

HashiCorp often tests the misconception that the AWS auth method requires explicit IAM credentials in the Vault configuration file, when in fact credentials are provided by the client at authentication time, not stored in the server configuration.

How to eliminate wrong answers

Option A is wrong because the 'region' parameter is optional for the AWS auth method; Vault can infer the region from the instance metadata or environment variable AWS_DEFAULT_REGION. Option B is wrong because 'my-role' is a valid role name; the role name is arbitrary and does not need to match any AWS resource name. Option C is wrong because 'aws' is the correct method type for the AWS auth method; 'iam' is not a valid Vault auth method type—the AWS auth method uses IAM principals internally but is configured as type 'aws'.

Practice this question →

61

MCQeasy

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?

A.vault kv write secret/myapp password=pass123

B.vault kv create secret/myapp password=pass123

C.vault kv put secret/myapp password=pass123

D.vault write secret/myapp password=pass123

AnswerC

This is the correct syntax for KV v2 put.

Why this answer

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/`.

Exam trap

HashiCorp often tests the distinction between KV v1 (`vault write`) and KV v2 (`vault kv put`) commands, and the trap here is that candidates mistakenly use the generic `vault write` command (which works for KV v1 but not for KV v2) or invent non-existent subcommands like `write` or `create` under `vault kv`.

How to eliminate wrong answers

Option A is wrong because `vault kv write` is not a valid subcommand; the KV v2 engine uses `put` for writing secrets, not `write`. Option B is wrong because `vault kv create` is not a valid subcommand; the KV v2 engine does not have a `create` subcommand—secrets are written with `put` and optionally checked for existence with `get` or `metadata`. Option D is wrong because `vault write` targets the generic Vault API endpoint (used for KV v1 or other backends) and does not use the KV v2-specific subcommand structure; for KV v2, the correct CLI approach is `vault kv put`.

Practice this question →

62

MCQeasy

Refer to the exhibit. A user wants to write a secret 'db_password' with value 's3cret' to this secrets engine. Which CLI command should be used?

A.vault write shared/db_password value=s3cret

B.vault write shared/data/db_password value=s3cret

C.vault write shared/metadata/db_password value=s3cret

D.vault write shared/config/db_password value=s3cret

AnswerB

C is correct: KV v2 uses data/ prefix.

Why this answer

Option B is correct because in Vault's KV v2 secrets engine, secrets are stored under the 'data' path. The correct CLI command to write a secret is 'vault write shared/data/db_password value=s3cret', which targets the data endpoint for the secret 'db_password' in the 'shared' mount.

Exam trap

HashiCorp often tests the distinction between KV v1 and v2 paths, and the trap here is that candidates assume the secret can be written directly to the mount path (e.g., 'shared/db_password') without the '/data/' prefix, which only works in KV v1.

How to eliminate wrong answers

Option A is wrong because 'vault write shared/db_password' targets the root of the mount, not the data path, and KV v2 requires the '/data/' prefix to write secret data. Option C is wrong because 'vault write shared/metadata/db_password' is used for metadata operations (like configuring versions or deletion settings), not for writing the secret value itself. Option D is wrong because 'vault write shared/config/db_password' is not a valid path; 'config' is used for engine configuration (e.g., max versions), not for individual secrets.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Utilize Vault CLI and API questions.

Start 20-question session