HashiCorp Vault Associate (003) Question 36
Single answer2 Vault policiesA security team enables the KV v2 secrets engine at path secret/. Developers in the payments team need to read the latest version of application secrets under secret/data/payments/*, but they must not be able to list other teams' secret names or read secret metadata. An operator proposes several ACL policy stanzas. Which policy best meets the requirement?
- A
path "secret/data/payments/*" { capabilities = ["read"] }
- B
path "secret/payments/*" { capabilities = ["read", "list"] }
- C
path "secret/metadata/payments/" { capabilities = ["read"] } path "secret/data/payments/" { capabilities = ["read"] }
- D
path "secret/data/" { capabilities = ["read"] } path "secret/metadata/" { capabilities = ["deny"] }
Show answer and explanation
Correct answer: A
Explanation
In Vault ACL policies, capabilities are granted against API paths, not just logical secret names. For the KV secrets engine version 2, reading a secret's value requires access to the mount/data/... path, while listing keys and reading metadata are handled through mount/metadata/.... To meet the scenario, the policy must grant only read on secret/data/payments/* and avoid granting list or metadata access. This follows Vault best practices of least privilege and understanding KV v2 path structure. Relevant HashiCorp documentation covers ACL policy syntax and KV v2 path semantics, including the distinction between /data/ and /metadata/ endpoints.
- A. Correct.
Correct. For KV v2, reading the secret value uses the
/data/API path. Grantingreadonsecret/data/payments/*allows the team to retrieve the latest version of secrets under thepaymentssubtree. Because nolistcapability is granted and no access tosecret/metadata/...is provided, the policy does not allow listing secret names or reading metadata. - B. Incorrect.
Incorrect. This uses a KV v1-style path and also grants
list, which would allow enumeration of paths where permitted. In KV v2, secret data access is controlled with the/data/path, notsecret/payments/*directly. This option reflects a common mistake when moving from KV v1 to KV v2. - C. Incorrect.
Incorrect. While the
readcapability onsecret/data/payments/*would allow reading the secret values, grantingreadonsecret/metadata/payments/*also allows reading metadata for those secrets, which the requirement explicitly forbids. Metadata access in KV v2 is separate from data access. - D. Incorrect.
Incorrect. This is overly broad because it grants read access to all secrets under
secret/data/*, including other teams' paths. Although the explicitdenyon metadata is valid and deny takes precedence in Vault ACL evaluation, this policy still violates least privilege by exposing all teams' secret data.