Knowledge + Practice

CCNA Utilize Vault CLI and API Questions

38 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

KV v2 secrets are read through the data/ segment of the mount path, so the token-bearing GET request must target /v1/secret/data/myapp. Omitting data/ hits the metadata endpoint instead, satisfying the stem's requirement to read the secret value.

Why this answer

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

Vault tokens embed a snapshot of their policies at issuance; policy edits do not retroactively alter existing tokens. Service-a's token still holds the pre-correction policy granting services/service-b/*, so it must be reissued or renewed to inherit the corrected policy.

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

The lookup-self endpoint returns metadata about the calling token itself, including its attached policies, TTL and renewal status. Reading auth/token/lookup-self therefore satisfies the requirement to inspect the current token without needing its accessor or a privileged token.

Why this answer

Option A, `vault read auth/token/lookup-self`, is correct because it reads the `auth/token/lookup-self` endpoint, which returns details about the token used to make the request, including its policies, TTL, and other metadata. Option E, `vault token lookup`, is correct because it queries the same token lookup functionality through the CLI and, when run without a token argument, displays information about the current token such as policies and TTL. Option B, `vault token list`, is incorrect because it lists accessor values of tokens rather than showing details of the current token.

Option C, `vault write auth/token/lookup`, is incorrect because the lookup endpoint is read-oriented and requires a token parameter; writing to it without a token does not return current-token information. Option D, `vault token info`, is incorrect because it is not a valid Vault CLI command.

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

An application authenticates to Vault using the AppRole auth method and needs to retrieve the token's remaining TTL and renewable status programmatically. The application already has a valid token and calls the lookup-self endpoint. Which response fields should it read to determine whether the token can be renewed and how long it remains valid?

A.lease_duration and renewable

B.ttl and renewable

C.creation_time and expire_time

D.num_uses and policies

AnswerB

The lookup-self response includes a `ttl` field giving the remaining lifetime in seconds and a `renewable` boolean indicating whether the token can be renewed. Reading these two fields lets the application decide when to renew or re-authenticate. This directly answers the requirement to determine renewability and remaining validity.

Why this answer

The token lookup-self response exposes `ttl` (remaining seconds) and `renewable` (boolean). An application reading these two fields can decide whether to renew the token before it expires or to re-authenticate. Timestamps, use counts, and policies are informative but do not answer the renewability and remaining-lifetime question on their own.

Exam trap

The trap here is reading `lease_duration` from a token lookup response, when the token-specific field is `ttl` and the renewability flag is `renewable`.

Practice this question →

5

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

A deny capability on `secret/data/team/admin` takes precedence over any broader `secret/data/team/*` grant, because Vault evaluates policies with deny winning regardless of path specificity or rule order. The read therefore fails, satisfying the stem's constraint that the narrower deny path overrides the wider allow.

Why this answer

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 →

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

Token lookup returns the token's policies, TTL and renewal status, so an authentication or permission failure can be traced to an expired token or missing policy. This directly satisfies the stem's need to verify token validity and expected policies before retrying the command.

Why this answer

Option A is correct because 'vault token lookup' inspects the current token's metadata, including its TTL, renewal status, and attached policies, which directly verifies whether the token is valid and authorized as expected. Option C is correct because if the token is expired, revoked, or missing, 'vault login' re-authenticates against the configured auth method and issues a fresh token so subsequent CLI commands can succeed. Option B is not a general troubleshooting step since 'vault write' mutates data at a path and requires knowing a valid path and payload, so it is not a reliable diagnostic.

Option D is not among the marked answers because 'vault status' only reports seal and HA state, not token or policy validity, and it can succeed even when the token is the actual problem. Option E is likewise not marked because 'vault read' depends on a specific existing path and permissions, making it an unreliable test of general accessibility.

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

A 403 from Vault means the token authenticated successfully but its attached policy lacks the required capability on that path. Read on 'database/creds/readonly' must be granted by a policy bound to the token; without it, Vault denies the request rather than returning 404.

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

The userpass auth method exposes a login endpoint scoped to the specific username, so the credential travels in the JSON body rather than the path. POST /v1/auth/userpass/login/jdoe satisfies the stem's requirement to authenticate jdoe with the supplied password, returning a Vault token on success.

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

