Azure VM Sizing, Availability, and Disks

Deploy and manage Azure VMs with availability sets, disk types, and encryption.

Introduction

30 Second Summary

When a cloud server goes down, it takes applications and users with it. In production environments, engineers configure virtual machines across multiple hardware racks and datacenters so that a single failure never takes down the entire service.

In this project, you will deploy two Azure VMs inside an Availability Set, resize a VM across size families, attach different managed disk types, and enable end-to-end disk encryption. These are the exact hands-on skills tested in the AZ-104 compute domain.

What You'll Build

A two-VM "web tier" deployment that demonstrates the core VM administration concepts from the AZ-104 exam: sizing, availability, and disk management.

By the end of this project, you'll have:

  • Two Windows Server VMs deployed inside an Availability Set with verified fault and update domain distribution.
  • Hands-on experience resizing a VM from B-series (burstable) to D-series (general purpose), including the deallocation workflow.
  • Multiple managed disk types attached and configured (Standard SSD and Premium SSD) with Encryption at Host enabled for end-to-end protection.
  • Secret Mission: Deploy a third VM into a specific Availability Zone with a Proximity Placement Group to observe zone-pinning behaviour.

Are there any prerequisites?

You need an Azure subscription with active credit and basic familiarity with navigating the Azure Portal. Prior experience creating a VM is helpful but not strictly required.

Set Up the Resource Group and Availability Set

Every Azure lab needs a home. A resource group is that home. It keeps all your resources organized under one roof so you can manage (and delete) them as a single unit.

In this step, you will create a dedicated resource group and then build an Availability Set inside it. The Availability Set is what tells Azure to spread your future VMs across separate physical hardware, protecting against single-point failures.

In this step, get ready to:
  • Create a resource group named rg-az104-vm-lab in East US 2.
  • Create an Availability Set with 2 fault domains and 5 update domains.
  • Verify the setup in the Azure Portal and Cloud Shell.
Create a dedicated resource group

A resource group stores metadata about its contents and lets you deploy, tag, and delete related resources together. You will create one specifically for this lab so cleanup is simple at the end.

  • In the Azure Portal search bar at the top, type Resource groups and select the result.
  • Click Create.
  • Select your Azure subscription from the Subscription dropdown.
  • In the Resource group field, enter rg-az104-vm-lab.
  • For Region, select East US 2.
  • Click Review + create, then click Create.

Why East US 2?

East US 2 supports Availability Zones, which you will use in the Secret Mission later. Choosing a zone-capable region now saves you from recreating resources later.

Now verify the resource group exists using Cloud Shell.

  • Open Cloud Shell by clicking the Cloud Shell icon (>_) in the top navigation bar of the Azure Portal.
  • If prompted to choose an environment, select PowerShell.
  • If prompted about storage, select a storage option to continue. Cloud Shell needs a small file share to persist sessions.
  • Verify your resource group by running this command:
Get-AzResourceGroup -Name rg-az104-vm-lab

What does this command do?

Get-AzResourceGroup queries Azure for the named resource group and returns its properties. You should see rg-az104-vm-lab with a ProvisioningState of Succeeded and a location of eastus2.

Not seeing your resource group?

Make sure you are in the correct subscription. Run Get-AzContext to check. If the subscription is wrong, switch with Set-AzContext -SubscriptionName "Your Subscription Name".

Also confirm the spelling matches exactly: rg-az104-vm-lab (all lowercase, hyphens, no spaces).

Help me troubleshoot my resource group not appearing in Cloud Shell.

Create an Availability Set via Cloud Shell

An Availability Set tells Azure to distribute VMs across multiple fault domains (separate power and network hardware) and update domains (groups that reboot at different times during maintenance). This guarantees that not all VMs go down at once.

  • Create the Availability Set by running this command in Cloud Shell:
New-AzAvailabilitySet -ResourceGroupName "rg-az104-vm-lab" -Name "avset-webtier" -Location "eastus2" -PlatformFaultDomainCount 2 -PlatformUpdateDomainCount 5 -Sku Aligned

