VA-003 Create Vault policies Practice Question
A developer has a policy that grants 'create' capability on path 'secret/data/team/*'. They successfully create a new secret using 'vault kv put secret/data/team/db', but when they try to update the same secret with new data, they get a permission denied error. What is the most likely cause?
⚠ Common exam trap
A common misconception in Vault is that 'kv put' is a single operation, when in fact Vault treats the first write as 'create' and subsequent writes as 'update', requiring separate capabilities in the policy.
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
✓
The policy does not include the 'update' capability, which is required for modifying existing secrets.
In Vault, the 'kv put' command performs a 'create' operation when the secret does not exist, but an 'update' operation when it does. The policy only grants 'create' capability on 'secret/data/team/*', which allows the initial write but not subsequent modifications. To update an existing secret, the policy must also include the 'update' capability on the same path, as Vault's ACL system enforces separate capabilities for creating and updating secrets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The developer does not have the 'create' capability on the parent path.
Why it's wrong here
The 'create' capability on secret/data/team/* already covers the child path; the failure is that updating an existing KV v2 secret requires 'update', not 'create'. Parent-path permissions are irrelevant because Vault matches the exact request path. It is tempting because Vault policies do inherit along path hierarchies, but that inheritance governs which paths are covered, not which operations are permitted.
- ✓
The policy does not include the 'update' capability, which is required for modifying existing secrets.
Why this is correct
Vault's key-value v2 secrets engine treats creation and modification as distinct operations. The 'create' capability permits the initial write to a new path, but updating an existing secret requires the separate 'update' capability, which the policy omits, causing the permission denied error.
- ✗
The policy needs the 'list' capability on the path.
Why it's wrong here
'list' governs enumerating keys under a path via LIST requests; it grants no write access to secret data. The update fails because KV v2 requires the 'update' capability to write a new version over an existing secret. It is tempting because list often accompanies read policies, but it would be correct when the task is discovering which secrets exist.
- ✗
The developer's token lacks the 'sudo' capability for updates.
Why it's wrong here
The 'sudo' capability only bypasses root-protected API endpoints such as sys/ paths; it plays no part in KV v2 data writes. The denial stems from the missing 'update' capability, since overwriting an existing secret version is an update operation. It is tempting because sudo appears in Vault policies, but it would be correct only for privileged system operations.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 366 original VA-003 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.