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. The permission model is a single vault-level setting, so a vault uses one model or the other; in Azure RBAC mode, access policies are ignored, which is why a migration needs matching role assignments created first. Azure RBAC is the recommended model and, from API version 2026-02-01, the default for new vaults. Under the access policy model, anyone with Contributor (or any role with vault write permission) can grant themselves data-plane access by editing the policies. 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?