What does this command do?

  • -PlatformFaultDomainCount 2 creates 2 fault domains. Each fault domain shares a power source and network switch. Spreading VMs across fault domains means a single hardware failure cannot take down both VMs.
  • -PlatformUpdateDomainCount 5 creates 5 update domains. During planned maintenance, Azure reboots only one update domain at a time, so most of your VMs stay online.
  • -Sku Aligned ensures managed disks align with VM fault domains. Without this, managed disks might land in a different fault domain than their VM, defeating the purpose of the set.

You should see output showing avset-webtier with a ProvisioningState of Succeeded.

Command failed with an error?

If you see a location error, confirm the -Location value is eastus2 (no spaces, all lowercase). Azure location strings do not match the Portal display name.

If you see a permissions error, run Get-AzContext and verify you are logged into the subscription that owns rg-az104-vm-lab.

Help me troubleshoot my Availability Set creation error.

Verify the Availability Set in the Portal

Cloud Shell confirms creation, but the Portal gives you a visual layout of fault and update domain assignments. This is also where you will see VM placement later.

  • In the Azure Portal search bar, type avset-webtier and select the Availability Set result.
  • On the Overview page, confirm Fault domains shows 2 and Update domains shows 5.
  • Confirm the SKU shows Aligned.

Why does the Aligned SKU matter for AZ-104?

The exam tests whether you know the difference between Classic and Aligned (managed) availability sets. Aligned ensures that managed disks are placed in the same fault domain as their VM. Classic availability sets do not provide this guarantee and are considered legacy.

Azure provides a 99.95% SLA when you run two or more VMs inside an Availability Set. This is a frequently tested detail on the AZ-104 exam.

Can't find the Availability Set in search?

Navigate manually: open Resource groups in the Portal, click rg-az104-vm-lab, and you should see avset-webtier listed inside.

If it is not there, return to Cloud Shell and re-run the New-AzAvailabilitySet command. Check for typos in the resource group name.

Help me find my Availability Set in the Azure Portal.

Your resource group and Availability Set are ready. Next up, you will deploy two VMs into this Availability Set and see how Azure distributes them across fault domains.

Deploy Two VMs into the Availability Set

Your Availability Set is ready to protect VMs from correlated hardware failures. Now you need actual VMs inside it.

In this step, you will deploy two Windows Server VMs into the Availability Set using different VM size families. This lets you compare B-series burstable VMs with D-series general purpose VMs while verifying that Azure distributes them across separate fault domains.

In this step, get ready to:
  • Create VM1 using a B-series burstable size inside the Availability Set.
  • Create VM2 using a D-series general purpose size inside the same Availability Set.
  • Verify that Azure placed each VM in a different fault domain.
Create VM1 (B-series burstable)

Azure's B-series VMs use a credit-based CPU model. They accumulate credits when idle and burst above baseline when workloads spike. This makes them cost-effective for workloads with variable CPU demand like dev/test servers.

  • Cloud Shell will prompt you for administrator credentials when you run New-AzVM. Choose a username (not admin or administrator) and a password at least 12 characters long with uppercase, lowercase, a number, and a special character.
  • Create VM1 as a Standard_B2s burstable VM inside your Availability Set by running this command in Cloud Shell:
New-AzVM `
  -ResourceGroupName "rg-az104-vm-lab" `
  -Location "eastus2" `
  -Name "vm1-webtier" `
  -AvailabilitySetName "avset-webtier" `
  -Size "Standard_B2s" `
  -Image "MicrosoftWindowsServer:WindowsServer:2022-datacenter:latest"

What does this command do?

  • -AvailabilitySetName "avset-webtier" places VM1 inside the Availability Set you created in Step 1. Azure automatically assigns it to a fault domain and update domain.
  • -Size "Standard_B2s" selects the B-series burstable VM size with 2 vCPUs and 4 GiB RAM. It includes a local temporary disk.
  • -Image specifies the Windows Server 2022 Datacenter marketplace image using its full URN.
  • Enter your chosen username and password when prompted. The VM provisioning takes 2-3 minutes.
  • You should see output showing ProvisioningState: Succeeded once the VM is created.

Seeing a credential error?

