HashiCorp Vault Associate (003) Question 47
Single answer2b Describe Vault policy syntax: pathA platform engineer is writing an ACL policy for an application team that stores credentials in a KV v2 secrets engine mounted at secret/. The team should be able to read only secrets under app/payments/ and list keys in that folder, but they must not be able to read metadata for other application folders. Which policy configuration best meets this requirement?
- A
path "secret/app/payments/*" { capabilities = ["read", "list"] }
- B
path "secret/data/app/payments/" { capabilities = ["read"] } path "secret/metadata/app/payments/" { capabilities = ["list"] }
- C
path "secret/data/app/payments/*" { capabilities = ["read"] } path "secret/metadata/app/payments" { capabilities = ["list"] }
- D
path "secret/app/payments" { capabilities = ["read", "list"] } path "secret/metadata/*" { capabilities = ["deny"] }
Show answer and explanation
Correct answer: C
Explanation
Vault ACL policies are path-based, and the exact path must match the API route used by the secrets engine. With KV v2, operations are split across distinct paths: secret/data/... for reading and writing secret data, and secret/metadata/... for listing and metadata operations. A common mistake is to write policies against the mount path as if it were KV v1, for example secret/app/payments/, which does not match KV v2 requests. Another frequent error is granting list on secret/metadata/app/payments/ instead of on the folder path itself. To list keys within a folder, Vault checks the metadata path for that directory, such as secret/metadata/app/payments. This aligns with HashiCorp Vault documentation and best practice for least-privilege ACL design: grant read only on the specific data subtree required and list only on the exact metadata folder that users need to browse.
- A. Incorrect.
Incorrect. This uses a path pattern that looks like a generic mount path, but KV v2 API paths are policy-sensitive and require the internal route structure. Reads occur under secret/data/... and list operations occur against secret/metadata/.... Using secret/app/payments/* will not match the actual KV v2 API paths needed for these operations.
- B. Incorrect.
Incorrect. This is close, but list on KV v2 must target the metadata path for the folder being listed, not metadata/app/payments/*. Listing is performed on the directory path itself, such as secret/metadata/app/payments, not on a wildcard child path. As written, the policy allows reads of individual secrets but does not correctly grant list on the payments folder.
- C. Correct.
Correct. For KV v2, reading secret values requires access to the data endpoint, so secret/data/app/payments/* with read is appropriate for secrets beneath that folder. Listing keys requires list capability on the metadata endpoint for the folder itself, so secret/metadata/app/payments with list is the correct path. This grants listing only within the payments folder and does not expose metadata listing for sibling application folders.
- D. Incorrect.
Incorrect. The first stanza again uses a non-KV-v2-aware path for reads and lists, so it will not correctly authorize the intended operations. The deny rule on secret/metadata/* is also overly broad and would block metadata access needed for listing the payments folder unless a more specific rule were evaluated as applicable; in practice this is not the clean, correct solution for granting the required KV v2 access.