HashiCorp Vault Associate (003) Question 58
Single answer2d Choose a Vault policy based on requirementsA security team wants to let an application read only one secret from a KV v2 secrets engine mounted at secret/. The secret is stored at secret/data/payments/api-key. The application must not be able to list other secrets, update the secret, or read secret metadata. Which Vault policy best meets these requirements?
- A
path "secret/data/payments/api-key" { capabilities = ["read"] }
- B
path "secret/payments/api-key" { capabilities = ["read"] }
- C
path "secret/data/payments/*" { capabilities = ["read", "list"] }
- D
path "secret/metadata/payments/api-key" { capabilities = ["read"] }
Show answer and explanation
Correct answer: A
Explanation
The key to this question is choosing a Vault policy path that matches the underlying API path used by the secrets engine while also enforcing least privilege. For KV v2, secret values are accessed under the data/ path and metadata is accessed under the metadata/ path. Therefore, a policy that permits only read on secret/data/payments/api-key is the correct choice. This grants the minimum capability needed for the application to retrieve exactly one secret and nothing more. Broad wildcards and extra capabilities such as list should be avoided unless explicitly required. This aligns with Vault best practices for policy design: grant the narrowest path scope and the fewest capabilities necessary. See HashiCorp Vault documentation for KV secrets engine version 2 API paths and Vault policy capabilities.
- A. Correct.
Correct. For KV v2, reading secret data requires policy access to the
data/API path, not just the mount path plus logical secret name. Granting onlyreadonsecret/data/payments/api-keyallows the application to read exactly that secret value and does not grant list, create, update, or metadata access. This is the most restrictive policy that satisfies the requirement. - B. Incorrect.
Incorrect. This path format is commonly confused with KV v1. In KV v2, the API path for secret data includes
/data/, sosecret/payments/api-keywill not match the read request for the secret. A candidate might choose this if they are thinking in terms of the CLI's simplified path syntax rather than the policy path Vault evaluates. - C. Incorrect.
Incorrect. Although this would allow reading the target secret, it is broader than required because it covers all secrets under
payments/and also grantslist. The scenario explicitly says the application must not be able to list other secrets or access more than one secret. This violates least-privilege policy design. - D. Incorrect.
Incorrect. In KV v2, the
metadata/path is for secret metadata operations, such as reading version metadata or listing keys in some contexts, not for reading the secret value itself. The requirement specifically says the application must not read metadata, so this path is both functionally wrong for the secret read and misaligned with the requirements.