VA-003 Assess Vault tokens Practice Question
A DevOps engineer needs to create a token that can only read secrets under the path 'secret/engineering'. What is the recommended approach?
⚠ Common exam trap
In Vault exams, a common trap is confusing time-based restrictions with proper policy-based access control. TTL limits duration but does not restrict which paths a token can access; a policy is required for that.
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
✓
Create a policy that allows read on secret/engineering/* and attach it to the token
Vault's recommended approach for granting least-privilege access is to create a policy that explicitly defines the allowed actions and paths, then attach that policy to the token. A policy with `path "secret/engineering/*" { capabilities = ["read"] }` ensures the token can only read secrets under that specific path, adhering to the principle of least privilege.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a token with a short TTL so it expires quickly
Why it's wrong here
A short TTL only limits how long the token lives; it does not restrict which paths the token may read, so secret/engineering is not enforced. It is tempting because short TTLs are a genuine Vault hardening measure that reduces exposure from leaked tokens, and would be correct where the requirement is limiting credential lifetime rather than scoping access.
- ✗
Create a token with the default policy only
Why it's wrong here
The default policy grants broad capabilities across many paths, so it cannot confine the token to reading secret/engineering. It is tempting because the default policy is genuinely attached to tokens for general-purpose access, and would be the right choice when a token needs ordinary self-management and broad read access rather than path-scoped permissions.
- ✗
Use the root token and restrict usage with a low TTL
Why it's wrong here
A root token carries unrestricted privileges; a low TTL shortens its life but never narrows its scope to secret/engineering, so any read during that window remains over-permissive. It is tempting because root tokens are legitimately used for initial setup and emergency recovery, where short-lived, tightly controlled usage is the accepted practise.
- ✓
Create a policy that allows read on secret/engineering/* and attach it to the token
Why this is correct
A least-privilege policy granting read on secret/engineering/* restricts the token to exactly that path subtree, then attaching it to the token scopes access accordingly. This satisfies the read-only, single-path constraint without granting broader capabilities elsewhere in the secrets engine.
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.