A token carries two policies:
# policy team-rw
path "secret/data/team/*" {
capabilities = ["create", "read", "update"]
}
# policy prod-ro
path "secret/data/team/+/prod" {
capabilities = ["read"]
}
What happens when the token writes to secret/data/team/billing/prod?
AIt succeeds, because Vault unions create, read and update from both matching paths
BIt is denied, because the + path is the higher-priority match and allows only read
CIt succeeds, because a path ending in a * glob outranks a path with a + segment
DIt succeeds, because the policy attached to the token first takes precedence
Show the answer and why
AIt succeeds, because Vault unions create, read and update from both matching paths
Incorrect
Vault unions capabilities only when the same pattern appears in several policies; for different patterns it takes the highest-priority match.
BIt is denied, because the + path is the higher-priority match and allows only read
Correct
Both wildcards start at the same place, and a pattern ending in * ranks below one that does not, so only prod-ro's rule applies.
CIt succeeds, because a path ending in a * glob outranks a path with a + segment
Incorrect
The priority rules work the other way: a pattern that ends in * is lower priority than one that does not.
DIt succeeds, because the policy attached to the token first takes precedence
Incorrect
The order in which policies are attached plays no part in matching.
With several matching patterns, Vault picks one by its priority rules: earlier wildcards, a trailing *, more + segments and shorter paths all rank lower. Capabilities are merged only for identical patterns.
Every user's entity carries the metadata key team, for example team=payments. One policy, attached to all users, must let each of them read secrets under secret/data/teams/<their team>/ on a KV v2 mount. Which policy path does it?
A platform team's policy must allow its members to enable a secrets engine at db/ and nothing else in Vault's configuration. Which path does the policy name?
Adb/*
Bsys/mounts/db
Csys/auth/db
Dsys/policy/db
Show the answer and why
Adb/*
Incorrect
db/* covers requests to the engine once it exists, not the request that enables it.
Bsys/mounts/db
Correct
Secrets engines are enabled through sys/mounts/<path>, and every action, internal configuration included, has a path a policy can name.
Csys/auth/db
Incorrect
sys/auth/<path> enables auth methods, not secrets engines.
Dsys/policy/db
Incorrect
sys/policy stores ACL policies.
Even core configuration lives under sys/, so policies control it the same way they control secrets.