VA-003 Create Vault policies Practice Test 2 — 15 Questions

Question 1

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

Accepted Answer

The read is denied because the deny policy takes precedence.. 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.

Answer

The read fails because the path does not exist.

Answer

The read succeeds because the first path grants read.

Answer

The read succeeds because deny only applies to write operations.

Question 2

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?

Accepted Answer

The policy allows both encryption and decryption, which is correct for the transit engine.. 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.

Answer

The policy allows both encryption and decryption, but the capabilities should be "read" and "write" instead.

Answer

The policy allows encryption but not decryption, which is sufficient.

Answer

The policy incorrectly uses "create" and "update" for transit operations; it should use "read" and "write".

Question 3

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

Accepted Answer

The write fails because the policy only allows read on production.. 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.

Answer

The write succeeds if the secret already exists.

Answer

The write succeeds because the path matches.

Answer

The write fails because the user does not have list capability.

Question 4

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?

Accepted Answer

["update"]. 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.

Answer

["read", "update"]

Answer

["write"]

Answer

["create", "update"]

Question 5

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?

Accepted Answer

path "sys/auth" { capabilities = ["list"] }. 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.

Answer

path "sys/auth" { capabilities = ["read", "list"] }

Answer

path "sys/auth" { capabilities = ["read"] }

Answer

path "auth/*" { capabilities = ["list"] }

Question 6

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

Accepted Answer

secret/data/team-a/app. 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.

Answer

secret/data/team-a/app/db

Answer

secret/data/team-a/team-b/app

Answer

secret/data/app

Question 7

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

Accepted Answer

path "auth/token/revoke-self" { capabilities = ["update"] }. 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.

Answer

path "auth/token/revoke" { capabilities = ["update"] }

Answer

path "auth/token/revoke-self" { capabilities = ["write"] }

Answer

path "sys/leases/revoke" { capabilities = ["update"] }

Question 8

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

Accepted Answer

Listing all identity entities and reading their details.. 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.

Answer

Reading and updating all identity entities.

Answer

Reading and listing all identity entities.

Answer

Reading and listing all identity entity IDs.

Question 9

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"?

Accepted Answer

No, because deny takes precedence over allow.. 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'.

Answer

No, because the paths conflict.

Answer

Yes, because policies are additive.

Answer

Yes, because the first policy allows create/update.

Question 10

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?

Accepted Answer

The policy uses a single asterisk, which does not match nested paths; it should use double asterisk or specify the exact path.. 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.

Answer

The policy lacks the 'deny' capability to override the default deny.

Answer

The secret engine's mount path is different; it is mounted at 'secret/' but the policy expects 'secret/data/'.

Answer

The user's token does not have the correct identity policies attached.

Question 11

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?

Accepted Answer

Create separate policies for each application and use group aliases to attach them.. 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.

Answer

Create policies with broad paths and then restrict via ACL tokens.

Answer

Create a single policy with a wildcard path '*' and full capabilities for all administrators.

Answer

Create a single policy with all paths and capabilities for all users.

Question 12

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?

Accepted Answer

path "secret/data/{{identity.entity.metadata.team}}/*" { capabilities = ["read", "list"] }. 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.

Answer

path "secret/data/{{entity.metadata.team}}/*" { capabilities = ["read", "list"] }

Answer

path "secret/data/{{.team}}/*" { capabilities = ["read", "list"] }

Answer

path "secret/data/{{identity.entity.aliases.team}}/*" { capabilities = ["read", "list"] }

Question 13

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?

Accepted Answer

The policy does not include the 'update' capability, which is required for modifying existing secrets.. 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.

Answer

The developer does not have the 'create' capability on the parent path.

Answer

The policy needs the 'list' capability on the path.

Answer

The developer's token lacks the 'sudo' capability for updates.

Question 14

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

Accepted Answer

Use path templating to incorporate entity metadata.. 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.

Answer

Avoid using negative capabilities (deny) when possible.

Answer

Grant maximum permissions initially and then restrict as needed.

Answer

Use a single all-encompassing policy for each environment.

Question 15

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?

Accepted Answer

Create a policy using a templated path: path "secret/data/{{identity.entity.metadata.team}}/*" { capabilities = ["read", "list"] }.. 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.

Answer

Create a policy using a wildcard alias for each team in the entity alias.

Answer

Create a policy that uses the 'default' policy to allow all reads and then restrict with ACL tokens.

Answer

Create a policy with path "secret/data/*" { capabilities = ["read", "list"] } and assign it to all users.