Capstone: Deploying a Simple Web Application on GCP

GCP Fundamentals

Chapter 10 · Capstone: Deploying a Simple Web Application on GCP

AWS Fundamentals and Azure Fundamentals each closed with the same small photo-upload web application, built using each provider's own real architecture. This capstone rebuilds it a third time, on GCP — the same nine dependency-ordered steps, each one using GCP's own genuinely different mechanisms explored across this course's own nine prior chapters, closing the full three-course, 30-chapter Cloud Platform Specifics project.

Step 1: Organization, Folder & Project Planning (Ch. 1)

Before creating anything, we place the project inside GCP's own real resource hierarchy — an Organization, a Folder for this application, and a Project underneath it — and choose a Region with real Availability Zone support, keeping in mind Chapter 1's own caution that not every GCP region necessarily offers the same zone count.

Step 2: A Scoped IAM Role, No Long-Lived Keys (Ch. 2)

A dedicated service account is created for the application, granted a real predefined role scoped to exactly what it needs (never a basic role like Editor or Owner), and OS Login is enabled for SSH access instead of managing static SSH keys — avoiding the exact real risk category, long-lived service account keys, that Chapter 2's own case study covered.

Step 3: A Global VPC With One Regional Subnet & Cloud NAT (Ch. 5)

A Custom mode VPC network is created (per Google's own real production recommendation from Chapter 5) with one subnet in the chosen Region, and a Cloud NAT gateway attached via a Cloud Router for outbound-only internet access from private instances — no route table entry required.

Step 4: A Web Tier on a Regional Managed Instance Group (Ch. 3, Ch. 8)

Web servers run on Compute Engine, deployed via a regional Managed Instance Group (Chapter 8's own real zone-failure protection, not a zonal group alone), with a firewall rule scoped only to the necessary inbound ports and enforced via network tags.

Step 5: Cloud Storage for Uploaded Photos (Ch. 4)

Uploaded photos land in a Cloud Storage bucket with object versioning and Public Access Prevention enabled. Any temporary, shareable photo link uses a Signed URL — automatically capped at GCP's own real, platform-enforced 7-day maximum, the exact structural protection Chapter 4 contrasted against Azure's own unbounded SAS token model.

Step 6: Cloud SQL for Metadata (Ch. 6)

Photo metadata (uploader, caption, timestamp) is stored in a Cloud SQL regional instance — a PostgreSQL primary with an HA standby in a different zone of the same region — reachable only from the web tier's own subnet via a scoped firewall rule, never from the public internet.

Step 7: A Storage-Triggered Cloud Function for Thumbnails (Ch. 7)

A 2nd-generation Cloud Function — genuinely deployed as a real Cloud Run service under the hood, per Chapter 7's own central finding — triggers automatically on each new object landing in the Cloud Storage bucket, generating a thumbnail and writing it back to a separate bucket.

Step 8: A Global Load Balancer in Front of the Regional MIG (Ch. 8)

A global external Application Load Balancer fronts the web tier's regional Managed Instance Group behind one real anycast IP address — Chapter 8's own central finding, delivered here with no separate global-routing service layered on top the way an equivalent AWS or Azure build would need.

Step 9: Monitoring & an Honestly-Framed Budget (Ch. 9)

The Ops Agent is installed on every web tier instance so real memory metrics are actually collected (not just the automatic CPU/disk figures), an alerting policy watches CPU and error-rate thresholds, and a Cloud Billing budget is configured with the real default 50/90/100% alert thresholds — framed honestly per Chapter 9: this budget alerts, it does not by itself cap spending. A spend cap budget is noted as a genuine, GCP-specific option worth evaluating for this workload once it leaves preview.

Chapter Attribution: Every Step's Real Cross-Cloud Equivalent

Step	GCP Chapter	AWS Fundamentals Equivalent	Azure Fundamentals Equivalent
1. Org/Folder/Project & region planning	Ch. 1	Ch. 1 — Region/AZ planning	Ch. 1 — Region/AZ-support planning
2. Scoped IAM role, no static keys	Ch. 2	Ch. 2 — scoped IAM role	Ch. 2 — scoped Managed Identity
3. Global VPC, one regional subnet, Cloud NAT	Ch. 5	Ch. 5 — VPC, public/private subnets	Ch. 5 — single VNet spanning every AZ
4. Regional MIG web tier, scoped firewall	Ch. 3, Ch. 8	Ch. 3 — EC2, scoped security group	Ch. 3 — web VM, scoped NSG
5. Cloud Storage, versioning, capped Signed URLs	Ch. 4	Ch. 4 — S3, versioning, Block Public Access	Ch. 4 — Blob Storage, ZRS, scoped SAS tokens
6. Cloud SQL regional instance for metadata	Ch. 6	Ch. 6 — Multi-AZ RDS	Ch. 6 — General Purpose Azure SQL Database
7. Storage-triggered thumbnail function	Ch. 7	Ch. 7 — S3-triggered Lambda	Ch. 7 — Blob-triggered Azure Function
8. Global LB + regional MIG	Ch. 8	Ch. 8 — ALB + Auto Scaling Group	Ch. 8 — Application Gateway + Flexible-mode VMSS
9. Ops Agent, alerts, honest budget	Ch. 9	Ch. 9 — CloudWatch Agent, honest Budget	Ch. 9 — Azure Monitor Agent, Budget + Action Group

What's Still Out of Scope

No CI/CD pipeline for deploying application code
No CDN or WAF layer (Cloud CDN, Cloud Armor)
No DNS layer (Cloud DNS)
No multi-Region disaster recovery
No containerization of the web tier itself (beyond what Cloud Run implicitly provides for the thumbnail function)

The Same Discipline, Three Genuinely Different Toolkits

Across all three courses, the same underlying security and architecture discipline held: least privilege (IAM roles / IAM RBAC / Managed Identities), private-by-default networking (scoped firewall rules / security groups / NSGs, with GCP's own global VPC and load balancer going further than either sibling), and honest monitoring and budgeting (alerts that inform, not silently enforce, unless deliberately wired to). The real lesson of this three-course arc isn't that one provider is "better" — it's that the same real principles get expressed through three genuinely different, verifiable mechanisms, and knowing which is which is what actually transfers between them.

Hands-On Exercises

Exercise 1

A reviewer asks why the web tier uses a regional Managed Instance Group instead of a zonal one for this capstone. Explain, in your own words, the real risk a zonal MIG alone would leave unaddressed.

📄 View solution

Exercise 2

A teammate familiar with the AWS Fundamentals capstone asks why this GCP build doesn't need a separate service like Route 53 or CloudFront to get one global entry point across regions. Explain, in your own words, why not.

📄 View solution

Exercise 3

A stakeholder assumes that once the Cloud Billing budget in Step 9 is configured, GCP will automatically stop the application's own services from running if spend exceeds the budget. Explain, in your own words, whether this assumption is correct, and what real GCP feature would actually be needed to make it true.

📄 View solution

Chapter 10 Quick Reference — Course Complete

Nine dependency-ordered steps, each using GCP's own real architecture: resource hierarchy → IAM → global VPC/Cloud NAT → regional MIG → Cloud Storage → Cloud SQL → Cloud Function → global load balancer → monitoring/budget
Chapter-attribution table names each step's real AWS Fundamentals and Azure Fundamentals equivalent
Honest scope boundary: no CI/CD, no CDN/WAF, no DNS layer, no multi-Region DR, no full containerization
GCP Fundamentals is now complete — 10/10 chapters. This closes the full three-course Cloud Platform Specifics project: AWS Fundamentals, Azure Fundamentals, and GCP Fundamentals, 30 chapters total.