Exercise 1: The AWS Subnet-Per-Zone Assumption Doesn't Apply — Possible Solution
====================================================================

In AWS, a subnet is bound to exactly one specific Availability Zone --
placing an instance in a particular AZ genuinely requires choosing the
matching subnet for that zone, since the subnet-to-zone relationship
is fixed and one-to-one. A team with AWS experience naturally applies
this same real pattern when working in a new environment: create one
subnet per zone, place instances accordingly.

Azure's real model works fundamentally differently: a Virtual Network,
and every subnet inside it, spans ALL Availability Zones in the region
at once. There's no such thing as a "zone-specific subnet" in Azure --
subnet choice and Availability Zone placement are two entirely
independent decisions, made separately when a VM is actually created.

ANSWER: This approach reflects the AWS-specific assumption that a
subnet must correspond to exactly one zone -- a real, structural
property of AWS's own VPC model that simply doesn't exist in Azure.
In Azure, the team doesn't need three separate subnets at all; a
single subnet can host VMs across all three zones, with each VM's own
zone assignment specified independently when it's created, not
determined by which subnet it happens to sit in.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the specific real assumption being carried
over incorrectly (subnet-to-zone binding) rather than vaguely saying
"Azure networking is different," and explains what the team should
actually do instead (one subnet, independent per-VM zone
assignment), directly matching the chapter's own explicit framing of
this as the chapter's biggest structural difference from AWS.