Azure rejects common usernames like admin, administrator, root, or test. Use a different username like azureadmin. Your password must be 12-123 characters and contain at least 3 of: lowercase, uppercase, number, special character.

help me fix a credential error when creating an Azure VM with New-AzVM

Create VM2 (D-series general purpose)

Unlike B-series burstable VMs, D-series VMs deliver consistent compute performance without the credit model. They are designed for production workloads that need predictable CPU availability.

  • Create VM2 as a Standard_D2ds_v5 general purpose VM in the same Availability Set by running this command:
New-AzVM `
  -ResourceGroupName "rg-az104-vm-lab" `
  -Location "eastus2" `
  -Name "vm2-webtier" `
  -AvailabilitySetName "avset-webtier" `
  -Size "Standard_D2ds_v5" `
  -Image "MicrosoftWindowsServer:WindowsServer:2022-datacenter:latest"

What is the D-series?

D-series VMs are general purpose, meaning they offer a balanced CPU-to-memory ratio. The Standard_D2ds_v5 size provides 2 vCPUs, 8 GiB RAM, and includes a local temporary disk (the d in the name indicates a local temp disk). This makes it compatible with resizing from Standard_B2s later in the project.

The s suffix means the size supports Premium SSD storage, which you will use in Step 4.

  • Enter your chosen username and password when prompted. Wait for ProvisioningState: Succeeded to appear.

VM creation failed with a quota error?

Some subscriptions have vCPU quota limits per region. If you see an error mentioning quota, try a different region or request a quota increase from the Azure Portal under Subscription > Usage + quotas.

help me resolve an Azure VM quota error

Verify fault domain distribution

Azure automatically distributes VMs across fault domains when they belong to the same Availability Set. Each fault domain shares a common power source and network switch. Spreading VMs across fault domains means a single hardware failure cannot take down both VMs simultaneously.

  • In the Azure Portal, type avset-webtier in the search bar at the top and select the Availability Set resource.
  • On the Overview page, look at the Virtual machines section. You should see both vm1-webtier and vm2-webtier listed.
  • Confirm that the Fault Domain column shows different numbers for each VM (e.g., 0 and 1).
  • Note the Update Domain column as well. Azure assigns update domains so that planned maintenance restarts VMs in only one update domain at a time.

Why do fault domains matter for the AZ-104 exam?

The AZ-104 exam tests whether you understand that each fault domain in an Availability Set shares a power source and network switch. Distributing VMs across fault domains protects against correlated hardware failures within a single datacenter.

An Availability Set with 2 fault domains guarantees a 99.95% SLA when two or more VMs are deployed. Update domains control how Azure rolls out planned maintenance, restarting only one update domain at a time.

Both VMs in the same fault domain?

With only 2 fault domains and 2 VMs, Azure should place them in separate fault domains. If both show the same fault domain, delete one VM and recreate it. Azure assigns fault domains at creation time and cannot change them afterward.

help me understand why my VMs ended up in the same fault domain

Both VMs are running and protected by the Availability Set. Next up, you will resize VM1 from B-series to D-series to experience the deallocation workflow that the AZ-104 exam tests.

Resize VM1 Across Families

Your two VMs are running inside the Availability Set, each distributed across separate fault domains. Next, you'll tackle one of the most common VM administration tasks tested on AZ-104.

VM workloads change over time. A burstable B-series VM might be fine during development, but production traffic often demands the consistent performance of a D-series. In this step, you'll resize VM1 from Standard_B2s to Standard_D2ds_v5, experiencing the deallocate-resize-start workflow firsthand.

In this step, get ready to:
  • Observe the available sizes for a running VM and the temp disk compatibility constraint.
  • Deallocate VM1 and resize it from B-series to D-series.
  • Verify the resize completed and understand the key constraints for the exam.
Observe available sizes in the Portal

Azure only shows resize options that are compatible with your VM's current configuration. The local temp disk setting is a key factor that limits which target sizes appear.

  • In the Azure Portal, navigate to your vm1-webtier virtual machine.
  • In the left menu under Settings, click Size.
  • Look at the list of available sizes displayed in the blade.

