This chapter covers encryption at rest in Azure, a fundamental security control that protects data when it is stored on physical media. For the AZ-500 exam, approximately 15-20% of questions touch on data protection, with encryption at rest being a core topic. You will learn how Azure encrypts data by default, the different key management options (platform-managed vs. customer-managed), and how to configure encryption for various Azure services including Storage, SQL Database, and virtual machines. Understanding these mechanisms is critical for passing the exam and for designing secure Azure solutions.
Jump to a section
Imagine a hotel where each guest room has a personal safe. When a guest checks in, they receive a key to their room and a separate key to the safe. The guest can place valuables inside the safe and lock it. Only the guest (or someone with the guest's key) can open the safe. The hotel staff, even with a master key to the room, cannot open the safe because it requires a different key. Now, consider that the hotel is Azure, the guest rooms are storage accounts or virtual machines, and the safe is the encryption layer protecting data at rest. The guest's safe key is the customer-managed key (CMK), while the hotel also has a backup set of keys (platform-managed keys) that can open any safe in case the guest loses their key. However, if the guest wants to ensure maximum security, they can bring their own lock (customer-provided key) that even the hotel cannot open. This mirrors Azure's encryption at rest: data is encrypted by default with platform-managed keys, but customers can opt for customer-managed keys or even bring their own key (BYOK) using Azure Key Vault. Just as the hotel's master key can open any safe, Azure's platform-managed keys allow Microsoft to access data during support scenarios, but with customer-managed keys, the customer controls access via Azure Key Vault, and Microsoft cannot decrypt the data without the customer's key. The analogy also extends to key rotation: just as a hotel might periodically rekey all safes for security, Azure supports automatic or manual key rotation for encryption keys.
What is Encryption at Rest?
Encryption at rest is the process of encrypting data when it is written to persistent storage (e.g., disk, SSD, tape) and decrypting it when read. It ensures that if physical media is stolen or accessed by unauthorized personnel, the data remains unreadable without the proper decryption keys. Azure implements encryption at rest for all data stored in its cloud services, using strong encryption algorithms and multiple key management options.
Why Encryption at Rest Exists
Encryption at rest addresses threats such as:
Physical theft of storage media from datacenters
Insider threats from unauthorized access to storage systems
Compliance requirements (e.g., HIPAA, GDPR, PCI DSS) that mandate encryption of stored data
Separation of duties between cloud provider and customer
How Azure Encryption at Rest Works
Azure uses symmetric encryption with AES-256 (Advanced Encryption Standard with 256-bit keys) as the default cipher. The encryption process involves three layers:
Data Encryption Key (DEK): A symmetric key used to encrypt individual data blocks or files. DEKs are generated by Azure or by the customer.
Key Encryption Key (KEK): A symmetric key used to encrypt the DEK. KEKs are stored in Azure Key Vault or managed by Azure.
Master Key: The top-level key that protects KEKs. For platform-managed keys, this is managed by Microsoft. For customer-managed keys, the customer controls the master key.
By default, Azure Storage and Azure SQL Database encrypt data at rest using Storage Service Encryption (SSE) and Transparent Data Encryption (TDE), respectively. Both use platform-managed keys unless the customer opts for customer-managed keys.
Key Components, Values, and Defaults
Encryption algorithm: AES-256 (FIPS 140-2 validated)
Key sizes: 256-bit for DEK and KEK
Default key management: Platform-managed keys (Microsoft generates and rotates keys)
Customer-managed keys (CMK): Customer creates keys in Azure Key Vault and assigns them to storage or database resources
Bring Your Own Key (BYOK): Customer imports keys from on-premises HSM into Azure Key Vault, then uses them as CMK
Double encryption: Two layers of encryption with different keys (e.g., SSE + customer-managed key)
Infrastructure encryption: Additional layer at the storage infrastructure level (enabled per storage account)
Configuration and Verification Commands
Azure Storage
To enable encryption at rest for a storage account (enabled by default):
# Using Azure PowerShell
Set-AzStorageAccount -ResourceGroupName "myRG" -Name "mystorageaccount" -EnableEncryptionService BlobTo configure customer-managed keys:
# Using Azure CLI
az storage account update --name mystorageaccount --resource-group myRG --encryption-key-name mykey --encryption-key-source Microsoft.Keyvault --encryption-key-vault https://mykeyvault.vault.azure.net/Azure SQL Database
Transparent Data Encryption (TDE) is enabled by default for all new databases. To verify:
SELECT * FROM sys.dm_database_encryption_keys;To enable customer-managed TDE:
# Using Azure PowerShell
Set-AzSqlDatabaseTransparentDataEncryption -ResourceGroupName "myRG" -ServerName "myserver" -DatabaseName "mydb" -State "Enabled"Azure Virtual Machines
Encryption at rest for VM disks uses Azure Disk Encryption (ADE) or server-side encryption (SSE). ADE uses BitLocker for Windows and dm-crypt for Linux. To enable ADE:
# Using Azure PowerShell
Set-AzVMDiskEncryptionExtension -ResourceGroupName "myRG" -VMName "myVM" -DiskEncryptionKeyVaultUrl https://mykeyvault.vault.azure.net/ -DiskEncryptionKeyVaultId /subscriptions/.../resourceGroups/myRG/providers/Microsoft.KeyVault/vaults/mykeyvaultFor server-side encryption with customer-managed keys:
# Using Azure CLI
disk update --resource-group myRG --name myDisk --encryption-type EncryptionAtRestWithCustomerKey --disk-encryption-set myDESInteraction with Related Technologies
Azure Key Vault: Central repository for keys, secrets, and certificates. All customer-managed keys must be stored in Key Vault. Key Vault supports HSM-backed keys (Premium tier) and soft-delete/purge protection.
Azure Policy: Can enforce encryption at rest across subscriptions. Built-in policies include "Storage accounts should use customer-managed keys for encryption" and "SQL databases should have TDE enabled."
Azure Blueprints: Combine policies and role assignments to enforce encryption at rest for new resources.
Azure Security Center: Provides recommendations for enabling encryption at rest and monitoring compliance.
Azure Monitor: Logs encryption-related operations via Azure Activity Log and diagnostic settings.
Trap Patterns on the Exam
Confusing encryption at rest with encryption in transit: Encryption at rest protects stored data; encryption in transit (TLS/SSL) protects data moving over the network.
Assuming platform-managed keys are less secure: While customer-managed keys provide more control, platform-managed keys are still secure and meet compliance requirements.
Forgetting that Azure Storage Service Encryption (SSE) is enabled by default: Many candidates think they need to manually enable it.
Mixing up Azure Disk Encryption (ADE) with server-side encryption (SSE): ADE uses BitLocker/dm-crypt inside the VM, while SSE encrypts at the storage host level.
Overlooking double encryption: Some services support two layers of encryption (e.g., SSE + CMK).
1. Create Azure Key Vault
First, create an Azure Key Vault to store encryption keys. The vault must be in the same region as the resource to be encrypted. Enable soft-delete and purge protection to prevent accidental key deletion. Choose the Standard tier (software-protected keys) or Premium tier (HSM-protected keys). For customer-managed keys, you will need at least the Key Vault Contributor role and the ability to grant the storage account or SQL server access to the vault via access policies or RBAC.
2. Generate or Import a Key
Generate a new key in Key Vault using the Azure portal, PowerShell, or CLI. For BYOK, generate a key on-premises using an HSM and transfer it to Key Vault following the BYOK procedure (which involves a key exchange process). The key must be an RSA key of size 2048, 3072, or 4096 bits. The key is stored as a Key Vault key resource with a specific name and version.
3. Assign Key to Resource
For Azure Storage, configure the storage account to use the customer-managed key by specifying the key URI from Key Vault. For Azure SQL Database, enable TDE with customer-managed key by setting the database's TDE protector to the key. For VM disks, create a Disk Encryption Set (DES) that references the Key Vault key, then assign the DES to the disk. The resource must have appropriate permissions to access the key (e.g., via Key Vault access policies).
4. Enable Encryption
After assigning the key, enable encryption. For Storage, encryption is already on by default; switching to customer-managed key automatically re-encrypts all data with the new key. For SQL Database, enable TDE if not already enabled. For VM disks, enable Azure Disk Encryption (ADE) or server-side encryption (SSE) with the DES. This step may trigger a background re-encryption process that does not affect availability.
5. Monitor and Rotate Keys
Monitor encryption status using Azure Monitor, Security Center, or resource logs. Rotate keys periodically (e.g., every 90 days) by creating a new version of the key in Key Vault and updating the resource to use the new version. Key rotation re-encrypts the DEK with the new KEK. For customer-managed keys, key rotation is manual unless you enable automatic rotation (currently in preview for some services). Always test key rotation in a non-production environment first.
Enterprise Scenario 1: Healthcare Provider with Compliance Requirements
A healthcare provider stores patient health information (PHI) in Azure Blob Storage and Azure SQL Database. They must comply with HIPAA, which requires encryption of ePHI at rest. They use customer-managed keys (CMK) stored in Azure Key Vault (Premium tier with HSM) to maintain control over who can decrypt data. The keys are rotated every 90 days using Azure Automation runbooks. They also enable infrastructure encryption for an additional layer of protection. When a security audit occurs, they can prove that only authorized personnel have access to the keys via Key Vault access policies. A common misconfiguration is forgetting to grant the storage account access to Key Vault, causing encryption to fail. They also enable soft-delete and purge protection to prevent accidental key deletion, which would make data permanently unreadable.
Enterprise Scenario 2: Financial Services with BYOK
A bank requires that encryption keys be generated in their on-premises FIPS 140-2 Level 3 HSM and never exposed to Microsoft. They use BYOK to import keys into Azure Key Vault. The keys are used for Azure Disk Encryption on virtual machines hosting trading applications. The bank sets up Azure Policy to enforce that all disks use customer-managed keys. They also use Azure Blueprints to automatically deploy Key Vault and assign keys to new subscriptions. Performance considerations: using HSM-backed keys adds latency for key operations, so they monitor Key Vault performance and scale up if needed. A common issue is key versioning: when they rotate keys, they must update the disk encryption set reference, otherwise old keys are used.
Enterprise Scenario 3: E-commerce with Double Encryption
An e-commerce company uses Azure Storage for transaction logs and customer data. They enable double encryption (SSE with platform-managed key + customer-managed key) to meet internal security policies. They also enable infrastructure encryption for storage accounts. This means data is encrypted three times: at the storage node, at the infrastructure layer, and with a customer-controlled key. They use Azure Monitor alerts to detect any unauthorized access to Key Vault. A misconfiguration they encountered: when they revoked access to the customer-managed key, the storage account became inaccessible. They learned to test key revocation in a dev environment first. They also set up automatic key rotation using Azure Event Grid and Azure Functions.
What AZ-500 Tests on Encryption at Rest
The AZ-500 exam objectives under "Implement data protection" (15-20%) include:
Implement encryption at rest for Azure Storage (including SSE, CMK, double encryption)
Implement encryption at rest for Azure SQL Database (TDE with platform-managed and customer-managed keys)
Implement encryption at rest for Azure Virtual Machines (ADE and server-side encryption)
Understand key management options (platform-managed, customer-managed, BYOK)
Configure Azure Key Vault for storing encryption keys
Apply Azure Policy to enforce encryption at rest
Common Wrong Answers and Why Candidates Choose Them
"Encryption at rest is not enabled by default for Azure Storage." Many candidates think they need to manually enable SSE, but it is enabled by default for all new storage accounts. The exam may present a scenario where a company fails an audit because encryption is not enabled, and the answer is that it is already on.
"Azure Disk Encryption uses server-side encryption with customer-managed keys." ADE uses BitLocker/dm-crypt inside the VM, while server-side encryption is a separate feature. Candidates often confuse the two.
"Customer-managed keys are required for compliance." While CMK provides more control, platform-managed keys meet compliance requirements for most regulations. The exam tests whether you know that CMK is optional.
"Key rotation is automatic for customer-managed keys." As of the exam date, automatic key rotation is in preview for some services but not generally available. The exam expects you to know that rotation is manual unless stated otherwise.
Specific Numbers, Values, and Terms to Memorize
AES-256 encryption algorithm
Key sizes: 2048, 3072, 4096 bits for RSA
Default encryption: SSE for Storage, TDE for SQL Database
Double encryption: two layers (e.g., SSE + CMK)
Infrastructure encryption: third layer at storage infrastructure (enabled per storage account)
BYOK: Bring Your Own Key (import from on-premises HSM)
Key Vault tiers: Standard (software) and Premium (HSM)
Soft-delete retention period: 90 days (configurable)
Purge protection: cannot be disabled after enabling
Edge Cases and Exceptions
Encryption of managed disks: For OS and data disks, server-side encryption (SSE) is enabled by default with platform-managed keys. To use CMK, you must create a Disk Encryption Set (DES) and assign it to the disk.
Encryption of temp disks: Temp disks are not encrypted by default. Use Azure Disk Encryption (ADE) to encrypt them.
Azure Files: Supports SMB encryption in transit, but encryption at rest is provided via SSE.
Azure Backup: Encrypted at rest using platform-managed keys by default. Can use CMK if the source VM uses CMK.
Key Vault firewall: If enabled, you must allow trusted Microsoft services to access the vault for encryption operations.
How to Eliminate Wrong Answers
If a question mentions "encryption when data is stored," it's about encryption at rest, not in transit.
If a question mentions "BitLocker" or "dm-crypt," it's about Azure Disk Encryption.
If a question mentions "storage account" and "encryption," think SSE.
If a question mentions "SQL Database" and "encryption," think TDE.
If a question asks about "key rotation," remember that for CMK it's manual (unless preview).
Encryption at rest in Azure uses AES-256 by default.
Azure Storage Service Encryption (SSE) is enabled by default for all storage accounts.
Azure SQL Database Transparent Data Encryption (TDE) is enabled by default for new databases.
Customer-managed keys require Azure Key Vault and must be in the same region as the resource.
Azure Disk Encryption (ADE) uses BitLocker (Windows) or dm-crypt (Linux) inside the VM.
Server-side encryption (SSE) for disks encrypts at the storage host level.
Double encryption combines two layers of encryption (e.g., SSE + CMK).
Infrastructure encryption adds a third layer at the storage infrastructure level.
Key rotation for customer-managed keys is manual (unless using preview features).
Soft-delete and purge protection should be enabled on Key Vault to prevent data loss.
Azure Policy can enforce encryption at rest across subscriptions.
BYOK allows importing keys from on-premises HSMs into Azure Key Vault.
These come up on the exam all the time. Here's how to tell them apart.
Platform-Managed Keys
Microsoft generates and manages keys
Automatic key rotation by Microsoft
No additional cost for key management
Data can be accessed by Microsoft for support (with permission)
Suitable for most compliance requirements
Customer-Managed Keys
Customer creates and manages keys in Azure Key Vault
Manual key rotation (or automatic in preview)
Additional cost for Key Vault operations
Customer controls access; Microsoft cannot decrypt without customer consent
Required for organizations with strict key control policies
Mistake
Encryption at rest must be manually enabled for all Azure services.
Correct
Azure Storage and Azure SQL Database have encryption at rest enabled by default. Only services like Azure VMs require manual configuration (ADE or SSE).
Mistake
Customer-managed keys are always more secure than platform-managed keys.
Correct
Both are secure using AES-256. CMK provides more control and separation of duties, but platform-managed keys meet compliance requirements. The choice depends on organizational policy.
Mistake
Azure Disk Encryption (ADE) is the only way to encrypt VM disks.
Correct
Server-side encryption (SSE) with platform-managed or customer-managed keys is also available and is easier to manage. ADE encrypts inside the VM, while SSE encrypts at the storage host.
Mistake
If a customer-managed key is deleted, the data is still recoverable.
Correct
If the key is deleted (and not soft-deleted), the data becomes permanently unreadable. Soft-delete and purge protection are critical to prevent data loss.
Mistake
Encryption at rest protects data in transit.
Correct
Encryption at rest only protects stored data. Data in transit is protected by TLS/SSL. These are separate controls tested on the exam.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, Azure Storage Service Encryption (SSE) is enabled by default for all new storage accounts. It encrypts data at rest using AES-256 with platform-managed keys. You do not need to take any action to enable it. However, you can choose to use customer-managed keys for more control.
Azure Disk Encryption (ADE) encrypts VM disks inside the VM using BitLocker (Windows) or dm-crypt (Linux). It requires the VM to have the encryption extension installed. Server-side encryption (SSE) encrypts disks at the Azure storage host level, before the data is written to disk. SSE is transparent to the VM and does not require any guest OS configuration. SSE is enabled by default for managed disks, while ADE must be enabled manually.
Yes, you can use customer-managed keys for Transparent Data Encryption (TDE) in Azure SQL Database. This is called "Bring Your Own Key" (BYOK) support for TDE. The keys must be stored in Azure Key Vault. You can also import keys from on-premises HSMs. Using customer-managed keys gives you control over key rotation and access.
If you delete a customer-managed key (without soft-delete), the data encrypted with that key becomes permanently unreadable. Azure cannot recover the data because the key is gone. To prevent this, always enable soft-delete and purge protection on Key Vault. Soft-delete retains the key for 90 days, allowing recovery. If the key is purged, data loss is permanent.
Yes, encryption at rest using AES-256 meets the requirements of most compliance frameworks, including HIPAA, GDPR, PCI DSS, and FedRAMP. Both platform-managed and customer-managed keys are acceptable. However, some organizations require customer-managed keys for additional control and separation of duties. Always verify with your compliance officer.
To rotate a customer-managed key for Azure Storage, create a new version of the key in Azure Key Vault. Then update the storage account to use the new key version. This can be done via the Azure portal, PowerShell, or CLI. The storage account will automatically re-encrypt the data encryption keys with the new key. Rotation does not cause downtime.
Yes, but temp disks are not encrypted by default. To encrypt temp disks, you must use Azure Disk Encryption (ADE). ADE encrypts both OS and data disks, including temp disks. Server-side encryption (SSE) does not encrypt temp disks. Note that temp disks are not persistent and may be recreated during VM maintenance events.
You've just covered Encryption at Rest in Azure — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?