Azure Key Vault: access, network and recovery

Azure Key Vault is a managed store for secrets (passwords, connection strings), keys (for encryption and signing) and certificates, with Microsoft Entra authentication, auditing and recovery built in. The decision rule for exams: an app should read a secret at run time using a managed identity that holds a data-plane role such as Key Vault Secrets User, never a stored credential; control-plane roles manage the vault but do not read its contents; and soft delete plus purge protection, not backups, are what make a deleted object recoverable.

Four gates a request passes

Think of every call to a vault as passing four checks. Most exam questions fail at exactly one of them.

Gate 1: network

By default a new vault has its firewall disabled, so all networks can send requests to it. That does not make it open: callers still need to authenticate and be authorized (network security for Key Vault). When you enable the firewall you can allow IPv4 ranges, allow specific virtual network subnets through a service endpoint, or use a private endpoint and disable public access. The option “Allow trusted Microsoft services to bypass this firewall” lets listed first-party services through, and Learn states that this bypass still applies when public network access is disabled. Services not on that list, Azure DevOps being the documented example, are blocked and need a private endpoint. The firewall governs data-plane calls only; ARM template deployments of secrets use the control plane and are not blocked by it.

To choose between a service endpoint and a private endpoint, see private endpoint vs service endpoint.

Gates 2 and 3: identity and roles

Key Vault has two planes. The control plane (management.azure.com) creates and configures vaults. The data plane (the vault’s own URL) reads and writes secrets, keys and certificates. They are authorized separately (Azure RBAC for Key Vault).

Azure RBAC is the recommended model for data-plane access. Starting with API version 2026-02-01, new vaults default to Azure RBAC. Existing vaults keep their current model unless you change it, and access policies remain supported (access control default). Older control-plane API versions retire on February 27, 2027.

Two traps. First, Contributor on the vault resource is not data access under RBAC. Under the older access policy model, though, a user with Contributor on the control plane can grant themselves data-plane access by editing access policies, which is why Learn says to restrict that role tightly. Second, switching a vault to RBAC invalidates all its access policy permissions, which can cause an outage if equivalent roles are not assigned first.

Learn recommends one vault per application per environment, with roles assigned at vault scope. For how the identity itself is created, see managed identities vs service principals, and for how RBAC scopes work in general, Azure RBAC vs Entra roles.

Gate 4: lifecycle

Soft delete is on for new vaults and cannot be turned off once enabled. A deleted vault or object stays recoverable for a retention period of 7 to 90 days, default 90, set at creation and not changeable afterwards. Purging an object in the soft-deleted state needs a purge permission, for example the Key Vault Purge Operator role. Purge protection is optional and off by default: when on, nothing can be purged until the retention period ends, even by someone with purge rights (soft delete). Learn notes that most Azure services that use vault keys for encryption, Storage for example, require purge protection. A soft-deleted vault name cannot be reused until retention expires.

Secrets also have versions. Fetching a secret by name returns the current version; fetching by version returns that exact value.

Worked example: web app to vault

1. Create a vault kv-orders-prod with RBAC authorization and soft delete (default).
2. Store a secret SqlConnection.
3. Turn on the web app’s system-assigned managed identity.
4. Assign that identity Key Vault Secrets User at the vault scope.
5. Add an app setting whose value is @Microsoft.KeyVault(VaultName=kv-orders-prod;SecretName=SqlConnection).

The app now reads an ordinary environment variable. Without a version in the reference, App Service picks up a new secret version within 24 hours, because it refetches every 24 hours; any app configuration change restarts the app and refetches at once (Key Vault references). If the vault has a firewall, the app must reach it through a virtual network the vault allows, not through the app’s public outbound IPs. An unresolved reference shows up as the literal reference text, which is the symptom to recognise. For where the app itself runs, see App Service plans.

Which exams test this

How exam questions are built around Key Vault

• Remove the stored credential. If one option uses a managed identity and the others keep a secret in app settings, a pipeline variable or code, the identity option wins.
• Least privilege by verb. “Read a secret” is Secrets User. “Create and rotate secrets” is Secrets Officer. “Manage the vault” is Key Vault Contributor, which cannot read values. “See that a secret exists” is Reader.
• Recover versus protect. “Recover an accidentally deleted secret” is soft delete. “Nobody, including administrators, may permanently delete before retention ends” is purge protection.
• Layering. A vault with RBAC but open to every network is still a finding. Add a private endpoint or firewall.
• Throttling. Calling the vault on every request invites 429 responses; the documented limit for most secret operations is 4,000 per 10 seconds per vault per region, so cache values in the app (service limits).

Practice questions

Go deeper

• Azure RBAC for Key Vault data plane (built-in roles, scopes)
• Key Vault soft delete and purge protection
• Network security for Key Vault
• Key Vault references for App Service and Functions
• Related guides: Azure Policy vs RBAC vs locks, SAS tokens and stored access policies, Azure Functions triggers and bindings