Planning and Configuring a Cloud Solution
Match workload to service
Compute: Compute Engine for full VM control, GKE for container orchestration, Cloud Run for stateless containers with no cluster to operate, App Engine for app-code-only deployment, Cloud Functions for event-driven glue. Data: Cloud SQL for regional relational OLTP up to a few TB, Spanner for globally consistent horizontally scalable relational, Firestore for document/mobile, Bigtable for high-throughput wide-column time series, BigQuery for analytics. A frequent trap is choosing Cloud SQL for a globally distributed write-heavy workload, or Bigtable for transactional queries.
Regions, zones, and high availability
Resources are regional or zonal. Real HA needs at least two zones: a multi-zone managed instance group, a regional persistent disk, or Cloud SQL with a failover replica. A single-zone MIG with autoscaling is scalable but not highly available - read the question for the word "availability."
Network design
A VPC network is global; subnets are regional. Firewall rules are stateful, attach to the network, and target instances by network tag or service account; baseline behavior is default-deny ingress and implied-allow egress. Cloud NAT provides outbound-only internet for instances with no external IP; Private Google Access reaches Google APIs privately; Shared VPC centralizes networking under a host project so many projects share subnets. Pick the load balancer deliberately: global external HTTP(S) for multi-region web, regional internal for private tiers, network LB for non-HTTP protocols.
Cost levers
Sustained-use and committed-use discounts, Spot VMs for interruptible batch work, storage class selection, and network egress dominate savings questions.
Rule of thumb: identify the hard constraint first - global consistency, latency, availability, or operational burden - and it will usually select the product for you.