HashiCorp Vault Associate (003) Question 55
Single answer2d Choose a Vault policy based on requirementsA platform team uses Vault KV v2 at the path secret/ to store application configuration. Developers for the payments service must be able to read current secrets under secret/data/payments/*, but they must not be able to view metadata, list other secret names, or modify any values. Which Vault policy best meets these requirements while following least-privilege principles?
- A
path "secret/data/payments/*" { capabilities = ["read"] }
- B
path "secret/payments/*" { capabilities = ["read"] }
- C
path "secret/data/payments/" { capabilities = ["read", "list"] } path "secret/metadata/payments/" { capabilities = ["list"] }
- D
path "secret/data/payments/*" { capabilities = ["create", "read", "update"] }
Show answer and explanation
Correct answer: A
Explanation
The best choice is the policy that grants only read on secret/data/payments/*. In Vault, policy design should match both the secrets engine version and the exact operations required. For KV v2, secret data is accessed through the data path, while metadata and listing use the metadata path. If users should read secret values but not list keys or inspect metadata, do not grant list and do not include permissions on the metadata path. This follows Vault least-privilege best practices and reflects the KV v2 API structure documented by HashiCorp for policy pathing and capabilities.
- A. Correct.
Correct. For KV v2, reading secret values requires access to the
/data/API path, so a policy onsecret/data/payments/*with only thereadcapability allows developers to read the secret data without granting write access or listing capability. This aligns with the requirement to read current secrets only and not enumerate names or modify data. - B. Incorrect.
Incorrect. This path format is typical of KV v1-style thinking, but KV v2 policy paths must reference the API paths such as
/data/for secret values and/metadata/for metadata and listing. A policy onsecret/payments/*will not grant the needed access for a KV v2 mount. - C. Incorrect.
Incorrect. Although this would allow reading data, it also grants listing via the metadata path, which directly violates the requirement that developers must not be able to view metadata or list secret names. This is a common mistake when operators add
listfor convenience without considering information disclosure. - D. Incorrect.
Incorrect. This policy grants
createandupdate, which allows modifying secret values. That exceeds the stated requirement and violates least privilege. It would be appropriate for an application or operator that needs to write secrets, but not for read-only developer access.