Vault returns 403 when the token's attached policy lacks a read capability matching the requested path. Since 'secret/data/app' is the exact path being read, the absence of that capability in the policy is the direct cause of the forbidden response.

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

POST /v1/auth/token/renew is a valid token lifecycle endpoint, satisfying the stem's requirement for token-related actions. It renews an existing token before expiry, extending the session without full re-authentication. This matches the operator's need to manage token lifecycle operations alongside revoke and lookup endpoints.

Why this answer

In HashiCorp Vault's token auth method, POST /v1/auth/token/renew (option B) is correct because token renewal is performed by submitting a token (and optional increment) to the renew endpoint, which extends the token's TTL. POST /v1/auth/token/create (option D) is correct because new tokens are minted by POSTing parameters such as policies, TTL, and renewable flags to the create endpoint. GET /v1/auth/token/lookup (option E) is correct because looking up a token's metadata (policies, TTL, display name) is a read operation against the lookup endpoint, typically using the X-Vault-Token header or the token as a parameter.

Option A is wrong because token roles are managed under /v1/auth/token/roles using POST to create, GET to read, and DELETE to remove, not PUT. Option C is wrong because revoking a token is done with POST /v1/auth/token/revoke (or /revoke-self, /revoke-orphan), not DELETE.

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

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

`vault login -method=userpass` authenticates against the userpass auth method, passing `username` and `password` as method-specific parameters. This satisfies the stem's requirement to authenticate a user with a username and password, unlike `vault auth` or token-based commands that target different auth methods.

Why this answer

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

12

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` sends data to a specified path, storing it as a new secret version or creating the path if absent. It satisfies the stem's requirement to write data, accepting key-value pairs as arguments and returning the written metadata. This makes it one of the two valid commands for persisting data in Vault.

Why this answer

Option D, `vault write`, is correct because it is the general-purpose Vault CLI command for writing data to a path, such as `vault write secret/foo bar=baz`, and it works across secrets engines including KV v1 and v2. Option E, `vault kv put`, is correct because it is the KV secrets engine subcommand specifically designed to write key-value data, e.g. `vault kv put secret/foo bar=baz`, and it handles KV v2 versioning automatically. The unmarked options do not belong: `vault set`, `vault put`, and `vault push` are not valid Vault CLI commands for writing data, so they would fail as unknown subcommands.

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 →

13

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` targets the KV version 1 API, returning the secret's data directly from the given path. For the `kv/secret/mykey` mount, this retrieves the stored value without requiring the `-field` flag or a `data/` path segment that KV version 2 mandates.

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 →

14

MCQmedium

A Vault operator needs to enable the `userpass` auth method at the path `auth/legacy-userpass` and then create a user named `svc-backup` with a password, all from a CI script. Which single command correctly enables the auth method at that custom path?

A.vault auth enable userpass -path=legacy-userpass

B.vault write sys/auth/legacy-userpass type=userpass

C.vault auth enable -path=legacy-userpass userpass

D.vault secrets enable -path=legacy-userpass userpass

AnswerC

`vault auth enable` accepts `-path` to mount an auth method at a custom path, and the final argument names the method type. This mounts userpass at `auth/legacy-userpass`, exactly as required. Subsequent user creation would target `auth/legacy-userpass/users/svc-backup`. It is the correct, non-interactive CLI form for the scenario.

Why this answer

The `vault auth enable` command mounts an auth method, and its `-path` flag sets a custom mount path so the method lives at `auth/legacy-userpass` rather than the default `auth/userpass`. The method type is the trailing positional argument. Using `vault secrets enable` targets secrets engines instead, and writing to `sys/auth` directly is the raw API path rather than the intended CLI interface.

Exam trap

The trap here is confusing `vault auth enable` with `vault secrets enable`, which mount auth methods and secrets engines respectively.

Practice this question →

15

MCQeasy

A developer wants to inspect the metadata of the current Vault token, including its attached policies, TTL, and whether it is renewable, using a single CLI command. Which command should the developer run?

A.vault token renew

B.vault auth list

C.vault token capabilities

D.vault token lookup

