Designing and Planning a Cloud Solution Architecture
Architecture questions on this exam almost always start with a requirement that has two plausible product answers. Convert the requirement into measurable constraints before you pick a service.
Requirements first
Separate functional requirements (what the system does) from non-functional ones (availability, latency, throughput, RPO/RTO, data residency, cost ceiling, compliance scope). Non-functional drivers pick the product tier; functional ones rarely do.
Resource hierarchy
Organization → folders → projects. Projects are the boundary for APIs, quotas, billing, and IAM inheritance. Structure folders around environments or business units, and use labels for cost attribution instead of inventing a folder per team.
Compute decision tree
Stateless containers, no cluster ops → Cloud Run. Kubernetes APIs needed → GKE (Autopilot unless node control is required). Event-driven single-purpose code → Cloud Functions. Lift-and-shift VMs or licensing constraints → Compute Engine. GPUs or specialized hardware push you to Compute Engine or GKE, never Cloud Run.
Data and availability
Cloud Storage location type (regional vs dual-region vs multi-region) drives latency, durability, and egress. Cloud SQL for regional relational HA, Spanner for horizontally scalable strongly consistent global relational, Bigtable for high-throughput wide-column, BigQuery for analytics. A regional resource survives a zone failure, not a region failure; multi-region designs need actual data replication plus a global load balancer.
Traps
Equating "highly available" with "multi-region"; ignoring quota ceilings; assuming a managed service replicates across regions by default; forgetting Shared VPC when many projects must share one network.
Rule of thumb: RTO ≤ 1 hour with near-zero RPO → warm standby in a second region (continuous data replication, scaled-down app tier, global load balancer failover). RTO and RPO measured in hours → in-region backup/restore is usually sufficient and far cheaper.