Azure Virtual Machines for AZ-104: Disks, Encryption and Availability

Introduction

Azure virtual machine administration for AZ-104 combines sizing, managed disks, encryption at host and resilient placement. This lesson continues the skills area Deploy and manage Azure compute resources (20–25% of the exam). The study guide objective is create and configure virtual machines: create a virtual machine, configure encryption at host, move a virtual machine to another resource group, subscription or region, manage virtual machine sizes, manage virtual machine disks, deploy virtual machines to availability zones and availability sets, and deploy and configure an Azure Virtual Machine Scale Set.

Virtual machines are the most traditional Azure compute service and the one where the administrator has the most responsibility: you choose the size, the disks, the network placement, the resilience model and the encryption. Questions are scenario based: a workload has a requirement for performance, availability, security or cost, and you must pick the feature or the command that satisfies it.

After this lesson you will be able to build a VM with the right size, disks and availability design, protect its disks with the right encryption, resize or move it, and scale identical instances with a scale set.

Learning objectives

• Create a VM and describe the resources that belong to it (disk, NIC, public IP, NSG).
• Choose a VM size family and resize a VM, knowing when a restart or deallocation is required.
• Compare managed disk types and explain the temporary disk.
• Compare server-side encryption, customer-managed keys, Azure Disk Encryption and encryption at host.
• Move a VM between resource groups, subscriptions, regions and zones.
• Design for availability with availability sets, availability zones and scale sets, and configure autoscale.

Build reproducible configurations using ARM templates and Bicep deployments.

Creating a virtual machine

A VM creation wizard asks for:

• Subscription, resource group, name and region. The region decides latency, price, available sizes and zones.
• Availability options: no infrastructure redundancy, availability zone, availability set or scale set.
• Image: a marketplace image (Windows Server, Ubuntu, etc.), a custom image or an image from an Azure Compute Gallery.
• Size: vCPU, memory, maximum data disks, network bandwidth and disk throughput.
• Administrator account: username and password, or an SSH public key for Linux (recommended).
• Disks: OS disk type, optional data disks, encryption options.
• Networking: virtual network, subnet, public IP, network security group (NSG) and inbound ports.
• Management and monitoring: boot diagnostics, managed identity, auto-shutdown, backup, guest-level monitoring.

The portal creates companion resources: an OS managed disk, a network interface (NIC) and optionally a public IP address and NSG. The disk/NIC DeleteOption and associated resource settings determine which resources are removed with the VM. Defaults vary by creation method; inspect them before deletion and check for remaining billable disks or IPs afterwards.

az group create --name rg-vm --location westeurope
az vm create \
  --resource-group rg-vm \
  --name vm-web01 \
  --image Ubuntu2204 \
  --size Standard_D2s_v5 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --zone 1 \
  --public-ip-address "" \
  --vnet-name vnet-app --subnet web

The Bash example assumes the existing vnet-app/web subnet is available to the VM and that you have a private connectivity path. The following PowerShell example is an alternative Windows deployment, rather than a second command to run against the same VM name:

New-AzVM -ResourceGroupName rg-vm -Name vm-web01 -Location westeurope `
  -Image MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:latest -Size Standard_D2s_v5 `
  -Credential (Get-Credential) -Zone 1

Connecting

Use RDP (port 3389) for Windows and SSH (port 22) for Linux. Exposing those ports to the internet is risky; prefer Azure Bastion (browser-based RDP/SSH over TLS with no public IP on the VM), just-in-time access in Microsoft Defender for Cloud, or a VPN. Bastion is covered in the networking domain.

For private RDP/SSH access and traffic controls, see securing Azure virtual networks.

Power states and billing

Do not rely on a legacy dynamic public IP persisting after deallocation; current Standard public IP designs use static allocation. Temporary/local disk contents are not durable and can be lost on deallocation, redeployment or host changes. A normal restart does not imply guaranteed loss, but this storage is never a persistence guarantee.

Sizes

VM sizes are grouped in families:

Resizing a VM

Resizing changes the vCPU and memory allocation. Two cases:

1. The new size is available on the hardware cluster currently hosting the VM: the VM is restarted to apply the new size.
2. The new size is not available on that cluster: you must stop (deallocate) the VM first, so Azure can place it on a cluster that supports the size; the VM then starts again.

