HashiCorp Vault Associate (003) Question 45
Single answer2b Describe Vault policy syntax: pathA platform team stores application secrets in a KV v2 secrets engine mounted at secret/. Developers in the payments team should be able to read only secrets under secret/data/payments/*, but they must not be able to list or read metadata for other teams' paths. An administrator is writing an ACL policy and wants to scope access correctly using Vault policy path syntax. Which policy stanza best meets this requirement?
- A
path "secret/payments/*" { capabilities = ["read", "list"] }
- B
path "secret/data/payments/*" { capabilities = ["read"] }
- C
path "secret/metadata/payments/*" { capabilities = ["read"] }
- D
path "secret/data/*" { capabilities = ["read"] }
Show answer and explanation
Correct answer: B
Explanation
Vault ACL policies use path stanzas that match request paths. For KV v2, this is a common source of mistakes because the policy must reference the API-style subpaths such as data/ and metadata/, not just the visible folder structure. To read a secret in a KV v2 engine mounted at secret/, the request path is secret/data/
- A. Incorrect.
Incorrect. For KV v2, policy paths must match the API path structure, not just the mount and logical folder name. Reading secret values uses the data/ path segment, so secret/payments/* does not correctly target KV v2 read operations. In addition, granting list here would not behave as intended because listing for KV v2 is performed against metadata/ paths, not data/ paths.
- B. Correct.
Correct. In KV v2, reading secret data occurs under the mount path plus data/, so secret/data/payments/* is the correct ACL path pattern for read access to secrets in the payments area. Because the requirement is to read only those secrets and not list or view metadata more broadly, granting only read on this path is the best fit.
- C. Incorrect.
Incorrect. The metadata/ path in KV v2 is used for metadata operations and listing keys, not for reading secret values. A read capability on secret/metadata/payments/* would not grant access to the actual secret data stored under secret/data/payments/*.
- D. Incorrect.
Incorrect. Although this uses the correct KV v2 data/ API prefix, it is too broad. secret/data/* would allow reads for all teams under the mount, violating the requirement to restrict access to only the payments team.