AZ-104 · Deploy and manage Azure compute resources · Updated August 7, 2026
Azure Availability Sets vs Availability Zones: Fault and Update Domains, SLA
An availability set protects virtual machines from failures inside a single Azure datacenter. An availability zone protects them from the loss of an entire datacenter. That one-sentence distinction is where most AZ-104 candidates start, but the exam digs deeper: it wants you to know the mechanics behind each option, the exact SLA each one earns you, and how Virtual Machine Scale Sets layer on top of both. Get the mechanics straight and the scenario questions stop being memorization and start being pattern matching.
Availability sets: fault domains and update domains inside one datacenter
An availability set is a logical grouping you create when you deploy VMs, and it exists to reduce the odds that a single hardware failure or maintenance event takes down every instance of an application at once. It does this by spreading VMs across two groupings Azure assigns automatically: fault domains and update domains.
A fault domain groups VMs that share physical infrastructure, specifically a rack, a power source, and a network switch. Each availability set spans up to three fault domains by default (the exact maximum depends on region capabilities), so a single rack-level failure can take out at most one fault domain’s worth of instances rather than the whole set. Managed disks follow the same alignment: Azure keeps a VM’s attached disks in the same fault domain as the VM itself.
An update domain groups VMs and their underlying hardware for the purpose of staggering planned maintenance reboots. An availability set can span up to 20 update domains, and Azure never restarts more than one update domain at a time during planned maintenance, giving a just-restarted domain 30 minutes to recover before the next one goes down. Put two or more VMs running the same workload into an availability set and you get both protections at once, meeting the 99.95% Azure SLA. There’s no extra charge for the availability set itself, only for the VM instances inside it.
What an availability set does not do matters just as much: it doesn’t autoscale instance count, and it doesn’t protect against a datacenter-level outage, because every VM in the set still lives inside the same physical facility and remains exposed to shared infrastructure failures like a datacenter-wide network outage.
Availability zones: physically separate datacenters within a region
An availability zone is a physically separate location within an Azure region, made up of one or more datacenters with independent power, cooling, and network. Regions that support this model each provide three availability zones, and deploying replicated VMs across two or more of them protects your application from the loss of an entire datacenter, something no availability set can do since it never leaves one facility.
Two deployment patterns matter here. A zonal deployment pins a resource to a specific zone you choose; it isolates that resource from failures in other zones but gives no automatic protection if your chosen zone goes down, since you must deploy and fail over to other zones yourself. A zone-redundant deployment spreads a resource across multiple zones automatically, and for VMs that means running replicated instances in at least two zones so a single zone failure doesn’t take the application offline.
The tradeoff for that stronger protection is latency: availability sets place VMs in close physical proximity, keeping VM-to-VM latency low, while zones are typically separated by several kilometers and target a round-trip latency under roughly 2 milliseconds. A chatty, latency-sensitive tier might deliberately stay zonal in a single zone to keep that tighter latency, accepting the zone-outage risk in exchange.
SLA differences
The SLA gap between these two options is concrete and exam-relevant:
| Configuration | SLA |
|---|---|
| Single VM, all disks on premium storage | 99.9% |
| Two or more VMs in an availability set | 99.95% |
| Two or more VMs across multiple availability zones | 99.99% |
The pattern to remember: single instance is weakest, an availability set steps you up to 99.95%, and spreading VMs across zones is the only configuration that reaches 99.99%. Availability sets and availability zones are also mutually exclusive for a given VM: it belongs to one or the other, not both, since a set is single-datacenter by definition and a zone deployment spans datacenters.
VM Scale Sets: elasticity, and two ways to orchestrate it
A Virtual Machine Scale Set (VMSS) deploys and manages a group of load-balanced VM instances whose count can grow or shrink automatically based on demand, metrics, or a schedule. That autoscaling behavior is the one thing neither an availability set nor a zone deployment provides on its own; both are placement strategies, not scaling mechanisms. Scale sets can spread instances across fault domains within a datacenter, across multiple availability zones, or both, so scale sets and zones are complementary, not competing, options.
Where candidates most often get tripped up is orchestration mode: scale sets come in two flavors, locked in at creation and never changeable afterward.
Flexible orchestration is Microsoft’s current recommendation for new deployments. It manages standard Azure IaaS VMs directly, giving you the same VM, disk, and NIC APIs a standalone VM uses, plus Azure Backup and Site Recovery support that Uniform mode lacks. Flexible sets support mixing operating systems, mixing Spot and on-demand pricing in the same set, and scale up to 1,000 instances, achieving the same 99.95%/99.99% split as availability sets and zones.
Uniform orchestration is the older model: a single VM configuration profile deploys identical instances managed as a group through scale-set-specific VM APIs rather than standard IaaS VM APIs. It’s still supported, but lacks Backup and Site Recovery integration, can’t mix operating systems within one set, and is now positioned mainly for very large homogeneous workloads (a higher instance ceiling, up to 3,000) rather than as the default choice.
Both modes support deploying across up to three availability zones, so the zone-resilience story is the same either way; the difference is manageability, API compatibility, and which auxiliary services come free.
Availability set vs. VM Scale Set vs. Availability Zones
| Feature | Availability Set | VM Scale Set | Availability Zones |
|---|---|---|---|
| Primary goal | Fault/maintenance isolation for a fixed group of VMs | Autoscaling a pool of load-balanced VMs | Protection from loss of an entire datacenter |
| Scope | Single datacenter | Single datacenter, or zone-spanning if configured | Multiple physically separate datacenters in a region |
| Autoscales instance count | No | Yes | N/A, a placement option not a scaling feature |
| SLA at two-plus instances | 99.95% | 99.95% (fault domains) / 99.99% (zones) | 99.99% |
| Mechanism | Fault domains + update domains | Load balancer + autoscale rules, plus orchestration mode | Independent power, cooling, and network per zone |
How the AZ-104 exam tests this
- A scenario asks for the highest available SLA for a set of VMs with no mention of autoscaling: the answer is VMs spread across multiple availability zones (99.99%), not a larger availability set.
- A scenario describes surviving a rack failure or planned maintenance reboot with no requirement to survive a full datacenter outage: an availability set is sufficient, and adding zones over-engineers the answer.
- A scenario mentions a region without availability zone support: fall back to an availability set as the only fault-isolation option available there.
- A scenario describes a new scale set deployment with no legacy constraint: Flexible orchestration is the recommended answer.
- A scenario mixes operating systems, or needs Backup or Site Recovery for scale set instances: that rules out Uniform orchestration, since only Flexible and standalone VMs support those capabilities.
Quick reference
- Fault domains isolate shared hardware (rack, power, network switch); update domains stagger planned maintenance reboots. Both are availability-set-only concepts, capped at up to 3 fault domains and up to 20 update domains.
- Availability zones are physically separate datacenters within a region, typically three per zone-enabled region, connected by low-latency (roughly under 2 ms) links.
- SLA ladder: 99.9% single VM on premium storage, 99.95% availability set or fault-domain-spread scale set, 99.99% VMs or scale set instances spread across multiple availability zones.
- VM Scale Sets add autoscaling on top of either placement model; Flexible orchestration is Microsoft’s current recommendation and, unlike Uniform, adds Azure Backup and Site Recovery support. Orchestration mode is locked in at creation and can’t be changed later.
- An availability set and an availability zone deployment are mutually exclusive per VM: pick one placement model, not both.
For the governance layer these compute resources sit under, see Azure management groups, subscriptions, and resource groups. For a broader map of the exam’s compute, networking, storage, and identity domains, start with the AZ-104 study guide.