AnswerD

`vault token lookup` with no argument inspects the calling token and returns its accessor, policies, TTL, renewable status, and other metadata. This matches the developer's need to see policies, TTL, and renewability in one command. It is the standard CLI command for examining the current token's properties.

Why this answer

The `vault token lookup` command retrieves metadata for the calling token when no token argument is supplied, exposing fields like `policies`, `ttl`, `renewable`, and `accessor`. It is a read-only operation with no side effects, unlike renewal. Commands such as `vault auth list` or `vault token capabilities` serve entirely different purposes and cannot report the token's policies and TTL.

Exam trap

The trap here is reaching for `vault token renew` to see TTL, when renewal mutates the token and does not list policies.

Practice this question →

16

Multi-Selecthard

A cloud engineer is scripting against the Vault HTTP API and must authenticate, then read a KV v2 secret, using only `curl`. Which TWO request elements are required for the read to succeed? (Choose two.)

Select 2 answers

A.A GET to the path `/v1/secret/data/apps/web/config`.

B.The header `X-Vault-Request: true` on the request.

C.A POST to the path `/v1/secret/apps/web/config` with a JSON body.

D.The header `X-Vault-Namespace: root` on the request.

E.The header `X-Vault-Token: <token>` on the request.

AnswersA, E

For KV v2, reading data uses the `/v1/<mount>/data/<path>` endpoint with the HTTP GET method. The `/v1` prefix and the `data` segment are both required; hitting the metadata or mount-root path returns metadata or a 404 instead of the secret payload. This endpoint is what the CLI calls under the hood.

Why this answer

API reads require a valid token in the `X-Vault-Token` header and, for KV v2, a GET to the `/v1/<mount>/data/<path>` endpoint. The token authorizes the call against policy, while the data endpoint routes to the versioned secret store. Namespace and request-marker headers are situational and not required for a root-namespace read.

Exam trap

The trap here is reusing the KV v1 path shape or assuming a custom header like `X-Vault-Request` is needed, when KV v2 reads go through the `data` endpoint with only the token header.

Practice this question →

17

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

The LDAP auth method is invoked through the login command's method flag, which selects the auth backend and passes credentials as parameters. vault login -method=ldap username=john authenticates against the configured LDAP mount and returns a Vault token.

Why this answer

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

18

Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

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

Practice this question →

19

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

`vault policy write` uploads a local HCL file to Vault's policy store, creating or updating the named policy. The command takes the policy name (`app-policy`) followed by the source file path (`app-policy.hcl`), satisfying the stem's requirement to upload the existing `app-policy.hcl` file.

Why this answer

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 →

20

MCQmedium

An operator has authenticated to Vault and wants to inspect the metadata of the currently active token, including its accessor, policies, and creation time, without exposing the token's secret value. Which CLI command returns this information?

A.vault token lookup

B.vault token renew

C.vault read auth/token/lookup-self

D.vault token capabilities

AnswerA

`vault token lookup` with no arguments inspects the token currently in use and returns its accessor, policies, TTL, creation time, and other metadata. It never displays the token's secret value, which makes it safe for auditing the active session. This matches the operator's goal of examining metadata without exposing the token itself.

Why this answer

`vault token lookup` without arguments queries the token auth method's lookup-self endpoint and returns metadata for the token in use, including accessor, policies, TTL, and creation time. It deliberately omits the token's secret value, so an operator can audit the active session safely. Other token subcommands perform renewal, capability checks, or creation instead.

Exam trap

The trap here is assuming you must read a raw API path to inspect the current token, when the dedicated `vault token lookup` command already wraps that endpoint.

Practice this question →

21

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

Granting the delete capability on the 'team/' path lets the user remove secrets there, satisfying the stem's requirement. Vault policies are path-scoped, so read and list permissions alone cannot authorise destruction; the delete capability must be explicitly added to that path's policy stanza.

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 →

22

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

Token role creation uses the PUT method on the auth/token/roles endpoint, with the role name in the path. The body's default_ttl field sets the 24-hour TTL required by the stem, so this request satisfies both the naming and TTL constraints.

Why this answer

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 →

23

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

