Design and Plan a Cloud Solution Architecture
This domain accounts for 24% of the GCP Professional Cloud Architect exam — the largest single domain. It tests your ability to translate business and technical requirements into concrete GCP architectural decisions: selecting the right compute, storage, and networking primitives; applying high-availability and fault-tolerance patterns; choosing between serverless, containerized, and VM-based approaches; and reasoning about cost, scalability, and compliance trade-offs. Expect scenario-based questions where two or three answers look plausible; precision on service capabilities and limits is what separates correct from almost-correct answers.
Google Cloud Compute Options
| Service | Abstraction | Best For | Scaling Model | Cold Start |
|---|---|---|---|---|
| Compute Engine | VM (IaaS) | Lift-and-shift, stateful workloads, custom OS | Manual / MIG autoscaling | None |
| GKE | Container (CaaS) | Microservices, portability, stateful apps needing orchestration | HPA / Cluster Autoscaler | Seconds (node) |
| Cloud Run | Container (serverless) | Stateless HTTP/event workloads, per-request billing | Automatic 0→N | ~1–2 s |
| App Engine Standard | Managed runtime | Web apps with bursty traffic, legacy runtimes | Automatic 0→N | Milliseconds |
| App Engine Flexible | Container on VMs | Apps needing custom runtimes but managed infra | Instance-based, min 1 | Minutes |
| Cloud Functions | Function (FaaS) | Single-purpose event handlers, lightweight glue code | Automatic 0→N | ~100 ms–2 s |
Key limits to memorize:
- Cloud Run: max request timeout 3,600 seconds (60 min); max memory 32 GiB; max CPU 8 vCPU per container instance.
- Cloud Functions (2nd gen): max timeout 60 minutes; built on Cloud Run internally.
- App Engine Standard: request timeout 60 seconds (60 min for background tasks via task queues).
- GKE Autopilot: Google manages nodes; you pay per Pod resource request, not per node.
- Compute Engine MIG (Managed Instance Group): supports autoscaling, autohealing, and rolling updates.
Common traps:
- Choosing App Engine Flexible when Cloud Run is simpler and cheaper for containerized stateless workloads — Flexible has a minimum of one running instance; Cloud Run can scale to zero.
- Selecting Cloud Functions when the task exceeds 60-minute timeouts — use Cloud Run instead.
- Recommending GKE Standard when the customer wants minimal operational overhead — GKE Autopilot or Cloud Run is the lower-ops answer.
- Forgetting that GKE Autopilot does not allow privileged containers or DaemonSets.
Worked scenario: A retail company runs a monolithic Java application on-premises. They want to migrate with minimal code changes and need full control over OS packages and kernel parameters. → Compute Engine: only IaaS gives OS-level control. GKE requires containerizing; Cloud Run requires stateless containers.
Storage Selection
| Service | Type | Consistency | Best For | Max Size/Scale |
|---|---|---|---|---|
| Cloud Storage | Object | Strong (since 2021) | Blobs, backups, data lake, CDN origin | Unlimited objects; max object 5 TiB |
| Cloud SQL | Relational (MySQL/PG/SQL Server) | Strong | OLTP, <10 TB, single-region primary | 64 TB per instance |
| Cloud Spanner | Relational distributed | External consistency | Global OLTP, horizontal scale, 99.999% SLA | Unlimited (split-based) |
| Bigtable | NoSQL wide-column | Eventual (strong per row) | Time-series, IoT, >1 TB, low-latency reads/writes | Unlimited rows; min 1 node SSD |
| Firestore | NoSQL document | Strong | Mobile/web apps, hierarchical data, offline sync | 1 MiB per document |
| BigQuery | Columnar analytics (DWH) | Eventual (streaming ~seconds) | OLAP, ad-hoc analytics, petabyte scale | Unlimited |
| Memorystore | In-memory (Redis/Memcached) | N/A | Caching, session state | 300 GB per Redis instance |
| AlloyDB | Relational (PG-compatible) | Strong | High-performance OLTP, analytics hybrid | 128 TB |
Decision rules:
- Need global transactions with SQL: Cloud Spanner.
- Need sub-10 ms reads on time-series at petabyte scale: Bigtable.
- Need managed RDBMS, single-region, <64 TB: Cloud SQL.
- Need serverless SQL analytics: BigQuery.
- Need mobile SDK with offline: Firestore.
Common traps:
- Choosing Bigtable for ad-hoc SQL analytics — Bigtable has no SQL query engine; use BigQuery.
- Choosing Cloud Spanner for a small single-region MySQL workload — cost is disproportionate; Cloud SQL suffices.
- Confusing Firestore's 1 MiB document limit with storage total — total storage is unlimited.
- Treating BigQuery streaming inserts as immediately strongly consistent — there is a brief delay before streamed rows appear in queries.
- Choosing Cloud SQL for a globally distributed OLTP requiring 99.999% availability — Spanner is the correct answer.
Worked scenario: An IoT platform ingests 500,000 sensor readings per second and must serve dashboards with millisecond latency over 5 years of data (≈50 TB). → Bigtable: designed for high-throughput time-series, handles 50+ TB, sub-10 ms reads. BigQuery is too slow for millisecond dashboard queries; Cloud SQL cannot scale to that volume.
Sign in free to read the full guide
12 more sections (about 2,690 words) continue below. The first domain's study guide is free for every Professional Cloud Architect learner with a free account.