1.2.2. Regions, Zones, and Global Resources
💡 First Principle: Every Google Cloud resource is scoped to one of three geographic levels — zonal, regional, or global — and that scope determines both its failure blast radius and which other resources it can directly talk to.
A zone is a single physical facility (or set of facilities) within a region — the smallest unit of geographic isolation. A region is a specific geographic area (like us-central1) containing multiple zones, giving you resilience against a single-zone outage. Global resources exist outside any single region entirely and are reachable from anywhere in the network.
| Scope | Example Resources | Failure Domain |
|---|---|---|
| Zonal | Compute Engine VM, zonal Persistent Disk | A single zone going down affects only zonal resources there |
| Regional | Regional Persistent Disk, regional managed instance group | A whole region's outage is needed to affect it |
| Global | VPC network, HTTPS load balancer, Cloud DNS | Effectively unaffected by any single region or zone outage |
Some of the most heavily tested exam facts live here: a VPC network itself is a global resource (its subnets are regional), while a Compute Engine instance is zonal — meaning a zonal outage takes down the VM, but the VPC it lives in is completely unaffected and reachable from every other region.
⚠️ Exam Trap: Don't assume "spanning multiple zones" automatically means "highly available" without checking whether the resource type in question actually supports that scope. A zonal Persistent Disk cannot be attached across regions no matter how you configure it — achieving cross-region resilience for disk-backed workloads requires deliberately choosing a regional Persistent Disk or a replication strategy, not just picking a "bigger" zone.
Reflection Question: Why does it make architectural sense for a VPC network to be a global resource while the VM instances running inside it are zonal — what would break if it were the other way around?
