Knowledge + Practice

CCNA Vault Policies Questions

31 questions · Vault Policies topic · All types, answers revealed

Practice these questions Exam hub All 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 1 answer

A.write

B.create

C.read

D.sudo

E.update

AnswersC

Correct. 'read' is required to read secrets and to generate dynamic database credentials (both are read operations).

Why this answer

The only capability required for the described tasks is 'read'. Reading specific secrets from KV v2 or generating dynamic database credentials (via database/creds/<role-name>) both use the 'read' operation. AppRole authentication is handled before the policy applies; the policy itself does not need to grant capabilities for the login process.

Exam trap

Candidates often confuse 'write' with 'create' and 'update', not realizing that Vault uses specific capabilities: 'create' for new resources, 'update' for changes to existing ones, and 'read' for reading data (including generating dynamic credentials). The 'write' capability is a more generic permission that was used in older policies but is now replaced by finer-grained capabilities. Also, generating dynamic database credentials requires 'read' on the creds path, not 'create'.

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

It uses the proper templating syntax `{{identity.entity.metadata.team}}` to reference the `team` metadata key stored on the Vault entity. This allows the policy to dynamically grant read and list access to the path `secret/data/<team>/*`, ensuring users only see secrets belonging to their own team as defined by the external identity provider.

Exam trap

Vault often tests the distinction between entity metadata and alias metadata, and the trap here is that candidates confuse `{{identity.entity.metadata}}` with `{{identity.entity.aliases}}` or use invalid shorthand like `{{entity.metadata}}` or `{{.team}}`.

How to eliminate wrong answers

Option B is wrong because it uses `{{entity.metadata.team}}` which is not valid ACL policy templating syntax; the correct prefix must be `identity.entity.metadata`. Option C is wrong because `{{.team}}` is a shorthand used in Consul templates, not in Vault ACL policies, and does not reference entity metadata. Option D is wrong because `{{identity.entity.aliases.team}}` incorrectly attempts to access a metadata key directly under aliases; team membership is stored in entity metadata, not in the alias object itself.

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 policy must grant read access to the specific path 'secret/data/app' for the service to retrieve secrets. Option B is correct because renewing a token requires the 'update' capability on the 'auth/token/renew-self' endpoint, which allows the service to extend its own token's TTL without needing broader token management privileges.

Exam trap

HashiCorp Vault often tests the distinction between 'auth/token/renew-self' and 'auth/token/renew', where candidates mistakenly choose the broader 'renew' path instead of the self-service endpoint, overlooking the requirement for the service to renew only its own token.

Practice this question →

4

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

The policy shown grants 'read' capability on the path 'secret/data/engineering/*'. In Vault, the 'read' capability allows listing and reading secrets at that path, but not creating, updating, or deleting them. Therefore, a user can read all secrets under secret/data/engineering/.

Exam trap

Vault often tests the distinction between 'read' and 'create'/'update' capabilities, where candidates mistakenly assume 'read' includes the ability to modify secrets.

How to eliminate wrong answers

Option A is wrong because creating secrets requires the 'create' or 'sudo' capability, which is not granted by the policy. Option C is wrong because deleting secrets requires the 'delete' capability, which is not included in the policy. Option D is wrong because updating secrets requires the 'update' capability, which is not granted by the policy.

Practice this question →

5

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

The policy grants 'read' and 'list' capabilities on the path `identity/entity/id/*`. In Vault, the 'list' capability returns entity IDs (a summary), while the 'read' capability retrieves the full details of a specific entity. Option C correctly captures both actions: listing all entities and reading their details.

Exam trap