Resizing is not possible if the target size is not available in the region, if the VM is in an availability set whose cluster cannot host it (deallocate all VMs in the set, resize and restart), or if the target size does not support features that the VM uses (for example premium storage, the number of data disks or accelerated networking). Check available sizes with az vm list-vm-resize-options or the portal's Size blade, and check your subscription vCPU quotas per region and family, which can block a resize or a scale-out.

az vm deallocate --resource-group rg-vm --name vm-web01
az vm resize --resource-group rg-vm --name vm-web01 --size Standard_D4s_v5
az vm start --resource-group rg-vm --name vm-web01

Managing disks

Every VM has an OS disk and may have data disks; sizes with host-local storage also have a temporary disk (local SSD on the host, exposed as D: on Windows and /dev/sdb on Linux). The temporary disk holds the page file or swap and scratch data; it is not persistent, so never store anything important on it. Some newer sizes have no temporary disk.

Managed disk types

Use managed disks for all new deployments: Azure handles the storage accounts, scales better and supports zones, snapshots and encryption sets. Unmanaged disks are a retired legacy model; use managed disks rather than designing new VMs around account-managed VHD page blobs. Premium SSD v2 and Ultra disks do not support host caching; select compatible VM sizes, zone/regional placement and disk settings from the current support tables.

Operations you should know:

• Add a data disk: create or attach a disk, then initialize and format it inside the guest operating system. Attaching alone does not make it usable.
• Expand a disk: increase the size in Azure (the VM may need to be deallocated for some disk types and VM combinations, though many support live expansion), then extend the partition and file system in the OS. Disk sizes can only grow, never shrink.
• Change the disk type (for example Standard SSD to Premium SSD): deallocate the VM, change the account type of the disk, then start the VM.
• Detach and reattach a data disk to a different VM in the same region (not simultaneously, unless the disk is a shared disk).
• Snapshots and images: a snapshot is a point-in-time copy of one disk; an image captures an OS/data disk configuration for reuse. Azure Compute Gallery supports generalized and specialized images; a snapshot of one disk is not a complete multi-disk application-consistent VM backup.
• Disk caching (ReadOnly, ReadWrite, None): use ReadOnly for read-heavy data disks, None for write-heavy data such as database logs, ReadWrite for the OS disk by default.

Disk encryption

Four mechanisms are easily confused:

Facts to remember:

• All managed disks are encrypted at rest by default with SSE and platform-managed keys. You do not have to enable anything.
• ADE (legacy) uses a VM extension and requires a Key Vault in the same region and subscription, with the vault enabled for disk encryption. Linux requirements are stricter (supported distributions, certain volume types). ADE does not encrypt the temporary disk on all configurations unless a specific option is set. Legacy compatible VMs use az vm encryption enable. ADE is scheduled for retirement on September 15, 2028: migrate before then, because encrypted disks may fail to unlock after reboot. New designs should use encryption at host or an appropriate confidential-VM design, rather than adopt ADE.
• Encryption at host must be enabled on the subscription as a feature (Microsoft.Compute/EncryptionAtHost) and requires a supported VM size. It encrypts the temporary disk and the OS/data disk caches, and gives end-to-end encryption. It cannot be enabled on a VM that currently has, or previously had, ADE. Decrypting an ADE volume is not enough to make the same VM eligible; follow the supported migration/rebuild procedure. Temporary and ephemeral OS disks use platform-managed keys. OS/data disk caches follow the disks' platform-managed or customer-managed key configuration.
• A disk encryption set is the resource that links disks to a Key Vault key for customer-managed keys.
• The current AZ-104 objective explicitly names encryption at host. Understand ADE to interpret legacy estates, but prioritize supported host encryption, disk encryption sets and their prerequisites for this objective. Managed-disk SSE does not by itself cover local temporary storage; some newer VM families separately encrypt temporary/ephemeral OS disks with platform-managed keys by default.

Worked example: meeting an encryption requirement

Scenario. Litware must encrypt VM data so that even the temporary disk and caches are encrypted before leaving the host, without installing agents or using BitLocker in the guest. Litware requires customer-managed keys for persistent OS/data disks and their caches, and accepts platform-managed keys for temporary/ephemeral OS storage.

Reasoning.

