Azure Key Vault: Deploy, Access, Firewall, Defender for Key Vault

Key Vault: the place secrets are supposed to live

Authorisation: RBAC vs access policies

Key Vault authorisation models — RBAC is the SC-500 default; access policies show up only in 'migrate from legacy' questions

Feature	Azure RBAC (recommended)	Vault access policies (legacy)
Authorisation model	Azure Resource Manager role assignments at vault or item scope	Per-principal entry on the vault listing data-plane permissions
Granularity	Built-in and custom RBAC roles; scope to vault, key, secret, or certificate	Coarser — list of allowed actions per principal at vault level
PIM support	Yes — eligible/just-in-time assignment via Microsoft Entra PIM	No — assignments are standing
Audit + management	Standard Azure RBAC view, role assignment APIs, Privileged Access reports	Per-vault list with no unified directory or RBAC-aware tooling
Defender CSPM scoring	Higher CSPM secure score for vaults using RBAC	Lower CSPM secure score; flagged as a recommendation
Microsoft direction	Recommended and required for several modern integrations	Supported for backward compatibility, no new investment
Common roles to know	`Key Vault Administrator`, `Key Vault Secrets Officer`, `Key Vault Secrets User`, `Key Vault Crypto Officer`, `Key Vault Crypto User`, `Key Vault Certificates Officer`, `Key Vault Reader`	Get/List/Set/Delete on Secrets, Get/List/Update/Create on Keys, etc.

Network access patterns

A new Key Vault is reachable from the public internet by default. For production workloads, lock that down:

1. Public access disabled + Private Endpoint — the highest-assurance pattern. Vault is reachable only over a private IP in a customer virtual network, via private DNS. Requires private DNS zone privatelink.vaultcore.azure.net configured for the consuming VNets (and connected hubs).
2. Selected virtual networks + IP rules — vault firewall enforces VNet service endpoints and explicit public IP CIDRs. Lower assurance than Private Endpoint but sufficient for many.
3. Allow trusted Microsoft services — toggle that lets certain Azure first-party services (App Service Environment, Disk Encryption, Backup, etc.) reach the vault even when public access is disabled.

💡 The 'managed identity sees Key Vault from the internet' trap

A common exam trap: “Esme enabled a managed identity on App Service and granted it Key Vault Secrets User, but secrets requests return Forbidden from the Key Vault.” The reader is expected to spot that the vault has the firewall enabled with no allowance for the App Service outbound network.

The right answer depends on the App Service’s network configuration:

• If App Service has VNet integration → add the integration subnet to the vault’s selected virtual networks list (with Microsoft.KeyVault service endpoint on the subnet), or move the vault behind a Private Endpoint reachable from the integration subnet.
• If App Service has no VNet integration → its outbound traffic uses shared Azure IPs that you generally cannot allowlist by IP. Enabling ‘trusted Microsoft services’ is the documented bypass — App Service is on that list for Premium tier scenarios; for general App Service, VNet integration or Private Endpoint is the right answer.

The exam likes to test whether you can reason about identity + network together. Both must allow the request.

Data protection: soft delete + purge protection

Key Vault has two features that protect against accidental and malicious deletion:

• Soft delete — when a vault, key, secret, or certificate is deleted, it enters a “soft deleted” state for a configurable retention period (7–90 days, default 90 for new vaults). A privileged caller can recover the item during that period. Soft delete is mandatory for new vaults — you cannot disable it.
• Purge protection — when enabled, no one (not even a tenant admin) can purge a soft-deleted item before the retention period expires. Recovery is the only path forward. Purge protection is a one-way switch — once enabled, you cannot disable it. This is intentional: the protection only matters if it can’t be undone by the same insider you’re protecting against.

For regulated workloads, purge protection is almost always required. The combination of soft delete + purge protection means even a malicious admin can’t permanently destroy keys protecting encryption-at-rest until retention has elapsed — giving you time to detect and respond.

Key, secret, and certificate management

