Courseiva

CCNA Create Vault policies Questions

33 questions · Create Vault policies · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
Multi-Selectmedium

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

Select 3 answers
A.write
B.create
C.read
D.sudo
E.update
AnswersB, C, E

'create' is needed to generate new database credentials.

Why this answer

Option B (create) is correct because the CI/CD pipeline needs to write dynamic database credentials, which requires the 'create' capability on the database secrets engine path (e.g., database/creds/my-role). The 'create' capability allows generating new credentials from a role, which is distinct from simply updating existing secrets. Without 'create', the pipeline cannot request fresh credentials from the database backend.

Exam trap

HashiCorp often tests the distinction between 'write' and 'create' capabilities, where candidates mistakenly choose 'write' for generating dynamic credentials, not realizing that 'create' is specifically required for role-based credential generation in the database secrets engine.

Practice this question →
2
MCQhard

A Vault administrator needs to create a policy that grants users read access only to the secrets that belong to their own team. The team membership is stored in an external identity provider and mapped to Vault entity aliases. The administrator wants to use a templated policy that references the entity's metadata. Which policy syntax accomplishes this goal?

A.path "secret/data/{{identity.entity.metadata.team}}/*" { capabilities = ["read", "list"] }
B.path "secret/data/{{entity.metadata.team}}/*" { capabilities = ["read", "list"] }
C.path "secret/data/{{.team}}/*" { capabilities = ["read", "list"] }
D.path "secret/data/{{identity.entity.aliases.team}}/*" { capabilities = ["read", "list"] }
AnswerA

Correctly references the entity metadata key 'team'.

Why this answer

Option C is correct because Vault's policy templating uses the format {{identity.entity.metadata.<key>}} to reference entity metadata. Option A misses the 'identity.' prefix. Option B uses 'entity' without 'identity'.

Option D uses an invalid template syntax.

Practice this question →
3
Multi-Selecthard

A Vault policy must allow a service to read secrets from "secret/data/app" and also be able to renew its own token. Which two policy statements are necessary and sufficient for this requirement? (Select two.)

Select 2 answers
A.path "secret/data/app" { capabilities = ["read"] }
B.path "auth/token/renew-self" { capabilities = ["update"] }
C.path "auth/token/renew" { capabilities = ["update"] }
D.path "secret/data/app/*" { capabilities = ["read"] }
E.path "sys/auth" { capabilities = ["read"] }
AnswersA, B

This provides read access to the specific secret path.

Why this answer

The necessary statements are path "secret/data/app" with read capability and path "auth/token/renew-self" with update capability. The other options either provide too much or are not relevant.

Practice this question →
4
MCQhard

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?

A.The policy also needs 'read' capability on 'transit/keys/*'.
B.The encrypt and decrypt capabilities must be applied to the specific encrypt/decrypt paths, not the key metadata path.
C.The application token has expired.
D.The transit engine requires the 'create' capability on the key to perform encryption.
AnswerB

The correct policy should target 'transit/encrypt/my-key' or 'transit/encrypt/*'.

Why this answer

Option B is correct because the encrypt and decrypt operations are performed at the 'transit/encrypt/<key>' and 'transit/decrypt/<key>' endpoints, not at the 'transit/keys/' path which is used for key management (create, read, delete, etc.). The policy must grant the encrypt capability on 'transit/encrypt/my-key' or a wildcard under that path. Option A is not required for encryption.

Option C is not a cause; token expiration was verified. Option D is incorrect; 'create' is not needed for encryption.

Practice this question →
5
MCQmedium

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

A.A user can create secrets under secret/data/engineering/.
B.A user can read all secrets under secret/data/engineering/.
C.A user can delete secrets under secret/data/engineering/.
D.A user can update secrets under secret/data/engineering/.
AnswerB

