Google Cloud Fundamentals — The Hard Way: A Break-and-Fix Learning Series

Overview

Most cloud onboarding tutorials optimize for one outcome: getting a
resource into a RUNNING state as fast as possible. That approach
teaches syntax, but it doesn't teach the skill that actually matters in
production — diagnosing a system when it's not behaving as expected,
using only logs, metrics, and a hypothesis-driven process of
elimination.

This eight-part series takes the opposite approach. Each post walks
through provisioning a piece of Google Cloud infrastructure using the
gcloud CLI, deliberately introducing a realistic failure mode into
that infrastructure, and then walking through the diagnostic process
needed to identify and remediate the issue — with the actual commands,
log queries, and decision points included.

This series is intended for engineers who already understand IaaS/PaaS
fundamentals and want hands-on, failure-driven practice with core
GCP services, in the spirit of Kubernetes The Hard Way.

What this series covers

Architecture pattern used throughout the series

Several posts in this series build on a common reference architecture:

                    ┌────────────────────┐
   Client  ──────▶  │ Cloud Load Balancer │
                    └─────────┬──────────┘
                              │
                    ┌─────────▼──────────┐
                    │  Managed Instance    │
                    │  Group (2–4 VMs)     │
                    └─────────┬──────────┘
                              │  Private IP
                    ┌─────────▼──────────┐
                    │     Cloud SQL       │
                    │  (Primary + Replica)│
                    └────────────────────┘

This pattern is intentionally simple — the goal isn't architectural
complexity, it's giving you a stable baseline you can break in
controlled, repeatable ways.

Prerequisites for the series

• A Google Cloud project with billing enabled (a fresh project with free trial credit or a dedicated test project is strongly recommended)
• The gcloud CLI installed locally, or access to Cloud Shell
• Working familiarity with Linux command-line tools and basic log interpretation
• A Budget Alert configured on your billing account (instructions in Part 1) to avoid unexpected cost overrun while experimenting

How to use this series

Each post is self-contained but builds conceptually on the ones before
it — Part 8 in particular reuses techniques introduced in Parts 2–4.
We recommend working through them in order, and resisting the urge to
look up the fix for an injected failure for at least 20–30 minutes.
That struggle is where the retained learning happens.

Let's get started with [Part 1: Migrating a Legacy Application Without
Touching Its Code →]