Notice that sizes like Standard_D2ds_v5 appear in the list, but Standard_D2s_v5 does not.

Why don't all sizes appear?

Standard_B2s has a local temp disk. Azure only shows target sizes that also have a local temp disk (like Standard_D2ds_v5).

Sizes without a temp disk (like Standard_D2s_v5) will not appear. Azure blocks resizing between VMs with different temp disk configurations. Only temp-to-temp or no-temp-to-no-temp is allowed.

This constraint is a common exam question on AZ-104. Remember: the d in a VM size name (like D2ds) indicates it has a local temp disk.

Deallocate and resize VM1

Resizing across VM families often requires deallocation when the target size is not available on the current hardware cluster. Deallocation releases compute resources but preserves your OS and data disks.

  • Deallocate VM1 by running this command in Cloud Shell:
Stop-AzVM -ResourceGroupName "rg-az104-vm-lab" -Name "vm1-webtier" -Force

What does this command do?

Stop-AzVM with -Force fully deallocates the VM without a confirmation prompt. This is different from shutting down Windows inside the VM, which leaves it in a "Stopped" state that still incurs compute charges.

Only "Stopped (deallocated)" via Portal or CLI stops billing. The -Force flag ensures you reach the fully deallocated state.

  • Wait for the command to complete. You should see Status showing Succeeded in the output.
  • In the Portal, return to VM1's Overview page. The Status should show Stopped (deallocated).

Still seeing Running status?

The command can take 1-2 minutes to complete. If the Portal still shows Running, click Refresh at the top of the Overview blade.

If the command returned an error, confirm you typed the resource group name and VM name exactly as shown. Names are case-sensitive.

Why is my VM not deallocating?

  • Resize VM1 to Standard_D2ds_v5 by running these commands:
# Get the VM object
$vm = Get-AzVM -ResourceGroupName "rg-az104-vm-lab" -Name "vm1-webtier"

# Change the size property to D-series general purpose
$vm.HardwareProfile.VmSize = "Standard_D2ds_v5"

# Apply the update
Update-AzVM -VM $vm -ResourceGroupName "rg-az104-vm-lab"

What does this code do?

  • Get-AzVM retrieves the VM configuration object so you can modify it locally.
  • Setting .HardwareProfile.VmSize changes the target size in the local object. No Azure changes happen yet.
  • Update-AzVM pushes the modified object back to Azure, triggering the actual resize operation.
  • Wait for the update to complete. You should see StatusCode: OK in the output.
  • Start VM1 back up by running this command:
Start-AzVM -ResourceGroupName "rg-az104-vm-lab" -Name "vm1-webtier"
  • Wait for the command to finish. You should see Status showing Succeeded in the output.
  • In the Portal, navigate to VM1's Overview page.
  • Confirm the Size now shows Standard_D2ds_v5 and the Status shows Running.

VM failed to start after resize?

If Start-AzVM returns an error, the target size may not have capacity on the current cluster. Try running the Update-AzVM command again. Azure may allocate the VM to a different cluster with available capacity.

If the VM starts but shows the old size, re-run Get-AzVM to confirm the HardwareProfile.VmSize property was saved correctly.

Help me troubleshoot my VM resize

Understand the resize constraints

You just experienced the full deallocate-resize-start workflow. Here are the key constraints that AZ-104 tests in scenario-based questions.

Key resize rules for AZ-104

  • Resizing a running VM causes a restart. If the target size is not available on the current cluster, deallocation is required.
  • You cannot resize between VMs with a local temp disk and VMs without one. Only temp-to-temp or no-temp-to-no-temp is allowed.
  • You cannot resize between SCSI-based VMs and remote NVMe-enabled VMs.
  • Deallocating releases dynamic public IPs but preserves OS and data disks.
  • "Stopped" from inside Windows still incurs compute charges. "Stopped (deallocated)" via Portal or CLI does not.

Why D2ds_v5 instead of D2s_v5?

Standard_D2ds_v5 includes a local temp disk, making it compatible with the resize from Standard_B2s (which also has a temp disk). Standard_D2s_v5 does not have a local temp disk, so Azure blocks a direct resize between them.