A wrapping token is single-use: unwrapping consumes it, returning the wrapped data and rendering the token invalid for further calls. This one-time property limits exposure if the token leaks, satisfying the security constraint behind response wrapping.

Why this answer

Option B is correct because a response-wrapping token is single-use: the first call to the sys/wrapping/unwrap endpoint (or a lookup) consumes it, and any subsequent attempt fails. Option C is correct because clients enable wrapping by supplying the X-Vault-Wrap-TTL header on the request, which tells Vault to return a wrapping token instead of the actual response data. Option E is correct because Vault stores the wrapped response in the cubbyhole secret engine, which is scoped to the wrapping token and is where the data lives until it is unwrapped.

Option A is wrong because the wrapping token has a TTL set by X-Vault-Wrap-TTL and expires like any other Vault token. Option D is wrong because unwrapping requires only the wrapping token itself, not the original token that created the wrapped response.

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 →

24

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

Listing enabled auth methods requires a GET to the sys/auth endpoint with a valid X-Vault-Token header. This command supplies the token and targets the correct path, satisfying the requirement to enumerate all enabled authentication methods through the Vault API.

Why this answer

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 →

25

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

The -period flag on vault token create establishes a periodic token, and 36h sets the renewal period the stem demands. Periodic tokens have no maximum TTL, so they renew indefinitely provided the period does not exceed the system max_lease_ttl.

Why this answer

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 →

26

Multi-Selectmedium

A CI pipeline authenticates to Vault using the AppRole auth method and needs to obtain a token non-interactively. The pipeline has a role_id and a secret_id but cannot use an interactive login prompt. Which TWO methods can the pipeline use to authenticate and receive a token? (Choose two.)

Select 2 answers

A.`vault secrets enable -path=approle approle`

B.`vault login -method=approle role_id=<id> secret_id=<sid>`

C.`vault auth enable approle`

D.`vault write auth/approle/login role_id=<id> secret_id=<sid>`

E.`vault operator init -key-shares=1 -key-threshold=1`

AnswersB, D

The vault login command supports the -method flag, and approle is a registered auth method that accepts role_id and secret_id as parameters. This produces a token and stores it in the local token helper, which is convenient for subsequent CLI calls. It is a valid non-interactive path for the CI pipeline to authenticate and receive a token.

Why this answer

AppRole is designed for machine authentication, and both the direct write to auth/approle/login and the vault login -method=approle invocation accept role_id and secret_id and return a client token. The login subcommand additionally stores the token in the local token helper for later CLI calls. The remaining options are administrative or cluster operations that do not authenticate a workload, and one of them targets a secrets engine path rather than the AppRole auth method.

Exam trap

The trap here is confusing the one-time administrative step of enabling the AppRole auth method with the per-run authentication call that actually returns a token to the pipeline.

Practice this question →

27

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

Renewing via `auth/token/renew` extends the existing token's lease without requiring re-authentication, matching the one-hour token TTL that caused the permission denied errors. The application must call this endpoint before expiry, since the token is renewable by default and the AppRole secret ID TTL of 30 days is irrelevant here.

Why this answer

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 →

28

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

Mounting via the API requires POST to /v1/sys/mounts/aws, with the engine type supplied in the JSON body as {"type":"aws"}. This satisfies the stem's constraint of mounting the AWS secrets engine at the 'aws' path, since sys/mounts handles enablement and the path segment defines the mount point.

Why this answer

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 →

29

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

The userpass auth method exchanges static credentials for a Vault token, satisfying the requirement to authenticate without an existing token. The CLI `vault login -method=userpass` call submits the username and password to the userpass auth backend, which validates them against its configured store and returns a client token.

Why this answer

Option A is correct because `vault login -method=userpass username=joe password=pass` invokes the userpass auth method's login endpoint and returns a Vault token, allowing CLI authentication without supplying an existing token. Option B is correct because `vault login -method=ldap username=joe password=pass` performs the same token-issuing login flow against the LDAP auth method, which is a valid non-token authentication path. Option C is not valid because `vault auth` is used to enable, disable, and tune auth methods, not to log in and obtain a token.

