This chapter covers Customer-Managed Keys (CMK) in Azure Key Vault, a critical security feature that allows you to control the encryption keys used to protect your data at rest. For the AZ-500 exam, this topic appears in approximately 10-15% of questions in the Compute Security domain (Objective 2.3). Mastery of CMK is essential because it directly impacts data sovereignty, compliance, and security posture. You will learn the exact mechanisms, configuration steps, and exam traps that differentiate a passing candidate from a failing one.
Jump to a section
Imagine you own a safety deposit box at a bank (Azure Key Vault). The bank provides a strong vault and security guards, but you alone hold the key to your box. To store an item (your data), you place it in the box and lock it with your key. The bank cannot open your box because they don't have your key. If you want to give someone else (an Azure service like Storage or SQL) access to the item, you lend them your key, but you can revoke that access at any time by changing the lock (rotating the key). The bank's management (Azure platform) handles the physical security of the vault, but you control access to your box. If you lose your key (delete the key from Key Vault), the box becomes permanently inaccessible — your data is gone forever. This is exactly how Customer-Managed Keys work: Azure Key Vault stores your key, Azure services use it for encryption/decryption via a secure envelope encryption mechanism, and you maintain full control, including the ability to revoke access, rotate keys, and audit usage.
What Are Customer-Managed Keys (CMK)?
Customer-Managed Keys (CMK) are encryption keys that you create, store, and manage in Azure Key Vault (AKV) or Azure Key Vault Managed HSM, and that you authorize Azure services to use for encrypting your data at rest. By default, Azure services use Microsoft-managed keys (platform-managed keys) to encrypt data, meaning Microsoft controls the key lifecycle. With CMK, you take ownership of the root key used in the encryption hierarchy, giving you control over key rotation, revocation, and auditing.
Why CMK Exists
CMK exists to meet compliance and regulatory requirements where organizations must control their own encryption keys. For example, GDPR, HIPAA, PCI-DSS, and FedRAMP often require that the data controller (you) maintain exclusive control over encryption keys. Additionally, CMK enables you to implement key rotation policies, revoke access immediately if a breach is suspected, and audit key usage via Azure Key Vault logs.
How CMK Works Internally: Envelope Encryption
Azure services do not directly use your CMK to encrypt every block of data. Instead, they use a technique called envelope encryption (also known as key wrapping). Here is the step-by-step mechanism:
Data Encryption Key (DEK): When you write data to an Azure service (e.g., Azure Storage), the service generates a symmetric Data Encryption Key (DEK) specific to that data. This DEK is used to encrypt the actual data blocks using AES-256.
Key Encryption Key (KEK): Your CMK stored in Key Vault acts as the Key Encryption Key (KEK). The service sends a request to Key Vault to wrap (encrypt) the DEK using your CMK. Key Vault performs the wrap operation using the RSA-OAEP algorithm (for RSA keys) or AES-GCM (for symmetric keys). The wrapped DEK is then stored alongside the encrypted data.
Decryption: When you read the data, the service sends the wrapped DEK to Key Vault with an unwrap request. Key Vault decrypts the DEK using your CMK and returns the plaintext DEK to the service. The service then uses the DEK to decrypt the data.
Key Vault Access: The service must have appropriate permissions in Key Vault to perform wrap and unwrap operations. This is granted via an access policy or RBAC role (Key Vault Crypto Service Encryption User).
Key Components and Defaults
Key Vault Types: Standard (software-protected keys) and Premium (HSM-protected keys). Premium uses FIPS 140-2 Level 2 validated HSMs. Managed HSM offers FIPS 140-2 Level 3.
Key Types: RSA (2048, 3072, 4096 bits) and EC (Elliptic Curve) keys. For CMK, RSA 2048 or higher is typical.
Key Operations: Only wrapKey, unwrapKey, getKey are needed for CMK. encrypt and decrypt are not used by services for envelope encryption.
Key Rotation: You can manually rotate keys or set up automatic rotation (in preview for Key Vault). When rotating, the old key remains valid for unwrapping existing DEKs, but new DEKs are wrapped with the new key.
Soft Delete and Purge Protection: Key Vault must have soft-delete enabled (default) and purge protection recommended to prevent accidental or malicious key deletion that would cause data loss.
Key Vault Firewall: By default, Key Vault denies access from all networks. You must configure firewall rules to allow trusted Azure services or specific IP ranges.
Configuration and Verification Commands
To create a key vault and key for CMK:
az keyvault create --name MyKV --resource-group MyRG --location eastus --enable-soft-delete true --enable-purge-protection true
az keyvault key create --vault-name MyKV --name MyCMK --protection software --kty RSA --size 2048To assign permissions to an Azure service (e.g., Storage account):
az keyvault set-policy --name MyKV --object-id <storage-account-principal-id> --key-permissions get wrapKey unwrapKeyTo enable CMK on a Storage account:
az storage account update --name mystorageaccount --resource-group MyRG --encryption-key-name MyCMK --encryption-key-source Microsoft.Keyvault --encryption-key-vault MyKVTo verify encryption settings:
az storage account show --name mystorageaccount --resource-group MyRG --query encryptionOutput:
{
"keySource": "Microsoft.Keyvault",
"keyVaultProperties": {
"keyName": "MyCMK",
"keyVaultUri": "https://MyKV.vault.azure.net/",
"keyVersion": "abc123..."
}
}Interaction with Related Technologies
Azure Disk Encryption: Uses BitLocker (Windows) or DM-Crypt (Linux) with KEK stored in Key Vault. The KEK wraps the DEK in an envelope encryption pattern.
Azure SQL Database TDE: Supports CMK via Azure Key Vault (Bring Your Own Key - BYOK). The TDE protector is an asymmetric key stored in Key Vault.
Azure Storage: Supports CMK for blob, file, queue, and table storage. Also supports double encryption with infrastructure encryption.
Azure Key Vault Managed HSM: For FIPS 140-2 Level 3 compliance, you can use Managed HSM instead of standard Key Vault.
Azure Policy: You can enforce CMK usage via Azure Policy (e.g., require CMK on Storage accounts).
Important Timers and Defaults
Key Vault Soft Delete Retention Period: Default 90 days (configurable 7-90). During this period, deleted keys can be recovered.
Key Rotation Period: No default. You define the schedule. Automatic rotation is in preview (check Azure updates).
Key Vault Access Policy Propagation: Changes are effective within a few minutes (not instantaneous).
Purge Protection: Once enabled, cannot be disabled. Prevents permanent deletion for the retention period.
Exam Traps
Trap: CMK means you manage the entire encryption stack. Reality: You only manage the KEK. The DEK is generated and managed by the Azure service.
Trap: Deleting a key from Key Vault immediately stops access. Reality: If the key is soft-deleted, it can be recovered within the retention period. If purged, data becomes permanently inaccessible.
Trap: Any Azure service can use any key. Reality: The service must have explicit permission (wrap/unwrap) on the key. Also, some services require the key to be in the same region.
Trap: CMK provides stronger encryption than Microsoft-managed keys. Reality: Both use AES-256. The difference is in key ownership and control, not cryptographic strength.
Trap: You must use a Premium Key Vault for CMK. Reality: Standard Key Vault supports CMK with software-protected keys. Premium adds HSM protection but is not required.
Compliance and Auditing
Enable Key Vault diagnostic settings to send logs to Log Analytics or Storage. Logs capture all key operations (wrap, unwrap, get, list, etc.). You can use Azure Monitor to set alerts for unauthorized access attempts or key revocation. CMK is often required for compliance frameworks like SOC 2, ISO 27001, and PCI DSS.
Create Key Vault and Key
First, you create a Key Vault in the same Azure region as the service that will use the CMK. Enable soft-delete and purge protection to prevent accidental key loss. Then generate a key (RSA 2048 recommended) within the vault. This key will serve as the Key Encryption Key (KEK). The key can be software-protected (Standard tier) or HSM-protected (Premium tier). Choose based on compliance requirements.
Grant Service Permissions
The Azure service (e.g., Storage account, SQL Server) needs an identity to access Key Vault. For most services, you use a system-assigned managed identity. You grant this identity the 'get', 'wrapKey', and 'unwrapKey' permissions on the key via an access policy or RBAC role. Without these permissions, the service cannot encrypt or decrypt data using the CMK.
Configure Service to Use CMK
In the service's encryption settings, select 'Customer-Managed Key' and specify the Key Vault URI and key name. The service will then use the CMK for envelope encryption. At this point, any new data written will be encrypted with a DEK that is wrapped by the CMK. Existing data remains encrypted with the previous key unless re-encrypted.
Monitor and Rotate Keys
Regularly rotate the CMK according to your security policy. When you create a new version of the key, the service automatically uses the new version for wrapping new DEKs. Old versions remain available to unwrap existing DEKs. Use Key Vault diagnostic logs to monitor key usage. Set up alerts for unusual activity, such as repeated unwrap failures.
Handle Key Revocation or Deletion
If you suspect a key compromise, you can revoke access by removing the service's permissions or disabling the key. This immediately prevents the service from encrypting or decrypting data. However, existing encrypted data becomes inaccessible unless the key is restored. If you delete the key (soft-delete), you have a retention period to recover it. After purge, data is permanently lost.
Scenario 1: Financial Services Compliance
A bank must comply with PCI DSS, which requires that they control encryption keys for cardholder data. They deploy Azure SQL Database with Transparent Data Encryption (TDE) using CMK from a Premium Key Vault with HSM-backed keys. The key is rotated every 90 days. The bank enables Key Vault diagnostic logs and sends them to a SIEM for real-time monitoring. They also use Azure Policy to enforce CMK on all SQL servers. A common mistake is forgetting to grant the SQL server's managed identity access to Key Vault, causing TDE to fail. The bank mitigates this by using RBAC (Key Vault Crypto Service Encryption User) instead of access policies, which simplifies management across multiple subscriptions.
Scenario 2: Healthcare Data Storage
A healthcare provider stores patient records in Azure Blob Storage. They require CMK to meet HIPAA regulations. They configure the storage account to use a CMK stored in a Key Vault with soft-delete and purge protection enabled. They set up automatic key rotation every 6 months. A challenge is ensuring that backup and disaster recovery scenarios also use the same key. They use Azure Backup with CMK support and store the key in a secondary Key Vault in a paired region. When a key is accidentally disabled during a test, all blob data becomes inaccessible. The provider learns to use Azure Policy to prevent disabling keys without proper authorization.
Scenario 3: Multi-tenant SaaS Application
An ISV runs a multi-tenant SaaS application on Azure Kubernetes Service (AKS). They use Azure Disk Encryption with CMK to encrypt each tenant's persistent volumes. They create a separate Key Vault per tenant to isolate keys. Each AKS node has a managed identity that can only access its tenant's Key Vault. They use Azure Key Vault Provider for Secrets Store CSI Driver to mount keys as volumes. Performance is a concern because every disk I/O involves a call to Key Vault for DEK unwrapping. They mitigate by caching DEKs in memory for a short period. A misconfiguration occurs when the CSI driver's service principal lacks the 'unwrapKey' permission, causing pods to fail to start. They implement a validation script that checks permissions before deployment.
Exam Objective Coverage
This topic maps to AZ-500 Objective 2.3: "Configure security for compute workloads," specifically the subtopic "Manage keys for encryption at rest." Expect 1-3 questions directly on CMK, plus questions that involve CMK as part of broader scenarios (e.g., data protection, compliance).
Common Wrong Answers and Why Candidates Choose Them
"CMK uses the customer's key to encrypt every block of data directly." Candidates think the key is used for bulk encryption. Reality: Envelope encryption uses the CMK only to wrap/unwrap DEKs. The DEK does the actual encryption.
"You must use a Premium Key Vault for CMK." Candidates assume HSM protection is required. Reality: Standard Key Vault supports CMK. Premium is optional but recommended for compliance.
"Deleting a CMK immediately makes data inaccessible." Candidates think deletion is instantaneous. Reality: Soft-delete allows recovery within 90 days. Only after purge is data lost.
"Any Azure service can use any CMK without special setup." Candidates forget that the service needs a managed identity and Key Vault permissions. The service must be explicitly authorized.
Specific Numbers and Terms That Appear on the Exam
RSA key sizes: 2048, 3072, 4096. 2048 is the default.
Key operations: wrapKey, unwrapKey, get. Not encrypt/decrypt.
Soft-delete retention: 90 days default, configurable 7-90.
Envelope encryption: The term itself is tested.
KEK and DEK: Know the acronyms.
Azure Policy: 'Deny' effect to enforce CMK.
RBAC role: Key Vault Crypto Service Encryption User.
Edge Cases and Exceptions
Cross-region scenarios: Key Vault and the Azure service must be in the same region for CMK to work. Exception: Some services like Azure Disk Encryption allow cross-region keys? No, they must be same region.
Double encryption: Azure Storage supports infrastructure encryption (using platform-managed key) in addition to CMK. This is a separate layer.
Key rotation impact: Rotating the key does not re-encrypt existing data. Only new writes use the new key version.
Managed HSM: For FIPS 140-2 Level 3, use Managed HSM instead of Key Vault. The exam may ask about the difference.
How to Eliminate Wrong Answers
If an answer says the customer manages the entire encryption process, eliminate it — the service still generates and manages DEKs.
If an answer says CMK provides stronger encryption, eliminate it — both use AES-256.
If an answer says you can use any key from any vault, eliminate it — region and permissions matter.
If an answer says deleting the key immediately stops access, check for soft-delete mention. If soft-delete is enabled, data is still recoverable.
CMK uses envelope encryption: a DEK encrypts data, and the CMK (KEK) wraps the DEK.
The Azure service must have 'get', 'wrapKey', and 'unwrapKey' permissions on the CMK.
Key Vault and the Azure service must be in the same Azure region.
Soft-delete (default 90-day retention) and purge protection are critical to prevent permanent data loss.
Rotating the CMK creates a new key version; old versions remain available to unwrap existing DEKs.
CMK does not change the encryption algorithm (AES-256); it only changes who controls the root key.
Use Azure Policy to enforce CMK on supported services (e.g., Storage, SQL, Disk Encryption).
These come up on the exam all the time. Here's how to tell them apart.
Customer-Managed Keys (CMK)
You create and manage the key in Azure Key Vault.
You control key rotation, revocation, and auditing.
Required for compliance (GDPR, HIPAA, etc.).
Costs extra for Key Vault operations and storage.
Risk of data loss if key is deleted/purged.
Microsoft-Managed Keys (MMK)
Microsoft generates and manages the key internally.
No customer control; key lifecycle is opaque.
Suitable for most scenarios without compliance needs.
No additional cost for key management.
No risk of data loss from key deletion; Microsoft manages backup.
Mistake
CMK means the customer manages the entire encryption lifecycle, including DEKs.
Correct
The customer only manages the Key Encryption Key (KEK). The Azure service generates and manages Data Encryption Keys (DEKs) internally. The KEK is used only to wrap/unwrap DEKs via envelope encryption.
Mistake
You must use a Premium Key Vault (HSM-backed) to use CMK.
Correct
CMK works with both Standard (software-protected) and Premium (HSM-protected) Key Vaults. Premium is only required if you need FIPS 140-2 Level 2+ validation or higher assurance.
Mistake
Deleting a CMK from Key Vault immediately makes all encrypted data inaccessible.
Correct
If soft-delete is enabled (default), the key is retained for 90 days and can be recovered. Data becomes inaccessible only after the key is purged (permanently deleted).
Mistake
CMK uses the customer's key to directly encrypt each block of data.
Correct
Direct encryption would be inefficient. Instead, envelope encryption is used: a DEK encrypts data, and the DEK is wrapped by the CMK. The CMK is never directly exposed to the data.
Mistake
Any Azure service can automatically use any CMK without configuration.
Correct
Each service must be explicitly granted permissions (get, wrapKey, unwrapKey) on the key via an access policy or RBAC. The service also needs a managed identity to authenticate to Key Vault.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CMK (Customer-Managed Key) is a key generated and stored in Azure Key Vault that you control. BYOK (Bring Your Own Key) is a key you generate on-premises and import into Key Vault. Both are CMK in the sense that you manage the key, but BYOK involves importing an existing key. The exam may use CMK broadly to include both.
Yes, you can grant multiple services (e.g., Storage account, SQL Server, Disk Encryption) access to the same CMK. However, for security isolation, it's recommended to use separate keys per service or per environment.
Disabling the key immediately prevents any service from wrapping or unwrapping DEKs. This means new data cannot be encrypted, and existing encrypted data cannot be read. The data becomes inaccessible until the key is re-enabled.
Yes, Azure Key Vault supports automatic key rotation (currently in preview). You can set a rotation policy (e.g., rotate every 90 days). When a new key version is created, services automatically use it for new DEKs. Old versions remain for unwrapping.
No, only services that support CMK. Major ones include Azure Storage, Azure SQL Database, Azure Disk Encryption, Azure Cosmos DB, Azure Kubernetes Service (for etcd encryption), and Azure Data Factory. Always check service documentation.
Standard uses software-protected keys (FIPS 140-2 Level 1). Premium uses HSM-protected keys (FIPS 140-2 Level 2). Managed HSM offers Level 3. For most compliance needs, Premium is sufficient. Standard is cheaper but less secure.
No, the Key Vault must be in the same region as the Azure service that uses the CMK. This is a hard requirement. Cross-region CMK is not supported.
You've just covered Customer-Managed Keys (CMK) in Key Vault — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?