If you need to move to a no-temp-disk size, the workaround is a snapshot-based migration. That is beyond the scope of this lab.

  • In the Portal, navigate to VM1's Overview page and confirm the size shows Standard_D2ds_v5.
  • Click Disks in the left menu under Settings to verify the OS disk is still attached and intact.

VM1 is now running as a D-series general purpose machine with consistent compute performance. Next up, you'll attach and manage data disks of different types to both VMs.

Attach and Manage Data Disks

Your two VMs are running and distributed across fault domains. Now it's time to give them storage beyond the OS disk.

Every VM gets an OS disk automatically, but production workloads store application data on separate data disks. Azure offers multiple managed disk types, each tuned for different performance and cost profiles. In this step, you will attach a Standard SSD disk to VM1 and a Premium SSD disk to VM2, then compare the two.

In this step, get ready to:
  • Attach a Standard SSD data disk to VM1.
  • Attach a Premium SSD data disk to VM2.
  • Verify disk configuration in the Portal Disks blade.
Attach a Standard SSD data disk to VM1

A managed disk is an Azure-managed block storage volume. You create a disk resource first, then attach it to a VM at a specific Logical Unit Number (LUN).

  • In Cloud Shell, create a Standard SSD disk and attach it to VM1 by running these commands:
# Create a Standard SSD disk configuration (64 GiB, locally redundant)
$diskConfig = New-AzDiskConfig -SkuName StandardSSD_LRS -Location "eastus2" -CreateOption Empty -DiskSizeGB 64

# Create the managed disk resource in your resource group
$disk1 = New-AzDisk -ResourceGroupName "rg-az104-vm-lab" -DiskName "disk-vm1-data" -Disk $diskConfig

# Retrieve VM1, attach the disk at LUN 0, and apply the update
$vm1 = Get-AzVM -ResourceGroupName "rg-az104-vm-lab" -Name "vm1-webtier"
Add-AzVMDataDisk -VM $vm1 -Name "disk-vm1-data" -CreateOption Attach -ManagedDiskId $disk1.Id -Lun 0
Update-AzVM -VM $vm1 -ResourceGroupName "rg-az104-vm-lab"

What does this code do?

These commands perform two operations: creating a disk and attaching it.

  • `New-AzDiskConfig` defines the disk's properties. `StandardSSD_LRS` means Standard SSD with locally redundant storage. `Empty` means a blank disk (no pre-existing data). `64` sets the size to 64 GiB.
  • `New-AzDisk` creates the actual managed disk resource in Azure.
  • `Add-AzVMDataDisk` attaches the disk to the VM object in memory at LUN 0. LUN is the address the operating system uses to identify the disk.
  • `Update-AzVM` pushes the updated VM configuration to Azure, making the attachment live.
  • Wait for the command to finish. You should see output with IsSuccessStatusCode showing True and StatusCode showing OK.

Seeing an error about disk SKU?

Make sure you typed StandardSSD_LRS exactly (capital S in both words, underscore before LRS). A typo here causes a validation error.

If Cloud Shell timed out, reconnect and run the commands again. The disk creation is idempotent if the disk name already exists.

Help me troubleshoot my Standard SSD disk creation in Azure Cloud Shell.

Attach a Premium SSD data disk to VM2

VM2 runs on Standard_D2ds_v5, which supports Premium storage (indicated by the "s" in the size name). VMs without the "s" suffix in their size name cannot attach Premium SSD disks.

  • Create a Premium SSD disk and attach it to VM2 by running these commands:
# Create a Premium SSD disk configuration (64 GiB, locally redundant)
$diskConfig = New-AzDiskConfig -SkuName Premium_LRS -Location "eastus2" -CreateOption Empty -DiskSizeGB 64

# Create the managed disk resource in your resource group
$disk2 = New-AzDisk -ResourceGroupName "rg-az104-vm-lab" -DiskName "disk-vm2-data" -Disk $diskConfig

