VA-003 Create Vault policies Practice Question
A security administrator wants to create a policy that allows a service to renew its own token and list its own token capabilities, but not create new tokens. Which policy statements should be included?
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 "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["read"] }
It uses the correct endpoints and capabilities: update for renew-self and read for capabilities-self. Option B uses create for renew-self, which is incorrect (renew-self requires update). Option C uses update for capabilities-self, which is wrong (capabilities-self requires read). Option D uses non-self endpoints (renew and capabilities) which would allow renewing or checking capabilities of any token, granting broader privileges than intended.
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 "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["read"] }
Why this is correct
Renewing a token maps to the update capability on `auth/token/renew-self`, while listing capabilities requires read on `auth/token/capabilities-self`. Both paths are self-scoped, so the service acts only on its own token, satisfying the constraint that it must not create new tokens.
- ✗
path "auth/token/renew-self" { capabilities = ["create"] }; path "auth/token/lookup-self" { capabilities = ["read"] }
Why it's wrong here
Renewing a token is a write operation, so renew-self requires "update", not "create"; lookup-self correctly needs "read". The create capability is tempting because it governs token issuance, which is exactly what auth/token/create would need — but the stem explicitly forbids creating new tokens.
- ✗
path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["update"] }
Why it's wrong here
capabilities-self requires read, not update; update would permit modifying capability queries rather than merely listing them. It is tempting because renew-self correctly uses update, suggesting both statements share that capability, but the capabilities endpoint is read-only and the policy must reflect that.
- ✗
path "auth/token/renew" { capabilities = ["update"] }; path "auth/token/capabilities" { capabilities = ["read"] }
Why it's wrong here
These paths target renewing and reading capabilities of other tokens, requiring broader privileges than self-service. They are tempting because they mirror the self endpoints' names, but the correct policy uses auth/token/renew-self with update and auth/token/capabilities-self with read, granting only the service's own token.
Go deeper
Related to this question
About these practice questions
This VA-003 question is part of Courseiva's 366-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.