Utilize Vault CLI and API →mediumMultiple ChoiceObjective-mapped

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
This is incorrect because even though there is a broad allow on 'secret/data/team/*', the more specific deny on 'secret/data/team/admin' takes precedence, causing the read to fail.
✗
Read fails because the path does not exist.
Why it's wrong here
This is incorrect because the path 'secret/data/team/admin' does exist; the failure is due to the explicit deny rule, not because the path is missing.
✓
Read fails because deny overrides the broader path.
Why this is correct
This is correct. Vault policy evaluation gives precedence to explicit denies over allows. Since there is an explicit deny on 'secret/data/team/admin', the read operation fails despite the broader allow.
✗
Read succeeds if the user also has sudo capability.
Why it's wrong here
This is incorrect. The sudo capability does not override an explicit deny statement. Sudo only allows operations that would otherwise be forbidden due to missing capabilities, but explicit denies always block access.

Go deeper

VA-003 Utilize Vault CLI and API Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question