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

Question 1

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 2

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 3

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 4

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 allow a user to revoke their own token, the policy must grant the 'update' capability on the 'auth/token/revoke-self' endpoint. Vault's token revocation for self uses the update capability on that specific path, not write or the general revoke endpoint.

Answer

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

Answer

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

Answer

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

Question 5

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 6

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 7

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 8

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 9

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 10

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.

Question 11

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?

Accepted Answer

The Vault mount for 'secret' is KV v1, so the path should be 'secret/app/prod' without 'data'.. 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.

Answer

The policy should include the 'sudo' capability.

Answer

The pods are using a token with insufficient TTL.

Answer

The Vault role is not bound to the correct Kubernetes namespace.

Question 12

A Vault administrator is writing a policy for a monitoring tool that must be able to list all secrets under the 'secret/metadata/finance/' path and read the metadata of individual secrets, but must not read the secret data itself. Which policy snippet correctly grants only these permissions?

Accepted Answer

path "secret/metadata/finance/*" { capabilities = ["list", "read"] }. In Vault's KV v2 secrets engine, metadata operations such as listing secrets and reading secret metadata are performed on the metadata/ path, while reading and writing secret data uses the data/ path. To allow listing and reading metadata without accessing secret data, the policy must grant list and read on secret/metadata/finance/*. The other options either target the wrong path or omit required capabilities.

Answer

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

Answer

path "secret/metadata/finance/*" { capabilities = ["read"] }

Answer

path "secret/finance/*" { capabilities = ["list", "read"] }

Question 13

A security team needs to grant a service account the ability to read secrets from the path 'secret/data/backup' and also to update the secret at that same path. Which policy correctly implements this requirement?

Accepted Answer

path "secret/data/backup" { capabilities = ["read", "update"] }. For KV v2 secrets, reading and updating a secret at a specific path requires capabilities read and update on secret/data/<path>. The update capability allows modifying an existing secret, which is necessary here. Using create instead of update would not allow modifying an existing secret. Specifying the exact path without a wildcard ensures least privilege.

Answer

path "secret/backup" { capabilities = ["read", "update"] }

Answer

path "secret/data/backup" { capabilities = ["read", "create"] }

Answer

path "secret/data/backup/*" { capabilities = ["read", "update"] }

Question 14

A platform team stores KV v2 secrets under the mount 'kv-prod'. They need a policy that lets an application read only the metadata (not the underlying secret values) for every path under 'kv-prod/apps/', including the ability to enumerate keys. Which policy stanza satisfies this requirement?

Accepted Answer

path "kv-prod/metadata/apps/*" { capabilities = ["read", "list"] }. KV v2 splits each secret into a data endpoint that returns values and a metadata endpoint that returns version information. To inspect versions without exposing secret material, the policy must target the metadata path and include list so the prefix can be enumerated. Pointing the stanza at the data path leaks values, and omitting list breaks key discovery.

Answer

path "kv-prod/data/apps/*" { capabilities = ["read", "list"] }

Answer

path "kv-prod/metadata/apps/*" { capabilities = ["read"] }

Answer

path "kv-prod/apps/*" { capabilities = ["read", "list"] }

Question 15

A Vault administrator is creating a policy for an application that needs to read a PKI role configuration and also generate certificates using that role. The PKI secrets engine is mounted at 'pki/'. Which policy snippet grants the minimum required capabilities?

Accepted Answer

path "pki/roles/app-role" { capabilities = ["read"] } path "pki/issue/app-role" { capabilities = ["create", "update"] }. The PKI secrets engine uses pki/roles/ for reading role configuration and pki/issue/ for generating certificates. Generating a certificate is a write operation, so the policy must grant create or update on the issue path. Reading the role requires read on the roles path. The sign endpoint is for signing CSRs, not for generating certificates.

Answer

path "pki/roles/app-role" { capabilities = ["read", "list"] }
path "pki/issue/app-role" { capabilities = ["read"] }

Answer

path "pki/roles/app-role" { capabilities = ["read"] }
path "pki/sign/app-role" { capabilities = ["create", "update"] }

Answer

path "pki/roles/app-role" { capabilities = ["read"] }
path "pki/issue/app-role" { capabilities = ["sudo"] }