VA-003 Utilize Vault CLI and API Practice Question
Exhibit
path "secret/data/team/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "secret/data/team/admin" {
capabilities = ["deny"]
}Refer to the exhibit. A user with this policy attempts to read 'secret/data/team/admin'. What will happen?
⚠ Common exam trap
HashiCorp often tests the misconception that broader allow rules automatically grant access to all sub-paths, but the trap here is that an explicit deny on a more specific path always overrides the broader allow, and candidates mistakenly think sudo can bypass deny rules.
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
✓
Read fails because deny overrides the broader path.
Vault's policy evaluation uses a deny-by-default model where explicit deny rules override any allow rules. The policy first allows read on 'secret/data/team/*' but then explicitly denies read on 'secret/data/team/admin'. Since the deny rule is more specific and matches the exact path, it takes precedence, causing the read operation to fail.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Read succeeds because the first path allows read.
Why it's wrong here
Vault policies are deny-by-default and the most specific matching path wins, so a broader grant cannot override a narrower deny on secret/data/team/admin. It is tempting because path ordering in the policy document looks significant, but precedence is determined by path specificity, not by which stanza appears first.
- ✗
Read fails because the path does not exist.
Why it's wrong here
The 400-class failure here stems from policy evaluation, not from the secret being absent; a missing path returns 404 at read time, after authorisation passes. It is tempting because a nonexistent secret does produce an error, but the question asks what the policy itself causes.
- ✓
Read fails because deny overrides the broader path.
Why this is correct
A deny capability on `secret/data/team/admin` takes precedence over any broader `secret/data/team/*` grant, because Vault evaluates policies with deny winning regardless of path specificity or rule order. The read therefore fails, satisfying the stem's constraint that the narrower deny path overrides the wider allow.
- ✗
Read succeeds if the user also has sudo capability.
Why it's wrong here
Sudo grants access to privileged system paths such as sys/, not to arbitrary secret/ paths, and it cannot override a deny capability. It is tempting because sudo sounds like a universal privilege escalator, but in Vault it is a narrowly scoped capability for administrative endpoints.
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.