This chapter covers Azure Key Vault, a critical service for securely storing and managing secrets, keys, and certificates in Azure. It is a core topic in the Compute Security domain of the AZ-500 exam, specifically under objective 2.3 (Secure data at rest and in transit). Approximately 10-15% of exam questions touch on Key Vault, covering topics such as access policies, firewall and network settings, soft-delete, purge protection, key rotation, and integration with other Azure services. Mastering Key Vault is essential for any Azure Security Engineer.
Jump to a section
Azure Key Vault is like a bank's safety deposit box system. The bank (Azure Key Vault) stores your valuables (secrets, keys, certificates) in individual boxes (vaults). You don't have direct access to the vault room; you must go through the bank teller (Azure AD authentication). The teller checks your ID (managed identity or service principal) and your permission slip (RBAC or access policy) before letting you access your box. Each box has a unique key (vault URI) and can only be opened by you or someone you explicitly authorize. The bank also has a special service (HSM) for ultra-secure items (hardware-protected keys). If you try to open someone else's box, the teller denies access (401 Unauthorized). The bank keeps an audit log of every access (diagnostic logs). You can also have the bank automatically handle your valuables (certificate auto-renewal) without ever seeing the private key. Importantly, the bank does not store the contents of your box in plain sight—everything is encrypted at rest (using a key encryption key or KEK). And just like you wouldn't write your safe combination on a sticky note, Azure Key Vault ensures secrets are never exposed in code or configuration files.
What is Azure Key Vault and Why Does It Exist?
Azure Key Vault is a cloud service for securely storing and accessing secrets (e.g., API keys, passwords, connection strings), cryptographic keys (e.g., AES, RSA), and certificates (X.509 v3). Its primary purpose is to centralize secret management, reducing the risk of secrets being exposed in source code, configuration files, or logs. Key Vault integrates with Azure AD for authentication and supports fine-grained access control via RBAC or access policies. It also provides hardware security module (HSM) backed keys for FIPS 140-2 Level 2 (standard) or Level 3 (premium) compliance.
How Does Key Vault Work Internally?
When an application needs a secret, it authenticates to Azure AD (using a managed identity, service principal, or user identity) and obtains an access token. The application then calls the Key Vault REST API (e.g., https://{vault-name}.vault.azure.net/secrets/{secret-name}?api-version=7.4) with the token. Key Vault validates the token (ensuring it's from a trusted tenant and has the correct audience) and checks the access policy or RBAC role to determine if the caller has permission to read the secret. If authorized, Key Vault decrypts the secret (which is encrypted at rest using a key encryption key) and returns it over HTTPS. The entire operation is logged to Azure Monitor and can be streamed to Event Hubs or Log Analytics.
Key Components, Values, Defaults, and Timers
- Vault Types: Two tiers—Standard (software-protected keys) and Premium (HSM-protected keys). Premium vaults support HSM-backed keys (RSA 2048, 3072, 4096; EC P-256, P-384, P-521; and symmetric keys). - Soft-Delete: Enabled by default (since 2020). Retains deleted vaults and objects for a configurable retention period (7 to 90 days, default 90). Soft-delete must be enabled to use purge protection. - Purge Protection: Optional. When enabled, soft-deleted vaults/objects cannot be purged until the retention period expires. Requires soft-delete to be enabled. - Access Control: Two models: - Vault Access Policies: Legacy, vault-level, granular permissions (e.g., Get, List, Set, Delete) per principal. Max 1024 access policies per vault. - RBAC: Newer, uses Azure roles (e.g., Key Vault Secrets User, Key Vault Crypto Officer) at vault or subscription level. Recommended for most scenarios. - Firewall and Network Rules: By default, Key Vault accepts traffic from all networks. You can restrict access to specific IP addresses, VNet service endpoints, or private endpoints. When firewall is enabled, deny all traffic by default. - Throttling: Key Vault has limits: 2000 operations per second per vault (for secrets and keys), 1000 for certificates. Throttling returns HTTP 429. - Key Rotation: Manual or automated via Event Grid and Azure Functions. Key Vault does not auto-rotate keys natively; you must implement a rotation policy. - Diagnostic Logs: Must be enabled to capture audit events (e.g., SecretGet, KeyBackup). Logs are sent to a Log Analytics workspace, storage account, or Event Hubs.
Configuration and Verification Commands
Create a vault:
az keyvault create --name "MyVault" --resource-group "MyRG" --location "eastus" --sku standardEnable soft-delete and purge protection:
az keyvault update --name "MyVault" --enable-soft-delete true --enable-purge-protection trueSet an access policy:
az keyvault set-policy --name "MyVault" --upn user@contoso.com --secret-permissions get listAdd a secret:
az keyvault secret set --vault-name "MyVault" --name "MySecret" --value "SuperSecret123"Retrieve a secret:
az keyvault secret show --vault-name "MyVault" --name "MySecret" --query "value" -o tsvEnable diagnostic logs:
az monitor diagnostic-settings create --name "kv-diag" --resource "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vault}" --workspace "{workspace-id}" --logs '[{"category":"AuditEvent","enabled":true}]'How Key Vault Interacts with Related Technologies
Azure App Service: Web apps can reference Key Vault secrets via app settings using the @Microsoft.KeyVault(SecretUri=...) syntax.
Azure DevOps: Use the Azure Key Vault task to download secrets during pipeline runs.
Azure Policy: Enforce Key Vault settings (e.g., soft-delete required) via built-in policies.
Azure Disk Encryption: Uses Key Vault to store disk encryption keys (BitLocker for Windows, DM-Crypt for Linux).
Azure SQL TDE: Uses Key Vault for Bring Your Own Key (BYOK) for Transparent Data Encryption.
Azure Information Protection: Uses Key Vault for tenant keys.
Event Grid: Can trigger on Key Vault events (e.g., secret near expiration) to invoke Azure Functions for rotation.
Security Best Practices
Always enable soft-delete and purge protection.
Use RBAC instead of access policies when possible.
Restrict network access using private endpoints or VNet service endpoints.
Use managed identities for applications instead of service principals or connection strings.
Enable diagnostic logs and monitor for suspicious activity.
Rotate keys and secrets regularly (automate with Event Grid).
Use HSM-backed keys for highest security (Premium tier).
Separate vaults by environment (dev, test, prod) and by application.
Create a Key Vault
Use the Azure portal, CLI, or PowerShell to create a Key Vault. Specify the subscription, resource group, name (globally unique), region, pricing tier (Standard or Premium), and retention period for soft-delete (default 90 days). Enable purge protection if required. The vault is created with a default access policy that grants the creator full permissions. After creation, you can configure network rules, diagnostic settings, and additional access policies.
Configure Access Control
Choose between vault access policies or RBAC. For access policies, add each principal (user, group, service principal) with specific permissions (e.g., Get, List, Set, Delete) for secrets, keys, and certificates. For RBAC, assign built-in roles like 'Key Vault Secrets User' (read secrets) or 'Key Vault Crypto Officer' (manage keys). RBAC is recommended for centralized management. Ensure least privilege—only grant necessary permissions.
Add Secrets, Keys, or Certificates
Secrets: Use the portal or CLI to add a secret (name-value pair). Keys: Generate or import RSA/EC keys. Certificates: Create self-signed or import CA-signed certificates. For certificates, you can define a policy that includes subject, SANs, key type, and lifetime action (e.g., auto-renewal). Private keys are generated inside Key Vault and never exported. Certificates can be stored as PFX or PEM.
Configure Networking and Firewall
By default, Key Vault accepts traffic from all networks. To restrict, enable the firewall and specify allowed IP addresses (CIDR ranges) or VNet service endpoints. For private connectivity, create a private endpoint (requires Private Link). When a firewall is enabled, all traffic is denied by default; only allowed sources can access the vault. This prevents data exfiltration and unauthorized access.
Enable Monitoring and Alerts
Enable diagnostic settings to stream audit events to Log Analytics, storage, or Event Hubs. Use Azure Monitor to create alerts for suspicious activities (e.g., multiple failed access attempts, secret retrieval from unusual locations). Set up alerts for key expiration (e.g., 30 days before expiry). Integrate with Azure Sentinel for advanced threat detection.
Enterprise Scenario 1: Web Application Secret Management
A large e-commerce company hosts a web app on Azure App Service that connects to a SQL database. Previously, the connection string was stored in the app settings, leading to accidental exposure in logs. They migrate to Key Vault: they create a vault, store the connection string as a secret, and enable a system-assigned managed identity for the web app. They grant the managed identity 'Key Vault Secrets User' role. In the app settings, they reference the secret using @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/DBConnString). The app now retrieves the secret at runtime without ever storing it in code or config. They also enable soft-delete and purge protection to prevent accidental deletion. Performance is fine—Key Vault handles thousands of requests per second. The biggest challenge was ensuring the managed identity had the correct RBAC role; initially they used access policies but migrated to RBAC for consistency.
Enterprise Scenario 2: BYOK for Azure SQL TDE
A financial institution requires control over encryption keys for their Azure SQL databases. They create a Premium Key Vault with HSM-backed RSA keys. They generate the key on-premises using their own HSM and transfer it to Key Vault using the Bring Your Own Key (BYOK) process (which involves a key exchange using Azure Key Vault's key import method). They then configure Azure SQL Transparent Data Encryption (TDE) to use the Key Vault key as the TDE protector. This gives them full control over key rotation and revocation. They must ensure the vault has a firewall enabled, allowing only the SQL server's IP and management IPs. They also set up alerts for key access and expiration. A common pitfall: if the Key Vault is deleted (even soft-deleted), the database becomes inaccessible. Hence, they enable purge protection and have a backup process.
Enterprise Scenario 3: Certificate Auto-Renewal for Internal PKI
A multinational corporation uses Key Vault to manage TLS certificates for internal services. They create a certificate policy with auto-renewal (enabled at 80% of the certificate lifetime). Key Vault automatically generates a new key pair and obtains a certificate from the configured CA (e.g., DigiCert or a private CA). The certificate is stored in Key Vault and can be deployed to Azure services (e.g., Application Gateway, CDN) via integration. They use Event Grid to trigger a notification when a certificate is near expiration (e.g., 30 days before) to alert the operations team. Misconfiguration: if the CA is unreachable during renewal, the certificate expires and services fail. They mitigate by setting a grace period and monitoring renewal failures.
AZ-500 Exam Focus on Azure Key Vault
Objective Codes: This topic maps to objective 2.3 (Secure data at rest and in transit) and also appears in 2.1 (Secure compute) and 2.2 (Secure storage). The exam expects you to know:
How to configure access control (access policies vs RBAC, when to use each)
Soft-delete and purge protection (default retention period, how to enable, implications)
Network security (firewall, service endpoints, private endpoints)
Key rotation and expiration (how to automate, what happens when a key expires)
Integration with Azure services (App Service, SQL, Disk Encryption, etc.)
Backup and restore of secrets/keys (az keyvault backup, restore)
Diagnostic logging (categories, how to enable, what events are logged)
Common Wrong Answers: 1. "Key Vault automatically rotates secrets." — FALSE. Key Vault does not rotate secrets automatically; you must implement rotation via Event Grid + Azure Functions. However, it can auto-renew certificates if configured. 2. "Access policies are the recommended access control method." — FALSE. RBAC is now recommended for most scenarios. Access policies are legacy but still supported. The exam may ask which is better. 3. "Soft-delete is optional and disabled by default." — FALSE. Since 2020, soft-delete is enabled by default on all new vaults. The exam may test that you cannot disable it after creation. 4. "Key Vault can store passwords up to 64 KB." — FALSE. Secrets are limited to 25 KB (UTF-8) for the value. Keys are limited to 2048 bytes for RSA public/private keys.
Specific Numbers and Terms:
Soft-delete retention: 7-90 days (default 90)
Max access policies per vault: 1024
Throttling limit: 2000 operations/second per vault (secrets/keys), 1000 for certificates
Secret size limit: 25 KB
Key types: RSA (2048, 3072, 4096), EC (P-256, P-384, P-521), symmetric (in Premium)
API version: 7.4 (current as of exam)
RBAC roles: Key Vault Administrator, Key Vault Secrets User, Key Vault Crypto Officer, etc.
Edge Cases:
If a vault is deleted with soft-delete enabled, it can be recovered within the retention period. After that, it is permanently deleted.
If purge protection is enabled, you cannot purge the vault until the retention period expires.
When using RBAC, access policies are ignored. If both are set, RBAC takes precedence.
Key Vault firewall does not block Azure services by default; you must explicitly allow trusted services.
How to Eliminate Wrong Answers: Understand the mechanism. For example, if a question asks about automatic secret rotation, remember that Key Vault has no built-in scheduler for secrets—only certificates can auto-renew. For access control, if the question mentions 'centralized management' or 'Azure Policy', RBAC is likely the answer. For network security, if the question says 'private IP only', private endpoint is needed.
Soft-delete is enabled by default on all new Key Vaults with a retention period of 90 days (configurable 7-90).
Purge protection prevents permanent deletion until the retention period expires; requires soft-delete enabled.
RBAC is the recommended access control model; access policies are legacy but still supported.
Key Vault does not auto-rotate secrets; only certificates can auto-renew via policy.
Secrets are limited to 25 KB; keys are limited to 2048 bytes for RSA public/private keys.
Throttling limit: 2000 operations per second per vault for secrets and keys, 1000 for certificates.
Firewall defaults to deny all; must explicitly allow IP ranges, VNet endpoints, or private endpoints.
Enable diagnostic logs (AuditEvent category) to capture all access attempts and operations.
Managed identities are the preferred authentication method for Azure services accessing Key Vault.
Key Vault Premium supports HSM-backed keys (FIPS 140-2 Level 3).
These come up on the exam all the time. Here's how to tell them apart.
Vault Access Policies
Legacy method, specific to Key Vault.
Granular permissions per principal (e.g., Get, List, Set).
Limited to 1024 policies per vault.
Cannot use Azure Policy to enforce access control.
Managing at scale is cumbersome (per-vault).
RBAC (Role-Based Access Control)
Modern method, consistent across Azure.
Uses built-in roles (e.g., Key Vault Secrets User).
No hard limit (inherits subscription limits).
Supports Azure Policy for compliance.
Centralized management via Azure AD and management groups.
Mistake
Key Vault automatically rotates secrets like passwords.
Correct
Key Vault does not automatically rotate secrets. Only certificates can be configured for auto-renewal. For secrets, you must implement a custom rotation solution using Event Grid and Azure Functions or another automation tool.
Mistake
Access policies are the only way to control access to Key Vault.
Correct
Key Vault supports two access control models: vault access policies (legacy) and RBAC (recommended). RBAC provides centralized management and is consistent with other Azure services. Access policies are still available but are being phased out.
Mistake
Soft-delete is optional and disabled by default.
Correct
Since 2020, soft-delete is enabled by default for all new Key Vaults. You cannot disable it after creation. The retention period is configurable from 7 to 90 days (default 90).
Mistake
Key Vault secrets can be any size up to 64 KB.
Correct
Secrets are limited to 25 KB (UTF-8) for the value. Keys have a size limit based on type (e.g., RSA 4096-bit public key is about 512 bytes). Certificates are limited by the total size of the PFX/PEM file (typically under 20 KB).
Mistake
Key Vault firewall blocks all traffic by default even from Azure services.
Correct
When the firewall is enabled, all traffic is denied by default. However, you can allow trusted Microsoft services (e.g., Azure App Service, Azure SQL) by enabling the 'Allow trusted Microsoft services' exception. This does not require explicit IP rules.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Soft-delete is enabled by default on new vaults. For existing vaults, you can enable it via CLI: `az keyvault update --name MyVault --enable-soft-delete true`. Purge protection can be enabled similarly: `az keyvault update --name MyVault --enable-purge-protection true`. Note: You cannot disable soft-delete once enabled. Purge protection requires soft-delete to be enabled.
Standard tier uses software-protected keys (FIPS 140-2 Level 2). Premium tier uses hardware security modules (HSMs) for key protection (FIPS 140-2 Level 3). Premium supports HSM-backed keys (RSA, EC, symmetric) and is required for BYOK. Premium costs more but provides higher security.
Yes. Use the 'Azure Key Vault' task in Azure Pipelines to download secrets from Key Vault. The task authenticates using a service principal or managed identity. You can also use variable groups linked to Key Vault for YAML pipelines.
Expired keys cannot be used for cryptographic operations (e.g., encrypt, decrypt). The key becomes disabled. You can manually enable it or rotate it. For certificates, if auto-renewal is configured, Key Vault attempts to renew before expiration. If renewal fails, the certificate expires and services using it will break.
You can use VNet service endpoints or private endpoints. For service endpoints, enable 'Microsoft.KeyVault' service endpoint on the subnet and add the subnet to the Key Vault firewall rules. For private endpoints, create a private endpoint in the VNet and link it to the Key Vault, then disable public access.
The maximum is 1024 access policies per vault. Each policy can have multiple permissions. If you need more, consider using RBAC instead.
For HSM-backed keys (Premium tier), the private key is non-exportable by design. For software-backed keys (Standard tier), you can export the key using `az keyvault key download` but only if it was importable (e.g., imported as PEM or PFX). Keys generated inside Key Vault are not exportable.
You've just covered Azure Key Vault — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?