1. SSE with platform-managed keys is automatic but does not encrypt the temporary disk, and Litware wants to control keys.
2. ADE encrypts inside the guest but needs an extension and BitLocker, which Litware wants to avoid.
3. Encryption at host covers temporary disks and caches. Combine it with a disk encryption set for the persistent disks so their caches use customer-managed keys. The temporary disk still uses a platform-managed key.

Solution. Register the EncryptionAtHost feature, choose a supported VM size, enable encryption at host on the VM, and use a disk encryption set for customer-managed keys.

Why the others are worse. Managed-disk SSE alone does not configure end-to-end host encryption. ADE requires guest encryption and is incompatible with encryption at host. If the requirement instead demanded a customer-managed key for every temporary disk, this design would not satisfy it; the platform-managed-key limitation must be addressed explicitly.

Moving virtual machines

The Move to another region experience in the portal is Resource Mover. A resource group move does not move the VM between regions: the resource group is only a logical container.

Availability

Azure offers three infrastructure resilience models for VMs.

A single VM using premium SSD or Ultra disks has a 99.9% SLA. Availability sets are chosen at creation, and adding an existing standalone VM to a set or changing its set requires recreating the VM while preserving the required disks and configuration; deallocation alone is insufficient. Choose compatible disk and public-IP placement for a zonal VM. Eligible regional VMs now have a documented one-way migration to a zone after deallocation and feature registration; other topology changes need their own supported procedure. Pair a zone-redundant load balancer or Application Gateway with VMs in different zones so that clients keep reaching healthy instances. For zonal designs, the VM disks and public IP must be in the same zone as the VM (zonal) or zone-redundant.

Do not mix concepts: you cannot place a VM in both an availability set and a specific zone.

Worked example: choosing between sets and zones

Scenario. Wingtip runs a three-VM web tier in West Europe and needs protection from the loss of an entire datacenter. The region supports availability zones.

Reasoning.

1. Availability sets protect against rack and maintenance events inside one datacenter; a datacenter-wide failure would take all three VMs.
2. Availability zones place VMs in separate datacenters; losing one zone leaves two VMs.
3. The SLA improves from 99.95% to 99.99%.

Solution. Deploy the VMs across zones 1, 2 and 3 with Standard SKU public IPs or a zone-redundant load balancer.

Why not an availability set? It cannot survive the failure of the datacenter itself. Why not a single larger VM? Single instances have no redundancy for host maintenance and a lower SLA.

Virtual Machine Scale Sets

A Virtual Machine Scale Set (VMSS) manages a group of load-balanced VMs and can automatically increase or decrease the number of instances.

Orchestration modes

The orchestration mode is immutable after creation. Zones are different: supported scale sets can add availability zones using API 2023-03-01 or later. Expanding the zone list does not automatically move existing instances; add new zonal capacity and drain/migrate old instances using the documented procedure. The generic expansion flow does not allow removing zones or reverting to regional placement.

Autoscale

Autoscale adjusts instance counts based on rules:

• Metric-based: for example, scale out by 2 when average CPU > 70% over 10 minutes; scale in by 1 when average CPU < 30% over 10 minutes.
• Schedule-based: for example, 10 instances on weekdays 08:00–18:00, 3 otherwise.
• Limits: minimum, maximum and default instance counts.
• Cool-down: wait time after a scale action before the next one, which prevents flapping.
• Manual scale: set the instance count directly.

The scale-in threshold should be well below the scale-out threshold; otherwise, the scale set oscillates. Autoscale actions rely on the metrics being available, so the scale set must be healthy and quotas must be sufficient for the maximum count.

az vmss create --resource-group rg-vmss --name vmss-web \
  --image Ubuntu2204 --instance-count 2 --vm-sku Standard_D2s_v5 \
  --orchestration-mode Flexible --zones 1 2 3 \
  --admin-username azureuser --generate-ssh-keys

az monitor autoscale create --resource-group rg-vmss \
  --resource vmss-web --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name autoscale-web --min-count 2 --max-count 10 --count 2

az monitor autoscale rule create --resource-group rg-vmss --autoscale-name autoscale-web \
  --condition "Percentage CPU > 70 avg 10m" --scale out 2
az monitor autoscale rule create --resource-group rg-vmss --autoscale-name autoscale-web \
  --condition "Percentage CPU < 30 avg 10m" --scale in 1