# Retrieve VM2, attach the disk at LUN 0, and apply the update
$vm2 = Get-AzVM -ResourceGroupName "rg-az104-vm-lab" -Name "vm2-webtier"
Add-AzVMDataDisk -VM $vm2 -Name "disk-vm2-data" -CreateOption Attach -ManagedDiskId $disk2.Id -Lun 0
Update-AzVM -VM $vm2 -ResourceGroupName "rg-az104-vm-lab"

What does this code do?

The structure is identical to the VM1 commands. The only difference is the SKU: Premium_LRS instead of StandardSSD_LRS.

Premium SSD delivers up to 20,000 IOPS and is designed for production workloads needing consistent low-latency. Standard SSD delivers up to 6,000 IOPS and suits balanced workloads where maximum throughput is not critical.

  • Wait for the output showing IsSuccessStatusCode: True and StatusCode: OK.

Azure disk types for the AZ-104 exam

Azure offers five managed disk types. Here is the hierarchy from lowest to highest performance:

  • Standard HDD: backup and dev/test workloads. Up to 2,000-3,000 IOPS.
  • Standard SSD: balanced cost and performance. Up to 6,000 IOPS.
  • Premium SSD: production workloads. Up to 20,000 IOPS.
  • Ultra Disk: IO-intensive workloads. Up to 400,000 IOPS. Data disk only, no caching, LRS only, cannot be used with availability sets.

You can convert between Premium SSD, Standard SSD, and Standard HDD. You cannot directly convert to or from Ultra Disk (requires a snapshot). Disk type changes are limited to twice per day.

Seeing a Premium storage not supported error?

Only VM sizes with an "s" in the name support Premium storage. Your VM2 uses Standard_D2ds_v5 which includes the "s", so it should work. Double check the SKU name is Premium_LRS (capital P, underscore before LRS).

Help me fix a Premium SSD disk attachment error in Azure.

Verify disk configuration in the Portal

Both disks are attached. Now confirm the configuration visually in the Azure Portal.

  • In the Azure Portal, navigate to **Virtual machines**.
  • Click vm1-webtier.
  • In the left menu under Settings, click Disks.
  • Confirm you see two disks listed: the OS disk (automatically created) and disk-vm1-data attached at LUN 0 with type Standard SSD.
  • Navigate back to Virtual machines and click vm2-webtier.
  • Open the Disks blade and confirm disk-vm2-data is attached at LUN 0 with type Premium SSD.

What is the difference between OS disks, data disks, and temporary disks?

The OS disk holds the operating system and is limited to approximately 4,095 GiB. It is created automatically when you provision a VM.

Data disks store application data separately. They are registered as SCSI drives and can hold up to 32 TiB each. You can attach multiple data disks per VM.

Temporary disks are ephemeral storage that lives on the physical host. They are NOT managed disks. Data on a temporary disk is lost when the VM is deallocated or moved to a different host.

Both VMs now have dedicated data disks. Next up, you will enable encryption at host on VM2 to ensure end-to-end data protection across all disk types.

Enable Disk Encryption at Host

Your VMs now have dedicated data disks attached and configured. The next question is: how do you keep all that data safe at rest?

Azure encrypts managed disks by default with server-side encryption (SSE), but that does not cover temporary disks or disk caches. Encryption at Host closes this gap by encrypting everything on the VM host before it ever reaches storage. In this step, you will register the feature and enable it on VM2.

In this step, get ready to:
  • Register the EncryptionAtHost feature on your subscription.
  • Enable Encryption at Host on VM2 via the deallocate-update-start workflow.
  • Verify encryption status in the Portal's Disks blade.
Register the EncryptionAtHost feature

Before you can enable Encryption at Host on any VM, the feature must be registered on your Azure subscription. This is a one-time prerequisite.

  • In Cloud Shell, register the feature by running this command:
Register-AzProviderFeature -FeatureName "EncryptionAtHost" -ProviderNamespace "Microsoft.Compute"

What does this command do?

This registers the EncryptionAtHost feature flag under the Microsoft.Compute resource provider. Until this flag is registered, Azure will reject any attempt to set -EncryptionAtHost $true on a VM.

  • Check the registration status by running:
