Exercise 1: Why Three Separate VPCs Are Unnecessary on GCP — Possible Solution
====================================================================

A GCP VPC network is a real, global resource - it is not scoped to
any single region the way an AWS VPC or an Azure VNet is. Subnets,
not the VPC itself, are what carry regional scope on GCP. This means
one single VPC network can hold three separate regional subnets, one
per region the team plans to deploy into, all inside the very same
network.

On AWS and Azure, a VPC/VNet is genuinely bound to one Region, so
covering three regions really does require three separate networks,
manually connected together (via VPC peering, Transit Gateway, or an
Azure equivalent) if resources in different regions need to talk to
each other. That real requirement simply doesn't carry over to GCP,
because the team's prior AWS/Azure experience assumed a per-region
network scope that GCP's own VPC model doesn't have.

ANSWER: Creating three separate VPCs is unnecessary because a single
GCP VPC network is already a global resource capable of holding
regional subnets in all three regions at once - unlike AWS or Azure,
where the network itself (not just the subnet) is scoped to one
Region, genuinely requiring multiple networks to cover multiple
regions.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the chapter's own central real structural
difference - that GCP's VPC, unlike AWS's or Azure's, is global while
only its subnets are regional - and explains why the team's prior
platform experience led them to an assumption that doesn't hold on
GCP.