Updates to the scale set model are applied according to the configured Manual, Automatic or Rolling upgrade policy. Current documentation covers Flexible as well as Uniform modes. Rolling upgrades require the Application Health Extension for Flexible; Uniform can use an application health extension or load-balancer health probe. A scale set and autoscale rules alone do not configure HTTP health checks or a traffic-distribution endpoint.

Comparison: which resilience or scale feature?

Pitfalls and exam tips

• Stopped is not deallocated. Shutting down inside the OS still bills compute.
• Temp disk is ephemeral. Do not store databases or logs there.
• Resize can require deallocation. If a size is missing from the resize list, deallocate first.
• Topology changes are constrained. Eligible regional VMs support a documented one-way zonal migration; do not confuse that with arbitrary zone-to-zone moves. Scale-set zone expansion is separate and does not migrate existing instances automatically.
• ADE and encryption at host are incompatible on the same VM.
• Availability sets and zones are mutually exclusive for a VM.
• Premium disks require a premium-capable size.
• Scale set modes cannot be changed after creation.
• Quotas: a scale-out that exceeds regional vCPU quota fails (see the autoscale activity log); request a quota increase beforehand.
• Exam tip: pick the cheapest feature that meets the stated failure scope (rack, datacenter, region).

Mini case study: Fourth Coffee web tier

Fourth Coffee hosts an ordering site on one D4s_v5 VM in West Europe. After a datacenter incident the business asks for:

1. Survival of a single-datacenter failure.
2. Automatic capacity for lunch-time peaks (08:00–14:00 spikes, otherwise quiet).
3. Encryption of all host data, with security-team keys for persistent disks and their caches; platform-managed keys are accepted for temporary storage.
4. Lower cost overnight.

Proposed solution.

• Replace the single VM with a Flexible VM Scale Set across zones 1, 2 and 3, behind a zone-redundant Standard load balancer.
• Autoscale: minimum 3, maximum 12; scale out by 2 at CPU > 70% over 10 minutes, scale in by 1 at CPU < 30% over 10 minutes, plus a schedule that raises the minimum to 6 on weekdays 11:00–14:00.
• Enable encryption at host on supported instances, with a disk encryption set for persistent OS/data disks and their caches. Temporary storage uses platform-managed keys. Add the Application Health Extension before selecting a rolling upgrade policy.
• Overnight the set runs at its minimum of 3 instances.

Commentary. An availability set would not satisfy requirement 1. Metric rules react after load rises; the schedule prepares capacity before the lunch peak. Encryption at host covers temporary storage and caches, with the key ownership distinction stated above. Quota for 12 instances must be checked before go-live.

For restore points, protection policies and regional recovery, continue with Azure backup and disaster recovery.

Key terms

• Managed disk: Azure-managed block storage volume for VMs.
• Temporary disk: non-persistent local storage on the host.
• Deallocate: stop compute billing by releasing hardware.
• Disk encryption set: resource linking disks to a customer-managed key.
• Encryption at host: encryption on the VM host including temp disk and caches.
• Fault domain / update domain: failure and reboot isolation units in an availability set.
• Availability zone: physically separate datacenter group in a region.
• Autoscale: rule-based instance count adjustment.

Summary checklist

• I can create a VM and list its companion resources.
• I know when a resize needs deallocation.
• I can choose a managed disk type and know the temporary disk is not persistent.
• I can differentiate SSE, CMK, ADE and encryption at host.
• I know how to move a VM between resource group, subscription, region and zone.
• I can choose between availability sets, zones and scale sets.
• I can design autoscale rules with min, max and cool-down.

Official sources

• AZ-104 study guide: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-104 (opens in a new tab)

• Orchestration modes for Virtual Machine Scale Sets: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes (opens in a new tab)

• Azure managed disks overview: https://learn.microsoft.com/en-us/azure/virtual-machines/managed-disks-overview (opens in a new tab)

• Disk encryption overview: https://learn.microsoft.com/en-us/azure/virtual-machines/disk-encryption-overview (opens in a new tab)

• Managed disk types and placement limits (opens in a new tab)

• Server-side and host encryption key ownership (opens in a new tab)

• Enable encryption at host (opens in a new tab)

• ADE retirement and migration planning (opens in a new tab)

• Modernization and previous ADE use (opens in a new tab)

• Virtual networks and VM recreation (opens in a new tab)

• Regional-to-zonal VM migration (opens in a new tab)

• Expand scale-set availability zones (opens in a new tab)

• Scale-set upgrade policies (opens in a new tab)