Prepare and test your skills
Prepare and test your skills
Choosing the appropriate compute platform means matching workload control, scaling, and accelerator needs to Compute Engine (opens in a new tab), Google Kubernetes Engine (GKE) (opens in a new tab), or Cloud Run (opens in a new tab). Compute Engine is Infrastructure as a Service with full virtual machine control, GKE is managed Kubernetes orchestration, and Cloud Run is fully managed serverless containers. As control decreases from Compute Engine to GKE to Cloud Run, Google manages more of the operating system, scaling, and capacity.
Compute ownership defines who manages the operating system and capacity. Compute Engine leaves the guest operating system, kernel, machine type, and network rules to you, with support for all available NVIDIA GPUs and Google TPUs. GKE manages the Kubernetes control plane for security and availability, with Autopilot mode where Google also manages nodes and capacity and Standard mode where you manage node pools. Cloud Run manages infrastructure, operating system, and runtime, runs stateless request-driven services and jobs that exit when done, and supports only NVIDIA RTX PRO 6000 Blackwell and L4 GPUs with no TPU support.
Scaling behavior follows the execution model. Cloud Run adds instances based on requests or CPU consumption, scales to zero when idle, and bills pay-per-use rounded to the nearest 100 milliseconds. GKE scales pods with the Horizontal and Vertical Pod Autoscalers and nodes with the cluster autoscaler, and bills pay-per-cluster per hour. Compute Engine virtual machines stay running for predictable throughput and scale manually or with managed instance groups (MIGs). The same standard container image can run on Cloud Run and GKE, and traffic can flow from a Global external Application Load Balancer to both platforms for gradual migration.
Exam tip: Choose Compute Engine when the workload needs self-managed OS and kernel control, and choose Cloud Run when the workload can run in a Google-managed container that scales automatically on requests.
Building, refactoring, and deploying containers is the process of packaging code once and promoting the same immutable image from development to production on Cloud Run (opens in a new tab) or GKE. Artifact Registry (opens in a new tab) stores versioned images, Cloud Build (opens in a new tab) builds and tests them, and Cloud Deploy applies rollout logic. Refactoring moves teams from manual virtual machine deploys to automated pipelines that test the image itself.
Automated production starts when source changes trigger a build. Cloud Build compiles code from a base image, runs functional and compliance tests against the image, and pushes passing images to Artifact Registry with semantic versioning for releases and Git commit hashes for pre-releases. The team deploys that identical artifact to development, then to quality assurance, then to production, with configuration and secrets injected at deploy time. Older images are retained for rollback, and Binary Authorization can block vulnerable images from deploying.
Cloud Run runs stateless services that respond to web requests and jobs that run background tasks and exit. A revision is an immutable snapshot of image and settings that scales to zero by default, and traffic splitting across revisions enables canary and blue-green releases. GKE runs Pods on nodes behind a control plane, where a Deployment declares replicas and labels, a Service exposes Pods at a stable endpoint, and the Horizontal Pod Autoscaler changes Pod count while the Cluster Autoscaler changes node count. Use type: LoadBalancer for network load balancing and Ingress for HTTP or HTTPS load balancing with content-based routing.
Exam tip: Promote the same immutable image from development to quality assurance to production instead of rebuilding it at each stage, so the tested artifact is the deployed artifact.
Geographic distribution in Google Cloud (opens in a new tab) determines latency, availability, and failure isolation. The hierarchy runs from universe to region to zone, where each zone such as asia-east1-a has high-bandwidth connections to other zones in the same region. Placing application endpoints in the region closest to users shortens round-trip time, while wider resource scope adds built-in redundancy.
Latency optimization means selecting a region near the largest user base, such as asia-northeast1 in Tokyo for users in Japan. Traffic flows from users to the regional endpoint and then to dependent data services, so extra distance adds delay to every call. 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. Firestore Regional offers at least 99.99% monthly uptime for low latency and lower cost, while Firestore Multi-Region offers at least 99.999% for maximum durability at higher cost and potentially higher write latency.
Resource scope defines which outage can interrupt a resource and who adds redundancy. Zonal resources such as Compute Engine virtual machines, Persistent Disk volumes, and single-zone GKE clusters require you to deploy redundantly across zones. Regional resources such as regional MIGs, regional GKE clusters, regional Cloud Storage buckets, and Cloud Run services survive a single-zone failure but need cross-region replication for regional outages. Multi-region and global resources such as dual-region buckets, multi-region Spanner, VPC networks, and Pub/Sub topics resist regional failures, but global configuration errors need careful change control.
Exam tip: After you select the location of your project for App Engine and Firestore in Datastore mode, you cannot change it.
Load balancer selection in Cloud Load Balancing (opens in a new tab) depends on protocol, geography, and client location. Application Load Balancers (opens in a new tab) provide proxy-based Layer 7 routing for HTTP and HTTPS, while Network Load Balancers provide Layer 4 routing for TCP, UDP, and other IP protocols. Scope adds a second choice between global or cross-region distribution and single-region deployment.
Application Load Balancers terminate the client connection at Google Front Ends or Envoy proxies and open a new connection to backends on Compute Engine, GKE, Cloud Run, on-premises, or other clouds. Because they understand HTTP, they route by host, path, headers, and request parameters and support HTTPS termination and content-based routing. Proxy Network Load Balancers also terminate TCP connections with optional SSL offload, while passthrough Network Load Balancers preserve source and destination addresses and ports, let backends terminate connections, and return responses directly to clients through direct server return. Choose passthrough when client IP preservation or ESP, GRE, ICMP, and ICMPv6 support is required.
Global load balancers support backends in multiple regions through a single anycast IP address and terminate TLS globally for lowest latency. Regional load balancers support backends in one region only, distribute across zones in that region, and guarantee TLS terminates in that region for compliance. External load balancers serve internet clients, while internal load balancers use internal IP addresses reachable from the same VPC network or connected networks. Requests through the global external Application Load Balancer first pass Cloud Armor edge policies, then a Cloud CDN cache check, then backend policies, so unwanted traffic is filtered before backends are used.
Exam tip: Choose an Application Load Balancer for HTTP(S) URL-based routing and SSL termination, and choose a passthrough Network Load Balancer when you must preserve client source IP addresses or handle UDP, ESP, GRE, ICMP, or ICMPv6.
Continue with this study guide: Understanding the use cases for load balancers
Session affinity is the practice of sending repeated requests from the same client to the same backend so cached state can be reused. Affinity improves per-client latency for stateful work such as shopping carts, but it creates uneven load and hot instances. Affinity is a performance optimization, not a guarantee of continuity.
Affinity type must match the load balancer and traffic. Client IP affinity maps clients by source IP and works for TCP and UDP without inspecting HTTP content. Generated Cookie affinity uses a cookie created by the Application Load Balancer on the first response to return later HTTP(S) requests to the same backend. Header-based affinity routes requests with the same header value to the same backend for HTTP(S) traffic. Cookie and header affinity fit Application Load Balancers, while Client IP affinity fits Network Load Balancers (opens in a new tab) that cannot rely on HTTP content.
Except for stateful cookie-based affinity, affinity breaks when the selected instance or endpoint is removed, fails health checks and moves from healthy to unhealthy, or when its group becomes full. Adding or removing any configured or healthy backend can reshuffle assignments, and UTILIZATION balancing mode causes unpredictable breaks, so use RATE or CONNECTION mode. Cloud Service Mesh shows the same tradeoff with spray and waterfall algorithms that trade even use for extra cross-zone traffic. Resilient designs keep services stateless when possible and store required session state externally in stores such as Cloud Spanner.
Exam tip: Use RATE or CONNECTION balancing mode, not UTILIZATION, to reduce unexpected affinity breaks caused by changing group fullness.
Continue with this study guide: Enabling session affinity for performant content delivery
Managed caching with Memorystore for Redis (opens in a new tab) serves hot data from memory in sub-millisecond time instead of forcing every read to disk. Application traffic flows from clients in an authorized Virtual Private Cloud (VPC) to the cache private endpoint, which has no public IP. Monitoring metrics flow from the cache to Cloud Monitoring for tuning hit ratio and memory pressure.
Memorystore for Redis supports rich structures such as Sorted Set leaderboards, hashes for profiles, and stream-processing storage, while Memorystore for Memcached uses Auto Discovery for node-based caching. Basic Tier is a standalone instance, while Standard Tier provides cross-zone replicas, automatic failover, up to 300 GB, up to five read replicas, and a 99.9% availability SLA. Access is restricted to the authorized VPC with private IPs, plus Identity and Access Management role-based control and Transport Layer Security in transit.
Read-through loads data on first miss, write-through writes synchronously to cache and storage for freshness, and write-back writes to cache first and to storage asynchronously for write-heavy work. Memorystore for Redis Cluster uses volatile-lru eviction, which removes only least-recently-used keys with an expiration, so missing TTLs can cause out-of-memory errors at the maxmemory-gb limit. Scale Redis Cluster when maximum utilization reaches about 100% for normal writes, 85% for moderately high writes, or 65% for very high writes, and lower maxmemory-gb when system memory usage ratio exceeds 80% to preserve overhead.
Exam tip: Choose Standard Tier when you need cross-zone replicas, automatic failover, and the 99.9% availability SLA; Basic Tier is a standalone instance without that replica set.
Continue with this study guide: Implementing caching solutions (e.g., Memorystore)
API management gives apps one stable entry point while backends on Cloud Run, GKE, Compute Engine, or App Engine can change. Cloud Endpoints (opens in a new tab) manages REST and gRPC APIs through a proxy, API Gateway provides managed REST access, and Apigee adds full lifecycle management with analytics. Traffic flows from clients to the gateway or proxy and then to backends, shielding apps from backend moves.
API Gateway fronts Cloud Run, Cloud Run functions, and App Engine with hosting, logging, monitoring, traffic management, and authorization. Cloud Endpoints uses the Extensible Service Proxy (ESP) or ESPv2 to fetch service configuration and proxy requests, where ESP supports App Engine flexible environment and ESPv2 supports GKE and Kubernetes but not App Engine. Apigee uses API proxies as a facade that decouples app-facing APIs from microservices, with rate limiting, quotas, and hybrid support through Apigee Hybrid. Pairing gateways with an Application Load Balancer adds multi-region balancing, Cloud CDN caching, and Cloud Armor protection.
HTTP REST uses resource URLs and verbs with JSON, described by a machine-readable Discovery document with resources, schemas, and OAuth scopes. gRPC uses defined RPC methods with typed messages, such as ProcessOrder for unary text turns and BidiProcessOrder for bidirectional streaming with concurrent audio, text, transcripts, and order updates. ProcessOrder requires config.mode set to TEXT with INITIALIZE then SUBSEQUENT turns, while BidiProcessOrder defaults to HYBRID for real-time interaction and resumes when the client reconnects with the same session identifier.
Exam tip: ProcessOrder requires config.mode set to TEXT, while BidiProcessOrder defaults to HYBRID when mode is omitted.
API protection with Apigee (opens in a new tab) controls how much traffic reaches backends and who is allowed to call. Rate controls sit between consumers and backends so excess requests are rejected before they exhaust services. Authentication checks credentials at the proxy, and observability records every request that flows from client to proxy to backend.
Quotas limit sustained request volume over time and also cap project billing, which fits fair long-term access control. The SpikeArrest policy guards against sudden bursts and returns HTTP 429 when the configured rate is exceeded, attached to the proxy PreFlow before target logic. The global external Application Load Balancer distributes traffic only to healthy backends, while Cloud Armor edge policies filter first, Cloud CDN serves cache hits, and backend policies evaluate cache misses before fulfillment.
An API product bundles proxies, resource paths, HTTP methods, and quotas, and developer apps receive API keys tied to those products for fine-grained access. API Gateway backends allow only authenticated access, where the gateway service account needs roles/run.invoker for Cloud Run and roles/cloudfunctions.invoker for Cloud Run functions. Apigee API Monitoring tracks uptime, traffic, and errors with alerting, while Analytics tracks usage patterns and consumer behavior for capacity and billing decisions.
Exam tip: Use a quota for sustained request limits and cost control, and use SpikeArrest for sudden bursts where excess requests receive HTTP 429.
Asynchronous integration with Cloud Pub/Sub (opens in a new tab) decouples publishers from subscribers so services scale and deploy independently. A publisher sends each message to a topic, and Pub/Sub delivers a copy to every attached subscription. Eventarc (opens in a new tab) routes events from providers to destinations such as Application Integration flows or Cloud Run functions without the producer naming the consumer.
Pull delivery lets subscriber clients request messages with credentials, control rate, extend acknowledgment deadlines, and process in parallel with batched throughput. Push delivery lets the Pub/Sub server send one message per request to a public HTTPS endpoint with a non-self-signed certificate, where the client signals overload with HTTP errors. Export subscriptions write directly to an existing BigQuery table, Cloud Storage bucket, or Bigtable table with automatic scaling and no subscriber client, using Single Message Transforms only and Dataflow when heavier transformation is needed.
An Eventarc trigger matches Google, custom, or third-party events and invokes its destination, staying inactive until the integration is published. Triggers need the Eventarc and Pub/Sub APIs, an IAM service account, and same-region placement of trigger, resource, and destination for best performance. Reliability requires acknowledging Pub/Sub messages only after successful processing, using ordering keys, DeadLetterPolicy, and exactly-once delivery where needed. A Cloud Run function requests retry by throwing an exception and stops redelivery by returning normally, so processing logic must be idempotent under duplicate delivery.
Exam tip: Choose pull when the subscriber can use credentials and the client library and needs high-throughput batched control, and choose push when the subscriber needs Pub/Sub to call a public HTTPS webhook without client-library dependencies.
Defining resource requirements means matching compute, storage, and throughput to IOPS, latency, durability, and cost goals. IOPS measures small operations per second, throughput measures data moved per second, and latency measures how quickly each operation completes. Baselines come from load testing and observability, and scaling policies add or remove capacity from that baseline.
Persistent Disk provides zonal volumes and regional volumes that replicate synchronously across two zones in the same region but not across regions. Hyperdisk Balanced allows IOPS and throughput to be provisioned separately, while Hyperdisk Extreme offers higher maximums than SSD Persistent Disk. Cloud Storage regional buckets replicate synchronously across zones for low latency, while dual-region buckets with turbo replication provide a 15-minute recovery point objective across regions. Filestore provides shared NFS with synchronous replication across three zones in a region, and NetApp Volumes provides NFS and SMB with continuous availability for SQL Server failover clustering.
Compute Engine machine types balance vCPUs and memory, custom machine types size them independently for predictable workloads, and Spot VMs offer the same performance at lower cost but can be preempted. Capacity estimation uses N+1 redundancy, quota verification, and Compute Engine reservations for assured zonal capacity. MIGs scale VMs on CPU thresholds, GKE uses Cluster Autoscaler for nodes plus Horizontal and Vertical Pod Autoscalers for pods, Cloud Run scales on traffic to zero, and Bigtable scales nodes on CPU and storage load. Stateless components with session state in Memorystore for Redis scale most cleanly.
Exam tip: Spot VMs offer the same machine types, options, and performance as regular VMs — the tradeoff is that they can be preempted, so use them only for fault-tolerant work.
Continue with this study guide: Defining resource requirements for workloads
Cost optimization matches each resource to actual demand so performance stays steady while idle spend stays low. Efficiency comes from automation and analysis, performance from scaling to demand, and scalability from handling growth. Cloud Billing (opens in a new tab) reports, FinOps hub, BigQuery exports, and labels turn raw usage into accountable decisions.
Standard and Nearline storage fit frequent access, while Coldline and Archive fit infrequent and rare access. A spike in Class A or B operations on Coldline or Archive data means the data should move up to Standard or Nearline. Object Lifecycle Management moves or deletes objects by administrator rules such as age or noncurrent versions, while Autoclass adjusts classes automatically by observed access. Storage Intelligence advisor tracks object count, volume over time, cross-region egress, and throttling without custom pipelines.
Recommender analyzes CPU and memory to suggest idle VM and machine-type changes, with budgets and alerts enforcing spending limits. MIGs add or remove VMs on thresholds, GKE combines Cluster, Horizontal Pod, Vertical Pod, and Node Auto-Provisioning, and Cloud Run scales to zero when idle. Committed use discounts require one-year or three-year commitments, sustained use discounts apply automatically for continuous use, and Spot VMs offer more than 80% savings but can be preempted. Autoscaling applies to stateless MIGs; stateful MIGs preserve per-VM disks and cannot autoscale.
Exam tip: Committed use discounts require a one-year or three-year commitment, sustained use discounts apply automatically for continuous use, and Spot VMs offer the deepest discount but can be preempted.
Continue with this study guide: Optimizing for cost and resource usage
Replication mode controls how much data failover can lose and how much delay writes pay. Synchronous replication waits for standby confirmation for strong consistency and zero recovery point objective, while asynchronous replication completes locally and copies in the background for low write latency with possible lag. The choice determines whether zonal or regional failover stays fast and safe.
Synchronous replication fits short distances such as two zones in one region, where PostgreSQL WAL streaming offers RPO=0 but adds commit latency and does not survive a double fault that loses all standbys before restart. Asynchronous Replication copies Compute Engine disks from a primary region to a secondary region without waiting, giving low RPO and low RTO for disaster recovery but allowing loss of recent writes. Use only asynchronous replication for remote-region disaster recovery because synchronous cross-region writes add too much latency.
A consistency group aligns replication or cloning across multiple disks to a common point in time, where primary disks must be added before replication starts. SQL Server Always On availability groups use synchronous replication to an in-region secondary and asynchronous replication to a remote DR node, with clients connecting through a listener or internal load balancer. Cloud SQL MySQL supports asynchronous and semisynchronous modes, PostgreSQL supports synchronous WAL streaming, and read replicas promote to primary on failover with Cloud DNS redirecting clients. Dual-region Cloud Storage buckets let jobs rerun where data already exists, while duplicate Pub/Sub, Dataflow, and BigQuery pipelines in two regions provide the highest-cost no-loss streaming redundancy.
Exam tip: Use synchronous replication for zonal high availability with zero RPO, and use only asynchronous replication for remote-region disaster recovery because synchronous cross-region writes add too much latency.
Traffic splitting divides client requests across versions so releases, rollbacks, and experiments happen by routing rather than redeploying. On Cloud Run (opens in a new tab), percentages and tags split traffic across revisions, while on GKE weights in HTTPRoute resources split traffic across Services or clusters. Weight is explicit and does not react to health, while capacity, health checks, and overflow protect overloaded backends.
A Cloud Run revision is an immutable snapshot of image and settings, where only revisions assigned traffic receive requests from the service URL. A gradual rollout deploys with no live traffic, shifts 1% to 5% to the new revision, observes errors and latency, then expands in stages; a rollback returns 100% to the stable revision. Revision tags create directly addressable URLs that bypass the percentage split, so a candidate can be tested with 0% live traffic or two revisions can each receive live share for A/B testing.
GKE natively supports recreate and rolling deployments where old and new Pods coexist, while blue-green needs twice capacity temporarily and canary needs gradual weight shifts with Spinnaker, Gateway weights, or Cloud Service Mesh. Multi-cluster Gateways drain failed clusters, shed excess to clusters with spare capacity, and autoscale receiving clusters. Safe increases follow the 500/50/5 pattern: start at or below 500 transactions per second, increase by no more than 50% at a time, and wait at least 5 minutes between increases.
Exam tip: Requests to the main service URL follow the traffic percentages, while requests to a tagged revision URL go directly to that revision and ignore the split.
Orchestration and event routing decouple work from the immediate request path. Workflows (opens in a new tab) runs loosely coupled services in a defined YAML or JSON order, while Eventarc delivers events from providers to consumers without the provider naming a destination. Cloud Tasks queues asynchronous work with rate limiting, and Cloud Scheduler triggers recurring work on schedule.
Workflows separates sequencing logic from business logic and calls any HTTP-based API through serverless connectors for Cloud Run functions, Firestore, BigQuery, and Application Integration. A typical flow uploads to Cloud Storage, triggers a workflow, calls recognition APIs, then writes to Firestore only after recognition completes. Eventarc listens for events from more than 130 Google providers and routes them through Pub/Sub push subscriptions to Cloud Run, Cloud Run functions, GKE public endpoints, internal VPC endpoints via network attachment, or Workflows as runtime arguments. Choose Workflows for ordered orchestration and Application Integration for low-code mapping between business systems with different schemas.
Traffic distribution from a Kubernetes Service works best with evenly distributed incoming traffic and three or more endpoints per zone, with Cloud Service Mesh (opens in a new tab) adding application-layer routing and observability when basic distribution is not enough. Metrics, logs, and traces together show health, where log sinks support exclusion filters to control cost and alerts focus on critical thresholds to avoid fatigue. Cloud Monitoring reveals under-provisioned and over-provisioned GKE, Compute Engine, and Spark resources, while Cloud Scheduler ensures time-based tasks do not depend on manual action.
Exam tip: Traffic distribution works best with evenly distributed incoming traffic and three or more endpoints per zone for each Kubernetes Service.
Choose Compute Engine when the workload needs self-managed operating system and kernel control, choose Google Kubernetes Engine (GKE) when you need managed Kubernetes orchestration, and choose Cloud Run when the workload can run in a Google-managed container that scales automatically on requests. Compute Engine leaves the guest operating system, machine type, and network rules to you, GKE manages the Kubernetes control plane with Autopilot mode where Google also manages nodes and Standard mode where you manage node pools, and Cloud Run manages infrastructure and runtime, scales to zero when idle, and bills pay-per-use rounded to the nearest 100 milliseconds.
Application Load Balancers provide proxy-based Layer 7 routing for HTTP and HTTPS and route by host, path, headers, and request parameters with termination at Google Front Ends or Envoy proxies. Passthrough Network Load Balancers provide Layer 4 routing for TCP, UDP, and other IP protocols, preserve source and destination addresses and ports, let backends terminate connections, and return responses directly through direct server return. Choose an Application Load Balancer for HTTP(S) URL-based routing and SSL termination, and choose a passthrough Network Load Balancer when you must preserve client source IP addresses or handle UDP, ESP, GRE, ICMP, or ICMPv6.
On Cloud Run percentages and tags split traffic across revisions where only revisions assigned traffic receive requests from the service URL, while on GKE weights in HTTPRoute resources split traffic across Services or clusters. A gradual rollout shifts 1 percent to 5 percent to the new revision, observes errors and latency, then expands in stages, and a rollback returns 100 percent to the stable revision without redeploying. Requests to the main service URL follow the traffic percentages, while requests to a tagged revision URL go directly to that revision and ignore the split, and weight is explicit and does not react to health.
Choose pull delivery when the subscriber can use credentials and the client library and needs high-throughput batched control, and choose push delivery when the subscriber needs Pub/Sub to call a public HTTPS webhook without client-library dependencies. Pull lets subscriber clients request messages, control rate, extend acknowledgment deadlines, and process in parallel with batched throughput, while push lets the Pub/Sub server send one message per request to a public HTTPS endpoint with a non-self-signed certificate where the client signals overload with HTTP errors.
Last updated