This chapter covers Customer-Managed Keys (CMK) for Azure Storage encryption, a critical topic for the AZ-104 exam. CMK allows you to control the encryption keys used to protect data at rest in Azure Storage accounts, providing an additional layer of security and compliance. Approximately 10-15% of exam questions in the Storage domain touch on encryption, key management, and Azure Key Vault integration. Understanding CMK is essential for scenarios requiring regulatory compliance, separation of duties, or key rotation policies.
Jump to a section
Imagine a bank vault where you store important documents. Normally, the bank provides a standard lockbox with a key they control. But with Customer-Managed Keys (CMK), you bring your own lock and key. You give the bank a copy of your key (the CMK stored in Azure Key Vault) and they use it to lock your box. Whenever you need to access your documents, the bank requests your permission to use the key, and only then can they unlock the box. If you revoke that permission, the bank can no longer open your box, even though they physically hold it. This is different from Microsoft-managed keys, where the bank holds the only key and can access your documents at any time. The bank never sees your original key—only a wrapped version that they can use temporarily. You can also rotate your lock periodically, and the bank re-locks your documents with the new key. The key itself never leaves your control; it stays securely in your own key cabinet (Azure Key Vault).
What is Customer-Managed Key (CMK) for Azure Storage?
Azure Storage automatically encrypts all data at rest using Storage Service Encryption (SSE), which uses 256-bit AES encryption. By default, Microsoft manages the encryption keys. However, you can choose to use your own keys – these are Customer-Managed Keys (CMK). With CMK, you control the key lifecycle, including rotation, revocation, and auditing. CMK is implemented via Azure Key Vault, where you store the key, and Azure Storage uses a Managed Identity to access the key for encryption and decryption operations.
Why CMK Exists
CMK addresses several requirements:
Regulatory Compliance: Some industries (e.g., finance, healthcare) require customers to control encryption keys.
Separation of Duties: The key custodian (security team) can be separate from the storage administrator.
Key Rotation: You can enforce custom rotation policies (e.g., every 90 days) independent of Microsoft's schedule.
Revocation: If you suspect a compromise, you can disable access to the key, effectively rendering the data inaccessible.
How CMK Works Internally
The process involves three main components: Azure Storage account, Azure Key Vault (AKV), and a Managed Identity (system-assigned or user-assigned). Here's the step-by-step mechanism:
Key Creation: You create or import a key into AKV. The key must be an RSA key of size 2048, 3072, or 4096 bits. Azure Storage supports both software-protected and HSM-protected keys.
Enable CMK on Storage Account: In the storage account's Encryption blade, you select "Use your own key" and specify the Key Vault URI and key version. You must also enable the storage account's system-assigned managed identity (or specify a user-assigned identity).
Grant Permissions: The managed identity must be granted at least Get, Unwrap Key, and Wrap Key permissions on the key in AKV. This is done via an access policy in Key Vault. Without these permissions, encryption/decryption will fail.
Encryption Process: When data is written to the storage account, Azure Storage uses the managed identity to call AKV's Wrap Key operation. This wraps the Data Encryption Key (DEK) – a symmetric key generated by Azure Storage – with the Customer-Managed Key (KEK) stored in AKV. The wrapped DEK is stored alongside the encrypted data.
Decryption Process: When data is read, Azure Storage calls AKV's Unwrap Key operation to unwrap the DEK using the KEK. The unwrapped DEK is then used to decrypt the data. The KEK never leaves AKV; only the wrap/unwrap operations are performed.
Key Rotation: When you rotate the key in AKV (create a new version), Azure Storage automatically detects the new version and re-wraps the DEKs with the new key. This happens transparently without downtime.
Key Components, Values, Defaults, and Timers
Key Vault URI: Format is https://<vault-name>.vault.azure.net/keys/<key-name>/<key-version>. If you omit the version, Azure Storage will use the latest version and auto-rotate when a new version is created.
Key Type: Must be RSA. Azure Storage does not support EC keys.
Key Sizes: 2048, 3072, or 4096 bits. 2048 is the default and most common.
Managed Identity: System-assigned identity is created per storage account and is deleted if the account is deleted. User-assigned identity is independent and can be shared across multiple storage accounts.
Permissions Required: get, wrapKey, unwrapKey on the key. Additionally, the Key Vault must have soft-delete and purge protection enabled.
Soft-Delete: Key Vault soft-delete must be enabled (retention period 7-90 days). If a key is deleted, Azure Storage will continue to work for up to the retention period but will fail after that if the key is purged.
Key Rotation Detection: Azure Storage checks for new key versions every 24 hours. If a new version is detected, it re-wraps all DEKs. You can also force re-wrapping by disabling and re-enabling CMK.
Configuration and Verification Commands
Using Azure CLI:
# Create Key Vault with soft-delete and purge protection
az keyvault create --name MyKeyVault --resource-group MyRG --enable-soft-delete true --enable-purge-protection true
# Create key
az keyvault key create --vault-name MyKeyVault --name MyKey --protection software
# Create storage account with system-assigned identity
az storage account create --name mystorageaccount --resource-group MyRG --assign-identity
# Get principal ID of the managed identity
principalId=$(az storage account show --name mystorageaccount --resource-group MyRG --query identity.principalId --output tsv)
# Grant permissions
az keyvault set-policy --name MyKeyVault --object-id $principalId --key-permissions get wrapKey unwrapKey
# Enable CMK
az storage account update --name mystorageaccount --resource-group MyRG --encryption-key-source Microsoft.Keyvault --encryption-key-vault https://MyKeyVault.vault.azure.net/keys/MyKeyVerification:
az storage account show --name mystorageaccount --resource-group MyRG --query encryptionThe output should show keySource: "Microsoft.Keyvault" and the key vault URI.
Interaction with Related Technologies
Azure Disk Encryption (ADE): Uses CMK for OS/data disks via Azure Key Vault, but it's separate from Storage CMK.
Azure Backup: Backup vaults also support CMK for encrypting backup data.
Azure SQL Database: Supports CMK via Transparent Data Encryption (TDE) with AKV integration.
Azure Information Protection: Uses CMK for protecting documents.
Azure Policy: You can enforce CMK using Azure Policy (e.g., require CMK for all storage accounts).
Limitations and Considerations
Performance: There is a slight latency overhead for each wrap/unwrap call to AKV. For high-throughput workloads, consider using a premium Key Vault with higher transaction limits.
Cost: Key Vault operations have costs (e.g., $0.03 per 10,000 operations). Storage CMK operations are included in the storage account costs but Key Vault transaction costs apply.
Availability: If Key Vault is unavailable, storage account operations that require encryption/decryption will fail. You can mitigate by using a redundant Key Vault or failover.
Key Vault Firewall: If Key Vault has a firewall, you must allow trusted Microsoft services to bypass it for Azure Storage to access the key.
Cross-Region: CMK keys must be in the same region as the storage account. You cannot use a key from a different region.
Create Key Vault with Soft-Delete
First, create an Azure Key Vault that will store your customer-managed key. Soft-delete and purge protection must be enabled because Azure Storage requires these features to prevent accidental permanent deletion of the key. Soft-delete retains deleted keys for a configurable period (7-90 days), and purge protection prevents purging during that period. Without these, CMK configuration will fail. Use Azure CLI: `az keyvault create --name MyVault --resource-group MyRG --enable-soft-delete true --enable-purge-protection true`. The vault name must be globally unique, 3-24 characters, alphanumeric and hyphens only.
Generate or Import the Key
Create an RSA key in the Key Vault. You can generate it within Key Vault (software or HSM protected) or import your own key. For CMK, the key must be RSA of size 2048, 3072, or 4096 bits. Use CLI: `az keyvault key create --vault-name MyVault --name MyKey --protection software`. The key is stored with a version. You can specify a key version in the storage account configuration or omit it to use the latest version. If you omit, Azure Storage will automatically use new versions when they are created, enabling seamless rotation.
Create Storage Account with Managed Identity
Create a storage account with a system-assigned managed identity. This identity will be used to authenticate to Key Vault. The identity is created automatically and tied to the storage account lifecycle. Use CLI: `az storage account create --name mystorageaccount --resource-group MyRG --assign-identity`. The identity's principal ID is returned. Alternatively, you can use a user-assigned managed identity, which allows the same identity to be used across multiple storage accounts. For system-assigned, the identity is deleted when the storage account is deleted.
Grant Key Vault Permissions to Managed Identity
The managed identity must have at least `get`, `wrapKey`, and `unwrapKey` permissions on the key in Key Vault. This is done via an access policy. Use CLI: `az keyvault set-policy --name MyVault --object-id <principal-id> --key-permissions get wrapKey unwrapKey`. Without these permissions, encryption/decryption will fail with a 403 Forbidden error. The `get` permission allows reading the key metadata; `wrapKey` and `unwrapKey` are used for encrypting and decrypting the Data Encryption Key (DEK).
Enable CMK on Storage Account
In the Azure portal, go to the storage account's Encryption blade, select "Use your own key", and enter the Key Vault URI (e.g., `https://MyVault.vault.azure.net/keys/MyKey`). Or use CLI: `az storage account update --name mystorageaccount --resource-group MyRG --encryption-key-source Microsoft.Keyvault --encryption-key-vault https://MyVault.vault.azure.net/keys/MyKey`. You can optionally specify a key version. Once enabled, all new data will be encrypted with the CMK. Existing data is not automatically re-encrypted; you must manually re-encrypt by rewriting data or using Azure Storage's rewrap feature.
Verify Encryption Configuration
Verify that CMK is correctly configured by checking the storage account properties. Use CLI: `az storage account show --name mystorageaccount --resource-group MyRG --query encryption`. The output should show `keySource: "Microsoft.Keyvault"` and the key vault URI. Also check the identity section to confirm managed identity is enabled. Test by uploading a blob and then attempting to read it. If the key is revoked or deleted, the read will fail. For audit, enable Key Vault logging to monitor wrap/unwrap operations.
Enterprise Scenario 1: Healthcare Compliance (HIPAA)
A hospital stores patient health records in Azure Blob Storage. To comply with HIPAA, they must maintain exclusive control over encryption keys. They use CMK with a key stored in a Key Vault with HSM-backed keys. The key is rotated every 90 days. The storage account uses a system-assigned managed identity. The security team manages the Key Vault, while the storage administrators manage the storage account. In production, they have multiple storage accounts for different data categories, each using the same key (or different keys). Performance is acceptable because the wrap/unwrap operations are cached. A common issue is when the Key Vault firewall is accidentally enabled, blocking access from storage accounts. They resolved this by adding a firewall rule to allow trusted Microsoft services.
Enterprise Scenario 2: Multi-Tenant SaaS Application
A SaaS provider uses Azure Storage for tenant data. They need to isolate encryption keys per tenant. They create a separate Key Vault for each tenant and store a unique key. Each storage account uses a user-assigned managed identity, which is granted access only to the corresponding tenant's Key Vault. This ensures that even if one key is compromised, other tenants are unaffected. In production, they have hundreds of storage accounts and Key Vaults. They use Azure Policy to enforce that all storage accounts have CMK enabled and that the key vault has soft-delete and purge protection. A challenge is managing the cost of multiple Key Vaults; they optimized by using a single Key Vault with multiple keys and applying access policies per identity.
Common Misconfigurations
Missing Permissions: The most common issue is forgetting to grant wrap/unwrap permissions to the managed identity. This results in a 403 error when trying to write data.
Soft-Delete Not Enabled: If Key Vault soft-delete is not enabled, CMK configuration fails. Always enable it.
Key Vault Firewall: If the Key Vault firewall is enabled, storage accounts cannot access the key unless you add a rule to allow trusted Microsoft services.
Key Deletion: If the key is deleted (even soft-deleted), storage operations will eventually fail. The storage account remains encrypted but inaccessible until the key is recovered.
Region Mismatch: The Key Vault must be in the same region as the storage account. Cross-region is not supported.
What AZ-104 Tests on CMK for Storage Encryption
The exam objective "Configure storage encryption" (AZ-104: Manage Azure storage, objective 2.3) includes CMK. You will be asked to:
Enable CMK on a storage account.
Configure Key Vault integration.
Understand managed identity requirements.
Troubleshoot common issues (permissions, soft-delete, firewall).
Differentiate between Microsoft-managed keys and CMK.
Understand key rotation behavior.
Top 4 Most Common Wrong Answers
"CMK requires a user-assigned managed identity." – Wrong. Both system-assigned and user-assigned identities are supported. System-assigned is simpler but tied to the storage account lifecycle.
"You must specify a key version to enable CMK." – Wrong. You can omit the version, and Azure Storage will use the latest version. Specifying a version disables automatic rotation.
"CMK encrypts data in transit." – Wrong. CMK is for encryption at rest. Data in transit is protected by TLS/HTTPS.
"If you delete the key from Key Vault, the storage account becomes immediately inaccessible." – Wrong. With soft-delete, the key is retained for 7-90 days, and storage operations continue. Only after the retention period and purge does access fail.
Specific Numbers and Terms
Key sizes: 2048, 3072, 4096 bits (RSA).
Soft-delete retention: 7-90 days.
Permissions: get, wrapKey, unwrapKey.
Key Vault URI format: https://<vault>.vault.azure.net/keys/<key>/<version>.
Managed identity types: System-assigned and user-assigned.
Key source: Microsoft.Keyvault vs Microsoft.Storage.
Edge Cases and Exceptions
Key Vault with firewall: If Key Vault firewall is enabled, you must allow trusted Microsoft services to bypass it. Otherwise, CMK will fail.
Storage account with hierarchical namespace (ADLS Gen2): CMK is supported, but you must enable the storage account's managed identity.
Existing data: Enabling CMK does not automatically re-encrypt existing data. You must rewrite data or use the rewrap operation.
Cross-region replication: If a storage account uses geo-redundant storage (GRS), the key must be available in the secondary region? Actually, CMK is only supported in the primary region; the secondary region uses the same key via replication. But if the primary region Key Vault is unavailable, the secondary region cannot unwrap keys. So CMK is not recommended for GRS unless you have a failover strategy.
How to Eliminate Wrong Answers
If the question mentions "key rotation" and the answer says "manually re-encrypt," it's likely wrong because Azure Storage automatically re-wraps DEKs when a new key version is detected.
If the question mentions "key permissions" and the answer lists only get, it's incomplete – must include wrapKey and unwrapKey.
If the question mentions "soft-delete" and the answer says it's optional, it's wrong because CMK requires soft-delete enabled.
If the question mentions "user-assigned identity" as the only option, it's wrong because system-assigned is also valid.
CMK uses an RSA key of size 2048, 3072, or 4096 bits stored in Azure Key Vault.
Key Vault must have soft-delete and purge protection enabled.
The managed identity must have get, wrapKey, and unwrapKey permissions on the key.
You can omit the key version to enable automatic rotation when a new version is created.
CMK only encrypts data at rest; data in transit uses TLS.
Existing data is not automatically re-encrypted when CMK is enabled; you must rewrite it.
CMK is supported for Blob and Files, but not for Queue and Table storage.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft-Managed Keys (SSE default)
Keys are managed by Microsoft.
No additional configuration required.
Key rotation is handled by Microsoft.
No control over key lifecycle.
No additional cost.
Customer-Managed Keys (CMK)
Keys are managed by the customer in Azure Key Vault.
Requires configuration of Key Vault, managed identity, and permissions.
Customer controls key rotation policy.
Provides separation of duties and compliance benefits.
Incur Key Vault transaction costs.
Mistake
CMK encrypts data in transit as well as at rest.
Correct
CMK only encrypts data at rest. Data in transit is encrypted using TLS/HTTPS, which is separate and always enabled.
Mistake
You must specify a key version when enabling CMK.
Correct
Specifying a key version is optional. If omitted, Azure Storage uses the latest version and automatically rotates when a new version is created. Specifying a version locks the key to that version, disabling automatic rotation.
Mistake
CMK requires a user-assigned managed identity.
Correct
Both system-assigned and user-assigned managed identities are supported. System-assigned is simpler and automatically created, but it is tied to the storage account lifecycle.
Mistake
If you delete the key from Key Vault, the storage account becomes immediately inaccessible.
Correct
Key Vault soft-delete retains deleted keys for 7-90 days. During that period, the storage account can still access the key and function normally. Only after the retention period and purge does access fail.
Mistake
CMK is supported for all Azure Storage services (Blob, Files, Queue, Table) in the same way.
Correct
CMK is supported for Blob storage and Azure Files. For Queue and Table storage, CMK is not currently supported; they use Microsoft-managed keys.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, CMK is supported for Azure Files shares. The configuration is the same as for Blob storage. Note that Azure Files also supports SMB encryption in transit, which is separate from CMK.
If you disable the system-assigned managed identity, the storage account will lose access to the key, and all encryption/decryption operations will fail. You must re-enable the identity and ensure the Key Vault permissions are still intact.
Yes, but with caveats. The key must be available in the primary region. If a failover occurs to the secondary region, the key may not be available, causing access failures. Microsoft recommends using a Key Vault in a paired region for failover scenarios.
Yes, rotation is seamless. When you create a new key version in Key Vault, Azure Storage automatically detects it within 24 hours and re-wraps all Data Encryption Keys (DEKs) with the new version. No downtime occurs.
There are costs for Key Vault operations (e.g., $0.03 per 10,000 operations for standard Key Vault). Storage account transactions are billed as usual. There is no extra charge for using CMK on the storage account itself.
Azure Storage does not automatically re-encrypt existing data when you change the key. To force re-encryption, you can rewrite the data (e.g., copy blobs to a new container) or use the 'rewrap' operation via PowerShell or CLI to re-encrypt the DEKs without rewriting data.
Yes, you can use the same key for multiple storage accounts. Each storage account's managed identity must be granted access to the key. Alternatively, you can use a user-assigned managed identity shared across storage accounts.
You've just covered Customer-Managed Keys (CMK) for Storage Encryption — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?