HashiCorp Vault Associate (003) Question 49
Single answer2b Describe Vault policy syntax: pathA team stores application secrets in a KV v2 secrets engine mounted at secret/. Developers should be able to read only the data for paths under apps/payments/, but they must not be able to view metadata for other applications or write any secrets. A Vault administrator is reviewing candidate policy stanzas and wants the one that correctly uses path syntax for this requirement. Which policy stanza should the administrator choose?
- A
path "secret/data/apps/payments/*" { capabilities = ["read"] }
- B
path "secret/apps/payments/*" { capabilities = ["read"] }
- C
path "secret/metadata/apps/payments/*" { capabilities = ["read"] }
- D
path "secret/data/apps/*" { capabilities = ["read", "list"] }
Show answer and explanation
Correct answer: A
Explanation
Vault policies use path blocks to match API paths and assign capabilities. For KV v2, this is especially important because the API path for secret values includes /data/, while metadata operations use /metadata/. A frequent real-world error is writing a policy against the mount-relative path, such as secret/apps/payments/, which does not match KV v2's actual API path structure. To allow reading only secret values under apps/payments/, the policy must target secret/data/apps/payments/ with the read capability. This follows HashiCorp Vault policy and KV v2 documentation, which distinguish data and metadata endpoints and require policy paths to align with the API path being authorized.
- A. Correct.
Correct. For KV v2, reading secret values uses the /data/ API path, so a policy must reference the full path including data. The stanza grants read on secret/data/apps/payments/*, which limits access to secrets under that subtree and does not grant write or list access. This matches the requirement to read only payment app secrets.
- B. Incorrect.
Incorrect. This is a common mistake caused by confusing the mount path with the underlying API path. In KV v2, policies are written against API paths such as secret/data/... and secret/metadata/..., not just the logical-looking path secret/apps/payments/*. This stanza would not grant the intended read access to KV v2 secret data.
- C. Incorrect.
Incorrect. In KV v2, the /metadata/ path is used for metadata operations such as listing and reading metadata, not the actual secret data values. Granting read on secret/metadata/apps/payments/* would not allow developers to read the secret contents from the data endpoint.
- D. Incorrect.
Incorrect. Although this uses the correct KV v2 /data/ prefix, it is too broad because it grants access to all applications under apps/, not just payments. It also includes list, which is unnecessary for the stated requirement and broadens access beyond read-only secret retrieval.