Get-AzProviderFeature -FeatureName "EncryptionAtHost" -ProviderNamespace "Microsoft.Compute"

You should see the RegistrationState column show Registered. If it shows Registering, wait a minute and run the command again.

  • Once the state is Registered, propagate the registration to the resource provider by running:
Register-AzResourceProvider -ProviderNamespace "Microsoft.Compute"

Still showing Registering after a few minutes?

Feature registration can take up to 10 minutes on some subscriptions. Keep re-running the Get-AzProviderFeature command until the state changes. Do not proceed to the next substep until it shows Registered.

If registration fails, confirm your subscription has sufficient permissions (Owner or Contributor role at the subscription level).

help me troubleshoot EncryptionAtHost feature registration

Enable Encryption at Host on VM2

Existing VMs must be deallocated before Encryption at Host can be enabled. This is the same deallocate-update-start workflow you used when resizing VM1.

  • Deallocate VM2 by running this command:
Stop-AzVM -ResourceGroupName "rg-az104-vm-lab" -Name "vm2-webtier" -Force

Wait for the command to complete. The output confirms that vm2-webtier has been stopped and deallocated.

  • Enable Encryption at Host on the deallocated VM by running:
Update-AzVM -ResourceGroupName "rg-az104-vm-lab" -VM (Get-AzVM -ResourceGroupName "rg-az104-vm-lab" -Name "vm2-webtier") -EncryptionAtHost $true

What does this command do?

The inner Get-AzVM retrieves the current VM object for vm2-webtier. The outer Update-AzVM applies the -EncryptionAtHost $true property to the VM's security profile.

Once enabled, all data flowing between the VM host and Azure Storage is encrypted end-to-end. This covers the OS disk, data disks, temporary disk, and all disk caches.

  • Start VM2 again by running:
Start-AzVM -ResourceGroupName "rg-az104-vm-lab" -Name "vm2-webtier"

Wait for the command to confirm that the VM has started successfully.

How does Encryption at Host compare to other options?

Azure offers four disk encryption approaches. Here is how they differ:

  • SSE (Server-Side Encryption) is the default. It uses AES-256 with platform-managed keys, but does NOT encrypt temp disks or disk caches.
  • Encryption at Host encrypts everything end-to-end (OS, data, temp disks, and caches) on the VM host. It does not use VM CPU resources.
  • Azure Disk Encryption (ADE) uses BitLocker (Windows) or dm-crypt (Linux) inside the VM. It consumes VM CPU and is retiring September 15, 2028.
  • Confidential Disk Encryption binds keys to the VM's TPM chip for confidential VM workloads.

ADE and Encryption at Host are mutually exclusive. You cannot enable both on the same disk.

Seeing a EncryptionAtHost validation error?

If the Update-AzVM command fails, check these common causes:

  • The EncryptionAtHost feature registration has not finished. Re-run the Get-AzProviderFeature check and wait until it shows Registered.
  • The VM is not fully deallocated. Confirm that the Portal shows Stopped (deallocated), not just Stopped.
  • The VM size does not support EncryptionAtHost. Standard_D2ds_v5 does support it, so this should not apply here.

help me fix EncryptionAtHost update failure on my Azure VM

Verify encryption status in the Portal
  • In the Azure Portal, navigate to vm2-webtier.
  • In the left menu, select Disks.
  • Look for the Encryption at host property. It should show Enabled.

You should see both the OS disk and the data disk (disk-vm2-data) listed. All disks on this VM, including the temporary disk, are now encrypted end-to-end at the host level.

Key exam points for Encryption at Host

  • Encryption at Host provides end-to-end encryption for all VM data including temp disks and caches.
  • ADE and Encryption at Host are mutually exclusive on the same disk. You cannot enable ADE on disks with Encryption at Host enabled.
  • Existing VMs must be deallocated to enable Encryption at Host. New VMs can have it enabled at creation time.
  • SSE (the default) does NOT encrypt temp disks or caches. Encryption at Host does.

Don't see the Encryption at host property?

Make sure you are on the Disks blade for vm2-webtier, not vm1-webtier. Only VM2 has Encryption at Host enabled.

