Manage Virtual Machines, Disks, and Scale Sets for AZ-104
Learn the VM sizing, disk, resilience, migration, and scale-set choices that appear repeatedly on AZ-104.
Virtual machines are still one of the most operationally dense parts of AZ-104. The exam expects you to understand creation, sizing, disks, resilience options, and scale behavior well enough to make changes without introducing unnecessary downtime or fragility.
What the objective list points to
Microsoft includes creating VMs, configuring encryption at host, moving VMs to another resource group, subscription, or region, managing sizes and disks, deploying to availability zones or availability sets, and deploying and configuring Virtual Machine Scale Sets.
The decisions behind the task list
The question is usually about fit. Is this a single VM, a resilient multi-instance pattern, or a workload that should scale horizontally? Availability sets and availability zones are related but not identical. Disk choice affects both performance and cost. Encryption at host strengthens the data-at-rest story, but you still need to understand the rest of the workload design.
One accuracy point worth remembering
Moving a VM to another resource group or subscription can be an administrative move. Moving to another region is usually a migration workflow, such as rebuilding, replicating, or using region-move tooling. It is not just changing one property on the existing VM.
Common traps
- resizing a VM without considering SKU availability or restart impact
- confusing OS-disk, data-disk, and image choices
- assuming a scale set automatically solves application health or session-state problems
Lab moves worth practicing
- deploy a VM, resize it, and inspect disk settings
- compare availability set and availability zone placement
- review a scale-set configuration and connect its health and scaling settings to the application behavior
Compute pattern chooser
| Need | Strongest first fit | Why |
|---|---|---|
| One instance with basic administration needs | Single VM | Simplest operating model |
| A few related VMs needing datacenter-level fault separation | Availability set | Spreads fault and update domains |
| Higher resilience across physically separate zones | Availability zones | Protects against one-zone failure when supported |
| Elastic horizontal scaling of similar instances | VMSS | Built for scale and coordinated instance management |
High-yield admin distinctions
| Topic | What to remember |
|---|---|
| Image versus OS disk | The image is the starting template. The OS disk is the running system state after deployment. |
| OS disk versus data disk | The OS disk carries the operating system. Data disks carry workload data that often needs separate performance and backup thinking. |
| Resource-group move versus region move | Moving across resource groups or subscriptions can be an admin operation. Moving across regions is usually a migration pattern. |
| Availability set versus availability zone | Availability sets spread risk inside one datacenter pattern. Zones spread risk across physically separate zones in a region. |
Encryption, sizing, and disk questions
The exam often compresses several VM operations into one scenario, so it helps to separate them cleanly:
- encryption at host strengthens the local host-level data-at-rest posture for the VM workload
- VM sizing is a compute-capacity and cost decision, and resizing can bring restart or SKU-availability consequences
- disk management is about performance, capacity, attachment model, and recovery implications
If a question mixes all three, identify which layer is actually being changed. Azure administrators lose points when they treat a disk problem like a size problem or a move problem like an encryption setting.
What VMSS does not solve automatically
Scale sets make it easier to run and scale many similar VMs, but they do not fix weak application design. If the app stores session state locally, fails health probes, or cannot tolerate instance replacement, VMSS will expose that weakness instead of hiding it. AZ-104 often tests whether you understand that scaling infrastructure and application resilience are related but different problems.
Azure CLI example: resize a VM and create a scale set
1# Resize an existing VM
2az vm resize \
3 --resource-group app-rg \
4 --name web-01 \
5 --size Standard_D4s_v5
6
7# Create a simple scale set across zones
8az vmss create \
9 --resource-group app-rg \
10 --name web-vmss \
11 --image Ubuntu2204 \
12 --instance-count 2 \
13 --zones 1 2 3 \
14 --upgrade-policy-mode automatic
What to notice:
- resizing is an operation on an existing VM, not a redesign of the workload
- VMSS creation introduces a different operating model, not just “more VMs”
- the zone-aware scale-set example hints at resilience, but the application still must survive replacement and scale events
Quiz
Continue with Containers and App Service to round out the rest of the compute domain.