Google Cloud has over 200 products. No one memorizes all of them — but in a typical production environment, you'll touch maybe 20. This Google Cloud cheat sheet focuses on those 20: the services, CLI commands, IAM concepts, and scaling mechanics that come up constantly in real work, not just on certification exams.
Whether you're prepping for the Associate Cloud Engineer exam, onboarding to a GCP environment, or just tired of looking up the same gcloud flags every week, this is the reference you can keep open in a tab.
What This Google Cloud Cheat Sheet Covers
This reference is organized around how practitioners actually use GCP — not alphabetically, not by product family. We'll cover:
- Core compute, storage, and networking services with the one-line description that actually helps
- Essential
gcloudCLI commands you'll run repeatedly - IAM hierarchy and the roles that matter
- Autoscaling and load balancing mechanics
- The GCP networking model (VPC, subnets, firewall rules) in plain language
One thing this cheat sheet doesn't do: pad word count with obvious filler. If a service is rarely used or only relevant to a specific vertical (like Healthcare API or Bare Metal Solution), it's not here.
Core GCP Services: Google Cloud Cheat Sheet by Category
Compute
| Service | What it is | When to use it |
|---|---|---|
| Compute Engine | VMs you manage | Lift-and-shift, custom OS configs, persistent workloads |
| Google Kubernetes Engine (GKE) | Managed Kubernetes | Containerized apps at scale, microservices |
| Cloud Run | Serverless containers | Stateless HTTP workloads, variable traffic |
| App Engine | PaaS (Standard or Flexible) | Web apps where you want GCP to manage infra entirely |
| Cloud Functions | FaaS (event-driven) | Lightweight triggers — Pub/Sub events, HTTP endpoints, storage events |
Compute Engine machine families to know: e2 (cost-optimized general purpose), n2/n2d (balanced), c2/c3 (compute-intensive), m1/m2/m3 (memory-optimized). For most workloads, e2 or n2 is the default choice.
Storage and Databases
| Service | Type | Best for |
|---|---|---|
| Cloud Storage | Object storage | Unstructured data, backups, static assets |
| Persistent Disk | Block storage | VM disks (SSD for latency-sensitive, HDD for sequential reads) |
| Cloud SQL | Managed relational | MySQL, PostgreSQL, SQL Server — standard transactional apps |
| Cloud Spanner | Distributed relational | Global scale with strong consistency — very expensive, use when you need it |
| Firestore | NoSQL document | Mobile/web apps, hierarchical data with offline sync |
| Bigtable | Wide-column NoSQL | Time-series, IoT, high-throughput analytics at low latency |
| BigQuery | Data warehouse | Analytical queries over large datasets — not for OLTP |
| Memorystore | Managed Redis/Memcached | Caching, session storage |
Cloud Storage classes: Standard (frequent access), Nearline (once/month), Coldline (once/quarter), Archive (once/year or less). Retrieval costs increase as storage costs drop — pick based on actual access patterns.
Networking
| Component | What you need to know |
|---|---|
| VPC | Global resource in GCP (unlike AWS, subnets are regional but VPC is global) |
| Subnets | Regional, assigned a primary IP range; secondary ranges for Pods/Services in GKE |
| Firewall rules | Applied at VPC level, target by network tags or service accounts; priority 0–65535 (lower = higher priority) |
| Cloud Load Balancing | Global (HTTP(S), SSL Proxy, TCP Proxy) vs regional (internal TCP/UDP, internal HTTP(S)) |
| Cloud NAT | Outbound internet for VMs without external IPs — no inbound connections |
| VPC Peering | Private connectivity between VPCs — routes are not transitive |
| Shared VPC | Host project owns network, service projects use it — useful for centralized networking |
| Cloud DNS | Managed DNS; private zones for internal name resolution |
Essential gcloud CLI Commands
The gcloud CLI is unavoidable. These are the commands that come up constantly — organized by resource type rather than alphabetically, because that's how you actually think when troubleshooting.
Auth and Config
# Authenticate
gcloud auth login
gcloud auth application-default login # for local dev with ADC
# Set active project
gcloud config set project PROJECT_ID
# View current config
gcloud config list
# Switch between configurations (named profiles)
gcloud config configurations activate NAMECompute Engine
# List instances
gcloud compute instances list
# SSH into an instance
gcloud compute ssh INSTANCE_NAME --zone=ZONE
# Create a VM
gcloud compute instances create INSTANCE_NAME \
--machine-type=e2-medium \
--image-family=debian-12 \
--image-project=debian-cloud \
--zone=us-central1-a
# Stop / start / delete
gcloud compute instances stop INSTANCE_NAME --zone=ZONE
gcloud compute instances start INSTANCE_NAME --zone=ZONE
gcloud compute instances delete INSTANCE_NAME --zone=ZONEGKE
# Get credentials for a cluster
gcloud container clusters get-credentials CLUSTER_NAME --zone=ZONE
# List clusters
gcloud container clusters list
# Create a cluster (basic)
gcloud container clusters create CLUSTER_NAME \
--num-nodes=3 \
--zone=us-central1-aCloud Storage
# List buckets
gcloud storage buckets list
# Copy file to bucket
gcloud storage cp LOCAL_FILE gs://BUCKET_NAME/
# List objects in bucket
gcloud storage ls gs://BUCKET_NAME/
# Make bucket
gcloud storage buckets create gs://BUCKET_NAME --location=us-central1IAM
# List service accounts
gcloud iam service-accounts list
# Create a service account
gcloud iam service-accounts create SA_NAME \
--display-name="My Service Account"
# Bind a role to a user
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:email@example.com" \
--role="roles/compute.viewer"
# Create and download a key (avoid when possible — use Workload Identity instead)
gcloud iam service-accounts keys create key.json \
--iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.comIAM, Scaling, and the Concepts That Actually Trip People Up
IAM Resource Hierarchy
GCP enforces IAM policies at four levels: Organization → Folder → Project → Resource. Policies are additive — a permission granted at a higher level flows down and cannot be denied at a lower level using standard roles. This is the single most common source of "why does this service account have access it shouldn't" bugs.
Role types:
- Primitive roles: Owner, Editor, Viewer — too broad for production, avoid
- Predefined roles: Fine-grained, service-specific (e.g.,
roles/storage.objectViewer) - Custom roles: Curated set of permissions — use when predefined roles are either too permissive or don't exist
Service accounts vs. user accounts: Service accounts are for workloads. Avoid creating service account keys unless necessary — prefer Workload Identity Federation for external workloads and the metadata server for GCP resources.
Managed Instance Groups and Autoscaling
Managed Instance Groups (MIGs) are the foundation for autoscaling in Compute Engine. Key things to know:
- Autoscaling signals: CPU utilization (most common), HTTP load balancing utilization, Pub/Sub queue depth, custom Cloud Monitoring metrics, or schedule-based
- Cooldown period: How long after scaling before the autoscaler evaluates again — default 60 seconds; too low causes oscillation
- Stateful vs. stateless MIGs: Stateful preserves per-instance configs and disks across updates; stateless is simpler and preferred when possible
- Health checks: Required for autohealing — configure both interval and unhealthy threshold conservatively to avoid premature instance replacement
Load Balancing Tiers
GCP load balancing is genuinely different from most cloud providers — it uses Andromeda (Google's virtual network stack) and anycast IPs for global load balancers. The important distinction:
- Global external Application Load Balancer: HTTP(S), anycast, single IP worldwide, integrates with Cloud Armor and Cloud CDN
- Regional external Application Load Balancer: HTTP(S), single region, lower cost
- Internal Application Load Balancer: HTTP(S) between services inside a VPC
- Network Load Balancer: TCP/UDP, pass-through (preserves client IP), regional
Top Courses to Go Deeper
A cheat sheet gets you oriented. These courses are where you build the muscle memory to actually use these services under pressure.
Modernize Infrastructure and Applications with Google Cloud
Covers the migration and modernization patterns that show up in real GCP projects — containers, serverless, and managed databases. Rated 9.7 on Coursera, it bridges the gap between "I know what these services are" and "I can architect with them."
Architecting with Google Kubernetes Engine: Workloads
Goes beyond cluster creation into the mechanics of deploying and managing workloads — deployments, services, config maps, persistent volumes. If you're working with GKE regularly, this is the one to do before you waste two days debugging pod scheduling issues.
Networking in Google Cloud: Fundamentals
The VPC model, subnets, firewall rules, and routing — explained at a level where you'll actually understand why traffic is or isn't flowing. This is the course to take before the networking concepts in this cheat sheet click fully.
Networking in Google Cloud: Routing and Addressing
The follow-on to Fundamentals, covering more advanced routing, Cloud NAT, VPN, and Interconnect. Pair with the Fundamentals course if you're responsible for GCP network architecture.
Google Cloud IAM and Networking for AWS Professionals
Specifically useful if you're coming from AWS — it maps GCP IAM and VPC concepts to their AWS equivalents rather than starting from scratch. Cuts down significantly on the mental overhead of switching clouds.
Google Cloud Generative AI Leader - Mock Exams
If you're targeting the Google Cloud Generative AI Leader certification, this Udemy course (rated 9.8) is the most efficient exam prep available — focused practice rather than re-teaching concepts you've already covered.
FAQ: Google Cloud Cheat Sheet
What's the fastest way to get a Google Cloud cheat sheet for the Associate Cloud Engineer exam?
The ACE exam tests breadth more than depth — you need to recognize the right service for a scenario, not recite API parameters. The most effective approach is: read the official exam guide to know what's in scope, then build a personal cheat sheet organized by domain (Compute, Storage, Networking, IAM, etc.) with one-line descriptions. The tables in this article cover most of what shows up repeatedly.
How does GCP networking differ from AWS enough to matter for a cheat sheet?
Three meaningful differences: (1) GCP VPCs are global — you create one VPC and add regional subnets, rather than per-region VPCs. (2) Firewall rules are VPC-level and target by network tag or service account, not by security group attached to an instance. (3) Global load balancers in GCP use anycast — a single IP routes traffic to the nearest healthy backend worldwide, which is architecturally different from AWS's regional ALB.
Which gcloud commands should I memorize vs. look up?
Memorize the ones you run daily: gcloud config set project, gcloud compute instances list, gcloud container clusters get-credentials, gcloud auth application-default login. Look up everything else. Even experienced engineers use gcloud COMMAND --help constantly — there's no shame in it, and the built-in help is actually good.
What's the difference between a service account key and Workload Identity?
A service account key is a JSON file with private key material you download and manage — it's a long-lived credential that can be exfiltrated, so Google and most security teams recommend avoiding it. Workload Identity Federation lets external workloads (GitHub Actions, AWS, on-prem) impersonate a GCP service account using short-lived tokens tied to the external identity. For GKE specifically, Workload Identity binds a Kubernetes service account to a GCP service account without any key file involved.
How does autoscaling work in Cloud Run vs. Compute Engine MIGs?
Cloud Run scales to zero and scales fast — instances spin up in milliseconds and the platform handles all of it transparently. You set min/max instance counts. Compute Engine MIGs scale based on signals you configure (CPU, HTTP utilization, custom metrics) with a cooldown period between scaling events. MIGs are slower to scale and don't reach zero by default, but they give you more control over the underlying VMs, persistent disks, and networking.
Is BigQuery the same as a regular database?
No — BigQuery is a columnar data warehouse built for analytical queries over large datasets. It doesn't support row-level updates/deletes efficiently, has higher query latency than transactional databases, and bills by bytes scanned (use partitioning and clustering to control this). For OLTP workloads — web app backends, anything requiring sub-millisecond transactions — use Cloud SQL or Cloud Spanner. BigQuery is for analytics, reporting, and data pipelines.
Bottom Line
This Google Cloud cheat sheet covers the 80% of GCP that shows up in 80% of projects. The services that matter most in practice are Compute Engine, GKE, Cloud Run, Cloud Storage, Cloud SQL, BigQuery, and the networking primitives (VPC, firewall rules, load balancing). Everything else is valuable in context — but if you understand these services well and can navigate the IAM and networking model, you can operate in GCP without constantly context-switching to documentation.
For exam prep specifically: the official GCP documentation is unusually good. The conceptual guides (not just API references) are worth reading, especially for networking and IAM. Pair that with hands-on labs — the kind where you actually break something and fix it — and a cheat sheet like this for quick review, and you're in reasonable shape for the Associate Cloud Engineer or Professional Cloud Architect exams.
The courses in the Top Courses section above are the most direct path from "I can read a cheat sheet" to "I can architect and debug GCP systems without a cheat sheet."