If the property is missing entirely, the Portal may still be updating after the VM restart. Refresh the page and wait 30 seconds.

help me find the Encryption at Host status in Azure Portal

Secret mission

Deploy into an Availability Zone with a Proximity Placement Group

Your Availability Set keeps VMs safe from hardware failures within a single datacenter. But what about entire datacenter outages? And what if your VMs need ultra-low latency between each other? This mission takes you beyond Availability Sets into zone-based deployment with latency optimization.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The VMs in this project incur compute charges for every minute they run, so deleting is recommended unless you plan to revisit within 24 hours.

Cost warning

Your three VMs collectively cost approximately $0.10-0.15 per hour while running. Left on overnight, that adds up to $3-5 per day.

Managed disks also incur a small storage charge (a few cents per day) even when VMs are deallocated. To stop all charges completely, delete the resource group.

Resources you used:

  • Resource group rg-az104-vm-lab (East US 2) containing all resources below.
  • VM vm1-webtier (Standard_D2ds_v5, Availability Set, Standard SSD data disk).
  • VM vm2-webtier (Standard_D2ds_v5, Availability Set, Premium SSD data disk, Encryption at Host).
  • VM vm3-webtier (Standard_F2s_v2, Availability Zone 1, Proximity Placement Group).
  • Managed data disks: disk-vm1-data (Standard SSD, 64 GB) and disk-vm2-data (Premium SSD, 64 GB).
  • Availability Set avset-webtier (free) and Proximity Placement Group ppg-webtier (free).

Keep everything running

No action needed. Choose this if you are still actively working through the lab or plan to experiment further today.

  • All three VMs will continue running and incurring compute charges (~$0.10-0.15/hour combined).
  • Managed disks will continue incurring storage charges.
  • The Availability Set and Proximity Placement Group are free resources with no ongoing cost.

Pause - I'll come back to this later

Shut down all VMs to stop compute charges. Your disks and configuration are preserved so you can restart later.

  • Deallocate all VMs in the resource group by running this command in Cloud Shell:
Get-AzVM -ResourceGroupName "rg-az104-vm-lab" | Stop-AzVM -Force
  • This fully deallocates each VM, stopping all compute charges.
  • Disk storage charges continue at a few cents per day.
  • Any dynamic public IP addresses will be released. Static IPs are retained.
  • To restart later, navigate to each VM in the Portal and click Start.

Delete - I don't want to use this again

Remove all project resources and stop all charges immediately. This cannot be undone.

  • Delete the entire resource group (and everything inside it) by running this command in Cloud Shell:
Remove-AzResourceGroup -Name "rg-az104-vm-lab" -Force
  • This deletes all VMs, managed disks, the Availability Set, the Proximity Placement Group, and any associated networking resources in one command.
  • The deletion may take a few minutes to complete. Wait for the confirmation message in Cloud Shell before closing your browser.
  • Verify the resource group is gone by navigating to Resource groups in the Portal. You should no longer see rg-az104-vm-lab in the list.

What about the EncryptionAtHost feature registration?

The EncryptionAtHost feature you registered is a subscription-level setting, not a billable resource. It stays registered on your subscription at no cost and does not need to be removed.

Nice Work!

Nice Work!

You just built a multi-VM Azure environment that covers the core compute concepts tested on AZ-104. From VM sizing and availability configuration to disk management and encryption, you now have hands-on muscle memory for the exam's scenario-based questions.

Here's what you accomplished:

  • Deployed two VMs into an Availability Set with verified fault domain and update domain distribution, then resized one from B-series (burstable) to D-series (general purpose) using the deallocate-resize-start workflow.
  • Attached managed data disks of different types (Standard SSD and Premium SSD) and understood when each type is appropriate based on performance requirements and VM compatibility.
  • Enabled Encryption at Host for end-to-end disk encryption covering OS disks, data disks, and temporary disks. You also compared this with SSE and the retiring ADE approach.
  • Secret Mission: Deployed a compute-optimized F-series VM into an Availability Zone with a Proximity Placement Group, demonstrating zone-pinning and latency-optimized placement.

Ready to quiz yourself?