Exercise 3: Why GCP's Zone Concern Is Real But Less Critical — Possible Solution
====================================================================

The concern isn't completely baseless, because GCP's own real
documentation does describe zones as a per-region property rather
than something automatically guaranteed identical everywhere - so in
principle, checking zone availability for a specific target region is
still a real, worthwhile habit, not something to skip entirely.

However, the real, practical severity of this concern is genuinely
different between the two providers. In Azure, the chapter's own
sibling course established that only a specific, limited, documented
SUBSET of regions support Availability Zones at all - meaning a team
could easily deploy into a region with no zone support whatsoever,
with no real fallback available. In GCP, the real, documented pattern
is that the large majority of regions have zones available, typically
three per region - the exception in GCP is closer to "occasionally a
region might have a different exact zone count," not "an entire
region might have no zone concept available at all," the way Azure's
own real gap can occur.

ANSWER: The concern is reasonable to keep in mind, since GCP's zone
availability is still technically a per-region property worth
verifying - but it's less critical in practice because GCP's real
model is far more consistently uniform: the common real case is zones
being available almost everywhere, unlike Azure's genuine, documented
split between regions that support Availability Zones and regions
that simply don't have the concept at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly avoids two extremes - dismissing the concern entirely,
or treating GCP's real model as identically risky to Azure's - and
instead explains the genuine, real difference in severity between the
two providers' own documented zone-availability patterns, matching
the chapter's own tip-box framing of "more uniform," not "risk-free."