HashiCorp Vault Associate (003) Question 46
Single answer2b Describe Vault policy syntax: pathA team stores application secrets in a KV v2 secrets engine mounted at secret/. Developers should be able to read only secrets under the path apps/dev/, such as secret/data/apps/dev/api, but they must not be able to read secrets in apps/prod/. You are reviewing policy options to grant the least privilege needed. Which policy stanza correctly grants this access?
- A
path "secret/apps/dev/*" { capabilities = ["read"] }
- B
path "secret/data/apps/dev/*" { capabilities = ["read"] }
- C
path "secret/metadata/apps/dev/*" { capabilities = ["read"] }
- D
path "secret/data/apps/*" { capabilities = ["read"] }
Show answer and explanation
Correct answer: B
Explanation
Vault policies use path stanzas to match API paths, and the capabilities granted apply to those matched paths. For a KV v2 secrets engine, the API path for reading secret values includes the data/ segment, so a policy must reference paths like secret/data/apps/dev/* rather than a simplified logical path. This is a frequent real-world issue when teams migrate from KV v1 to KV v2 or write policies based on the CLI secret name instead of the underlying API path. The best-practice approach is to grant only the minimum capabilities on the narrowest path needed. HashiCorp documentation for KV v2 and Vault policies emphasizes that policy paths must align with the actual endpoint path structure, including data/ for secret values and metadata/ for listing and metadata-related operations.
- A. Incorrect.
Incorrect. This path omits the KV v2 API prefix. For KV v2, policy paths must match the actual API path structure, where secret data is accessed under /data/. A common mistake is to write the logical-looking path based only on the mount and folder structure, but Vault policy path matching is based on the request path, not the user-friendly secret name.
- B. Correct.
Correct. In KV v2, reading a secret requires access to the data endpoint, which uses the path pattern secret/data/
. The wildcard correctly scopes access to only secrets beneath apps/dev/. This follows least privilege by not granting access to sibling paths such as apps/prod/. - C. Incorrect.
Incorrect. The metadata endpoint is used for operations such as listing and metadata management in KV v2, not for reading secret values. Granting read on metadata does not allow reading the secret data itself. Candidates often confuse data and metadata paths because both are part of KV v2 policy design.
- D. Incorrect.
Incorrect. Although this uses the correct KV v2 data prefix, the wildcard scope is too broad. It grants read access to all application secrets under apps/, including apps/prod/, which violates the requirement to restrict access to only the development subtree.