2.2.2. Access Control and Firewall Settings for Key Vault
💡 First Principle: Key Vault access has two independent gates that both have to pass — network reachability (can the request even reach the vault) and authorization (does the identity making the request have permission) — and a scenario question testing "why can't this app read its secret" could be pointing at either one.
The permission model decides how authorization works: vault access policies grant coarse-grained permissions per object type (keys, secrets, certificates) directly on the vault, while Azure RBAC uses the same role-assignment system as every other Azure resource, enabling fine-grained, auditable, and centrally-managed access. A vault uses one model at a time — mixing them is not supported and produces unpredictable results. Separately, firewall settings restrict which networks can reach the vault at all: public with exceptions, restricted to selected virtual networks, or fully private via a Private Endpoint (see 3.3.4).
⚠️ Exam Trap: Migrating a vault from access policies to Azure RBAC does not automatically recreate equivalent access — existing access policy grants don't translate into RBAC role assignments. Switching the permission model without separately assigning RBAC roles first will lock out everything that relied on the old access policies.
Reflection Question: An application can reach a Key Vault over the network (no firewall block) but still gets an authorization error retrieving a secret. Which of the two independent gates is the problem, and what would you check first?
