10.1 Disk Encryption

Why Disk Encryption Matters on SC-500

Under Secure compute, the SC-500 blueprint explicitly measures implement and configure disk encryption. Encryption is not one switch—Azure offers several mechanisms that protect different layers of the I/O path. Exam questions almost always test which layer you need, what is encrypted by default, and how Key Vault fits, not the click-path to enable a checkbox.

Treat encryption as part of a layered server security model alongside Bastion/JIT access, Defender for Servers, Trusted Launch, and Machine Configuration (later in this chapter). Disk encryption protects data at rest and in transit between compute and storage; it does not replace identity, network, or runtime threat protection.

---

The Four Encryption Options (Exam Map)

Microsoft documents four primary options for managed disks and VMs. Memorize this comparison table—it is the backbone of almost every SC-500 encryption stem.

Mental model for the exam

1. SSE = “Microsoft encrypts disks when they land on storage” (always true for managed disks).
2. Encryption at host = “Encrypt earlier—on the host—so temp disks, caches, and the path to storage are covered without taxing the guest.”
3. ADE = “Encrypt inside the OS like a traditional BitLocker/dm-crypt rollout, with Key Vault holding keys.”
4. Confidential disk encryption = “Keys are bound so even the host fabric cannot casually read the confidential OS disk content.”

---

Server-Side Encryption (SSE): Platform-Managed vs Customer-Managed Keys

Server-side encryption of Azure managed disks (also called encryption-at-rest or Azure Storage encryption on disks) is always enabled. You cannot turn it off. By default, Microsoft uses platform-managed keys (PMK)—Azure generates, stores, and rotates the encryption keys.

When compliance or policy requires customer control of keys:

1. Create a key in Azure Key Vault or Azure Key Vault Managed HSM.
2. Create a Disk Encryption Set (DES) that references that key.
3. Associate the DES with OS/data disks (or set it as the default for a subscription/resource group via policy).
4. Grant the DES’s managed identity permission to use the key (wrap/unwrap and related key operations).

Exam traps for SSE + CMK:

• CMK for disks uses a Disk Encryption Set, not the ADE “enable disk encryption” wizard.
• Soft-delete and purge protection on Key Vault are operational best practices for CMK durability; losing key access can make disks unreadable.
• SSE alone does not encrypt temporary disks or disk caches—if the stem requires those, you need encryption at host or ADE (legacy).

---

Encryption at Host: Preferred End-to-End Path

Encryption at host is a VM-level setting. When enabled, the Azure host encrypts data for temp disks and OS/data disk caches at rest on that host, and data remains encrypted as it flows to Azure Storage. It improves on default SSE without consuming guest CPU or relying on BitLocker/dm-crypt inside the VM.

Key exam facts:

• Mutual exclusion with ADE: You cannot enable encryption at host on VMs that currently have (or historically had) ADE enabled, and you cannot enable ADE on disks that already use encryption at host. Migration requires new disks/VMs—not an in-place flip.
• Scale sets: Enabling on a scale set encrypts new instances automatically; existing instances typically need deallocate/reallocate.
• Ultra Disk / Premium SSD v2: Additional restrictions apply; always check size/region support before answering “enable everywhere.”
• Performance: No guest CPU tax—prefer over ADE when the goal is performance-neutral encryption of temp/cache paths.
• Retirement guidance: Microsoft directs new deployments to encryption at host (or confidential VM OS disk encryption) instead of ADE.

Scenario: A regulated app uses Premium SSDs and a temporary disk for staging. Auditors require encryption of temp data and caches, and the app team refuses guest-level encryption agents that burn CPU. Answer: encryption at host (optionally with SSE + CMK via DES on the managed disks).

---

Azure Disk Encryption (ADE) and Key Vault Integration

Azure Disk Encryption encrypts the OS and data volumes inside the guest:

• Windows: BitLocker
• Linux: dm-crypt

ADE integrates with Azure Key Vault to store disk encryption secrets (and optionally a key encryption key / KEK that wraps those secrets). Classic exam setup steps:

1. Key Vault in the same subscription/region model the workload expects, with appropriate access policies or RBAC for the ADE identity model in use.
2. Enable ADE on the VM (portal, CLI, PowerShell, or ARM/Bicep).
3. Confirm volumes show encrypted and that Key Vault holds the BEK/KEK material.
4. Understand backup/restore and VM extension health—ADE relies on guest extensions and successful unlock at boot.

Critical lifecycle fact for SC-500: ADE is scheduled for retirement on September 15, 2028. Until then it works; after that date, ADE-enabled workloads may fail to unlock disks after reboot. Microsoft expects migration to encryption at host (or confidential VM disk encryption for confidential sizes). Exam questions may still describe ADE for legacy scenarios, but greenfield designs should not recommend ADE.

When ADE still appears in stems:

• Existing VMs already encrypted with BitLocker/dm-crypt via ADE.
• A requirement phrased as “guest OS volume encryption with keys in Key Vault” without mentioning host or confidential VMs.
• Defender recommendations that historically flagged missing ADE—modern recommendations also recognize encryption at host.

---

Confidential VMs and Confidential Disk Encryption (Overview)

Confidential VMs (for example DCasv5/ECasv5-class sizes and later families) use hardware-backed trusted execution environments so the guest can protect data in use, not only at rest. Confidential disk encryption binds OS disk encryption keys to the VM’s TPM and releases them only to attested code paths, reducing host/operator visibility into protected disk content.

Exam-level distinctions:

• Confidential disk encryption is not the same as ordinary SSE or encryption at host—it targets confidential computing threat models.
• You may still use encryption at host for additional disks on a confidential VM.
• Choosing security type = Confidential at VM create time is a different decision from Trusted launch (covered in section 10.4).

If the stem says “protect data from the cloud operator / host administrator while processing,” lean confidential computing—not ADE.

---

Decision Tree: Which Encryption Does the Exam Want?

Use this quick map:

Combined exam traps

• Trap: “Managed disks are unencrypted unless you enable ADE.” False—SSE is always on.
• Trap: “CMK for disks is configured the same way as storage-account encryption keys.” Disks use Disk Encryption Sets; storage accounts have their own encryption settings.
• Trap: “Enable both ADE and encryption at host for defense in depth.” Invalid—they are mutually exclusive.
• Trap: “SSE alone meets a requirement to encrypt temporary disks.” False—need encryption at host or ADE.

---

Operations and Policy Alignment

Security engineers implement encryption with Azure Policy and Defender recommendations:

• Deploy deny/deployIfNotExists policies that require encryption at host or DES-backed CMK on new VMs/disks.
• Watch Defender for Cloud recommendations that flag missing encryption at host or missing ADE/EncryptionAtHost for Windows/Linux VMs.
• Coordinate Key Vault network rules, private endpoints, and RBAC so disk encryption identities can still unwrap keys during boot and rekey operations.
• Treat key rotation as a joint Key Vault + DES + VM maintenance exercise—not a secret change in isolation.

Disk encryption is necessary but not sufficient: pair it with private management access (Bastion/JIT), Defender for Servers, Trusted Launch, and Machine Configuration baselines covered next.