VA-003 Create Vault policies Practice Question
A platform team stores KV v2 secrets under the mount 'kv-prod'. They need a policy that lets an application read only the metadata (not the underlying secret values) for every path under 'kv-prod/apps/', including the ability to enumerate keys. Which policy stanza satisfies this requirement?
⚠ Common exam trap
The trap here is assuming the KV v1 path layout still applies, so the policy is written against the bare mount path instead of the metadata sub-path that KV v2 actually uses.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
path "kv-prod/metadata/apps/*" { capabilities = ["read", "list"] }
KV v2 splits each secret into a data endpoint that returns values and a metadata endpoint that returns version information. To inspect versions without exposing secret material, the policy must target the metadata path and include list so the prefix can be enumerated. Pointing the stanza at the data path leaks values, and omitting list breaks key discovery.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
path "kv-prod/data/apps/*" { capabilities = ["read", "list"] }
Why it's wrong here
The data endpoint on a KV v2 mount returns the actual secret key/value payload, so granting read here exposes the sensitive values the team explicitly wanted to withhold. It also does not provide metadata such as version numbers or deletion timestamps, so it fails the requirement on both the confidentiality and the functionality axis.
- ✗
path "kv-prod/metadata/apps/*" { capabilities = ["read"] }
Why it's wrong here
Read alone allows fetching metadata for a known key, but without the list capability the client cannot enumerate the keys under the prefix, which the team explicitly requires. The ACL check for a LIST request fails, so tooling that discovers secrets dynamically by listing the folder will break even though direct metadata reads succeed.
- ✓
path "kv-prod/metadata/apps/*" { capabilities = ["read", "list"] }
Why this is correct
On a KV v2 mount the metadata endpoint is reached at '<mount>/metadata/<path>'. Granting read and list on kv-prod/metadata/apps/* lets the client list keys and inspect version metadata such as created_time and current_version, while never touching the data endpoint that returns secret values. This is exactly the least-privilege requirement described.
- ✗
path "kv-prod/apps/*" { capabilities = ["read", "list"] }
Why it's wrong here
On a KV v2 mount the bare path prefix is not where the API routes requests; clients must target either /data/ or /metadata/. A policy written against kv-prod/apps/* will not match the ACL check performed for metadata reads, so the application receives permission denied even though the stanza looks reasonable to someone used to KV v1 paths.
Go deeper
Related to this question
About these practice questions
Courseiva writes every VA-003 question from scratch — 366 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official HashiCorp exam blueprint
This VA-003 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the VA-003 exam.