Cascade Regional Airlines wants the crew-scheduling application to survive the complete loss of one entire physical Azure datacenter within its primary region, not just a rack, while still keeping the app's VMs inside that same region for low-latency access to regional storage. What should the team deploy the VMs across?
Select an answer to reveal the explanation.
Short Explanation
Losing a whole datacenter is a bigger event than losing a rack, but it's still smaller than losing an entire region. Availability zones exist for exactly that middle tier: each zone is its own physically separate datacenter, with its own power and network, but all the zones stay inside one region so latency to in-region resources stays low. That's the layer built for this specific ask.
Full Explanation
Availability zones are physically separate datacenters within the same Azure region, each with independent power, cooling, and networking, and spreading VMs across multiple zones protects against the loss of an entire datacenter while keeping the deployment inside one region for low latency to regional storage and other resources. That's exactly the resiliency layer this scenario calls for. An availability set's fault and update domains only separate racks and maintenance groupings inside a single datacenter — they don't protect against losing the whole building, so 'multiple update domains' doesn't reach the failure scope described. Using the paired secondary region is a real disaster-recovery pattern, but it's a bigger, cross-region failover designed for regional-scale disasters, and it doesn't satisfy the requirement to keep the VMs in the same region for latency reasons; it also isn't the only path to datacenter-level protection, since zones already provide that without leaving the region. Repeating 'a single fault domain across two availability sets in the same datacenter' doesn't add any real physical separation at all — both sets would still be in the same building, so a full datacenter loss would take out both regardless of how the sets are organized. As an operational check, confirm the VMs actually report different zone numbers after deployment, since simply selecting 'zonal' without specifying distinct zones can leave VMs co-located.