A cloud architecture exists to satisfy a business outcome. The architect's first job is to extract the outcome from stakeholders, decompose it into requirements that can be validated, and document the trade-offs between candidate Google Cloud designs. The exam tests this discipline through scenario questions that frame a business situation, then ask which design choice best satisfies the stated outcome. Reading those scenarios for the explicit and implicit business constraints is the technique that distinguishes a passing architect from a candidate who reaches for the most recent Google Cloud announcement.
A useful mental model is the layered requirements pyramid. At the top sit business goals such as revenue growth, market expansion, regulatory licensing, or cost reduction. Beneath them are product strategy commitments that translate goals into market behavior, such as launching a new mobile experience in a specific region. Beneath those sit functional requirements (what the system must do), non-functional requirements (how well it must do it), and constraints (what it cannot do or use). Architecture maps the lower three layers to Google Cloud constructs while staying consistent with the top two.
Business use cases and product strategy
A business use case is a specific way a customer or operator obtains value from the system. Use cases drive scope. A retail company moving to Google Cloud may state a product strategy of unifying loyalty data across web, mobile, and in-store channels, with use cases for personalized recommendations, fraud screening, and operations dashboards. Each use case implies different latency, freshness, and consistency requirements that shape the architecture. Personalization tolerates eventual consistency for taste signals but requires sub-200 millisecond response on the recommendation API. Fraud screening must process every payment within tens of milliseconds and cannot drop events. Dashboards accept minutes of staleness but require historical depth.
Translating product strategy into architecture means writing one or two sentences per use case that name the user, the action, the data, and the success metric. The architect uses those sentences to draw service boundaries: Cloud Run hosts the recommendation API, Pub/Sub plus Dataflow handles fraud event streaming, and BigQuery plus Looker Studio serves the dashboards. The exam rewards candidates who select the smallest set of Google Cloud services that satisfies all use cases without forcing one service to serve a workload it was not designed for.
💡 Exam Trap: Scenarios often describe a product strategy goal such as "expand to Europe within six months" without naming the technical constraint. The implicit constraint is data residency. Correct answers route European user data to European regions and pin storage to
europe-*locations; distractors place the workload in a global multi-region without addressing residency.
Identifying functional and non-functional requirements
Functional requirements describe behavior: "the system must allow a customer to redeem loyalty points during checkout." Non-functional requirements describe quality attributes: availability, latency, throughput, durability, capacity, security posture, and operational characteristics. The architect captures both as testable statements with numeric targets. A non-functional requirement such as "highly available" is not testable; "the checkout API returns a 2xx response within 300 milliseconds at the 99th percentile during peak hour" is testable.
Non-functional requirements drive most Google Cloud service selection. Availability targets push designs toward regional managed services (Cloud SQL with high availability, Spanner regional, GKE regional clusters) or multi-region designs (Spanner multi-region, Cloud Storage multi-region buckets, global external Application Load Balancer). Latency targets dictate region choice, Premium Tier networking, and Cloud CDN. Throughput targets shape autoscaling configuration, partitioning strategies, and quota requests submitted before launch.
📊 Limit: A regional external Application Load Balancer and a global external Application Load Balancer carry different feature sets. The global product supports cross-region failover and Cloud CDN integration; the regional product supports specific compliance scenarios where traffic must stay in one region. Selecting the wrong tier breaks the non-functional requirement it was meant to satisfy.
Business continuity plan
A business continuity plan (BCP) defines how the organization keeps operating when a component, region, or supplier fails. The architecture must implement the BCP, not invent it. The two numeric targets that drive design are the recovery time objective (RTO), which sets how long the system may be unavailable, and the recovery point objective (RPO), which sets how much data may be lost. Tight RTO and RPO require active-active or active-passive multi-region designs; relaxed RTO with relaxed RPO allows backup-and-restore.
Google Cloud building blocks for BCP include Spanner multi-region instances (synchronous replication across regions, RPO of zero, RTO measured in seconds), Cloud SQL cross-region read replicas with promotion (RPO of seconds, RTO of minutes), Cloud Storage turbo replication for dual-region buckets (RPO of fifteen minutes for newly written objects in a dual-region bucket), Backup and DR Service for VM-based and database workloads, and Cloud DNS with health checks for failover routing. The architect picks the combination that meets the stated targets without overspending on the rest.
Cost optimization
Cost optimization on Google Cloud is a continuous discipline, not a launch checklist. Architects design with commitment levels in mind: on-demand for unpredictable workloads, committed use discounts (CUDs) for predictable baselines, sustained use discounts (SUDs) for Compute Engine workloads that run a large fraction of the month, spot VMs for fault-tolerant batch and stateless serving, and autoscaling to size capacity to actual demand. Storage cost follows the access pattern: Standard for hot, Nearline for once-per-month access, Coldline for once-per-quarter, Archive for once-per-year, each with documented minimum storage durations and retrieval costs.
Network egress and inter-region traffic are the costs scenarios most often hide. Moving processing close to the data, choosing regional rather than multi-region storage when traffic does not cross regions, and using Private Google Access to keep traffic on Google's network all reduce egress. Cloud Storage egress to the public internet is charged; egress to Google Cloud services in the same region is free. Designing the data plane to minimize cross-region writes is one of the highest-impact cost decisions an architect makes.
⚠️ Anti-Pattern: Picking Cloud Storage multi-region buckets as a default for analytics datasets that are only ever read by BigQuery in
us-central1. The bucket should be regional inus-central1to remove cross-region traffic and reduce both storage and egress cost without changing the application.
Supporting the application design
Architecture supports the application; the application does not bend to the infrastructure. A microservice application with independent release cycles maps to Cloud Run or GKE; a monolith being lift-and-shifted maps to Compute Engine managed instance groups or GKE depending on team skill. Event-driven applications map to Pub/Sub, Eventarc, and Cloud Run functions. Batch and analytics workloads map to Dataflow, Dataproc, or BigQuery depending on whether the team writes Apache Beam pipelines, Apache Spark jobs, or SQL.
The architect documents the application's runtime model, persistence model, integration model, and operational model, then picks the Google Cloud services that fit each model. When two services could fit, the architect picks the one with the least operational burden that meets the requirements, because operational overhead compounds with every service in the architecture.
Integration patterns with external systems
External integrations include partners, software-as-a-service applications, on-premises systems, and other cloud providers. The architecture must name the integration pattern and the Google Cloud service that implements it. Synchronous request and response integrations use Cloud Endpoints, Apigee, or direct HTTPS calls. Asynchronous integrations use Pub/Sub topics with subscriptions, Eventarc triggers, or scheduled jobs in Cloud Scheduler. File-based integrations use Cloud Storage with object notifications, Storage Transfer Service for recurring transfers, and the Storage Transfer Service for on-premises sources for pulls from data centers and other clouds. Database integrations use Datastream for change data capture from supported sources into BigQuery or Cloud Storage.
When the external system is on the public internet, the architect specifies authentication (OAuth, mutual TLS, signed URLs), authorization (IAM conditions, VPC Service Controls perimeters with access levels), and rate limiting (Apigee policies, Cloud Armor security policies). When the external system is on a private network, the architect specifies the connectivity option: Cloud VPN for low-throughput encrypted tunnels, Cloud Interconnect (Dedicated or Partner) for high-throughput private connectivity, Private Service Connect for consuming services privately, and Cross-Cloud Interconnect for direct private connectivity to other cloud providers.
Movement of data
Data movement design separates one-time migration from ongoing flow. One-time migration uses Storage Transfer Service, Transfer Appliance for petabyte-scale offline transfer, Database Migration Service for supported source databases, and BigQuery Data Transfer Service for software-as-a-service sources. Ongoing flow uses Pub/Sub for event streams, Datastream for change data capture, Dataflow for transformation, and Cloud Composer for orchestrating multi-step pipelines.
The architect chooses the movement pattern based on volume, frequency, latency, and source system. A 200 terabyte initial migration over a one gigabit per second link would take more than twenty days of continuous transfer; Transfer Appliance shortens that to a shipping window. A real-time clickstream of one hundred thousand events per second requires Pub/Sub plus Dataflow streaming, not micro-batches. A nightly extract from a partner ftp drop requires Storage Transfer Service with a scheduled job.
💡 Exam Trap: Scenarios that mention bandwidth-constrained sites or air-gapped data centers expect Transfer Appliance even when the data volume is "only" tens of terabytes; doing the bandwidth math against the available link is part of the answer.
Design decision trade-offs
Every architecture decision has trade-offs. The exam frequently presents two valid Google Cloud services and asks which fits the scenario. Cloud Run and GKE Autopilot can both run a containerized API; Cloud Run optimizes for operational simplicity and request-driven scaling to zero, while GKE Autopilot optimizes for Kubernetes ecosystem integration and long-running workloads with custom networking. Spanner and Cloud SQL can both serve transactional workloads; Spanner optimizes for global scale and strong consistency at global scope, while Cloud SQL optimizes for compatibility with existing PostgreSQL or MySQL workloads at lower entry cost.
The architect documents each major decision with the alternatives considered, the criteria applied, and the rationale for the choice. This is the artifact that survives a design review and that scenario questions reward when the candidate matches stated criteria to the service that wins on those criteria.
Workload disposition strategies
Workload disposition is the build, buy, modify, or deprecate decision for each existing application or new capability. The architect classifies each workload by business value and technical fit. High-value workloads with poor cloud fit get modified (refactor, replatform, or rebuild). Low-value workloads get deprecated or replaced with a software-as-a-service offering. New capabilities follow a buy-first stance for commodity functions (authentication, content delivery, observability) and a build stance for differentiating capabilities. Google Cloud Migration Center supports this classification with a fit analysis that aligns with the seven Rs: rehost, replatform, refactor, repurchase, retire, retain, and relocate.
Success measurements
A design without measurements cannot prove it met the requirements. The architect defines key performance indicators (KPIs) such as conversion rate, average order value, mean time to recovery, and customer satisfaction; return on investment (ROI) calculations that compare lifetime cost to lifetime benefit; and operational metrics such as latency percentiles, error rate, saturation, and traffic. Cloud Monitoring service-level objectives (SLOs) operationalize these measurements with service-level indicators, error budgets, and burn-rate alerts. The architecture diagram identifies which Google Cloud component produces which metric and where it lands.
Security and compliance
Security and compliance are non-functional requirements that constrain every layer of the design. The architect specifies the resource hierarchy (organization, folders, projects), the IAM model (groups, roles, service accounts, conditional grants), the data protection model (Cloud KMS keys, customer-managed encryption keys, Cloud HSM, Cloud External Key Manager), the network protection model (VPC Service Controls perimeters, hierarchical firewall policies, Cloud Armor), and the compliance posture (the certifications and frameworks the workload claims, such as SOC 2, ISO 27001, HIPAA, PCI DSS). Compliance is not a single setting; it is a documented chain from policy to control to evidence.
Observability
Observability is the property that lets operators answer "what is happening" and "why is it happening" without redeploying. Google Cloud Observability provides Cloud Logging, Cloud Monitoring, Cloud Trace, Cloud Profiler, and Error Reporting. The architect designs the telemetry surface: structured logs with severity and trace IDs, metrics with cardinality limits, distributed traces with sampling rates, and synthetic checks for critical user journeys. Designs that omit observability fail in production even when they pass acceptance testing, which is why every section of the Well-Architected Framework includes operational excellence references to observability.
🎯 Scenario: A retailer launches a checkout API on Cloud Run with three percent error rate after deployment. The on-call engineer cannot identify which downstream call is failing because logs lack a correlation ID. The architect's fix is structural: enforce OpenTelemetry instrumentation, propagate the
x-cloud-trace-contextheader through every service call, and add a Cloud Monitoring dashboard with per-dependency latency and error rate. The same trace and log entries then point to a misconfigured Cloud SQL connection pool.
Decision anchor: business requirements
Choose a regional, single-tier Google Cloud design when the business requires the lowest cost and accepts an RTO of hours with an RPO of fifteen minutes. Choose a multi-region active-passive design when the business requires an RTO of minutes and an RPO of seconds. Choose a multi-region active-active design when the business requires an RTO measured in seconds with an RPO of zero and accepts the cost and consistency model of synchronous global replication.