• Secrets — opaque binary values up to 25 KB. Versioned automatically. Each version has its own URI; an unversioned URI returns the current version. Expiry and “not before” times can be set; expired secrets fail retrieval. No native rotation — rotation is an external process (Logic App, Functions, or third-party automation) that creates a new version.
• Keys — cryptographic keys (RSA, EC, AES, OCT). Software- or HSM-protected (Premium tier). Used for envelope encryption (BYOK, customer-managed keys for Storage / SQL / Cosmos / etc.). Key rotation policies can auto-rotate keys at a defined cadence with no application change (apps reference the unversioned key URI). Defender CSPM flags long-lived keys without rotation policies.
• Certificates — managed X.509 certs with their private keys. Can be created via an integrated issuer (DigiCert, GlobalSign — needs publisher account configured) or imported. Auto-renewal is supported when configured with an integrated issuer. Each cert is also exposed as a key (for the private key) and a secret (for the full PFX) — relevant when granting permissions and when retrieving the cert from a workload.

Defender for Key Vault — threat protection

Defender for Key Vault is a Defender for Cloud workload protection plan that monitors Key Vault for:

• Unusual access patterns (volume, geography, identity)
• Suspicious application access (known-bad client IDs)
• Anomalous key/secret access by managed identities or service principals
• Defender XDR correlation with broader incidents (e.g. a compromised identity that then accessed Key Vault)

Alerts surface in Defender for Cloud and (when integrated) in Microsoft Sentinel for SOC response. The plan is per-subscription and per-resource billing.

Defender CSPM — secret scanning

Defender Cloud Security Posture Management (Defender CSPM) includes agentless secret scanning for plaintext secrets stored outside Key Vault:

• VM disks (looking for credential files, config files with embedded secrets)
• Storage accounts (config files, source backups, exposed connection strings)
• Code repositories (when Defender for DevOps is configured)

Found secrets are surfaced as Defender for Cloud recommendations with attack-path context — “this VM holds a plaintext SQL connection string and is internet-facing” — so you can prioritise remediation. The fix path is always: move the secret to Key Vault, replace the on-disk reference with a managed-identity-based retrieval.

Scenario: Esme deploys Northwind Bank’s payments-app Key Vault

Esme’s new payments app needs to store: a third-party payment-processor API key, the cryptographic key wrapping customer PII in the database, and the TLS certificate for the public API.

Her hardened deployment:

1. Create a Premium-tier Key Vault (kv-payments-prod-aue1) so keys can be HSM-protected. Soft delete on (mandatory), retention 90 days, purge protection ON (one-way — accepted).
2. Authorisation: Azure RBAC. Disable legacy access policies. Assign:
   • Esme + 2 senior security engineers: Key Vault Administrator via PIM-eligible (just-in-time).
   • Payments app’s user-assigned managed identity: Key Vault Secrets User (read secrets) and Key Vault Crypto User (use the wrapping key).
   • PKI ops team: Key Vault Certificates Officer (manage TLS cert renewal).
3. Network: Private Endpoint only. Public network access disabled. Private endpoint in the payments-app VNet; private DNS zone privatelink.vaultcore.azure.net linked to that VNet. App Service for the payments app has regional VNet integration, so it resolves the vault by private IP.
4. Key wrapping key. RSA 2048 HSM key, with a rotation policy rotating annually with a 30-day grace period (old version retained for 30 days post-rotation).
5. Certificate. Configured with DigiCert integrated issuer; auto-renew 30 days before expiry.
6. Defender for Key Vault: enabled via Defender for Cloud’s Key Vault plan on the subscription. Alerts routed to Sentinel via the Defender for Cloud connector. Slack-equivalent severity-high pager rules.
7. Defender CSPM: enabled on the subscription so secret scanning flags any plaintext leak in adjacent VMs or storage.

The vault is reachable only from the payments app’s VNet, only by PIM-active admins and the app’s MI, with HSM-protected keys, soft delete + purge protection, threat detection, and discovery of any plaintext-secret backsliding elsewhere in the subscription.

