VA-003 KV v1 path structure Practice Question
A company uses Vault's Kubernetes authentication method to provide secrets to pods. Pods in the 'production' namespace need to read secrets from the path 'secret/data/app/prod'. The administrator has created a Vault role that maps the service account to a policy with capabilities ['read', 'list'] on path 'secret/data/app/*'. However, pods report 'permission denied' when trying to read the secrets. The administrator verifies that the service account has the correct Vault role attached and that the Vault token is being used correctly. What is the most likely cause?
⚠ Common exam trap
HashiCorp Vault often tests the distinction between KV v1 and KV v2 path structures, trapping candidates who assume all 'secret' mounts use the same path format without checking the engine version.
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 Vault mount for 'secret' is KV v1, so the path should be 'secret/app/prod' without 'data'.
The most likely cause is that the Vault mount for 'secret' is using KV v1, which does not use the 'data' segment in the path. The policy is written with 'secret/data/app/*' (KV v2 path), but because the mount is KV v1, the actual path is 'secret/app/prod'. This path mismatch leads to 'permission denied' because the policy does not apply to the correct path.
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 Vault mount for 'secret' is KV v1, so the path should be 'secret/app/prod' without 'data'.
Why this is correct
KV v2 inserts a mandatory `data/` segment between the mount and the secret path, so a policy written for the v2 layout cannot match a v1 mount. The role's policy grants `secret/data/app/*`, which never matches the actual v1 path `secret/app/prod`, producing the permission denied. Correcting the path to omit `data` resolves it.
- ✗
The policy should include the 'sudo' capability.
Why it's wrong here
Incorrect: Sudo is not required for reading secrets; it is used for privileged operations like path creation.
- ✗
The pods are using a token with insufficient TTL.
Why it's wrong here
Token TTL governs how long a token remains valid, not which paths it may access; an expired token yields a different error, and the pods authenticate successfully. It is tempting because short TTLs do cause authentication failures, but that scenario involves token expiry, not a policy path mismatch.
- ✗
The Vault role is not bound to the correct Kubernetes namespace.
Why it's wrong here
Namespace binding is verified as correct in the stem, so it cannot be the cause. It is tempting because a role bound to the wrong namespace or service account does produce permission denied, and that would be the answer if the binding had not already been confirmed.
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.