Option D is not the documented CLI login workflow; while it resembles a raw API write to the userpass login path, the CLI's supported non-token login mechanism is `vault login -method=...`. Option E is incorrect because `vault token create` requires an existing token with sufficient permissions and creates a new token rather than authenticating without one.

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 →

30

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

The correct matches are: create allows creating data, read allows reading data, update allows updating data, and delete allows deleting data. Common confusions involve swapping create and read capabilities.

Practice this question →

31

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

Response wrapping returns a single-use wrapping token instead of the secret itself, so interception during transit yields nothing usable. This satisfies the stem's benefit of reducing exposure of the actual secret while it travels between parties.

Why this answer

Option A is correct because Vault response wrapping returns a single-use wrapping token instead of the actual secret, so if the response is intercepted in transit the attacker only obtains a wrapping token that can be unwrapped once, reducing the risk of secret exposure. Option C is correct because a wrapping token is single-use: once it is unwrapped, the token is revoked and cannot be used again, which ensures the wrapped secret can be retrieved only once. Option E is correct because wrapping enables delegation of access without sharing the actual token — the wrapper can hand the wrapping token to another party (e.g., an app or trusted operator) who unwraps it to obtain a short-lived token with limited policy, without ever exposing the original token.

Option B is not correct because wrapping tokens support only a single unwrap, not unlimited unwraps. Option D is not correct because response wrapping does not extend the TTL of the underlying secret; the wrapping token itself has a short TTL and the wrapped secret retains its own lease/TTL.

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 →

32

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

Using `-wrap-ttl` instructs Vault to return a single-use wrapping token instead of the actual secret, satisfying the one-time use constraint. The wrapped response can be unwrapped only once by the remote service, and the five-minute TTL limits exposure. This is the correct flag for response wrapping via the CLI.

Why this answer

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

33

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

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 →

34

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

POST /v1/auth/token/create accepts a JSON body whose "policies" array binds named policies directly to the issued token, satisfying the stem's requirement for a token with a specific policy attached. The token auth method's create endpoint is the documented mechanism for policy-scoped token issuance via the Vault API.

Why this answer

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 →

35

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

Writing to secret/data/myapp creates or updates data, which requires the create or update capability. The token's policy grants only read and list on that path, so Vault denies the write despite the path matching correctly.

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 →

36

Multi-Selectmedium

A security engineer needs to authenticate a CI pipeline to Vault using the AppRole auth method from the CLI without a pre-existing token. The engineer has the role_id and a wrapped secret_id. Which TWO commands are required to complete the login and obtain a usable token? (Choose two.)

Select 2 answers

A.vault unwrap <wrapping_token>

B.vault token renew -self

C.vault login -method=approle role_id=<role_id>

D.vault write -wrap-ttl=120s auth/approle/role/web/secret-id

E.vault write auth/approle/login role_id=<role_id> secret_id=<secret_id>

AnswersA, E

The wrapped secret_id must be unwrapped to reveal the actual SecretID value before it can be used in a login. `vault unwrap` consumes the single-use wrapping token and returns the SecretID. Without this step the login payload would contain the wrapping token instead of the SecretID, causing authentication to fail. This is a required step when SecretIDs are delivered wrapped.

Why this answer

Authenticating with a wrapped SecretID requires two distinct actions: first, `vault unwrap` consumes the single-use wrapping token to reveal the real SecretID; second, `vault write auth/approle/login` submits the role_id and the unwrapped SecretID to receive a client token. Skipping the unwrap step sends the wrapping token as the SecretID, which the AppRole backend rejects because it does not match any stored SecretID.

Exam trap

The trap here is assuming the wrapped SecretID can be passed directly to the login endpoint, when it must be unwrapped into the real SecretID first.

Practice this question →

37

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

Writing to the KV v2 engine requires the `vault kv put` subcommand, which targets the versioned API rather than the legacy `vault write` path. Specifying `secret/myapp` places the secret at the mount point named in the stem, and the `password=pass123` pair supplies the key-value data correctly.

Why this answer

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

38

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

This is correct because in Vault's KV v2 secrets engine, secrets are written to the 'data' sub-path. The command 'vault write shared/data/db_password value=s3cret' targets the data endpoint for the secret 'db_password' under the 'shared' mount.

Why this answer

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