Key terms

Question

What is the difference between Key Vault soft delete and purge protection?

Click or press Enter to reveal answer

Answer

Soft delete: deleted vaults, keys, secrets, and certificates enter a recoverable state for the retention period (7–90 days). Mandatory for new vaults — cannot be disabled. Purge protection: prevents anyone from forcibly purging soft-deleted items before retention expires. One-way switch — once on, cannot be turned off. Combination prevents permanent destruction even by privileged insiders.

Click to flip back

Question

Which Key Vault built-in role grants read-only access to secrets?

Click or press Enter to reveal answer

Answer

`Key Vault Secrets User` (`4633458b-17de-408a-b874-0445c86b69e6`). Grants get and list on secret data. The corresponding 'officer' role (`Key Vault Secrets Officer`) grants create, get, list, delete, set, update, recover, and backup on secrets. Both are part of the RBAC authorisation model.

Click to flip back

Question

What does Defender for Key Vault detect?

Click or press Enter to reveal answer

Answer

Anomalous access to Key Vault — unusual volume, atypical geography, suspicious application access, anomalous key/secret retrieval by managed identities or service principals. A workload protection plan in Microsoft Defender for Cloud; alerts surface in Defender for Cloud and can route to Microsoft Sentinel.

Click to flip back

Question

What does Defender CSPM secret scanning find?

Click or press Enter to reveal answer

Answer

Plaintext secrets stored outside Key Vault — credentials embedded in VM disk files, in storage account blobs, in code repositories (when Defender for DevOps is connected). Surfaces them as Defender for Cloud recommendations with attack-path context to help prioritise migration to Key Vault.

Click to flip back

Question

When MUST you use Azure RBAC rather than legacy access policies for Key Vault?

Click or press Enter to reveal answer

Answer

When you need PIM-eligible just-in-time access on Key Vault roles, when CSPM secure-score recommendations are required, and as a general best practice for new vaults. Legacy access policies are still supported but receive no new feature investment; RBAC is the documented recommended model and required for granular scope (per-key or per-secret RBAC scope).

Click to flip back

Knowledge check

Knowledge Check

Esme at Northwind Bank wants her senior security engineers to hold the `Key Vault Administrator` role only when actively troubleshooting — not standing. She wants explicit approval and an audit trail per activation. Which approach fits best?

AAdd the engineers to a vault access policy with full permissionsBMake them PIM-eligible for the `Key Vault Administrator` Azure RBAC role at the vault scope, with approval and justification required on activationCCreate a custom Microsoft Entra role granting Key Vault data-plane permissionsDIssue them long-lived client secrets and rotate every 30 days

Check Answer

Knowledge Check

Ravi at Maple Genomics enables Key Vault firewall with no networks selected, and the App Service that holds his Foundry telemetry app starts getting `Forbidden` errors. The app has a managed identity with `Key Vault Secrets User`. What is the most likely cause and fix?

AThe managed identity needs to be re-enabled — toggle off and onBApp Service outbound traffic without VNet integration uses shared Azure IPs that aren't allowlisted by the vault firewall; enable Private Endpoint or VNet-integrate the App Service and allow that subnetCKey Vault must be moved to the same region as the App ServiceDHe needs to grant the `Reader` role at the resource group level

Check Answer

Knowledge Check

Asha at Aurora Health Service wants to be able to discover plaintext secrets — like SQL connection strings — sitting on VM disks across her subscriptions, so she can migrate them to Key Vault. Which capability should she enable?

ADefender for Key Vault threat protection planBDefender Cloud Security Posture Management (Defender CSPM) with secret scanningCMicrosoft Sentinel data connector for Key VaultDAzure Policy with the built-in 'Audit Key Vault' initiative

Check Answer

What’s next

Last module of Domain 1: Governance — Azure Policy (built-in and custom definitions), regulatory compliance evaluation in Defender for Cloud, resource locks, RBAC at scale, custom roles, overprivileged-access remediation, Azure Backup security features, and infrastructure-as-code security controls.