Create Vault policies practice questions

A company wants to grant developers the ability to read and write secrets under the path 'secret/dev/*', but only they should be able to delete their own secrets. Which policy design best meets this requirement?

Trap 1: path "secret/dev/*" { capabilities = ["create", "read", "update",…

This allows delete on all secrets, not just the user's own.

Trap 2: path "secret/dev/*" { capabilities = ["read", "list"] }

This only allows read and list, not write or delete.

Trap 3: path "secret/dev/+/{{identity.entity.name}}" { capabilities =…

The '+' wildcard matches a single directory level, but the path pattern may not cover all desired paths; also missing 'list'.

A
path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] }
Why it fails: This allows delete on all secrets, not just the user's own.
B
path "secret/dev/*" { capabilities = ["read", "list"] }
Why it fails: This only allows read and list, not write or delete.
C
path "secret/dev/+/{{identity.entity.name}}" { capabilities = ["create", "read", "update", "delete"] }
Why it fails: The '+' wildcard matches a single directory level, but the path pattern may not cover all desired paths; also missing 'list'.
D
path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/dev/{{identity.entity.name}}/*" { capabilities = ["delete"] }
Correctly grants full access to the dev path, but delete is only allowed on the user's own sub-path using entity name.

Question 2mediummulti select

Which TWO of the following are valid capabilities that can be specified in a Vault policy?

Trap 1: write

'write' is not a valid capability; use 'create' or 'update'.

Trap 2: sudo

'sudo' is not a capability; it's a parameter for root-protected paths.

Trap 3: rename

Rename is not a Vault policy capability; Vault policies grant path-based operations such as create, read, update, delete, list, patch and sudo. It is tempting because rename sounds like a filesystem or secret-management action, but Vault exposes no rename capability in policy documents.

A
create
"create" is a valid capability within a Vault policy path stanza, permitting clients to create new entries at that path. It is distinct from "update", which modifies existing data, and from "read", "list" and "delete".
B
write
Why it fails: 'write' is not a valid capability; use 'create' or 'update'.
C
sudo
Why it fails: 'sudo' is not a capability; it's a parameter for root-protected paths.
D
rename
Why it fails: Rename is not a Vault policy capability; Vault policies grant path-based operations such as create, read, update, delete, list, patch and sudo. It is tempting because rename sounds like a filesystem or secret-management action, but Vault exposes no rename capability in policy documents.
E
update
Vault policies express capabilities as verbs applied to paths; update is one of the valid CRUD-style capabilities, alongside create, read, delete, list, patch and sudo. It permits modifying existing data at a path without creating it, satisfying the stem's request for a genuine policy capability.

Question 3mediummultiple choice

A DevOps team is managing secrets for a microservices application using Vault. They have created a policy named 'app-policy' that grants read access to secrets under the path 'secret/data/app/*'. The policy is assigned to an AppRole role. When a service authenticates with the role ID and secret ID, it receives a token but is unable to read secrets from 'secret/data/app/db-creds'. The token's identity metadata shows the policies associated with the token include 'default' and 'app-policy'. The Vault server logs show no errors. The service can successfully read other secrets from the same path, like 'secret/data/app/config'. What is the most likely cause of the issue?

Trap 1: The token does not have the 'app-policy' policy attached due to a…

The token's identity metadata explicitly lists 'app-policy', so the policy is attached and the role is configured correctly. This tempts because a detached policy would explain the denial, but the stem's evidence rules it out; the real cause lies in the policy's path or capability definition.

Trap 2: There is an explicit deny rule in the policy that denies access to…

Vault policies are additive allow-only; explicit deny rules do not exist in HCL policy syntax, so no deny stanza could be present. This tempts because a deny rule would explain selective failure, but the actual mechanism is a path or capability mismatch in the allow rule itself.

Trap 3: The token is periodic and does not have the correct capabilities…

Periodic tokens renew on a TTL schedule and carry whatever policies the role grants; they do not strip capabilities from a specific path. The real cause is a policy path mismatch, since 'secret/data/app/*' does not match 'secret/data/app/db-creds' under Vault's glob rules. Periodic tokens suit long-running services needing automatic renewal.

A
The secret 'secret/data/app/db-creds' does not exist in Vault.
The policy grants read on secret/data/app/*, and sibling secrets like config succeed, so the token and policy binding work. A missing secret at secret/data/app/db-creds returns a 404 with no server error logged, matching the silent failure described.
B
The token does not have the 'app-policy' policy attached due to a misconfiguration in the role.
Why it fails: The token's identity metadata explicitly lists 'app-policy', so the policy is attached and the role is configured correctly. This tempts because a detached policy would explain the denial, but the stem's evidence rules it out; the real cause lies in the policy's path or capability definition.
C
There is an explicit deny rule in the policy that denies access to 'db-creds'.
Why it fails: Vault policies are additive allow-only; explicit deny rules do not exist in HCL policy syntax, so no deny stanza could be present. This tempts because a deny rule would explain selective failure, but the actual mechanism is a path or capability mismatch in the allow rule itself.
D
The token is periodic and does not have the correct capabilities for the path.
Why it fails: Periodic tokens renew on a TTL schedule and carry whatever policies the role grants; they do not strip capabilities from a specific path. The real cause is a policy path mismatch, since 'secret/data/app/*' does not match 'secret/data/app/db-creds' under Vault's glob rules. Periodic tokens suit long-running services needing automatic renewal.

Question 4hardmultiple choice

A security team wants to ensure that all Vault policies for applications follow the principle of least privilege. They have a policy 'app-kv' that grants read access to secrets under 'secret/data/app/'. An auditor finds that a developer can also read secrets under 'secret/data/team/'. The policy currently uses a path-based glob. Which change should the team make to restrict access to only the app path?

Trap 1: Change the path to 'secret/data/app/+' and use 'list' capability.

Using '+' matches a single segment; this would still allow reading 'secret/data/app/team' if it exists.

Trap 2: Change the path to 'secret/data/app/*' and add 'deny' capability…

Adding deny to other paths is not a Vault policy best practice; policies are additive.

Trap 3: Keep the path as 'secret/data/app/*' but add a policy with path…

Vault does not support deny capabilities; policies are additive and first-match wins.

A
Change the path to 'secret/data/app/+' and use 'list' capability.
Why it fails: Using '+' matches a single segment; this would still allow reading 'secret/data/app/team' if it exists.
B
Change the path to 'secret/data/app/*' and add 'deny' capability for other paths.
Why it fails: Adding deny to other paths is not a Vault policy best practice; policies are additive.
C
Keep the path as 'secret/data/app/*' but add a policy with path 'secret/data/team/*' and 'deny' capability.
Why it fails: Vault does not support deny capabilities; policies are additive and first-match wins.
D
Change the path to 'secret/data/app/' (without glob) and ensure the policy only grants 'read' capability.
Using a concrete path with trailing slash (or no glob) restricts to that specific path prefix only.

Question 5mediummulti select

A DevOps team is writing a Vault policy for a CI/CD pipeline that needs to authenticate using AppRole, read specific secrets, and write dynamic database credentials. Which THREE capabilities should be included in the policy to meet these requirements? (Choose three.)

Trap 1: write

Incorrect. 'write' is a generic capability that is not required; it is not used for generating dynamic credentials (which use 'read') or for authentication.

Trap 2: create

Incorrect. 'create' is not needed because the pipeline does not create AppRole roles or database roles; it only uses existing ones.

Trap 3: sudo

Incorrect. 'sudo' is not required for any of the given tasks.

A
write
Why it fails: Incorrect. 'write' is a generic capability that is not required; it is not used for generating dynamic credentials (which use 'read') or for authentication.
B
create
Why it fails: Incorrect. 'create' is not needed because the pipeline does not create AppRole roles or database roles; it only uses existing ones.
C
read
Correct. 'read' is required to read secrets and to generate dynamic database credentials (both are read operations).
D
sudo
Why it fails: Incorrect. 'sudo' is not required for any of the given tasks.
E
update
Why it fails: Incorrect. 'update' is not needed because the pipeline does not modify existing secrets; it only reads them and generates dynamic creds.

Question 6easymultiple choice

Refer to the exhibit. A developer reports that they cannot read secrets under 'secret/data/kv-v2/engineering/db-pass' using a token that has the above policy attached. What is the most likely cause?

Exhibit

Refer to the exhibit.

```hcl
path "secret/data/kv-v2/engineering/*" {
  capabilities = ["read", "list"]
}

path "secret/metadata/kv-v2/engineering/*" {
  capabilities = ["read", "list"]
}

path "sys/policies/acl/engineering" {
  capabilities = ["read"]
}
```

Trap 1: The policy requires the 'sudo' capability for reading secrets.

The sudo capability grants access to privileged root-protected paths, not ordinary KV reads, so requiring it would not be the cause here. It is tempting because sudo appears in many policies, but the actual failure is that the policy path omits the 'data/' segment KV v2 requires.

Trap 2: The secret does not exist because the path is incorrect.

A nonexistent secret returns a 404-style missing error, whereas a policy mismatch returns permission denied; the developer's reported symptom points to authorisation. Blaming the path is tempting because KV v2 paths are easily mistyped, but the policy's own path is what fails to match the requested secret.

Trap 3: The path uses a glob that does not match the exact secret path.

The policy path uses a trailing wildcard that does match the requested secret, so the glob is not the blocker. Globs are a tempting suspect because KV v2 policies commonly rely on them, but the real defect is the missing 'data/' segment in the policy path for a v2 mount.

A
The policy requires the 'sudo' capability for reading secrets.
Why it fails: The sudo capability grants access to privileged root-protected paths, not ordinary KV reads, so requiring it would not be the cause here. It is tempting because sudo appears in many policies, but the actual failure is that the policy path omits the 'data/' segment KV v2 requires.
B
The secret does not exist because the path is incorrect.
Why it fails: A nonexistent secret returns a 404-style missing error, whereas a policy mismatch returns permission denied; the developer's reported symptom points to authorisation. Blaming the path is tempting because KV v2 paths are easily mistyped, but the policy's own path is what fails to match the requested secret.
C
The token does not have the policy attached.
The policy grants read on `secret/data/kv-v2/engineering/db-pass`, so the path itself is not the blocker. The reported failure therefore points to the token lacking that policy: without the policy attached, no capability is granted, and Vault denies the read regardless of the policy's contents.
D
The path uses a glob that does not match the exact secret path.
Why it fails: The policy path uses a trailing wildcard that does match the requested secret, so the glob is not the blocker. Globs are a tempting suspect because KV v2 policies commonly rely on them, but the real defect is the missing 'data/' segment in the policy path for a v2 mount.

Question 7mediummatching

Match each Vault command to its function.

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

Concepts

Matches

Write a secret

Read data at a path

Write data or invoke an endpoint

Delete a secret or path

List keys under a path

Trap 1: vault kv get: Lists all secrets at a given path.

This describes vault kv list, not vault kv get.

Trap 2: vault kv list: Retrieves a secret from a specified path.

This describes vault kv get, not vault kv list.

Trap 3: vault write: Stores a secret at a specified path in the KV secret…

While vault write can write to KV, the dedicated command is vault kv put.

A
vault kv put: Stores a secret at a specified path in the KV secret engine.
vault kv put is the dedicated command to store or update secrets in the KV engine.
B
vault kv get: Lists all secrets at a given path.
Why it fails: This describes vault kv list, not vault kv get.
C
vault kv list: Retrieves a secret from a specified path.
Why it fails: This describes vault kv get, not vault kv list.
D
vault kv delete: Deletes a secret at a specified path.
vault kv delete is used to delete secrets from the KV engine.
E
vault write: Stores a secret at a specified path in the KV secret engine.
Why it fails: While vault write can write to KV, the dedicated command is vault kv put.
F
vault read: Reads data from a path in any secret engine.
vault read is used to read data from various paths, including KV secrets.

Question 8easymultiple choice

A DevOps team needs to create a Vault policy that allows reading secrets from path "secret/data/app" but only for the key "db_password". They want to enforce this using Vault's policy syntax. Which policy statement achieves this?

Trap 1: path "secret/data/app" { capabilities = ["read"] }

This allows reading all keys under the path, not just db_password.

Trap 2: path "secret/data/app/db_password" { capabilities = ["read"] }

This path is incorrect; KV v2 stores data under secret/data/app, not secret/data/app/db_password.

Trap 3: path "secret/data/app" { capabilities = ["read"];…

This requires the parameter but does not restrict to only db_password; other keys could also be read.

A
path "secret/data/app" { capabilities = ["read"]; allowed_parameters = {"db_password"=[]} }
This allows reading only the key db_password, with any value.
B
path "secret/data/app" { capabilities = ["read"] }
Why it fails: This allows reading all keys under the path, not just db_password.
C
path "secret/data/app/db_password" { capabilities = ["read"] }
Why it fails: This path is incorrect; KV v2 stores data under secret/data/app, not secret/data/app/db_password.
D
path "secret/data/app" { capabilities = ["read"]; required_parameters = ["db_password"] }
Why it fails: This requires the parameter but does not restrict to only db_password; other keys could also be read.

Question 9hardmultiple choice

A Vault administrator is designing a policy for a CI/CD pipeline that must be able to read dynamic database credentials from "database/creds/my-role" and also write to "secret/data/ci-cd" for storing build artifacts. The policy should follow the principle of least privilege. Which policy statements should be used?

Trap 1: path "database/creds/my-role" { capabilities = ["read"] }; path…

Including "delete" exceeds least privilege: the pipeline only needs to store build artifacts, so create and update suffice. Delete permits destroying secrets. Tempting because full CRUD on a path looks tidy, but delete is correct only when the pipeline must remove stored artifacts.

Trap 2: path "database/creds/my-role" { capabilities = ["read"] }; path…

The wildcard path "secret/data/ci-cd/*" grants create and update beneath that prefix, not on the exact path "secret/data/ci-cd" the pipeline must write to, so the required write fails. Wildcards suit granting access across many sibling secrets rather than one specific path.

Trap 3: path "database/creds/my-role" { capabilities = ["read"] }; path…

'write' is not a valid Vault capability; use create and update instead.

A
path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["create", "update", "delete"] }
Why it fails: Including "delete" exceeds least privilege: the pipeline only needs to store build artifacts, so create and update suffice. Delete permits destroying secrets. Tempting because full CRUD on a path looks tidy, but delete is correct only when the pipeline must remove stored artifacts.
B
path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["create", "update"] }
Least privilege grants read on the dynamic credentials path and only create plus update on the artifact path, omitting delete, sudo or wildcard capabilities. This satisfies the pipeline's stated read and write requirements without excess permissions.
C
path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd/*" { capabilities = ["create", "update"] }
Why it fails: The wildcard path "secret/data/ci-cd/*" grants create and update beneath that prefix, not on the exact path "secret/data/ci-cd" the pipeline must write to, so the required write fails. Wildcards suit granting access across many sibling secrets rather than one specific path.
D
path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["write"] }
Why it fails: 'write' is not a valid Vault capability; use create and update instead.

Question 10easymulti select

A Vault operator is crafting a policy for a new application. Which two of the following are valid capabilities in a Vault policy path statement? (Select two.)

Trap 1: modify

modify is not a standard capability; use create/update instead.

Trap 2: patch

patch is not a standard Vault policy capability.

Trap 3: encrypt

encrypt is an operation on the transit engine, not a policy capability.

A
modify
Why it fails: modify is not a standard capability; use create/update instead.
B
sudo
sudo is a valid capability that allows performing privileged operations.
C
patch
Why it fails: patch is not a standard Vault policy capability.
D
encrypt
Why it fails: encrypt is an operation on the transit engine, not a policy capability.
E
list
list is a valid capability for listing keys or items at a path.

Question 11mediummulti select

Which three of the following are valid capabilities in a Vault policy path statement? (Select three.)

Trap 1: encrypt

encrypt is an operation on the transit engine, not a policy capability.

Trap 2: patch

patch is not a standard Vault policy capability.

A
list
list is a valid capability for listing keys or items at a path.
B
encrypt
Why it fails: encrypt is an operation on the transit engine, not a policy capability.
C
deny
deny is a valid capability that overrides all other capabilities for a path.
D
patch
Why it fails: patch is not a standard Vault policy capability.
E
sudo
sudo is a valid capability that allows performing privileged operations.

Question 12hardmultiple choice

Refer to the exhibit. An application needs to encrypt data using the transit engine with key "app-key". It currently has this policy. Which statement is true?

Exhibit

# Vault policy snippet
path "transit/encrypt/app-key" {
  capabilities = ["create", "update"]
}
path "transit/decrypt/app-key" {
  capabilities = ["create", "update"]
}

Trap 1: The policy allows both encryption and decryption, but the…

'create' and 'update' are the correct capabilities for transit operations.

Trap 2: The policy allows encryption but not decryption, which is…

The policy includes both encrypt and decrypt endpoints, so decryption is also allowed.

Trap 3: The policy incorrectly uses "create" and "update" for transit…

'create' and 'update' are correct; 'read' and 'write' are not used for transit.

A
The policy allows both encryption and decryption, but the capabilities should be "read" and "write" instead.
Why it fails: 'create' and 'update' are the correct capabilities for transit operations.
B
The policy allows both encryption and decryption, which is correct for the transit engine.
The policy correctly provides the necessary capabilities for both operations.
C
The policy allows encryption but not decryption, which is sufficient.
Why it fails: The policy includes both encrypt and decrypt endpoints, so decryption is also allowed.
D
The policy incorrectly uses "create" and "update" for transit operations; it should use "read" and "write".
Why it fails: 'create' and 'update' are correct; 'read' and 'write' are not used for transit.

Question 13easymultiple choice

A company uses Vault's KV v2 secrets engine. A policy is needed to allow a service to only update existing secrets at path "secret/data/service/config", but not create new ones. Which capabilities should be included?

Trap 1: ["read", "update"]

Adds read capability which is not required.

Trap 2: ["write"]

'write' is not a standard Vault capability.

Trap 3: ["create", "update"]

Includes create, which would allow creating new secrets, violating the requirement.

A
["read", "update"]
Why it fails: Adds read capability which is not required.
B
["write"]
Why it fails: 'write' is not a standard Vault capability.
C
["update"]
Update allows modifying existing secrets without creating new ones.
D
["create", "update"]
Why it fails: Includes create, which would allow creating new secrets, violating the requirement.

Question 14mediummultiple choice

A Vault policy has the following: path "identity/entity/id/*" { capabilities = ["read", "list"] }. What does this policy allow?

Trap 1: Reading and updating all identity entities.

Update is not included in the capabilities.

Trap 2: Reading and listing all identity entities.

This could include aliases; the policy is specifically on entity IDs.

Trap 3: Reading and listing all identity entity IDs.

Listing gives IDs, but reading gives details, not just IDs.

A
Reading and updating all identity entities.
Why it fails: Update is not included in the capabilities.
B
Reading and listing all identity entities.
Why it fails: This could include aliases; the policy is specifically on entity IDs.
C
Listing all identity entities and reading their details.
List returns entity IDs, read returns full details of each entity.
D
Reading and listing all identity entity IDs.
Why it fails: Listing gives IDs, but reading gives details, not just IDs.

Question 15mediummultiple choice

A DevOps team has configured a Vault policy to allow reading secrets from the 'secret/data/engineering' path. The policy contains:

path "secret/data/engineering/*" { capabilities = ["read", "list"]

However, when a user attempts to read a secret at 'secret/data/engineering/db/password', they receive a permission denied error. What is the most likely cause?

Trap 1: The policy lacks the 'deny' capability to override the default deny.

'deny' is not a valid capability in Vault policies.

Trap 2: The secret engine's mount path is different; it is mounted at…

The path 'secret/data/engineering/*' is correct for KV v2 mounted at 'secret/'.

Trap 3: The user's token does not have the correct identity policies…

While possible, the most likely cause is the path pattern issue.

A
The policy uses a single asterisk, which does not match nested paths; it should use double asterisk or specify the exact path.
A single * does not cross directory boundaries in path matching.
B
The policy lacks the 'deny' capability to override the default deny.
Why it fails: 'deny' is not a valid capability in Vault policies.
C
The secret engine's mount path is different; it is mounted at 'secret/' but the policy expects 'secret/data/'.
Why it fails: The path 'secret/data/engineering/*' is correct for KV v2 mounted at 'secret/'.
D
The user's token does not have the correct identity policies attached.
Why it fails: While possible, the most likely cause is the path pattern issue.

Question 16hardmultiple choice

A development team is using the Vault transit secrets engine to encrypt sensitive data in their application. They have created a policy that includes: path "transit/keys/*" { capabilities = ["encrypt", "decrypt"] } and attached it to their application tokens. However, when the application calls the '/v1/transit/encrypt/my-key' endpoint, it receives a permission denied error. The key 'my-key' exists in the transit engine. The team has verified that the token is not expired and has the correct policy attached. What is the most likely cause of the error?

Trap 1: The policy also needs 'read' capability on 'transit/keys/*'.

Encryption does not read key material, so read on transit/keys/* is unnecessary; the policy's path itself is the fault. It is tempting because read is needed to inspect key configuration or versions, and would be correct if the application had to verify a key's settings before use.

Trap 2: The application token has expired.

The stem states the token is unexpired, so expiry cannot explain the denial. It is tempting because expired tokens are a common cause of permission denied errors, and would be the correct diagnosis if the team had not already verified the token's TTL and renewal status.

Trap 3: The transit engine requires the 'create' capability on the key to…

Encryption against an existing transit key requires only the encrypt capability on the key's endpoint; create governs generating new keys and is irrelevant here. It is tempting because key creation is a privileged operation, and create would be required if the application needed to generate a fresh transit key before encrypting.

A
The policy also needs 'read' capability on 'transit/keys/*'.
Why it fails: Encryption does not read key material, so read on transit/keys/* is unnecessary; the policy's path itself is the fault. It is tempting because read is needed to inspect key configuration or versions, and would be correct if the application had to verify a key's settings before use.
B
The encrypt and decrypt capabilities must be applied to the specific encrypt/decrypt paths, not the key metadata path.
Vault policies match exact request paths, so transit/keys/* grants capabilities on key metadata operations only. The encrypt and decrypt endpoints live at transit/encrypt/my-key and transit/decrypt/my-key, which the policy never covers, producing permission denied despite the token and key being valid.
C
The application token has expired.
Why it fails: The stem states the token is unexpired, so expiry cannot explain the denial. It is tempting because expired tokens are a common cause of permission denied errors, and would be the correct diagnosis if the team had not already verified the token's TTL and renewal status.
D
The transit engine requires the 'create' capability on the key to perform encryption.
Why it fails: Encryption against an existing transit key requires only the encrypt capability on the key's endpoint; create governs generating new keys and is irrelevant here. It is tempting because key creation is a privileged operation, and create would be required if the application needed to generate a fresh transit key before encrypting.

Question 17easymulti select

A Vault administrator needs to create a policy for a developer who must read and list secrets from the path 'secret/data/engineering/' and create new secrets under 'secret/data/engineering/projects/'. Which two policy statements should the administrator include? (Choose two.)

Trap 1: path "secret/data/engineering/projects/*" { capabilities =…

Incorrect: While it grants create, it also grants update which is not required, and it is not minimal.

Trap 2: path "secret/data/engineering" { capabilities = ["read","list"] }

Incorrect: Without a glob, this only matches an exact key named 'engineering', not subkeys.

Trap 3: path "secret/engineering/*" { capabilities = ["read","list"] }

Incorrect: Missing the 'data/' prefix, so this path does not match actual KV v2 secrets.

A
path "secret/data/engineering/projects/*" { capabilities = ["create","update"] }
Why it fails: Incorrect: While it grants create, it also grants update which is not required, and it is not minimal.
B
path "secret/data/engineering" { capabilities = ["read","list"] }
Why it fails: Incorrect: Without a glob, this only matches an exact key named 'engineering', not subkeys.
C
path "secret/data/engineering/projects/*" { capabilities = ["create"] }
Vault policies match paths exactly, so granting create on secret/data/engineering/projects/* permits writing new secrets beneath that prefix without conferring read or list. This satisfies the developer's requirement to create new secrets under that specific subpath.
D
path "secret/engineering/*" { capabilities = ["read","list"] }
Why it fails: Incorrect: Missing the 'data/' prefix, so this path does not match actual KV v2 secrets.
E
path "secret/data/engineering/*" { capabilities = ["read","list"] }
The wildcard in secret/data/engineering/* matches child paths, and the read and list capabilities together allow retrieving and enumerating secrets at the engineering path. This satisfies the stem's requirement to read and list secrets from secret/data/engineering/.

Question 18mediummultiple choice

Refer to the exhibit. Based on the policy shown, which statement is true?

Exhibit

path "secret/data/engineering/*" {
  capabilities = ["read", "list"]
}
path "secret/data/engineering/projects/*" {
  capabilities = ["create", "update"]
}

Trap 1: A user can create secrets under secret/data/engineering/.

Incorrect: Create and update are only granted on the projects subpath, not on the parent path.

Trap 2: A user can delete secrets under secret/data/engineering/.

Incorrect: The policy does not grant delete capability anywhere.

Trap 3: A user can update secrets under secret/data/engineering/.

Incorrect: Update is only granted on the projects subpath, not on the parent path.

A
A user can create secrets under secret/data/engineering/.
Why it fails: Incorrect: Create and update are only granted on the projects subpath, not on the parent path.
B
A user can read all secrets under secret/data/engineering/.
The policy grants read capability on the secret/data/engineering/ path, and Vault policies are additive across matching paths. This permits reading every secret beneath that prefix, satisfying the scope defined by the path glob rather than limiting access to a single named secret.
C
A user can delete secrets under secret/data/engineering/.
Why it fails: Incorrect: The policy does not grant delete capability anywhere.
D
A user can update secrets under secret/data/engineering/.
Why it fails: Incorrect: Update is only granted on the projects subpath, not on the parent path.

Question 19hardmultiple choice

A platform team manages a Vault KV v2 secrets engine mounted at 'kv-prod'. They need a policy for a batch job that must read the current version of the secret at 'kv-prod/data/reporting/api' and must also be able to permanently remove the secret's data at that same path when the reporting cycle ends. Which policy snippet correctly grants exactly these permissions?

Trap 1: path "kv-prod/metadata/reporting/api" { capabilities = ["read",…

The metadata endpoint exposes version history, custom metadata, and configuration for a secret, but never returns the secret's data values. Its delete capability removes all versions and metadata, which is a broader and different action than destroying one version's data, so this snippet does not meet the read-and-destroy requirement.

Trap 2: path "kv-prod/data/reporting/api" { capabilities = ["read",…

In KV v2 the delete capability on a data path only soft-deletes the latest version, marking it as deleted while the underlying data remains recoverable via undelete. The batch job requires permanent removal of secret data, which is the destroy capability on the data path, so this snippet grants a weaker operation than requested and fails the requirement.

Trap 3: path "kv-prod/delete/reporting/api" { capabilities = ["read",…

The 'delete/' segment of a KV v2 mount is the soft-delete endpoint, not the data endpoint, so read here does not return the secret's contents. Destroy is also not a valid capability on that endpoint; the destroy operation is performed against the data path. This snippet therefore fails to grant readable access to the current secret version.

A
path "kv-prod/metadata/reporting/api" { capabilities = ["read", "delete"] }
Why it fails: The metadata endpoint exposes version history, custom metadata, and configuration for a secret, but never returns the secret's data values. Its delete capability removes all versions and metadata, which is a broader and different action than destroying one version's data, so this snippet does not meet the read-and-destroy requirement.
B
path "kv-prod/data/reporting/api" { capabilities = ["read", "destroy"] }
The read capability retrieves the current version from the KV v2 data path, and destroy permanently removes the specified version's data with no possibility of undelete. Because both operations are defined on the same 'kv-prod/data/reporting/api' path, this snippet grants exactly the permissions the batch job requires and nothing extra.
C
path "kv-prod/data/reporting/api" { capabilities = ["read", "delete"] }
Why it fails: In KV v2 the delete capability on a data path only soft-deletes the latest version, marking it as deleted while the underlying data remains recoverable via undelete. The batch job requires permanent removal of secret data, which is the destroy capability on the data path, so this snippet grants a weaker operation than requested and fails the requirement.
D
path "kv-prod/delete/reporting/api" { capabilities = ["read", "destroy"] }
Why it fails: The 'delete/' segment of a KV v2 mount is the soft-delete endpoint, not the data endpoint, so read here does not return the secret's contents. Destroy is also not a valid capability on that endpoint; the destroy operation is performed against the data path. This snippet therefore fails to grant readable access to the current secret version.

Question 20mediummultiple choice

A Vault administrator is creating a policy named 'app-read' that must allow reading secrets at path 'secret/data/app/config'. The policy is written in HCL as:

path "secret/data/app/config" { capabilities = ["read"]

The administrator saves this to a file 'app-read.hcl' and runs `vault policy write app-read app-read.hcl`. However, when a token with this policy attempts to read the secret, it receives a 403 permission denied error. The secret exists at that path. What is the most likely cause?

Trap 1: The policy path must start with a forward slash, e.g.,…

Vault policy paths do not require a leading slash. In fact, adding a leading slash would make the path invalid because Vault paths are relative to the mount point. The policy path must match the request path exactly, without a leading slash. The issue is likely not a missing slash.

Trap 2: The policy was written without the 'list' capability, so Vault…

The 'list' capability is only required for listing operations, not for reading a specific secret. A read capability alone is sufficient to read a secret at a path. The absence of 'list' would not cause a read request to fail with a 403 error.

Trap 3: The policy path is missing the wildcard at the end to match the…

The policy path 'secret/data/app/config' exactly matches the request path if the secret is stored there. No wildcard is needed. If the actual path were different, a wildcard might help, but the scenario states the secret exists at that path. The issue is elsewhere.

A
The policy path must start with a forward slash, e.g., "/secret/data/app/config".
Why it fails: Vault policy paths do not require a leading slash. In fact, adding a leading slash would make the path invalid because Vault paths are relative to the mount point. The policy path must match the request path exactly, without a leading slash. The issue is likely not a missing slash.
B
The policy was written without the 'list' capability, so Vault denies read access.
Why it fails: The 'list' capability is only required for listing operations, not for reading a specific secret. A read capability alone is sufficient to read a secret at a path. The absence of 'list' would not cause a read request to fail with a 403 error.
C
The policy was written to the wrong namespace or the token does not have the policy attached.
The most likely cause is that the policy is not attached to the token, or the token is in a different namespace than the policy. Vault policies are namespace-scoped. If the token was created without specifying the 'app-read' policy, or if the policy was written in a different namespace, the token would not have the necessary permissions, resulting in a 403 error.
D
The policy path is missing the wildcard at the end to match the actual secret path, which includes a trailing data element.
Why it fails: The policy path 'secret/data/app/config' exactly matches the request path if the secret is stored there. No wildcard is needed. If the actual path were different, a wildcard might help, but the scenario states the secret exists at that path. The issue is elsewhere.