Create Vault policies →hardMultiple Choice

VA-003 Create Vault policies Practice Question

A security team needs to create a Vault policy that allows a token to read secrets under 'secret/data/finance/*' but explicitly denies access to 'secret/data/finance/salaries'. The policy must also allow listing all secrets under 'secret/data/finance/'. Which policy definition correctly achieves this?

⚠ Common exam trap

The trap here is thinking that a more specific path with allow capabilities overrides a wildcard deny, but in Vault deny always takes precedence regardless of path specificity.

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 "secret/data/finance/*" { capabilities = ["read", "list"] } path "secret/data/finance/salaries" { capabilities = ["deny"] }

Vault policies use a deny capability that overrides any other capability on a path. To deny access to a specific path while allowing a broader wildcard, you create a separate path block for the denied path with capabilities = ["deny"]. The order of blocks is irrelevant because Vault evaluates all matching paths and deny always wins. This is the correct and supported method.

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 "secret/data/finance/*" { capabilities = ["read", "list"] } path "secret/data/finance/salaries" { capabilities = ["read", "list"] allowed_parameters = { "deny" = [] } }
Why it's wrong here
The 'allowed_parameters' field is used to restrict which parameters can be provided in a request, not to deny access. Setting it to an empty list for 'deny' does not make sense. This policy would still allow read and list on salaries, violating the requirement. Vault does not use allowed_parameters for denial.
✗
path "secret/data/finance/*" { capabilities = ["read", "list"] } path "secret/data/finance/salaries" { capabilities = ["read"] }
Why it's wrong here
This policy grants read on the salaries path, which contradicts the requirement to deny access. Even though the wildcard path also grants read, the explicit read on salaries would allow access because there is no deny. The requirement is to deny access to salaries, so this policy fails.
✗
path "secret/data/finance/*" { capabilities = ["read", "list"] denied_parameters = ["salaries"] }
Why it's wrong here
Vault policies do not support a 'denied_parameters' field. Capabilities are the only way to control access at the path level. There is no parameter-level denial in Vault policies. This policy would be invalid and rejected by Vault. The correct approach is to use a separate path block with deny capability.
✓
path "secret/data/finance/*" { capabilities = ["read", "list"] } path "secret/data/finance/salaries" { capabilities = ["deny"] }
Why this is correct
This policy grants read and list on all paths under finance, then explicitly denies access to the salaries path. In Vault, a deny capability takes precedence over any other capability, even if a more specific path rule grants access. The order of path blocks does not matter; the deny rule overrides. This correctly restricts access to salaries while allowing everything else.

Go deeper

VA-003 Create Vault policies Practice Question

Why each option matters

Option-by-option breakdown

Related to this question