Google Cloud / Basic: Resource and Access Boundaries / Lesson 5

Locations and Failure Domains

Choose locations from service scope, data requirements, dependencies, and failure assumptions rather than a region name alone.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish zonal, regional, multi-regional, and global scope.
Explain correlated failures and retained dependency scope.
Calculate a synthetic zone-loss capacity check.

A global control plane does not make every byte global

Google Cloud services expose resources with different scopes. A Compute Engine VM is associated with a zone, a subnet with a region, and a VPC network is global. Other products have regional, dual-region, multi-region, or service-specific location choices. A project’s identity does not assign every contained resource to one universal location.

Distinguish resource-management scope from data placement, replication, and client access. A globally named endpoint can route to regional data or execution. Read each product’s location contract, not a generic cloud map, before claiming residency, availability, or latency. Service editions and features can vary by location and change over time.

Inventory each dependency’s actual scope

The first program counts declared scopes in a synthetic resource map. It deliberately contains a global network, a regional subnet, and a zonal VM. The check can expose a missing location field in design metadata, but it cannot verify that any location exists or supports the intended product. No Google endpoint is contacted.

Extend a real review to databases, secrets, artifact storage, logging, keys, and external dependencies. A regional application whose only database is in one zone can retain a zonal bottleneck. Copying just the compute tier to another location does not make the entire request path independent.

python Check synthetic scope metadata

from collections import Counter

resources = [{"name": "network", "scope": "global"}, {"name": "subnet", "scope": "regional", "location": "us-central1"}, {"name": "vm", "scope": "zonal", "location": "us-central1-a"}]
assert all(item.get("location") for item in resources if item["scope"] != "global")
counts = Counter(item["scope"] for item in resources)
for scope in sorted(counts):
    print(scope, counts[scope])

Expected output

global 1
regional 1
zonal 1

One resource is declared in each scope; these strings are inventory data, not service validation.

Failure separation also needs spare capacity

The second program models three independent named zones with four units each and a workload needing eight. Losing one leaves eight. This is arithmetic under invented assumptions, not a Google capacity guarantee, failure-independence proof, or SLA calculation. Real failover also depends on quotas, reserved/available capacity, routing, startup, and state recovery.

Distributing resources without headroom can leave a surviving fleet unable to serve normal demand. State peak load and degradation policy, and test the bottleneck dependency. Correlated regional failures or shared control/data dependencies can invalidate a simple one-zone-loss model. Name the event the design actually tolerates.

python Model one-zone-loss headroom

capacity_by_zone = {"zone-a": 4, "zone-b": 4, "zone-c": 4}
required = 8
remaining = [sum(capacity_by_zone.values()) - lost for lost in capacity_by_zone.values()]
print(f"worst_remaining={min(remaining)} required={required} fits={min(remaining) >= required}")

Expected output

worst_remaining=8 required=8 fits=True

The invented capacities leave eight after any one zone is lost; this is not a cloud reservation.

Data location and latency require complete paths

Choose a region using user location, data requirements, dependencies, feature availability, and total traffic paths. A nearby compute tier can still call a distant database. Data residency is a product/configuration question with organizational and legal context; selecting a region alone is not a universal compliance certificate. Check current service documentation and the organization’s requirements.

Replication can trade latency, consistency, recovery exposure, and cost. Synchronous and asynchronous mechanisms have different failure behavior. A multi-region label does not establish that an application automatically fails over with no data loss. Identify which data copies exist, when writes are acknowledged, and how clients find a surviving endpoint.

Record a location decision and its verification gaps

A location decision record should name service, resource scope, chosen location, dependencies, data classification, failure target, recovery objective, and current feature assumptions. Record what must be verified before deployment instead of embedding a hard-coded list of supposedly universal regions or fixed quota numbers.

For changes, examine data movement, migration consistency, identities, network paths, backups, and rollback. Moving a label in a diagram is not moving a database safely. The offline examples help reason about scope and capacity but intentionally perform no regional lookup, network test, or migration.

Common errors and fixes

A global VPC is assumed to make a VM multi-region.

Why it happens: Network scope was confused with compute placement.
How to fix it: Inventory each resource’s scope separately.
Prevent it next time: Trace end-to-end failure dependencies.

A multi-zone design fails under one-zone loss.

Why it happens: Surviving capacity or a state dependency was omitted.
How to fix it: Model headroom and recovery of every bottleneck.
Prevent it next time: Define the exact tolerated event.

A region choice is called proof of compliance.

Why it happens: Product settings and broader requirements were not evaluated.
How to fix it: Review the actual service data-location contract and organizational policy.
Prevent it next time: Record assumptions and verification responsibility.

Check your understanding

1. An application runs in two zones, but both instances depend on a single zonal database. What is the availability limitation?

Show worked solution

The compute tier is separated, but a failure of the database’s zone can still break both request paths. Review the database’s own HA/replication mode, client failover behavior, capacity, and recovery objectives. Do not label the whole application zone-resilient solely from the placement of its VMs. Each required dependency belongs in the failure model.

2. Why does the offline capacity result fits=True not establish a recovery-time objective?