Exercise 1: Why "Every AWS Region Has AZs" Doesn't Carry Over to Azure — Possible Solution
====================================================================

In AWS, every Region is guaranteed to contain multiple Availability
Zones by design -- this is a structural property of the platform
itself, true everywhere, with no exceptions to check for. A team
coming from AWS experience might reasonably assume the same universal
guarantee holds on any other cloud provider.

Azure genuinely does not work this way. Only a specific, documented
subset of Azure's own 70+ regions actually support Availability
Zones -- many others are single-datacenter regions with no zone
redundancy available inside them at all. Assuming otherwise and
designing a multi-zone architecture for a region that doesn't
actually support zones would mean the design simply can't be deployed
as intended once implementation begins.

ANSWER: This assumption is risky because it carries over a real,
AWS-specific guarantee to a provider where that guarantee doesn't
universally hold. Before designing a multi-zone architecture for a
specific Azure region, the team should explicitly check Microsoft's
own official "List of Azure regions" documentation (or query it
programmatically) to confirm that the specific region they plan to
deploy into is actually one of the documented regions that supports
Availability Zones.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies that the risk comes specifically from
transferring a provider-specific assumption across providers without
verifying it still holds, rather than treating it as a vague
"clouds work differently" caution, and names the concrete real step
(checking the documented list of AZ-supporting regions) that resolves
it.