3.1 Deploy and Configure Key Vault
Key Takeaways
- Azure Key Vault vaults are multi-tenant secret/key/certificate stores; Managed HSM is a single-tenant FIPS 140-3 Level 3 HSM pool for high-value cryptographic keys only.
- Soft-delete is on by default for new vaults and cannot be turned off; retention is 7–90 days (default 90) and is fixed at vault creation.
- Purge protection is optional but strongly recommended for encryption keys; once enabled, soft-deleted vaults and objects cannot be purged until retention expires.
- Prefer the Azure RBAC permission model for new vaults; Standard encrypts with software-protected keys (FIPS 140 Level 1), Premium adds HSM-protected keys.
- Enable diagnostic logging (AuditEvent) to storage, Event Hubs, or Log Analytics so every data-plane and control-plane operation is attributable.
Why Key Vault Matters on SC-500
The SC-500 blueprint explicitly measures Secure secrets and keys by using Azure Key Vault: deploy Key Vault, configure settings, control access, harden networking, manage keys/secrets/certificates, scan for secrets with Defender CSPM, and implement Defender for Key Vault. This section focuses on deploy and configure—the foundation for the access and object-management sections that follow.
Azure Key Vault solves three related problems in one service family:
| Capability | What you store | Typical use |
|---|---|---|
| Secrets management | Passwords, connection strings, API tokens | App runtime config without hardcoding |
| Key management | Cryptographic keys (RSA, EC, HSM types) | Customer-managed keys (CMK), sign/encrypt/wrap |
| Certificate management | TLS/SSL certs and policies | App Service, App Gateway, Front Door HTTPS |
Authentication always uses Microsoft Entra ID. Authorization is separate for the control plane (manage the vault resource) and the data plane (use keys, secrets, and certificates).
Vault vs Managed HSM (High Level)
Key Vault exposes two resource types. Do not treat them as interchangeable on the exam.
| Aspect | Key Vault (vault) | Managed HSM |
|---|---|---|
| Tenancy | Multi-tenant service | Single-tenant HSM cluster dedicated to one customer |
| Objects | Keys, secrets, certificates | Cryptographic keys only |
| Endpoint | https://<name>.vault.azure.net | https://<name>.managedhsm.azure.net |
| Key protection | Software-protected (Standard/Premium) and HSM-protected (Premium) | HSM-protected only |
| Compliance focus | FIPS 140 Level 1 software; Premium HSM keys up to FIPS 140-3 Level 3 | FIPS 140-3 Level 3 validated HSMs |
| Access model | Azure RBAC (preferred) or vault access policies | Local RBAC / HSM-specific control isolated from subscription admins |
| Best fit | Most app secrets, certs, and common CMK scenarios | Highest-value keys, strict isolation, advanced compliance |
Exam trap: Managed HSM is not “Premium Key Vault with a different name.” Premium is still a multi-tenant vault that can host HSM-backed key types. Managed HSM is a separate pool with stronger isolation, different DNS, and keys-only storage.
When to choose vault: application secrets, certificates, broad Azure PaaS CMK integrations, cost-sensitive multi-app estates.
When to choose Managed HSM: regulatory mandates for single-tenant HSMs, cryptographic isolation from subscription Owners, high-value key material that must never leave HSM boundaries beyond approved operations.
SKUs: Standard vs Premium
For vaults (not Managed HSM):
| SKU | Key protection | Notes for SC-500 |
|---|---|---|
| Standard | Software-protected keys (FIPS 140 Level 1 modules) | Secrets and certificates work the same; keys are software-backed |
| Premium | Software-protected and HSM-protected keys (RSA-HSM, EC-HSM; FIPS 140-3 Level 3 on current HSM platform) | Required when the scenario demands HSM-backed keys inside a vault |
Secrets and certificates are available on both SKUs. The SKU decision is primarily about whether keys must be HSM-protected inside a vault. Managed HSM is the path when multi-tenant vault architecture is unacceptable.
Soft-Delete, Purge Protection, and Recovery
Soft-delete
Soft-delete is enabled by default on new vaults and cannot be disabled once on. After delete:
- The vault or object enters a soft-deleted state for a retention interval of 7–90 calendar days (default 90).
- During retention you can list, recover, or (if allowed) purge.
- After retention, Azure automatically purges the soft-deleted item.
- You cannot reuse a soft-deleted vault name until retention ends (same for object names inside a vault while a deleted object with that name exists).
Retention is configured only at vault creation and cannot be changed later. The same interval applies to soft-delete and purge-protection waiting periods.
Recovery notes:
- Soft-deleting a vault does not restore dependent artifacts such as Azure RBAC role assignments or Event Grid subscriptions when you recover the vault—you must recreate them.
- Object recovery (key, secret, certificate) restores that object in the vault; callers need recover permissions (for example Key Vault Administrator / Officers with recover rights, or legacy access-policy recover).
Purge protection
Purge protection is optional and off by default. When enabled:
- Soft-deleted vaults and objects cannot be purged until the retention period expires.
- Soft-deleted items remain recoverable throughout retention.
- You can enable purge protection only when soft-delete is already on (which it is for modern vaults).
Exam guidance: Enable purge protection for vaults holding customer-managed encryption keys used by Storage, SQL, Disk Encryption Sets, and similar services. Many Azure services effectively require purge protection so a compromised principal cannot permanently destroy CMKs and cause irreversible data loss.
| Setting | Default | Can disable? | SC-500 expectation |
|---|---|---|---|
| Soft-delete | On for new vaults | No (once enabled) | Always on; know 7–90 day window |
| Purge protection | Off | Can enable; then irreversible for that vault’s retention behavior | On for production CMK vaults |
Permission Model at Deploy Time: Prefer RBAC
When you create a vault you choose the permission model:
- Azure role-based access control (RBAC) — recommended for new deployments; default for newer API versions.
- Vault access policy — legacy data-plane model stored on the vault resource.
Control-plane management (create/delete vault, tags, network settings) always uses Azure RBAC on the resource. Switching an existing vault to RBAC invalidates all access policies until equivalent data-plane roles are assigned—plan cutovers carefully.
Key Vault Contributor manages the vault resource (control plane) but does not grant secret/key/certificate data access by itself. That separation is a frequent exam trap covered more deeply in section 3.2.
Networking Overview at Deploy
Default: firewall disabled—any network path can reach the data plane if Entra authentication and authorization succeed. Hardening options include:
- Firewall with IPv4 allow lists and virtual network service endpoints (
Microsoft.KeyVaulton subnets) - Private endpoints (Private Link) with optional Disable public access
- Trusted Microsoft services firewall bypass for listed first-party services that still need Entra + permissions
- Association with a Network Security Perimeter for perimeter-based PaaS isolation
Critical trap: Network rules apply to the data plane (*.vault.azure.net). Control-plane operations via Azure Resource Manager (management.azure.com)—including some ARM template secret deployments—are not blocked by the Key Vault firewall.
Logging and Diagnostics
After deploy, enable diagnostic settings so AuditEvent traffic is retained:
| Destination | Use case |
|---|---|
| Storage account | Long-term archive; container insights-logs-auditevent |
| Event Hubs | Streaming to SIEM / custom pipelines |
| Log Analytics | KQL investigation, Azure Monitor workbooks, Sentinel |
Logs capture caller IP, identity claims, operation names (SecretGet, KeySign, VaultDelete, and so on), result type, and request metadata. Logs typically appear within minutes. Secure the log store with storage/RBAC controls separate from who can use the vault.
Scenario: A security engineer deploys kv-prod-cmk for Storage account CMKs. Correct baseline: Premium (if HSM keys required) or Standard with software keys per policy, soft-delete 90 days, purge protection on, RBAC permission model, private endpoint + public access disabled for high sensitivity, diagnostics to Log Analytics, and Contributor limited to platform admins while Crypto Officer roles manage keys.
SC-500 Exam Traps (Deploy)
- Soft-delete cannot be turned off; purging requires a second privileged step unless purge protection blocks it.
- Retention is immutable after creation—choose 7–90 days carefully.
- Contributor ≠ data plane access; RBAC data roles are separate.
- Firewall does not stop ARM control-plane management of the vault resource.
- Managed HSM ≠ Premium SKU.
A team creates a new Azure Key Vault to store customer-managed keys for Azure Storage. Soft-delete is on with a 90-day retention. Which additional setting best prevents a malicious principal with purge rights from permanently destroying keys immediately after deletion?
Which statement correctly distinguishes Azure Key Vault Managed HSM from a Premium Key Vault?
You enable a Key Vault firewall that denies public access and allows only a private endpoint. An administrator can still update vault tags and networking via the Azure portal from an untrusted network. Why?
For a greenfield Key Vault deployment in 2026, which permission model should you select by default?