Vault candidates often conflate 'list' (returns entity IDs) with 'read' (returns full details) on the identity/entity/id/* path. The 'list' action provides a summary of IDs, while 'read' gives the complete entity details for a specific ID.

How to eliminate wrong answers

Option A is wrong because 'update' is not listed in the capabilities; the policy only allows 'read' and 'list', not 'update'. Option B is wrong because it says 'reading and listing all identity entities', but 'read' retrieves details of a specific entity, not a bulk read of all entities; listing returns IDs, not full entities. Option D is wrong because it says 'reading and listing all identity entity IDs', but 'read' retrieves entity details, not just IDs; listing returns IDs, but reading returns the full entity object.

Practice this question →

6

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

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 →

7

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

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 →

8

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 developer needs to create new secrets under 'secret/data/engineering/projects/', which requires the 'create' capability on that path. Option E is correct because the developer needs to read and list secrets from 'secret/data/engineering/', and the wildcard 'secret/data/engineering/*' covers all paths under that prefix, including the base path itself when using KV v2 (the 'data/' prefix is part of the path).

Exam trap

The VA-003 exam often tests the distinction between KV v1 and KV v2 path structures — the trap here is that candidates forget the mandatory 'data/' prefix in KV v2 paths, leading them to select option D, or they overlook that 'create' alone (without 'update') is sufficient for creating new secrets, causing them to choose the overly permissive option A.

Practice this question →

9

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

It aligns with the principle of least privilege by creating separate policies for each application, ensuring that each application only has access to the specific paths and capabilities it requires. Using group aliases to attach these policies allows for centralized management and simplifies policy updates, as changes can be made at the group level rather than per user or token. This approach also leverages Vault's identity-based policies, which are evaluated based on the entity's group memberships, providing a scalable and maintainable policy structure.

Exam trap

A common misconception in Vault is that using broad policies with wildcards simplifies management, but the correct approach is to create granular, application-specific policies to enforce least privilege and maintain auditability.

How to eliminate wrong answers

Option A is wrong because creating policies with broad paths and then restricting via ACL tokens violates the principle of least privilege by initially granting excessive access, and ACL tokens are not a mechanism for restricting policies—policies themselves define capabilities, and tokens inherit them. Option B is wrong because a single policy with a wildcard path '*' and full capabilities for all administrators grants unrestricted access to all secrets and operations, which is a security risk and directly contradicts the principle of least privilege. Option C is wrong because a single policy with all paths and capabilities for all users provides no granularity, allowing every user to access every secret and perform all operations, which is insecure and unmanageable.

Practice this question →

10

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

Vault's ACL policy templating allows dynamic path construction using entity metadata. By using `{{identity.entity.metadata.team}}` in the policy path, the policy automatically resolves to the team name stored in the user's entity metadata, granting read/list access only to that team's secrets path. This eliminates the need for per-team policies while maintaining least-privilege access.

Exam trap

Vault often tests the distinction between static wildcard paths and dynamic templated paths, where candidates mistakenly think a simple wildcard like `secret/data/*` is sufficient, ignoring the need for metadata-driven access control.

How to eliminate wrong answers

Option A is wrong because wildcard aliases are not a Vault feature; entity aliases map external identities to Vault entities but do not support wildcards for policy path construction. Option B is wrong because the 'default' policy is a built-in policy that cannot be modified to restrict reads; ACL tokens are used for authentication, not for restricting permissions after a policy grants access. Option D is wrong because granting read/list on `secret/data/*` would give every user access to all team secrets, violating the principle of least privilege and the requirement for team-specific access.

Practice this question →

11

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

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

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

Practice this question →

12

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

The deny policy takes precedence over any allow policy in Vault, regardless of the path specificity. Even though the first path grants read access to 'secret/data/team-a/*', the second path explicitly denies all capabilities (including read) on 'secret/data/team-a/admin', which is a more specific path. Vault's policy evaluation uses a deny-overrides model, so the deny action blocks the read operation.

Exam trap

Candidates often mistakenly think Vault uses a first-match or most-specific-path-wins model, similar to firewall rules, when in fact deny always overrides allow regardless of path specificity.

How to eliminate wrong answers

Option A is wrong because the path 'secret/data/team-a/admin' exists in the policy (it is explicitly listed in the deny statement), so the failure is not due to a missing path. Option B is wrong because Vault does not use a first-match-wins model; deny policies take precedence over allow policies, even if the allow path is broader. Option C is wrong because the deny policy applies to all capabilities (read, write, list, delete, etc.) unless specific capabilities are listed; the deny statement here has no capabilities list, so it denies all operations, including read.

Practice this question →

13

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

In Vault's policy path matching, a single asterisk (`*`) matches only a single level of the path, not nested sub-paths. The path `secret/data/engineering/*` matches `secret/data/engineering/foo` but does NOT match `secret/data/engineering/db/password` because the latter has an additional sub-path level. To match all nested paths, you must use a double asterisk (`**`) or explicitly list the full path.

This is a common pitfall when writing Vault policies for hierarchical secret structures.

Exam trap

The Vault exam often tests the subtle distinction between single and double asterisks in Vault policy path matching, exploiting the common misconception that `*` matches any number of nested sub-paths, when in fact it only matches within a single path segment.

How to eliminate wrong answers

Option B is wrong because Vault's default behavior is to deny any action not explicitly allowed; there is no need to add a 'deny' capability, and the `deny` capability is not a standard Vault capability—it is used in Sentinel policies, not ACL policies. Option C is wrong because the policy path `secret/data/engineering/*` correctly matches the standard KV v2 secret engine mount path, where secrets are accessed under `secret/data/`; the mount path is `secret/`, and the `data/` prefix is part of the API path for KV v2, so the policy is correctly scoped. Option D is wrong because the error is specifically about path-level permissions, not about identity policies; identity policies (attached via tokens or entities) would be evaluated in addition to the ACL policy, but the core issue here is that the ACL policy's glob pattern does not cover the nested path.

Practice this question →

14

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

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 →

15

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

To revoke your own token, you need the endpoint 'auth/token/revoke-self' with the 'update' capability. Option A uses 'auth/token/revoke', which is for revoking other tokens and requires sudo capability. Option B uses the correct endpoint but 'write' is not a valid capability in Vault; the correct capability is 'update'.

Option C uses 'sys/leases/revoke', which is for revoking leases, not tokens.

Practice this question →

16

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

HashiCorp recommends using path templating with entity metadata (e.g., {{identity.entity.metadata.team}}) to dynamically scope policies to specific teams or applications. This approach reduces policy sprawl and ensures that permissions are automatically applied based on the authenticated entity's attributes, aligning with the principle of least privilege.

Exam trap

HashiCorp often tests candidates' understanding that Vault policies are purely additive (no deny) and that path templating is a key best practice for scaling policy management across multiple teams, tempting candidates to select 'avoid deny' or 'single policy' due to familiarity with other IAM systems.

Practice this question →

17

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

The policy only grants 'read' capability on the 'secret/data/production/*' path, which allows reading secrets but not creating or updating them. Writing a new secret requires 'create' or 'update' capabilities (or 'write' which encompasses both). Since the policy lacks these capabilities, the write operation fails regardless of whether the secret already exists.

Exam trap

A common misunderstanding in HashiCorp Vault is that path matching alone is sufficient for an operation to succeed, overlooking that each capability (e.g., read, create, update) must be explicitly granted in the policy.

How to eliminate wrong answers

Option A is wrong because even if the secret already exists, the policy does not grant 'update' capability, so the write fails. Option B is wrong because the path matches, but capability matching is also required; the policy only allows 'read', not 'write'. Option D is wrong because the failure is due to missing 'create'/'update' capability, not missing 'list' capability; 'list' is irrelevant for a write operation.

Practice this question →

18

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

The most likely cause is that the Vault mount for 'secret' is using KV v1, which does not use the 'data' segment in the path. The policy is written with 'secret/data/app/*' (KV v2 path), but because the mount is KV v1, the actual path is 'secret/app/prod'. This path mismatch leads to 'permission denied' because the policy does not apply to the correct path.

Exam trap

HashiCorp Vault often tests the distinction between KV v1 and KV v2 path structures, trapping candidates who assume all 'secret' mounts use the same path format without checking the engine version.

How to eliminate wrong answers

Option B is wrong because the 'sudo' capability is not required for reading secrets; it is used for privileged operations like updating mount configurations or policies, not for standard read/list actions. Option C is wrong because insufficient TTL would cause token expiration, not a 'permission denied' error; the token is being used correctly as verified, so TTL is not the issue. Option D is wrong because the administrator has already verified that the service account has the correct Vault role attached, implying the role binding to the Kubernetes namespace is correct; the error stems from path structure, not namespace binding.

Practice this question →

19

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

The correct matches are: A (vault kv put) stores secrets in KV, D (vault kv delete) deletes secrets, and F (vault read) reads data from any path. Options B and C are incorrect because their descriptions are swapped: vault kv get retrieves a secret (not lists), and vault kv list lists keys (not retrieves). Option E is incorrect because vault write is a generic command that writes to any path, not specifically to the KV secret engine; the KV-specific command for storing secrets is vault kv put.

Practice this question →

20

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 A. To list all enabled authentication methods, the required path is 'sys/auth' with the 'list' capability. The 'list' action returns the names of all auth methods.

Option B is incorrect because it includes 'read', which is unnecessary and not required for listing. Option C is also incorrect because it only has 'read', which would only retrieve a specific method if the name is known. Option D uses a wildcard 'auth/*', which would grant list capability on all sub-paths under 'auth/', but the standard path for listing auth methods is 'sys/auth'.

Therefore, option A is the most precise and correct.

Practice this question →

21

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

It grants the minimum required capabilities: 'read' for reading dynamic database credentials from 'database/creds/my-role', and 'create' and 'update' for writing to 'secret/data/ci-cd'. The principle of least privilege dictates that 'delete' is unnecessary for storing build artifacts, and the path must be exact without a wildcard to avoid granting unintended access to sub-paths.

Exam trap

The exam often tests distinguishing between valid capabilities (e.g., 'create' and 'update') and invalid ones (e.g., 'write'), as well as the correct use of exact paths versus wildcards. Candidates may mistakenly include 'delete' or use a wildcard, leading to over-permissioning or incorrect syntax.

How to eliminate wrong answers

Option A is wrong because it includes 'delete' capability on 'secret/data/ci-cd', which violates least privilege as the pipeline only needs to write artifacts, not delete them. Option C is wrong because it uses a wildcard path 'secret/data/ci-cd/*', which would grant capabilities to all sub-paths under 'ci-cd', potentially exposing other secrets and violating least privilege. Option D is wrong because 'write' is not a valid capability in Vault policies; the correct capabilities for writing are 'create' and 'update'.

Practice this question →

22

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

The transit engine in Vault uses the `encrypt` and `decrypt` capabilities to allow encryption and decryption operations, respectively. The policy shown uses `create` and `update` capabilities, which are correct for the transit engine because `create` is used to encrypt data (creating ciphertext) and `update` is used to decrypt data (updating the ciphertext back to plaintext). Therefore, the policy allows both encryption and decryption, making option B correct.

Exam trap

A common misconception is that `read` and `write` capabilities are used for all operations, but in the transit engine, `create` and `update` are the correct capabilities for encrypt and decrypt actions.

How to eliminate wrong answers

Option A is wrong because the transit engine does not use `read` and `write` capabilities for encryption/decryption; those are used for reading and writing data at rest, not for transit operations. Option C is wrong because the policy includes both `create` (encrypt) and `update` (decrypt) capabilities, so it allows decryption as well, not just encryption. Option D is wrong because `create` and `update` are the correct capabilities for transit operations; `read` and `write` are not used for encrypt/decrypt actions in the transit engine.

Practice this question →

23

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

In Vault policy path statements, capabilities define the allowed operations on secrets. The 'list' capability is valid and allows listing keys at a given path, which is essential for enumerating secrets without reading their values. This is a core capability in Vault's policy system, distinct from 'read' or 'write'.

Exam trap

The exam often tests the distinction between HTTP methods and Vault capabilities, so the trap here is that candidates confuse 'patch' (an HTTP method) or 'encrypt' (an API operation) with actual policy capabilities, leading them to select invalid options.

Practice this question →

24

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

In Vault's KV v2 secrets engine, the 'update' capability is specifically required to modify an existing secret at a given path without the ability to create a new one. The 'create' capability is needed only for initial creation, and 'read' is not required for the update operation itself. Since the policy must allow updating existing secrets but not creating new ones, only the 'update' capability is necessary.

Exam trap

The trap here is that candidates often confuse 'write' with 'update' in Vault, not realizing that 'write' is a super-capability that includes both 'create' and 'update', while 'update' alone is the precise capability for modifying existing secrets without creation rights.

How to eliminate wrong answers

Option A is wrong because 'read' is not required for updating an existing secret; it only allows reading the data, and including it would grant unnecessary read access. Option B is wrong because 'write' in Vault's KV v2 engine is a meta-capability that encompasses both 'create' and 'update', which would allow creating new secrets, violating the requirement. Option D is wrong because 'create' would allow the service to create new secrets at the path, which is explicitly disallowed by the requirement.

Practice this question →

25

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

Vault policy syntax uses `allowed_parameters` to restrict which keys within a path can be read. By setting `allowed_parameters = {"db_password"=[]}`, the policy permits reading only the `db_password` key under `secret/data/app`, while denying access to any other keys at that path. This enforces the requirement precisely.

Exam trap

A common trap is confusing Vault's `allowed_parameters` (which restricts which keys can be accessed within a path) with `required_parameters` (which mandates that certain keys be present in the request). Candidates often choose option D, thinking it restricts access to only the specified key, but `required_parameters` does not restrict access; it only requires those parameters to be provided in the request, allowing access to all keys if the required params are present.

How to eliminate wrong answers

Option B is wrong because it grants read access to all keys under `secret/data/app`, not just `db_password`, violating the requirement. Option C is wrong because it attempts to target a specific key as a subpath, but Vault's KV v2 engine does not expose individual keys as separate paths; the path must be the secret's full path, and key-level restrictions require `allowed_parameters`. Option D is wrong because `required_parameters` mandates that the request must include `db_password`, but does not restrict which keys can be read; it would still allow reading other keys if they are present, and it would block requests that omit `db_password` even if the user only wants that key.

Practice this question →

26

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

'sudo' is a valid capability in Vault policy path statements that allows a token to access paths and perform operations that would normally be denied by the policy, effectively granting elevated privileges for those paths. It is used to enable certain administrative actions, such as reading or writing to paths that require sudo-like permissions, and is explicitly supported in Vault's policy language.

Exam trap

Candidates often confuse RESTful API verbs (like POST, PATCH, MODIFY) with Vault policy capabilities. They incorrectly select 'patch' or 'modify' instead of the actual valid capabilities such as 'sudo' and 'list'.

Practice this question →

27

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

In Vault, the 'kv put' command performs a 'create' operation when the secret does not exist, but an 'update' operation when it does. The policy only grants 'create' capability on 'secret/data/team/*', which allows the initial write but not subsequent modifications. To update an existing secret, the policy must also include the 'update' capability on the same path, as Vault's ACL system enforces separate capabilities for creating and updating secrets.

Exam trap

A common misconception in Vault is that 'kv put' is a single operation, when in fact Vault treats the first write as 'create' and subsequent writes as 'update', requiring separate capabilities in the policy.

How to eliminate wrong answers

Option A is wrong because the developer successfully created the secret, which requires 'create' capability on the exact path 'secret/data/team/db' — the parent path 'secret/data/team/*' is irrelevant since the policy already covers the child path. Option C is wrong because the 'list' capability is only needed for listing secrets under a path (e.g., 'vault kv list'), not for updating an existing secret. Option D is wrong because Vault does not require 'sudo' capability for updates; 'sudo' is a special capability for certain privileged operations (e.g., writing to 'sys/') and is unrelated to KV secret updates.

Practice this question →

28

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

In Vault KV v2, the path structure is `secret/data/<path>`, and the `+` glob matches a single path segment. The policy `secret/data/+/app` matches exactly one segment between `data/` and `/app`. Option D, `secret/data/team-a/app`, has a single segment `team-a` before `app`, so it matches.

Options with additional segments (A, B) or missing the required segment (C) do not match.

Exam trap

The glob pattern `+` matches exactly one path segment. In KV v2, the path must include the `data/` prefix. Candidates may mistakenly believe that `+` can match multiple segments (like `*`) or that the `data/` prefix is not required, but this question tests both concepts.

How to eliminate wrong answers

Option A is wrong because `secret/data/team-a/app/db` has two segments after `data/` (`team-a/app/db`), and the `+` glob matches only one segment, so the extra `/db` segment causes a mismatch. Option B is wrong because `secret/data/team-a/team-b/app` has three segments after `data/` (`team-a/team-b/app`), exceeding the single-segment match of `+`. Option C is wrong because `secret/data/app` has zero segments between `data/` and `app`; the `+` requires exactly one segment, so this path does not match.

Practice this question →

29

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

B is correct because in Vault, the 'deny' capability takes precedence over all other capabilities. When a token has multiple policies attached, Vault evaluates all matching paths and applies the most restrictive result. Since 'admin-policy' explicitly denies access to 'secret/data/app/db', the token cannot write to that path, regardless of the 'create' and 'update' capabilities granted by 'app-policy'.

Exam trap

A common pitfall in Vault is assuming that policies are purely additive, overlooking that a 'deny' capability in any matching policy overrides all other capabilities.

How to eliminate wrong answers

Option A is wrong because path conflicts are resolved by capability precedence, not by blocking the operation outright; Vault uses a most-restrictive model where 'deny' overrides all allows. Option C is wrong because while policies are additive for non-conflicting capabilities, 'deny' is not additive—it is an absolute override that negates any allow on the same path. Option D is wrong because the first policy's 'create' and 'update' capabilities are overridden by the explicit 'deny' in the second policy; Vault does not use a first-match or additive model when 'deny' is present.

Practice this question →

30

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 →

31

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

It uses the correct endpoints and capabilities: update for renew-self and read for capabilities-self. Option B uses create for renew-self, which is incorrect (renew-self requires update). Option C uses update for capabilities-self, which is wrong (capabilities-self requires read).

Option D uses non-self endpoints (renew and capabilities) which would allow renewing or checking capabilities of any token, granting broader privileges than intended.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Vault Policies questions.

Start 20-question session