Correct: The policy grants read and list on secret/data/engineering/*, so all secrets under that path can be read.

Why this answer

Option C is correct because the first policy statement grants read and list on all secrets under secret/data/engineering/. The other capabilities are restricted to the projects subpath.

Practice this question →
6
MCQmedium

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

A.Reading and updating all identity entities.
B.Reading and listing all identity entities.
C.Listing all identity entities and reading their details.
D.Reading and listing all identity entity IDs.
AnswerC

List returns entity IDs, read returns full details of each entity.

Why this answer

Option D is correct. The path matches entity IDs. 'list' allows listing all entity IDs, and 'read' allows reading the details of each entity. Option A is too broad (might include aliases).

Option B is partially correct but D is more precise. Option C includes update which is not allowed.

Practice this question →
7
MCQeasy

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?

A.The policy requires the 'sudo' capability for reading secrets.
B.The secret does not exist because the path is incorrect.
C.The token does not have the policy attached.
D.The path uses a glob that does not match the exact secret path.
AnswerC

The policy itself looks correct; the most likely cause is that the token was not assigned this policy.

Why this answer

Option C is correct because the policy shown in the exhibit defines a path with a glob pattern (`secret/data/kv-v2/engineering/*`), which matches the secret path `secret/data/kv-v2/engineering/db-pass`. However, the developer reports they cannot read the secret, indicating the token likely does not have this policy attached. In Vault, a token must have a policy explicitly attached to it; merely having the policy defined in Vault does not grant permissions unless the token is associated with that policy.

Exam trap

HashiCorp often tests the misconception that a policy defined in Vault automatically applies to all tokens, when in fact a token must have the policy explicitly attached via a token role, identity group, or direct token creation.

How to eliminate wrong answers

Option A is wrong because the `sudo` capability is not required for reading secrets; `sudo` is used for privileged operations like modifying policies or enabling auth methods, not for standard read operations on KV v2 secrets. Option B is wrong because the path `secret/data/kv-v2/engineering/db-pass` is correctly formed for KV v2 (the `data/` prefix is mandatory), and the glob `secret/data/kv-v2/engineering/*` matches this exact path, so the secret path is valid. Option D is wrong because the glob `*` matches any single path segment, including `db-pass`, so it does match the exact secret path; the issue is not with the glob pattern.

Practice this question →
8
MCQhard

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?

A.path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] }
B.path "secret/dev/*" { capabilities = ["read", "list"] }
C.path "secret/dev/+/{{identity.entity.name}}" { capabilities = ["create", "read", "update", "delete"] }
D.path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/dev/{{identity.entity.name}}/*" { capabilities = ["delete"] }
AnswerD

Correctly grants full access to the dev path, but delete is only allowed on the user's own sub-path using entity name.

Why this answer

Option D is correct because it grants full CRUDL access to 'secret/dev/*' for reading and writing, but then restricts delete to only the path 'secret/dev/{{identity.entity.name}}/*', which uses the entity's name to ensure developers can only delete secrets under their own sub-path. This leverages Vault's identity entity name templating to enforce per-developer delete scoping.

Exam trap

HashiCorp often tests the distinction between wildcard '*' (matches any number of segments) and '+' (matches exactly one segment), and the use of identity template variables to scope permissions per entity, which candidates may overlook by choosing a broad delete permission.

How to eliminate wrong answers

Option A is wrong because it grants delete on the entire 'secret/dev/*' path, allowing any developer to delete any secret, violating the requirement that only they should delete their own. Option B is wrong because it only allows read and list, not create, update, or delete, so developers cannot write secrets at all. Option C is wrong because the path pattern 'secret/dev/+/{{identity.entity.name}}' uses a wildcard '+' for a single segment, but the requirement is for secrets under 'secret/dev/*'; also, it grants delete on that specific path but does not allow creating or updating secrets under other sub-paths, and the '+' does not match multi-segment paths.

Practice this question →
9
Multi-Selecteasy

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

Select 2 answers
A.path "secret/data/engineering/projects/*" { capabilities = ["create","update"] }
B.path "secret/data/engineering" { capabilities = ["read","list"] }
C.path "secret/data/engineering/projects/*" { capabilities = ["create"] }
D.path "secret/engineering/*" { capabilities = ["read","list"] }
E.path "secret/data/engineering/*" { capabilities = ["read","list"] }
AnswersC, E

Correct: Grants create capability on the projects subpath, fulfilling the create requirement with minimal permissions.

Why this answer

The correct statements are A and D. Statement A grants read and list on all secrets under engineering/. Statement D grants create on the projects/ subpath.

Other options either have incorrect paths (B, E) or grant unnecessary capabilities (C).

Practice this question →
10
MCQeasy

An organization is implementing Vault policies for the first time. They want to ensure that policies are easy to manage and follow the principle of least privilege. Which approach should they take when creating policies?

A.Create policies with broad paths and then restrict via ACL tokens.
B.Create a single policy with a wildcard path '*' and full capabilities for all administrators.
C.Create a single policy with all paths and capabilities for all users.
D.Create separate policies for each application and use group aliases to attach them.
AnswerD

This enables granular, least-privilege access based on application needs.

Why this answer

Option D is correct because creating separate policies per application and using group aliases to attach them allows granular control and follows least privilege. Option A is monolithic and insecure. Option B gives too much power.

Option C is backwards; tokens inherit policies, not the other way.

Practice this question →
11
MCQmedium

A company has deployed Vault with an LDAP auth method and has created entity aliases for all users. The company uses KV v2 secrets engine mounted at 'secret/'. Each team's secrets are stored under a path like 'secret/data/team_<team_name>/'. They have multiple teams (engineering, marketing, sales). Currently, an administrator manually creates a separate policy for each team, e.g., path "secret/data/team_engineering/*" { capabilities = ["read", "list"] }. This is becoming cumbersome as new teams are added. The administrator wants to create a single policy that dynamically grants read access to the secrets path corresponding to the user's team, which is stored in the entity's metadata as 'team'. The LDAP auth method is configured to sync group memberships and map to entity aliases, and the entity metadata is correctly populated. Which approach should the administrator take?

A.Create a policy using a wildcard alias for each team in the entity alias.
B.Create a policy that uses the 'default' policy to allow all reads and then restrict with ACL tokens.
C.Create a policy using a templated path: path "secret/data/{{identity.entity.metadata.team}}/*" { capabilities = ["read", "list"] }.
D.Create a policy with path "secret/data/*" { capabilities = ["read", "list"] } and assign it to all users.
AnswerC

This uses entity metadata to dynamically match the correct team path.

Why this answer

Option B is correct because Vault's policy templating allows using {{identity.entity.metadata.team}} to dynamically insert the team name from the entity's metadata into the path. This creates a single policy that works for all teams without manual updates. Option A gives too broad access.

Option C is not a valid policy mechanism. Option D is insecure and not scalable.

Practice this question →
12
Drag & Dropmedium

Drag and drop the steps to create and use a periodic service token in Vault into the correct order.

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

Steps
Order

Why this order

First create the role, then generate a token with a TTL, use it, and renew periodically.

Practice this question →
13
MCQmedium

Refer to the exhibit. A user with this policy attempts to read the secret at path "secret/data/team-a/admin". What will happen?

A.The read fails because the path does not exist.
B.The read succeeds because the first path grants read.
C.The read succeeds because deny only applies to write operations.
D.The read is denied because the deny policy takes precedence.
AnswerD

Deny always takes precedence over other capabilities.

Why this answer

Option B is correct. In Vault, a deny statement takes precedence over any other capabilities. Even though the wildcard grants read, the explicit deny on the specific path blocks access.

Practice this question →
14
MCQhard

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?

A.Change the path to 'secret/data/app/+' and use 'list' capability.
B.Change the path to 'secret/data/app/*' and add 'deny' capability for other paths.
C.Keep the path as 'secret/data/app/*' but add a policy with path 'secret/data/team/*' and 'deny' capability.
D.Change the path to 'secret/data/app/' (without glob) and ensure the policy only grants 'read' capability.
AnswerD

Using a concrete path with trailing slash (or no glob) restricts to that specific path prefix only.

Why this answer

Option D is correct because removing the glob and using an exact path 'secret/data/app/' restricts access to only that specific path. In Vault, a trailing slash without a glob matches exactly that path and its immediate children when used with the appropriate capabilities, enforcing least privilege without granting unintended access to other paths like 'secret/data/team/*'.

Exam trap

HashiCorp often tests the misconception that Vault supports a 'deny' capability or that you can override a wildcard with a deny policy, when in reality Vault policies are additive and only allow capabilities, not deny them.

How to eliminate wrong answers

Option A is wrong because the '+' glob in Vault matches only a single path segment, not a wildcard for multiple segments, and 'list' capability does not grant read access to secrets. Option B is wrong because Vault does not support a 'deny' capability; access control is based on allowed capabilities, and adding a deny is not a valid construct. Option C is wrong because Vault does not have a 'deny' capability; policies are additive, and you cannot explicitly deny access to a path; instead, you must avoid granting access to unintended paths.

Practice this question →
15
MCQmedium

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?

A.The policy uses a single asterisk, which does not match nested paths; it should use double asterisk or specify the exact path.
B.The policy lacks the 'deny' capability to override the default deny.
C.The secret engine's mount path is different; it is mounted at 'secret/' but the policy expects 'secret/data/'.
D.The user's token does not have the correct identity policies attached.
AnswerA

A single * does not cross directory boundaries in path matching.

Why this answer

Option A is correct because Vault's path glob treats a single asterisk (*) as matching any sequence of characters except '/'. Therefore, it does not match nested paths. To match nested paths, use double asterisk (**).

Option B is incorrect because 'deny' is not a valid capability. Option C is possible but less likely given the policy pattern. Option D is incorrect; the mount path is correct for KV v2.

Practice this question →
16
MCQmedium

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?

A.The secret 'secret/data/app/db-creds' does not exist in Vault.
B.The token does not have the 'app-policy' policy attached due to a misconfiguration in the role.
C.There is an explicit deny rule in the policy that denies access to 'db-creds'.
D.The token is periodic and does not have the correct capabilities for the path.
AnswerA

Other secrets work, so this specific secret likely does not exist.

Why this answer

Option A is correct because the most likely cause is that the secret 'secret/data/app/db-creds' does not exist in Vault. The token has the 'app-policy' policy attached, which grants read access to 'secret/data/app/*', and the service can successfully read other secrets under that path (e.g., 'secret/data/app/config'). The absence of Vault server errors indicates that the policy is correctly evaluated and the path is valid, but a read on a non-existent secret returns a 404 (or a permission-denied-like response) without logging an error.

The token's metadata confirms the policy is present, ruling out policy assignment issues.

Exam trap

HashiCorp often tests the distinction between a missing secret and a policy denial, trapping candidates who assume that a 'permission denied' response always indicates a policy issue, when in fact Vault returns a 404 for non-existent paths without logging an error.

How to eliminate wrong answers

Option B is wrong because the token's identity metadata explicitly shows that 'app-policy' is attached, so there is no misconfiguration in the role's policy assignment. Option C is wrong because the policy 'app-policy' grants read access to 'secret/data/app/*' with no explicit deny rules; Vault uses a default-deny model, and an explicit deny would require a separate 'deny' capability or a negative path match, which is not mentioned. Option D is wrong because periodic tokens are unrelated to the issue; the token's capabilities are determined by the attached policies, and the service can read other secrets under the same path, confirming the token has the correct capabilities.

Practice this question →
17
MCQeasy

A policy must allow a user to revoke their own token. Which endpoint and capability are required?

A.path "auth/token/revoke" { capabilities = ["update"] }
B.path "auth/token/revoke-self" { capabilities = ["write"] }
C.path "sys/leases/revoke" { capabilities = ["update"] }
D.path "auth/token/revoke-self" { capabilities = ["update"] }
AnswerD

This is the correct endpoint and capability for self-revocation.

Why this answer

Option A is correct. The endpoint 'auth/token/revoke-self' with 'update' capability allows a user to revoke their own token. 'write' is not a standard capability. The other options either use wrong endpoints or capabilities.

Practice this question →
18
Multi-Selectmedium

An organization is creating Vault policies to manage access to secrets across multiple application teams. According to HashiCorp best practices, which two approaches should be taken when designing policies? (Choose two.)

Select 2 answers
A.Avoid using negative capabilities (deny) when possible.
B.Grant maximum permissions initially and then restrict as needed.
C.Use a single all-encompassing policy for each environment.
D.Use path templating to incorporate entity metadata.
E.Name policies based on the application or team they serve.
AnswersD, E

Templating reduces duplication and ties access to identity attributes.

Why this answer

Options B and D are correct. Path templating with entity metadata reduces policy duplication, and naming policies by application or team improves manageability. Option A is monolithic and insecure.

Option C violates least privilege. Option E is not a recommended practice; deny can be useful for exceptions.

Practice this question →
19
MCQeasy

Refer to the exhibit. A user with this policy tries to write a new secret to "secret/data/production/db". What will happen?

A.The write succeeds if the secret already exists.
B.The write succeeds because the path matches.
C.The write fails because the policy only allows read on production.
D.The write fails because the user does not have list capability.
AnswerC

Only read is allowed on production paths, so write is denied.

Why this answer

Option B is correct. The policy for production only allows read, so write operations (create/update) are denied. The path does match the production glob, but capabilities do not permit write.

Practice this question →
20
MCQhard

A company uses Vault's Kubernetes authentication method to provide secrets to pods. Pods in the 'production' namespace need to read secrets from the path 'secret/data/app/prod'. The administrator has created a Vault role that maps the service account to a policy with capabilities ['read', 'list'] on path 'secret/data/app/*'. However, pods report 'permission denied' when trying to read the secrets. The administrator verifies that the service account has the correct Vault role attached and that the Vault token is being used correctly. What is the most likely cause?

A.The Vault mount for 'secret' is KV v1, so the path should be 'secret/app/prod' without 'data'.
B.The policy should include the 'sudo' capability.
C.The pods are using a token with insufficient TTL.
D.The Vault role is not bound to the correct Kubernetes namespace.
AnswerA

Correct: KV v1 does not use the 'data/' prefix. The policy is written for KV v2, so it does not match the actual path, resulting in permission denied.

Why this answer

Option B is the most likely cause. The mount being KV v1 means the actual secret path is 'secret/app/prod', not 'secret/data/app/prod'. The policy targeting 'secret/data/app/*' does not match, so the pods lack access.

The other options are less plausible given the verification steps.

Practice this question →
21
Matchingmedium

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

Why these pairings

These are basic Vault CLI commands.

Practice this question →
22
MCQmedium

An administrator wants to create a policy that grants the ability to list all authentication methods enabled on the Vault server. Which path and capability are required?

A.path "sys/auth" { capabilities = ["list"] }
B.path "sys/auth" { capabilities = ["read", "list"] }
C.path "sys/auth" { capabilities = ["read"] }
D.path "auth/*" { capabilities = ["list"] }
AnswerA

List on sys/auth returns the names of all enabled auth methods.

Why this answer

Option B is correct. The path 'sys/auth' with 'list' capability lists all auth methods. Option A with 'read' would give details but not list.

Option C includes both, which is overkill. Option D uses a wildcard that may also list unrelated items.

Practice this question →
23
MCQhard

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?

A.path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["create", "update", "delete"] }
B.path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["create", "update"] }
C.path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd/*" { capabilities = ["create", "update"] }
D.path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["write"] }
AnswerB

This grants read to credentials and create/update to the specific secret path, following least privilege.

Why this answer

Option A is correct. For database creds, read is sufficient. For KV v2, to write data, you need both create and update capabilities.

Option B uses 'write' which is not a standard capability. Option C uses a glob that may be too broad. Option D adds delete which is not needed.

Practice this question →
24
MCQhard

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?

A.The policy allows both encryption and decryption, but the capabilities should be "read" and "write" instead.
B.The policy allows both encryption and decryption, which is correct for the transit engine.
C.The policy allows encryption but not decryption, which is sufficient.
D.The policy incorrectly uses "create" and "update" for transit operations; it should use "read" and "write".
AnswerB

The policy correctly provides the necessary capabilities for both operations.

Why this answer

Option C is correct. In Vault Transit, encryption and decryption operations require 'create' or 'update' capabilities on the respective endpoints. The policy provides both, allowing the application to encrypt and decrypt as needed.

Practice this question →
25
Multi-Selectmedium

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

Select 3 answers
A.list
B.encrypt
C.deny
D.patch
E.sudo
AnswersA, C, E

list is a valid capability for listing keys or items at a path.

Why this answer

The valid capabilities are sudo, list, and deny. Patch and encrypt are not standard Vault policy capabilities.

Practice this question →
26
MCQeasy

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?

A.["read", "update"]
B.["write"]
C.["update"]
D.["create", "update"]
AnswerC

Update allows modifying existing secrets without creating new ones.

Why this answer

Option C is correct. The 'update' capability alone allows modifying existing secrets without creating new ones. 'create' would allow new secrets, and 'read' would add unnecessary read access. 'write' is not a valid capability.

Practice this question →
27
MCQeasy

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?

A.path "secret/data/app" { capabilities = ["read"]; allowed_parameters = {"db_password"=[]} }
B.path "secret/data/app" { capabilities = ["read"] }
C.path "secret/data/app/db_password" { capabilities = ["read"] }
D.path "secret/data/app" { capabilities = ["read"]; required_parameters = ["db_password"] }
AnswerA

This allows reading only the key db_password, with any value.

Why this answer

Option C is correct because it uses allowed_parameters to restrict to the key "db_password". Option A allows reading all keys. Option B uses an incorrect path for key-level restriction.

Option D requires the parameter but does not restrict to only that key.

Practice this question →
28
Multi-Selecteasy

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

Select 2 answers
A.modify
B.sudo
C.patch
D.encrypt
E.list
AnswersB, E

sudo is a valid capability that allows performing privileged operations.

Why this answer

The valid capabilities are sudo and list. Modify, patch, and encrypt are not standard Vault policy capabilities.

Practice this question →
29
MCQmedium

A developer has a policy that grants 'create' capability on path 'secret/data/team/*'. They successfully create a new secret using 'vault kv put secret/data/team/db', but when they try to update the same secret with new data, they get a permission denied error. What is the most likely cause?

A.The developer does not have the 'create' capability on the parent path.
B.The policy does not include the 'update' capability, which is required for modifying existing secrets.
C.The policy needs the 'list' capability on the path.
D.The developer's token lacks the 'sudo' capability for updates.
AnswerB

KV v2 requires separate 'update' capability for modifications.

Why this answer

Option B is correct because in KV v2, creating a new secret requires the 'create' capability, while updating an existing secret requires the 'update' capability. The policy only grants 'create', so updates fail. Option A is incorrect because the developer already created a secret.

Option C is incorrect; 'list' is not needed for updates. Option D is incorrect; 'sudo' is not required.

Practice this question →
30
MCQhard

A Vault policy includes the following statement: path "secret/data/+/app" { capabilities = ["read"] }. Which paths would match this policy? (Assume KV v2)

A.secret/data/team-a/app/db
B.secret/data/team-a/team-b/app
C.secret/data/app
D.secret/data/team-a/app
AnswerD

Team-a is one segment, matching the +.

Why this answer

Option A is correct. The '+' glob matches exactly one path segment. So 'secret/data/team-a/app' has one segment between 'data/' and '/app', matching.

Option B has two segments, so no match. Option C has no segment. Option D has an additional segment after app, so no match.

Practice this question →
31
MCQhard

A Vault cluster has several policies. One policy, "app-policy", contains: path "secret/data/app/*" { capabilities = ["create", "update"] }. Another policy, "admin-policy", includes: path "secret/data/app/db" { capabilities = ["deny"] }. A token is attached with both policies. Can the token write to "secret/data/app/db"?

A.No, because the paths conflict.
B.No, because deny takes precedence over allow.
C.Yes, because policies are additive.
D.Yes, because the first policy allows create/update.
AnswerB

Deny always takes precedence, so the token cannot write to that path.

Why this answer

Option B is correct. In Vault, deny statements override any other capabilities regardless of policy ordering. Therefore, the explicit deny on the specific path prevents the write, even though the first policy allows create/update.

Practice this question →
32
Multi-Selectmedium

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

Select 2 answers
A.create
B.write
C.sudo
D.rename
E.update
AnswersA, E

'create' is a valid capability.

Why this answer

In Vault policies, capabilities define the allowed actions on paths. The `create` capability permits creating new data at a path without needing to read existing data, which is distinct from `update` that allows modifying existing data. Both `create` and `update` are valid, separate capabilities in Vault's policy system.

Exam trap

HashiCorp often tests the distinction between `write` (which is not a valid capability) and the correct pair `create` and `update`, leading candidates to incorrectly select `write` as a catch-all for data modification.

Practice this question →
33
MCQmedium

A security administrator wants to create a policy that allows a service to renew its own token and list its own token capabilities, but not create new tokens. Which policy statements should be included?

A.path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["read"] }
B.path "auth/token/renew-self" { capabilities = ["create"] }; path "auth/token/lookup-self" { capabilities = ["read"] }
C.path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["update"] }
D.path "auth/token/renew" { capabilities = ["update"] }; path "auth/token/capabilities" { capabilities = ["read"] }
AnswerA

This is correct: renew-self uses update, capabilities-self uses read.

Why this answer

Option B is correct because it uses the correct endpoints and capabilities: update for renew-self and read for capabilities-self. Option A uses update for capabilities-self, which is wrong. Option C uses create for renew-self, which is incorrect.

Option D uses non-self endpoints giving broader privileges.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Create Vault policies questions.

Start 20-question session