While preparing for the GCP Professional Cloud Architect (PCA) exam, many candidates get confused by the trade-offs involved in designing web application backends that balance reliability, cost, and scalability. In the real world, this is fundamentally a decision about leveraging managed serverless platforms vs. container orchestration for unpredictable traffic with cost constraints. Let’s drill into a simulated scenario.
The Scenario #
Fintech startup MetricaPay is launching a new global web application with a public API backend for payment processing. They anticipate generally low traffic but expect sudden usage spikes after marketing campaigns. The team wants a reliable, highly available architecture leveraging Cloud Load Balancing while keeping costs low during idle periods. The backend must also handle occasional scaling seamlessly.
Key Requirements #
Build a highly reliable web application backend with a few public APIs. Traffic is mostly low but spikes occur unexpectedly. The solution must:
- Use Cloud Load Balancing for frontend traffic distribution
- Be cost-effective in low-traffic scenarios
- Support burst scaling without complex manual intervention
The Options #
- A) Store static HTML and images in Cloud CDN. Host the APIs on App Engine and store user data in Cloud SQL.
- B) Store static HTML and images in a Cloud Storage bucket. Host APIs on a zonal Google Kubernetes Engine (GKE) cluster (worker nodes in multiple zones). Save user data in Cloud Spanner.
- C) Store static HTML and images in Cloud CDN. Use Cloud Run to host the APIs and save user data in Cloud SQL.
- D) Store static HTML and images in a Cloud Storage bucket. Use Cloud Functions to host the APIs and save user data in Firestore.
Correct Answer #
C) Store static content such as HTML and images in Cloud CDN. Use Cloud Run to host the APIs and save the user data in Cloud SQL.
Step-by-Step Winning Logic #
Cloud Run is a fully managed serverless platform that abstracts away infrastructure management and autoscaling, allowing the backend APIs to scale to zero when idle and spike to handle bursts instantly. This aligns perfectly with MetricaPay’s unpredictable traffic and cost goals.
Using Cloud CDN for static content caching optimizes performance and reduces load on origin services, while Cloud SQL provides a managed relational database with strong consistency and ease of use. Overall, this solution prioritizes SRE principles of automation and reliability with minimal operational toil. It also follows FinOps best practices by operating on a pay-for-what-you-use model, avoiding always-on infrastructure cost.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
- Why not A? App Engine is fully managed but can have higher base costs than Cloud Run for low-traffic workloads. Plus, static content should ideally be served directly by Cloud Storage + Cloud CDN for better cost/performance.
- Why not B? GKE clusters with multi-zone nodes add significant ongoing cost and operational complexity. Cloud Spanner is powerful but costly for small datasets and use cases without global multi-region consistency requirements.
- Why not D? Cloud Functions scale well for event-driven processing but have limitations for API hosting compared to Cloud Run (e.g., cold start times, concurrency). Firestore is a NoSQL database, which may not fit relational data needs.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
Mermaid Diagram illustrating the flow of the CORRECT solution.
graph TD
User([User]) --> |HTTPS| GLB["Global Load Balancer (HTTP(S) LB)"]
GLB --> CDN[Cloud CDN]
CDN --> GCS["Cloud Storage Bucket (Static Content)"]
GLB --> CR["Cloud Run (API Backend)"]
CR --> SQL["Cloud SQL (User Data)"]
style GLB fill:#4285F4,stroke:#333,color:#fff
style CDN fill:#0F9D58,stroke:#333,color:#fff
style CR fill:#4285F4,stroke:#333,color:#fff
style SQL fill:#DB4437,stroke:#333,color:#fff
Diagram Note:
User requests pass through the global HTTPS Load Balancer, with static content served via Cloud CDN backed by Cloud Storage, and API requests routed to Cloud Run hosting the backend service connected to a Cloud SQL database.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | Est. Complexity | Est. Monthly Cost (Relative) | Pros | Cons |
|---|---|---|---|---|
| A) App Engine + Cloud CDN + Cloud SQL | Low | Medium | Fully managed, easy to deploy, managed scaling | Slightly higher baseline costs, static content not optimally separated |
| B) GKE Multi-Zonal + Cloud Storage + Spanner | High | High | Highly scalable, Spanner for global consistency | Complex ops, costly, overkill for low traffic |
| C) Cloud Run + Cloud CDN + Cloud SQL | Low | Low (Pay-per-use) | Serverless autoscaling to zero, cost-effective, managed services | Potential cold start latency in rare cases |
| D) Cloud Functions + Cloud Storage + Firestore | Low | Low-Medium | Serverless, easy dev | Limited API flexibility, NoSQL database may not fit all apps |
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
For the exam, always pick Cloud Run when you see unpredictable traffic patterns and moderate backend complexity for cost optimization and ease of scaling.
Real World #
Many teams initially choose GKE for flexibility, but operational complexity and cost often outweigh the benefits. Cloud Run lets you focus on code, not infrastructure — an SRE win to reduce toil and improve reliability.