VA-003 Compare and configure secrets engines Practice Question
Exhibit
path "database/creds/my-role" {
capabilities = ["read"]
}
path "database/roles/*" {
capabilities = ["list"]
}
path "sys/mounts" {
capabilities = ["read"]
}Refer to the exhibit. An application uses this policy to access Vault. The application is able to read database credentials from `database/creds/my-role`. However, attempts to list all roles at `database/roles/` fail. What is the most likely cause?
⚠ Common exam trap
HashiCorp often tests the distinction between 'read' and 'list' capabilities, trapping candidates who assume that read access on sub-paths implies the ability to list the parent path.
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 allow the 'list' capability on the path `database/roles/`
The policy grants 'read' capability on `database/creds/my-role` but does not include the 'list' capability on `database/roles/`. In Vault, listing requires an explicit 'list' capability in the policy, even if 'read' is allowed on sub-paths. Without 'list', the API call to `LIST database/roles/` returns a permission denied error.
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 path `database/roles/` is not a valid path for listing roles
Why it's wrong here
'database/roles/' is the standard list path for database roles; a GET on it returns the role names. The failure stems from the policy lacking 'list' capability there. This path is valid whenever the database secrets engine is mounted at 'database/'.
- ✗
The database secrets engine is not enabled
Why it's wrong here
Reading credentials from 'database/creds/my-role' proves the database secrets engine is mounted and enabled; otherwise that path would return no handler. Enabling the engine is the fix when no database mount exists, not when credential generation already succeeds but listing fails.
- ✓
The policy does not allow the 'list' capability on the path `database/roles/`
Why this is correct
Reading credentials at `database/creds/my-role` requires only the `read` capability, which the policy grants. Listing `database/roles/` is a distinct operation requiring the `list` capability on that exact path; Vault denies it because no policy rule grants `list` there, regardless of `read` access elsewhere.
- ✗
The application needs the 'sudo' capability to list roles
Why it's wrong here
The 'sudo' capability grants access to root-protected paths, not list permission on ordinary paths. Listing requires the 'list' capability on 'database/roles/'. Sudo would be relevant for privileged operations such as managing root credentials or seal status, not enumerating roles.
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.