Cascade Regional Airlines keeps adding VMs to a single availability set to handle a growing booking-load monitoring fleet, well past the number of fault domains that availability set offers. What happens to the resiliency benefit as the VM count grows beyond the number of available fault domains?
Select an answer to reveal the explanation.
Short Explanation
An availability set only has so many separate racks to spread you across, and that number doesn't grow just because you keep adding VMs. Once every fault domain already has a VM in it, the next VM you add has to double up and share a fault domain with one already there. More VMs past that point buys you more capacity, but not more isolation from a single rack failure.
Full Explanation
Each availability set exposes a limited, fixed number of fault domains (the exact count can vary by region and managed disk type, so it should be checked per deployment rather than assumed). VMs are distributed round-robin across those fault domains as they're added. Once the number of VMs in the set exceeds the number of fault domains, additional VMs necessarily start sharing a fault domain with a VM already placed there, which reduces the per-VM isolation the set was providing — a single rack failure can now take out more than one VM at once. This is a genuine capacity-planning gotcha: teams sometimes assume 'more VMs in the set' automatically means 'more spread out,' when in fact the spread is capped by the fixed fault domain count. The claim that Azure creates fault domains on demand is false — the count is fixed by the platform for a given set, not elastic. The claim that the set silently stops accepting new VMs is incorrect — Azure keeps accepting VMs into an availability set well past the fault domain count; it just means some VMs now share isolation boundaries, not that provisioning is blocked. The claim that every VM always gets its own dedicated fault domain is also false, since the whole point of round-robin placement is that assignment cycles back through the same fault domains once they're all in use. As an operational check, review each VM's actual fault domain assignment in the availability set rather than assuming isolation scales with VM count.