Prepare and test your skills
Prepare and test your skills
Optimize Performance through Geographic Placement is the practice of deploying application endpoints in the Google Cloud region closest to target users. Shorter physical distance reduces network round-trip time, which lowers response latency and improves user experience for applications and APIs. Traffic flows from users to the application endpoint in the selected region and then from that endpoint to dependent data services, so extra distance adds delay to every request.
Placing application endpoints close to users means selecting a region whose data center location minimizes distance to the largest user base. Google Cloud regions cover the Americas, Europe, Middle East, Asia, Australia, and Africa, with identifiers such as us-central1, europe-west3 in Frankfurt, asia-northeast1 in Tokyo, asia-southeast1 in Singapore, australia-southeast1 in Sydney, and asia-south1 in Mumbai. When users in Japan call an API hosted in asia-northeast1, request and response packets travel a short path, while serving those same users from Europe or South America adds latency on every call. Choose the region near users when latency directly affects experience, and use multiple regions with failover only when availability needs outweigh the added complexity.
Project location for App Engine and Firestore in Datastore mode (opens in a new tab) is a single, permanent setting shared by both products in a Google Cloud project. Creating a new App Engine application or creating the first Datastore mode entity sets the location for the entire project, and both services depend on that one choice. Not every region supports App Engine, including me-central1 in Doha, africa-south1 in Johannesburg, europe-west8 in Milan, and australia-southeast2 in Melbourne, so a project that needs App Engine must choose a different location. The current project location can be viewed by running the gcloud app describe command or by opening the App Engine Dashboard in the console, where the location appears in the upper right-hand corner.
Exam tip: After you select the location of your project for App Engine and Firestore in Datastore mode, you cannot change it.
Regional and multi-regional locations for Firestore represent a tradeoff between latency, availability, and cost. A regional Firestore database keeps data in one region close to the application, while a multi-regional Firestore database replicates data across regions for higher durability. Location type also determines pricing, because the cost of database operations varies by region and by region type.
| Location type | Monthly uptime SLA | Choose when |
|---|---|---|
| Firestore Regional | >= 99.99% | Low latency and lower cost matter most and a single region meets availability needs |
| Firestore Multi-Region | >= 99.999% | Maximum availability and durability outweigh higher cost and potentially higher write latency |
Regional API endpoints keep management traffic for a service inside a specific region instead of routing it globally. Compute Engine, Cloud Storage, and Cloud Trace support region-specific endpoints that follow the pattern of service plus region, such as compute.africa-south1.rep.googleapis.com, storage.us-central1.rep.googleapis.com, and cloudtrace.europe-west1.rep.googleapis.com. Some services also offer multi-region endpoints such as cloudtrace.eu.rep.googleapis.com or cloudtrace.us.rep.googleapis.com that keep traffic within the European Union or United States. In contrast, Cloud DNS uses only the global endpoint dns.googleapis.com, so its control traffic is not constrained to one region.
Latency monitoring for App Engine measures how long the application takes to respond, whether the cause is unoptimized code, insufficient resources, or busy machines. High latency often leads to 5xx errors, so rapid detection lets teams act before failures spread to users. Cloud Monitoring Metrics Explorer tracks App Engine latency with Resource Type GAE Application and Metric Response latency, with optional filters by service module, while the App Engine Dashboard provides a Latency graph that can be filtered by service, version, and interval.
An alerting policy in Cloud Monitoring notifies operators when response latency crosses a threshold. The ordered workflow creates the policy in sequence:
After creation, the policy appears in the Alerting list, and the service sends an alert to the selected channel when an incident is detected. For debugging, Cloud Logging separates automatically written request logs, which include HTTP method and response code for each request, from application logs written by code. Cloud Trace then shows how a slow request propagates through the application, linking the high-latency response back to the specific service call that caused it.
Design for high availability and disaster recovery is the practice of spreading applications and supporting services across multiple failure domains so a zonal or regional outage does not stop business operations. Resilient architectures place compute clusters in at least two different zones or regions and add replication for failover and recovery. Data, build, traffic, and name-resolution layers each need their own redundancy strategy so no single location becomes a single point of failure.
Multi-zonal and cross-regional distribution means running copies of an application in at least two zones or regions with replication keeping them ready for failover. If one zone or region loses power, networking, or a service, traffic and work shift to the remaining healthy location and business continuity is preserved. Replication is critical for this model because without copied data and deployable capacity, failover cannot happen quickly enough for disaster recovery. Cloud Build (opens in a new tab) private worker pools follow the same rule by deploying across at least two different regions, so continuous integration and continuous delivery (CI/CD) workflows can fail over when a regional build service has an outage.
Cloud Bigtable high availability depends on how a Bigtable AppProfile routes requests to clusters. An AppProfile configured with multi_cluster_routing_use_any can send traffic to any available cluster and enables automatic failover between clusters in different zones or regions. An AppProfile that uses single-cluster routing sends all traffic to one specific cluster, which creates a single point of failure if that cluster becomes unavailable. Choose multi-cluster routing when uptime must survive localized infrastructure outages, and reserve single-cluster routing only when strict isolation to one cluster is required.
Cloud Functions high availability across regions relies on combining functions with global traffic management instead of exposing each function directly. A function with ingress set to ALLOW_INTERNAL_AND_GCLB accepts traffic only from inside its Virtual Private Cloud (VPC) (opens in a new tab) network and from Google Cloud load balancing, which blocks direct public access to the function URL. Traffic flows from clients to the Global External Load Balancer and then from the load balancer to the healthy regional function, so the load balancer can steer requests away from an impaired region. This ingress setting is a requirement for implementing multi-regional high availability with Global External Load Balancers while keeping the function itself private.
Cloud DNS (opens in a new tab) offers global and zonal scopes with different failure domains, and the choice directly affects resilience. The default global Cloud DNS service makes private DNS names visible globally within the VPC network, which means a global control-plane problem can affect name resolution everywhere. Zonal Cloud DNS creates private DNS zones that exist only inside one Google Cloud zone, so the failure domain is contained within that zone and zonal zones are not impacted by global outages. A zonal outage affects only that specific zone and the Cloud DNS zones inside it, and any resource created in a zonal service is visible only to that zone.
The two DNS models differ in scope, visibility, and blast radius:
| Model | Scope and visibility | Failure impact |
|---|---|---|
| Global Cloud DNS | Names visible globally across the VPC network | Global outage can affect resolution in all zones |
| Zonal Cloud DNS | Zone-scoped private zones visible only in that Google Cloud zone | Global outage does not affect zonal zones; zonal outage affects only that zone |
Zonal Cloud DNS zones are commonly created for Google Kubernetes Engine (GKE) when a cluster scope is selected, and new projects can default to zonal internal DNS with the compute.setNewProjectDefaultToZonalDNSOnly organization-policy constraint. DNS scopes add finer control by attaching a private resource to a VPC network, to a GKE cluster, or to both, so multiple GKE clusters in one network can each have their own cluster.local hierarchy. Resolution starts at the most specific scope first and then walks up the hierarchy, so queries from within a cluster first check cluster-scoped zones and only after a miss fall back to network-scoped resources. A managed zone or response policy becomes visible to clients only after it is bound to a selector, with supported bindings:
Exam tip: Use multi_cluster_routing_use_any for Bigtable automatic failover; single-cluster routing creates a single point of failure if that cluster becomes unavailable.
Differentiate Service Scopes and Resource Hierarchy is the framework for understanding how Google Cloud (opens in a new tab) organizes physical infrastructure into access rules and failure boundaries. At the top is the universe, a fully self-contained cloud with separate networking, such as Google Cloud itself. Within a universe are regions, independent geographic areas, and each region contains zones, such as asia-east1-a. Zones have high-bandwidth, low-latency connections to other zones in the same region.
A region or zone acts as a failure domain, meaning a group of resources that can fail independently of other groups. The location scope of a resource — zonal, regional, multi-region, or global — defines which other resources can use it and which outage can interrupt it. For example, creating a Virtual Private Cloud (VPC) network is a global operation, while reserving a static external IP address is a regional operation, and a persistent disk can only be attached to a computer in the same zone.
Zonal resources are hosted within a single zone, so a service interruption in that zone can affect all of those resources in that zone. A zone outage defines the expected boundary of the incident and does not necessarily mean all infrastructure in that zone is unavailable. Zones are designed so a failure in one zone usually does not affect resources in other zones in the same region.
Common zonal resources include:
If you use zonal resources, you must build protection across zones yourself. Traffic can flow from Cloud Load Balancing to VMs in another zone when a health check detects a problem, identical VMs can run and scale across zones with instance templates and managed instance groups, and data can flow synchronously to another zone with a regional Persistent Disk.
Regional resources are deployed redundantly across multiple zones within a region by delivering service from a composition of those zones. If one backing zone is interrupted, the regional resource automatically makes itself available from another zone. This gives regional resources higher reliability than zonal resources, but a regional outage affecting more than one zone can still affect some or all regional resources in that region.
Common regional resources include:
To stay resilient to regional outages while using regional resources, you must compose failover across regions yourself. Data should flow by replication to a secondary region, to multi-regional storage such as Cloud Storage, or to a hybrid option such as GKE and Google Distributed Cloud. After the mitigation is in place, test it regularly so failover works when a real outage occurs.
Multi-region resources are distributed within and across specific regions to resist region outages by serving from multiple regions. In general, multi-region resources have higher reliability than regional resources. An outage that spans multiple regions can still affect multi-region resources provisioned in the affected regions.
Common multi-region resources include:
Multi-region products trade off latency, consistency, and cost, most often through synchronous versus asynchronous replication. Asynchronous replication offers lower latency but risks data loss during an outage, so the product capability details matter for recovery time and recovery point decisions.
Exam tip: In BigQuery, a multi-region location does not provide cross-region replication or regional redundancy; data is stored in a single region within the geographic location.
Global resources are available across all Google Cloud locations and do not rely on infrastructure in any specific region. Global resources are resilient to zonal and regional incidents, and Google Cloud uses monitoring and processes to minimize the risk of global outages. Because of this wide scope, a single global resource is easier to set up than operating many regional copies.
Common global resources include:
Global configuration is globally scoped, so a critical configuration error can become a single point of failure across all geographies. Manage changes to global resources carefully, and for very high availability needs use regional defense-in-depth fallbacks. For example, clients can prefer a global load balancer but fail over through Cloud DNS to the nearest regional load balancer if the global frontend is unavailable.
Choosing scope for failure isolation means matching resource scope to resilience needs, operational effort, and recovery responsibility. Wider scope provides more built-in redundancy but requires stricter change control, while narrower scope requires you to add redundancy yourself.
| Resource scope | Resilience | Mitigation responsibility |
|---|---|---|
| Zonal | Low | Deploy the resources redundantly in multiple zones or regions |
| Regional | Medium | Deploy the resources redundantly in multiple regions |
| Multi-region or global | High | Manage changes carefully and use defense-in-depth fallbacks where possible |
A combined topology shows how the scopes work together. Client requests flow to a global external Application Load Balancer, which distributes traffic to a regional MIG backend containing Compute Engine VMs in different zones. The application on the VMs reads and writes to a Cloud SQL deployment configured for high availability, where the primary database replicates synchronously over Hyperdisk Balanced High Availability volumes to a standby in another zone. Database backups flow to a multi-region Cloud Storage bucket, while the global VPC network contains regional subnets. In this flow, a zone outage may affect individual VMs or the primary database, but the regional load balancer and MIG shift traffic and Cloud SQL fails over automatically.
No, the project location for App Engine and Firestore in Datastore mode is a single permanent setting shared by both products that cannot be changed after selection. Creating a new App Engine application or creating the first Datastore mode entity sets the location for the entire project.
Use Firestore Regional when low latency and lower cost matter most and a single region meets availability needs, since it offers at least 99.99 percent monthly uptime. Use Firestore Multi-Region when maximum availability and durability outweigh higher cost and potentially higher write latency, since it offers at least 99.999 percent monthly uptime.
An AppProfile configured with multi_cluster_routing_use_any can send traffic to any available cluster and enables automatic failover between clusters in different zones or regions. Single-cluster routing sends all traffic to one specific cluster, which creates a single point of failure if that cluster becomes unavailable.
Global Cloud DNS makes private DNS names visible globally within the Virtual Private Cloud (VPC) network, so a global control-plane problem can affect name resolution everywhere. Zonal Cloud DNS creates private DNS zones that exist only inside one Google Cloud zone, so they are not impacted by global outages and a zonal outage affects only that specific zone.
Last updated