HashiCorp Vault Associate (003) Question 53
Single answer2c Describe Vault policy syntax: capabilitiesYour team stores application credentials in the KV v2 secrets engine mounted at secret/. A developer should be able to read the current value of secret/data/payments/api and view metadata for version history at secret/metadata/payments/api, but must not be able to create, update, or delete secrets. Which policy stanza best meets this requirement?
- A
path "secret/data/payments/api" { capabilities = ["read"] } path "secret/metadata/payments/api" { capabilities = ["read"] }
- B
path "secret/payments/api" { capabilities = ["read", "list"] }
- C
path "secret/data/payments/api" { capabilities = ["create", "read"] } path "secret/metadata/payments/api" { capabilities = ["list"] }
- D
path "secret/data/payments/" { capabilities = ["read", "update"] } path "secret/metadata/payments/" { capabilities = ["read"] }
Show answer and explanation
Correct answer: A
Explanation
Vault policies are path-based and use capabilities such as create, read, update, delete, list, and sudo to control what operations a token can perform. In real environments, the most common mistake is granting capabilities on the wrong path, especially with KV v2. KV v2 exposes secret data under mount/data/... and metadata under mount/metadata/..., so policies must reference those API paths rather than the simpler logical path often used at the CLI. Here, the requirement is strictly read-only access to one secret's value and its metadata, so read on both exact paths is the least-privilege solution. This aligns with HashiCorp's policy syntax and KV v2 access patterns documented in Vault policy and KV secrets engine documentation.
- A. Correct.
Correct. For KV v2, reading a secret's current value uses the
/data/API path, and reading metadata such as version information uses the/metadata/API path. Thereadcapability is sufficient for both of these read-only operations. This grants the developer access to the secret value and its metadata without allowing writes or deletes. - B. Incorrect.
Incorrect. This uses a KV v1-style path and does not account for KV v2's
/data/and/metadata/path structure. Even thoughreadandlistsound plausible, the path itself is wrong for the requested KV v2 operations, so the policy would not correctly authorize the developer's access. - C. Incorrect.
Incorrect.
createwould allow writing a new secret if one does not already exist, which violates the requirement that the developer must not be able to create or update secrets. Also,liston the exact metadata path is not the same asreadfor viewing that secret's metadata details; the requirement is to view metadata for that specific secret, not list children under a prefix. - D. Incorrect.
Incorrect.
updateallows modifying existing data, which is explicitly prohibited. The wildcard path is broader than required and grants access to all secrets underpayments/, not justpayments/api. Althoughreadon the metadata path is appropriate, the addedupdateand broader scope make this policy too permissive.