Azure Virtual Machines: Sizes, Disks, and Zones (AZ-104)

Creating an Azure virtual machine comes down to a handful of decisions the portal, Azure CLI, or Azure PowerShell all ask for. Get these right and the rest is configuration you can change later.

• Image — the operating system and any pre-installed software, such as Windows Server 2022 or Ubuntu Server. The image is the starting point for the OS disk.
• Size — the combination of virtual CPUs and memory (and sometimes GPUs or fast local storage) that determines performance and price. Sizes are grouped into families, covered next.
• Administrator credentials — a username plus a password for Windows, or an SSH public key (or password) for Linux, used for your first sign-in.
• Resource group — the logical container that holds the VM and its related resources so you can manage and bill them together.
• Region — the Azure datacenter location where the VM runs; choose one close to your users and where the sizes you need are available.

Behind the scenes, creating a VM also creates supporting resources: an OS disk, a network interface (NIC) that connects the VM to a subnet, and usually a public IP. The VM attaches to the NIC; the deeper virtual network and network security group configuration belongs to the networking domain. For the exam, know that image, size, credentials, resource group, and region are the five choices every VM deployment requires.

A VM's size sets its virtual CPUs, memory, and other characteristics, and Azure groups sizes into families tuned for different workloads. Knowing which family fits a scenario is a common exam task.

The pattern to remember: general purpose (B, D) balances CPU and memory; compute optimized (F) gives more CPU per gigabyte of memory; memory optimized (E) gives more memory per CPU. Other families exist for GPUs and storage-heavy work, but B, D, F, and E cover most AZ-104 scenarios.

Resizing is straightforward but has a catch. You can change a VM's size after creation from the portal or CLI. If the new size is supported on the same underlying hardware cluster, the change applies to a running VM; if it is not, you must stop (deallocate) the VM first, resize it, and start it again. So a size change may require a brief outage — a detail the exam likes to test.

Every VM has an OS disk that holds the operating system and boots the machine, plus a small temporary disk that is ephemeral and must never store data you want to keep. For application data you attach one or more data disks. In Azure these are managed disks — Azure handles the underlying storage, replication, and availability, so you just pick a type and size.

Match the tier to the need: use Standard HDD when cost matters more than speed, Premium SSD for most production workloads, and reserve Ultra Disk for the most demanding databases. Disk caching tunes performance further — ReadOnly caching suits read-heavy database data disks, while None suits write-heavy logs; the OS disk defaults to ReadWrite. You can add data disks to a running VM and later expand a disk to a larger size (shrinking is not supported), which the exam expects you to know as an online, non-destructive operation for growth.

A single VM has no high-availability guarantee — if its host fails, the VM goes down. Azure offers two ways to spread VMs so a fault affects only part of your workload, and telling them apart is one of the most tested comparisons in this domain.

Availability zones are physically separate datacenters within one Azure region, each with independent power, cooling, and networking. By deploying VMs across two or more zones, you survive the failure of an entire datacenter. Two or more VMs spread across zones qualify for a 99.99% VM SLA — the highest single-region VM availability Azure offers.

Availability sets protect against smaller failures within a single datacenter. Azure spreads the set's VMs across fault domains (groups of racks with separate power and network, so a rack failure hits only one) and update domains (groups rebooted separately during planned maintenance, so patching never restarts every VM at once). Two or more VMs in an availability set qualify for a 99.95% SLA.

On the exam, "99.99% across datacenters" means availability zones, while "fault and update domains in one datacenter" means an availability set.

Consider a concrete decision. Your team runs a customer-facing web application on two Azure VMs behind a load balancer, and the business wants the strongest single-region availability the platform can offer, with resilience to a complete datacenter outage. Which placement do you choose?

An availability set would protect the two VMs from a rack failure or a maintenance reboot, but every VM in the set lives in the same datacenter. If that datacenter lost power, both VMs — and your web tier — would go down, and the set only carries a 99.95% SLA.

The right answer is availability zones. Deploy VM 1 into zone 1 and VM 2 into zone 2 of the same region. The two zones are physically separate datacenters with independent power, cooling, and networking, so an outage in one zone leaves the other serving traffic. This configuration qualifies for the 99.99% VM SLA, the highest single-region guarantee, and directly meets the "survive a datacenter failure" requirement. You would front the zonal VMs with a zone-redundant load balancer so requests flow to whichever zone is healthy.

The lesson generalises: when a scenario stresses surviving a whole-datacenter failure or names the 99.99% SLA, choose availability zones; when it only needs protection from rack failures and patching within one datacenter, an availability set is enough. For a fleet that also needs to scale, the next section introduces scale sets.

When you need many identical VMs that grow and shrink with demand, use a Virtual Machine Scale Set (VMSS). A scale set manages a group of load-balanced, identical VM instances and can autoscale — adding instances when CPU or a schedule crosses a threshold and removing them when demand falls — so you pay for capacity only when you need it. A scale set can also span availability zones, combining elastic scale with datacenter-level resilience, which makes it a natural fit for stateless web and application tiers.

For data protection, encryption at host encrypts VM data on the physical host machine itself. It covers the temporary disk and the disk caches, and the OS and data disk data flows encrypted from the host to Azure Storage — giving true end-to-end encryption with no performance hit, enabled per VM. It differs from Azure Disk Encryption, which runs inside the guest operating system using BitLocker on Windows or dm-crypt on Linux to encrypt the OS and data disk volumes. Both differ again from the platform's default storage-side encryption, which is always on.

The distinction the exam draws is precise: if the requirement mentions encrypting the temp disk and caches at the host, that is encryption at host; if it mentions BitLocker or dm-crypt inside the guest OS, that is Azure Disk Encryption. You enable encryption at host on the VM's disk settings after registering the feature on the subscription.

Requirements change, and you will sometimes need to relocate a VM. Azure supports three kinds of move, and the exam expects you to match each to the right tool.

Moving a VM to another resource group or another subscription is a built-in operation. In the portal, select the VM (and its dependent resources — disks, NIC, public IP), choose Move, pick the destination, and Azure validates the resources support the move before completing it. The VM keeps running and its region does not change; you are only changing which management container or billing boundary owns it. Move the related resources together so you do not leave dependencies behind.

Moving a VM to another region is different, because the VM's data physically lives in its current region. For this you use Azure Resource Mover, a service purpose-built to move resources across regions. Resource Mover validates dependencies, prepares and copies the resources to the target region, and lets you commit the move — orchestrating what would otherwise be a manual redeploy. Historically this was also done with Azure Site Recovery, but Resource Mover is the current, recommended approach for cross-region moves.

Remember the split: resource group and subscription moves are native "Move" operations; moving a VM to another region uses Azure Resource Mover. Confusing the two is a classic exam trap.