1. Google Cloud Fundamentals

The global infrastructure and the resource hierarchy (organization, folders, projects) that every Google Cloud deployment is built on - plus the mental model that makes the rest of the platform predictable.

What Google Cloud is

Google Cloud Platform (GCP) is Google's public cloud: on-demand compute, storage, networking, databases, data analytics, and AI/ML services delivered from Google-operated regions, consumed over Google's private global network, and billed by usage. Its distinctive strengths for enterprises are its global network (a software-defined, private backbone that makes a VPC a global object and enables global load balancing from a single anycast IP), its data and analytics stack (BigQuery, Dataflow, Pub/Sub, Dataplex), and its AI/ML platform (Vertex AI, Gemini). If you come from traditional infrastructure, the biggest early surprises are that the network is global, the project is the main boundary, and much of the platform is API-first and serverless.

Google Cloud global infrastructure

Resource scope: global, multi-region, regional, zonal

This is the single most important idea for HA design on GCP - a resource's scope determines what failure it survives and where it can be reached.

The resource hierarchy

• Organization - the root node, tied to a Cloud Identity / Google Workspace domain. The top of IAM and policy inheritance.
• Folders - grouping nodes (by department, environment, or BU) for delegated administration and policy inheritance. Can nest.
• Projects - the fundamental unit. Every resource belongs to exactly one project. A project is the boundary for billing, quotas, API enablement, IAM, and isolation. It has a mutable name, an immutable project ID (globally unique), and a project number.
• Resources - VMs, buckets, datasets, etc., inside a project.
• Billing account - a separate object linked to projects; it is where charges accrue and can span many projects. Org and billing are managed independently.
• Resource Manager - the API/service that manages this hierarchy; Cloud Asset Inventory gives you a searchable, historical inventory of all resources and IAM across the org.

The Google Cloud mental model

Organization Policies

Organization Policy Service lets you set constraints that apply to a node (org, folder, or project) and inherit downward - guardrails that IAM cannot express. Common ones:

• constraints/compute.vmExternalIpAccess - block external IPs on VMs (huge for reducing exposure).
• constraints/gcp.resourceLocations - restrict which regions resources can be created in (data residency).
• constraints/iam.disableServiceAccountKeyCreation - stop long-lived SA keys.
• constraints/iam.allowedPolicyMemberDomains - domain restricted sharing: only allow IAM grants to your org's identities.
• constraints/compute.requireOsLogin - enforce OS Login instead of metadata SSH keys.

Labels vs tags

Resource names, project IDs, project numbers

• Project ID - globally unique, human-chosen, immutable (e.g. acme-app-prod-01). Used in most CLI/API calls. Choose a naming convention up front.
• Project number - an auto-assigned numeric ID; some APIs and service-agent identities use it.
• Project name - a mutable display name.
• Full resource names are hierarchical, e.g. //compute.googleapis.com/projects/<id>/zones/<zone>/instances/<name>.

Ways to work with Google Cloud

Designing the hierarchy & a landing zone

2. Identity and Access Management

Who can do what, on which resource, in which project - and the guardrails (deny policies, Org Policies, VPC Service Controls) around it. IAM is where most Google Cloud access issues and security incidents originate, so this section goes deep on principals, roles, inheritance, and troubleshooting.

The IAM model

An IAM allow policy is attached to a resource (or a hierarchy node) and contains bindings: each binding maps a role to one or more members (principals), optionally with a condition. When a principal calls an API, Google evaluates the effective policy (the union of allow policies inherited from the resource up through project, folder, and org), checks for any applicable deny policy, and checks Org Policy and VPC Service Controls. Access requires an allow, no matching deny, and no blocking Org Policy/perimeter.

Principals (members)

Roles: basic, predefined, custom

Allow policies and deny policies; conditional IAM

• Allow policy - grants roles to principals. Additive across the hierarchy; there is no "subtract."
• Deny policy - explicitly denies specified permissions to specified principals, and is evaluated before allows - a matching deny wins. Use it to carve exceptions ("nobody except break-glass may delete buckets in this folder").
• Conditional IAM - attach a condition (CEL expression) to a binding: by resource name/type, by request time, by tag. E.g. grant access only to resources tagged env=dev, or only during business hours.

# Conditional binding: grant only on buckets whose name starts with "app-"
gcloud projects add-iam-policy-binding my-proj \
  --member="group:app-team@example.com" \
  --role="roles/storage.objectAdmin" \
  --condition='expression=resource.name.startsWith("projects/_/buckets/app-"),title=app-buckets-only'

Inheritance and scope

Grant at the lowest node that works. A role granted at the org applies to every folder, project, and resource beneath it; a role granted on a single bucket applies only there.

Service accounts: keys vs impersonation vs workload identity

Cloud Identity, Workspace, and federation

• Cloud Identity / Google Workspace - where your human identities and groups live; the org is tied to a domain. Manage joiners/movers/leavers here.
• Workforce Identity Federation - let human users from an external IdP (Okta, Entra ID, Ping) access Google Cloud without provisioning Google accounts.
• Workload Identity Federation - let external workloads (GitHub Actions, AWS, on-prem) get short-lived GCP credentials by trust, no keys.

IAP, Access Context Manager, VPC Service Controls

Real IAM scenarios

Common Google Cloud IAM mistakes

Google Cloud access troubleshooting mental model

When a request is denied (or unexpectedly allowed), walk the layers in order. Most "permission denied" tickets are one of these:

gcloud projects get-iam-policy PROJECT_ID
gcloud asset analyze-iam-policy --organization=ORG_ID \
  --identity="user:jane@example.com"
# Is the API enabled?
gcloud services list --enabled --project PROJECT_ID

3. Networking Deep Dive

The global VPC, regional subnets, firewall model, private access to Google APIs, Shared VPC, and hybrid connectivity - plus the traffic-flow reasoning you need to design and debug real Google Cloud networks.

VPC networks and CIDR planning

A VPC network is a global, software-defined private network. Unlike most clouds, one VPC spans every region; you add a subnet per region as you expand, and resources in different regions on the same VPC route to each other over Google's backbone with no peering.

• Custom mode vs auto mode: auto mode auto-creates a subnet in every region from a fixed 10.128.0.0/9 range - convenient but it hands you overlapping, non-planned CIDRs. Always use custom mode in production and assign subnets deliberately.
• Subnets are regional; a subnet has a primary CIDR and optional secondary ranges (used for GKE pods/services alias IPs).
• CIDRs must not overlap with each other, with peered/shared VPCs, or with on-premises. Overlap is the number-one cause of hybrid that "connects but won't route."
• You can expand a subnet's primary range; plan generously so you rarely need to.

Firewall rules and hierarchical firewall policies

GCP firewalls are stateful and evaluated per VM by priority (lower number wins). Every network has two implied rules at priority 65535: deny all ingress and allow all egress. You open what you need above that.

Routes, Cloud Router, and Cloud NAT

• Routes - system-generated (subnet routes, default internet route) plus custom static routes; dynamic routes are learned via Cloud Router (BGP) from VPN/Interconnect.
• Cloud Router - the BGP speaker for hybrid connectivity and for regional dynamic routing; advertises your subnets to on-prem and learns on-prem routes.
• Cloud NAT - managed, outbound-only NAT so instances with no external IP can reach the internet (patches, external APIs). It is regional and requires a Cloud Router. It does not allow inbound.
• External vs internal IPs - internal (RFC1918) always; external only when you truly need internet-facing exposure. Block external IPs by Org Policy where possible.

Private Google Access, Private Service Connect, private services access

Three different "private" mechanisms that are constantly confused:

Shared VPC and VPC peering

• Shared VPC - a host project owns the VPC and subnets; service projects attach and deploy resources into shared subnets. Networking is centralized (one team owns IP space, firewall, connectivity) while app teams keep their own projects for IAM/billing. The enterprise default for multi-project networking.
• VPC Network Peering - connects two VPCs privately. Crucially, peering is not transitive: if A peers B and B peers C, A cannot reach C. And you cannot peer overlapping ranges.
• Network Connectivity Center (NCC) - a hub-and-spoke model to interconnect many VPCs and hybrid links through a central hub, addressing peering's non-transitivity at scale.

Hybrid connectivity: Cloud VPN and Interconnect

Both use Cloud Router for BGP. HA VPN uses two interfaces for a 99.99% topology. Common pattern: Interconnect primary + HA VPN backup, with BGP preferring Interconnect.

Cloud DNS

• Public zones for internet-facing names; private zones for internal resolution within (and across, via peering) your VPCs.
• DNS peering and forwarding integrate with on-prem DNS (inbound/outbound server policies) for hybrid name resolution.
• Managed private zones for *.googleapis.com (e.g. private.googleapis.com / restricted.googleapis.com) route Google-API traffic privately for PGA/VPC-SC.

How traffic flows in Google Cloud

1. Destination inside the same VPC (any region)? Routes locally over the backbone - only firewall rules apply.
2. Outside the VPC? The route table (subnet/static/dynamic routes) picks the next hop: default internet route (needs external IP or Cloud NAT), a VPN/Interconnect route (via Cloud Router), or a peering route.
3. Firewall (hierarchical policies, then VPC rules, by priority) must allow it - remember implied deny-ingress / allow-egress.
4. For Google APIs from private VMs: PGA/PSC + DNS to the private API endpoint.

Debugging is almost always: is there a route to the right next hop? does firewall allow it (both directions/priority)? is external IP / Cloud NAT / PGA in place for the destination type?

Reference diagrams

Three-tier with global external Application Load Balancer

Shared VPC (centralized networking)

Private Google Access & Cloud NAT egress

Network Intelligence Center

Networking troubleshooting

gcloud compute routers nats describe NAT --router=RT --region=REGION
gcloud compute firewall-rules list --filter="direction=EGRESS"

Google Cloud networking gotchas

4. Compute Deep Dive

Compute Engine machine families, managed instance groups, Spot VMs, and the serverless options (Cloud Run, Functions, App Engine) - how to choose, place, scale, and operate compute on Google Cloud.

Machine families

Custom types, Spot VMs, sole-tenant, GPUs/TPUs

Images, machine images, templates

• Public images (Debian, Ubuntu, RHEL, Windows Server, etc.) and custom images (your golden image).
• Machine images capture a full VM (disks + metadata) for cloning/backup; images capture a boot disk.
• Instance templates define shape, image, disks, network, metadata/startup script - the blueprint for MIGs.
• Startup scripts (and cloud-init on supported images) bootstrap a VM on boot; the metadata server (169.254.169.254) exposes metadata and workload credentials.

Managed instance groups & autoscaling

Shielded VMs, Confidential VMs, OS Login

• Shielded VM - secure boot, vTPM, integrity monitoring; enable by default (some Org Policies require it).
• Confidential VM - memory encrypted in use (AMD SEV / Intel TDX) for sensitive workloads.
• OS Login - manage SSH access via IAM (and 2FA) instead of project/instance metadata SSH keys. Enforce it with constraints/compute.requireOsLogin.
• IAP for SSH/RDP - reach VMs with no external IP through Identity-Aware Proxy, gated by IAM.

Serverless & managed compute

Choosing compute by workload

Operational guidance

5. Storage Deep Dive

Block (Persistent Disk, Hyperdisk, Local SSD), file (Filestore), and object (Cloud Storage) storage - their scope, performance, durability, and the decision of which to use for databases, shared filesystems, backups, archives, and data lakes.

Block storage: Persistent Disk, Hyperdisk, Local SSD

Filestore

Filestore is managed NFS (v3) for shared POSIX filesystems mounted by many VMs/GKE pods. Tiers (Basic, Zonal, Regional, Enterprise) trade performance, capacity, and availability. Use it for shared application state, home directories, media/render scratch, and lift-and-shift apps that expect a filesystem.

Cloud Storage

• Buckets & objects - a bucket has a global unique name, a location (region, dual-region, or multi-region), and a default storage class.
• Storage classes: Standard (hot), Nearline (~30-day), Coldline (~90-day), Archive (~365-day). Colder = cheaper storage, higher retrieval cost / minimum-storage-duration. Autoclass auto-moves objects between classes by access.
• Lifecycle management - rules to transition class or delete objects by age/version.
• Versioning keeps prior object versions; Object holds and retention policies + Bucket Lock give WORM/compliance immutability (a locked retention policy cannot be shortened or removed).
• Access: Uniform bucket-level access (UBLA) (IAM only, no per-object ACLs) + Public access prevention should be the default. Signed URLs grant time-boxed access without IAM.
• Cloud Storage FUSE mounts a bucket as a filesystem (with caveats - it is still object storage underneath).
• Transfer: Storage Transfer Service (online, from other clouds/on-prem/HTTP) and Transfer Appliance (physical, for very large datasets).

Encryption

• All data is encrypted at rest by default with Google-managed keys.
• CMEK (customer-managed encryption keys) via Cloud KMS - you control rotation and can disable a key to render data unreadable. Use for sensitive/regulated data.
• CSEK (customer-supplied keys) - you provide the raw key (niche; you manage all key handling).
• Encryption in transit uses TLS across Google's network.

When to use which

Practical examples

Storage gotchas

6. Database Services Deep Dive

Google Cloud's database portfolio - Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable, Memorystore - what each manages for you, how HA/DR/backup/patching differ, how to choose, and what changes for a DBA coming from Oracle.

The portfolio at a glance

Service deep dives

Database service decision table

Connectivity & observability

• Private IP (via private services access) is the production default - no public endpoint. Serverless VPC Access lets Cloud Run/Functions reach a private-IP DB.
• Cloud SQL Auth Proxy / connectors - IAM-authenticated, encrypted connections without managing SSL certs or IP allowlists.
• Authorized networks (public IP) - avoid; if used, restrict tightly and require SSL.
• Query Insights (Cloud SQL/AlloyDB) - query-level performance analysis; plus Cloud Monitoring metrics for CPU, connections, storage, replication lag.

How HA, DR, backup, and patching differ

Google Cloud database gotchas for Oracle DBAs

Enterprise examples

7. Load Balancing and Traffic Management

Google Cloud Load Balancing - the global and regional Application, Network, and proxy load balancers, their components (forwarding rule, target proxy, URL map, backend service, health check), and how to choose and debug them, with Cloud CDN and Cloud Armor.

The load balancer family

Anatomy of a load balancer

• Forwarding rule - the frontend IP + port. Target proxy terminates and (for HTTPS) holds the certificate. URL map does host/path routing. Backend service defines the balancing policy, session affinity, timeouts, and health check. Backends are MIGs, NEGs (network endpoint groups - incl. serverless NEGs for Cloud Run/Functions/App Engine), or backend buckets (static content).
• SSL certificates - Google-managed certs (auto-provision/renew) or self-managed, via Certificate Manager for scale.
• Session affinity - client IP / cookie based, when needed.

Cloud CDN and Cloud Armor

• Cloud CDN - cache cacheable responses at Google's edge; enable on a backend service/bucket to cut latency and egress.
• Cloud Armor - edge WAF/DDoS for the global external Application LB: OWASP rules, rate limiting, geo/IP allow-deny, bot management, and adaptive protection. Attach a security policy to the backend service.

When to use which

Load balancer troubleshooting

gcloud compute backend-services get-health BACKEND --global
gcloud compute firewall-rules list --filter="sourceRanges~35.191 OR sourceRanges~130.211"

8. Security Deep Dive

Defense in depth on Google Cloud: identity, governance (Org Policy, VPC-SC), network, data, and detective controls (SCC, audit logs) - plus concrete guidance for securing projects, storage, compute, and databases, ending in a production checklist.

Google Cloud shared responsibility model

Google secures the infrastructure (physical, hardware, host, network fabric, and managed-service internals). You are responsible for: IAM and identity, data classification and access, network exposure and firewall, key management choices, workload/OS security (for IaaS/GKE nodes), secure configuration, and monitoring/response. The higher up the managed-service stack you go (VM → GKE → Cloud SQL → BigQuery/Cloud Run), the more Google handles - but data, access, and configuration always remain yours.

The control layers

Cloud KMS, HSM, and Secret Manager

• Cloud KMS - manage encryption keys for CMEK across storage, disks, databases, and app-level crypto. Cloud HSM gives FIPS 140-2 Level 3 hardware-backed keys; Cloud EKM lets keys live in an external KMS.
• Secret Manager - store API keys, DB passwords, certs as versioned secrets; workloads read them via IAM (no secrets in code, images, or env files).
• Certificate Authority Service - private CA for issuing internal certificates at scale.

Security Command Center and detection

Perimeter and supply chain

• VPC Service Controls - a data-exfiltration perimeter around managed services so a valid identity can't copy BigQuery/Cloud Storage data to an outside project. The key control for sensitive data (see section 2).
• Identity-Aware Proxy (IAP) - context-aware access to apps/VMs without VPN or public IPs.
• Binary Authorization - only allow signed/attested container images to deploy (GKE/Cloud Run).
• Artifact Analysis - scan images in Artifact Registry for vulnerabilities; Web Security Scanner for app scanning.
• Confidential Computing - encrypt data in use (Confidential VMs/GKE).

How to secure specific things

Production Google Cloud security checklist

• Human access federated; 2FA enforced; access granted via groups, never individuals.
• No basic roles (Owner/Editor/Viewer) in production; least-privilege predefined roles at project/resource scope.
• Service account key creation disabled org-wide; workloads use attached SAs / Workload Identity Federation / impersonation.
• Preventive Org Policies: block external IPs, restrict resource locations, domain-restricted sharing, require OS Login + Shielded VM.
• Security Command Center enabled org-wide with findings triaged.
• VPC Service Controls perimeter around projects holding sensitive data.
• Shared VPC / hierarchical firewall centrally managed; no broad 0.0.0.0/0 ingress; SSH via IAP range only.
• Databases and internal services on private IP; no public database endpoints.
• Public HTTP behind global external App LB + Cloud Armor; backends private.
• All sensitive data encrypted with CMEK; keys in a locked security project; rotation on.
• Secrets in Secret Manager; nothing sensitive in code, images, or metadata.
• Cloud Storage buckets: UBLA + public access prevention; versioning + retention on backups.
• Org-level aggregated audit-log sink to a central logging project (+ BigQuery/SIEM); Data Access logs on where needed.
• Alerts on IAM/policy changes, new SA keys, public exposure, and anomalous access.
• Budgets + quotas as guardrails; consistent labels/tags for attribution.
• DR and backups tested (restores verified), including CMEK key availability in the DR region.

Common security mistakes

9. Observability, Monitoring, and Operations

Cloud Monitoring, Cloud Logging, and the Cloud Operations suite - what to monitor per service, how to build useful alerts without noise, how to centralize logs across projects, and Active Assist for optimization.

The observability stack

What to monitor per area

Building useful alerts

• Alert on symptoms users feel (5xx rate, unhealthy backends, DB down, high latency, SLO burn), not just causes.
• Use appropriate aligners/reducers and a duration to avoid flapping (e.g. mean over 5 min, not a single spike).
• Use absence conditions for signals that should always report (heartbeat, backup completion).
• Route by severity: critical → page; warning → ticket/Slack; info → dashboard.
• Adopt SLOs and alert on error-budget burn rather than raw thresholds where you can.

Example alerts to implement

Centralizing logs across projects

Create an aggregated sink at the org or folder level that routes all projects' logs (especially audit logs) to a central logging project - a log bucket for retention, BigQuery for analysis, and/or Pub/Sub to a SIEM. This gives cross-project security visibility and satisfies retention/compliance without per-project setup.

# Org-level aggregated sink of all audit logs to a central BigQuery dataset
gcloud logging sinks create org-audit-sink \
  bigquery.googleapis.com/projects/central-logging/datasets/org_audit \
  --organization=ORG_ID --include-children \
  --log-filter='logName:"cloudaudit.googleapis.com"'

Active Assist & recommendations

Recommender / Active Assist surface actionable insights: IAM over-grants, idle VMs/disks/IPs, right-sizing, commitment recommendations, and reliability/security findings. Review them monthly (they feed the cost checklist in section 14). Service Health shows Google-side incidents and maintenance events affecting your resources.

10. Containers, Kubernetes, and Cloud Native

GKE (Autopilot and Standard), Cloud Run, and the serverless / event-driven building blocks - when to use each, how networking and IAM work for containers, and reference patterns for microservices and event-driven systems.

The cloud-native services

GKE deep dive

• Autopilot vs Standard: Autopilot manages nodes, scaling, and much security for you and bills per-pod - less to run, fewer knobs. Standard gives you node pools and full control (custom machine types, GPUs, DaemonSets that need node access) at more operational cost.
• Node pools (Standard) - groups of nodes with a machine type/image; scale and upgrade per pool; use Spot node pools for fault-tolerant workloads.
• Regional vs zonal clusters - regional replicates the control plane and spreads nodes across zones (HA); zonal is single-zone.
• Networking - VPC-native clusters use alias IP ranges (secondary subnet ranges) for pods and services; plan those ranges (pods need many IPs).
• Ingress / Gateway API - a Kubernetes Ingress or the newer Gateway API provisions a Google Cloud load balancer for HTTP routing; a Service type=LoadBalancer provisions an L4 LB.
• Workload Identity - map a Kubernetes service account to a Google service account so pods call Google APIs with short-lived credentials, no keys.

# Bind a Kubernetes SA to a Google SA (Workload Identity)
gcloud iam service-accounts add-iam-policy-binding GSA@PROJECT.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT.svc.id.goog[NAMESPACE/KSA_NAME]"

GKE vs Cloud Run vs Cloud Functions vs Compute Engine

Networking, IAM, and security for containers

• Networking - VPC-native GKE in a (shared) VPC subnet with pod/service alias ranges; private clusters keep the control-plane endpoint private; Cloud Run connects to VPC via Serverless VPC Access or Direct VPC egress.
• IAM - cluster access via IAM + Kubernetes RBAC; Workload Identity for pod-to-Google auth; Cloud Run/Functions run as a service account you set.
• Supply chain - scan images in Artifact Registry (Artifact Analysis); enforce Binary Authorization so only attested images deploy.
• Runtime - network policies, pod security, secrets from Secret Manager, and least-privilege service accounts.
• Monitoring - GKE integrates with Cloud Monitoring/Logging and Managed Service for Prometheus; Cloud Run emits request metrics and logs automatically.

CI/CD for containers

Cloud Build builds and tests images (triggered from a repo), pushes to Artifact Registry (scanned), and Cloud Deploy promotes them through environments (dev → staging → prod) with approvals and rollback. Binary Authorization gates what can deploy.

Architecture patterns

• Microservices on GKE - deployments behind Gateway API/Ingress LB, HPA autoscaling, optional service mesh (Cloud Service Mesh) for mTLS/traffic control, Workload Identity, Cloud Deploy pipelines.
• Microservices on Cloud Run - each service a container, private ingress + internal LB for service-to-service, Pub/Sub/Eventarc for async - minimal ops.
• Serverless function on a Cloud Storage event - as diagrammed; image/ETL/validation triggers.
• Event-driven architecture - Eventarc + Pub/Sub + Workflows + Cloud Run/Functions + Cloud Tasks for decoupled, resilient pipelines.
• Private container platform - private GKE cluster in a Shared VPC, internal LBs, Binary Authorization, no public endpoints.

Troubleshooting

11. Analytics, Data, and Integration

Data is Google Cloud's strongest area. BigQuery, the lake/lakehouse stack (Cloud Storage, BigLake, Dataplex), the pipeline tools (Dataflow, Dataproc, Data Fusion, Dataform), streaming (Pub/Sub), CDC (Datastream), and BI (Looker) - with the BigQuery mental model that trips up newcomers.

The services

The BigQuery mental model

Common data patterns

Data governance with Dataplex

Dataplex gives you a data catalog, business/technical metadata, data lineage, data quality, and policy-based access across lakes and BigQuery - so a growing lake stays a governed asset instead of a "data swamp." Combine with VPC Service Controls (perimeter around BigQuery/Storage) and column/row-level security in BigQuery for sensitive data.

Reference architecture: lakehouse + BI

BigQuery cost control

12. AI, ML, and Generative AI on Google Cloud

Vertex AI as the unified ML platform, Gemini models and Agent Builder, vector search across AlloyDB / Cloud SQL / BigQuery, and the pretrained AI APIs - plus the enterprise RAG patterns and governance guardrails that separate a demo from something you can run on real data.

Vertex AI

Pretrained AI APIs & BigQuery ML

Vector search options

RAG architecture on Google Cloud

Enterprise patterns

Governance and security for GenAI

• Serving layer, always - agents/LLMs call a governed API (e.g. Cloud Run) that enforces authN/authZ, rate limits, input/output validation, and logging. They do not touch data stores directly.
• Entitlement-aware retrieval - filter retrieved context to what the requesting user may see (row/column/document level) so RAG cannot leak across users.
• Private & perimetered - keep model and data traffic private (Private Service Connect / private endpoints); wrap data services in VPC Service Controls.
• Credential hygiene - secrets in Secret Manager, access via service accounts / Workload Identity; the model never sees raw credentials.
• Auditability - log prompts, retrieved context IDs, and responses (per privacy rules) so answers are explainable.
• Responsible AI - safety filters, evaluation, and Model Monitoring for drift/quality; human review for consequential outputs.

Warnings (read before connecting AI to enterprise data)

13. Migration and Disaster Recovery

Getting workloads into Google Cloud (VMs, databases, data) and keeping them recoverable - the migration tooling, the DR patterns by tier, and how RTO/RPO drive architecture and cost.

Migration tooling

Database migration paths

DR patterns

Building blocks: cross-region Cloud SQL/AlloyDB replicas (promote for DR) or Spanner/Firestore multi-region (built-in); Cloud Storage dual/multi-region or Transfer for objects; regional PD and PD snapshots for VMs; the global external Application LB for automatic cross-region failover; and Cloud DNS for DNS-based failover where the LB doesn't cover it.

RTO and RPO

• RTO - how long you can be down → drives standby readiness and automation.
• RPO - how much data you can lose → drives replication mode (synchronous vs async vs backup interval).
• Zero data loss needs synchronous replication (regional HA, or Spanner multi-region) and low inter-region latency; verify the network and the performance trade-off.

Architecture examples

• On-prem VM → GCP: Migrate to VMs; cut over with the network in place.
• DB → Cloud SQL: DMS continuous, cut over at low replication lag.
• PostgreSQL → AlloyDB: DMS; validate performance/analytics gains.
• Oracle → Compute Engine (where required): self-managed, Data Guard to a second-region VM, sole-tenant for licensing.
• Cross-region DR (app): global LB + warm MIG + storage replication.
• Cross-region DR (database): cross-region replica (promote) or multi-region Spanner/Firestore.
• Backup-based DR: Backup and DR service / cross-region snapshots, rebuild on demand.

DR testing

• Cross-region replica within RPO (monitor replication lag); promotion rehearsed.
• CMEK keys present and usable in the DR region.
• App tier can start and connect in DR; config points to DR endpoints.
• Global LB / Cloud DNS failover tested and time-measured.
• Object data (dual/multi-region or replicated) within RPO.
• Capacity available in DR (reservations if RTO is tight); runbook current.

14. Cost Management and Governance

How Google Cloud charges, the tools to track and cap spend (billing export, budgets, quotas), the discount levers (CUDs, sustained-use, Spot), and the governance model - ending in a monthly cost-review checklist.

Pricing basics

Cost tracking tools

Discounts

• Committed use discounts (CUDs) - 1 or 3-year commitment (resource-based or spend-based) for a substantial discount on steady-state usage.
• Sustained-use discounts - automatic discounts for running certain machine families a large fraction of the month.
• Spot VMs - 60-90% off for preemptible, fault-tolerant workloads.
• Custom machine types - stop paying for vCPU or memory you don't use.

Governance model

Governance is enforced through the same primitives as security: the resource hierarchy (projects/folders for isolation and attribution), Organization Policies (restrict locations, machine types, external IPs), budgets + quotas, labels/tags, and a landing zone deployed as code. This keeps spend controlled and attributable by design rather than by cleanup.

Cost optimization examples

Monthly Google Cloud cost review checklist

• Review cost reports month-over-month by project, service, and label; investigate spikes.
• Check each budget: which projects/labels are over or trending over target.
• Act on Recommender right-sizing and idle-resource recommendations.
• Confirm non-prod stop/schedule ran (nothing running 24x7 by accident).
• Find and delete unused persistent disks, orphaned snapshots, and idle VMs.
• Release unused external (static) IPs - they bill when unattached.
• Review CUD coverage vs. steady-state usage; buy/adjust commitments.
• BigQuery: top queries by bytes scanned; add partitioning/clustering; set max-bytes-billed; review on-demand vs capacity.
• Cloud Storage: are lifecycle rules moving cold data to Nearline/Coldline/Archive?
• Logging/Monitoring ingestion: exclude noisy logs; check retention settings.
• Review egress / inter-region charges; co-locate chatty services; use private access.
• Cloud SQL / managed DB sizing vs. actual utilization; scale down over-provisioned.
• Confirm every resource is labeled (cost-center/env/owner) for attribution.
• Validate quotas still reflect intent; check for anomalous new spend by service.

15. Enterprise Architecture Patterns

Reference blueprints for real Google Cloud deployments. Each card gives the business case, services, traffic flow, and the security / HA / DR / monitoring / cost / risk dimensions so you can adapt rather than start from a blank page.

Foundational three-tier (reference backbone)

Pattern library

16. Troubleshooting Guides

A runbook catalog for the failures you will actually hit. Each entry lists symptoms, likely causes, checks (with Console path and gcloud where useful), fixes, and prevention. Deeper versions of some live in their service sections; this is the consolidated index.

Compute & access

gcloud compute ssh VM --tunnel-through-iap --zone=ZONE
gcloud compute instances get-serial-port-output VM --zone=ZONE

Storage

Network

Load balancer & databases

gcloud sql instances describe INSTANCE
./cloud-sql-proxy --private-ip PROJECT:REGION:INSTANCE

IAM & service accounts

Serverless & GKE

Observability

17. gcloud CLI, Terraform, and Automation

Practical, copy-friendly automation: gcloud setup and configurations, service-account impersonation, common commands, the Google Terraform provider, and clean examples for VPC, VMs, buckets, IAM, and alerts - plus state and structure practices.

gcloud CLI setup & configurations

# Install the Cloud SDK, then authenticate
gcloud auth login                       # human login
gcloud auth application-default login    # ADC for local tools/Terraform

# Named configurations (switch between projects/accounts fast)
gcloud config configurations create prod
gcloud config set account jane@example.com
gcloud config set project acme-app-prod-01
gcloud config set compute/region us-central1

gcloud config configurations activate prod
gcloud config configurations list

Service-account impersonation (no keys)

# Your user needs roles/iam.serviceAccountTokenCreator on the SA
gcloud config set auth/impersonate_service_account deployer@PROJECT.iam.gserviceaccount.com
gcloud compute instances list      # now runs AS the SA, short-lived token

# Or per-command:
gcloud storage ls --impersonate-service-account=deployer@PROJECT.iam.gserviceaccount.com

# Terraform: impersonate via ADC + provider setting (no key file)

Common gcloud commands

# Projects / APIs
gcloud projects list
gcloud services enable compute.googleapis.com run.googleapis.com --project PROJECT
gcloud services list --enabled

# Compute
gcloud compute instances list
gcloud compute instances create web-1 --machine-type=e2-standard-2 --no-address --zone=us-central1-a
gcloud compute ssh web-1 --tunnel-through-iap --zone=us-central1-a

# Storage
gcloud storage ls
gcloud storage cp -r ./data gs://my-bucket/data

# IAM
gcloud projects add-iam-policy-binding PROJECT --member="group:app@example.com" --role="roles/run.developer"
gcloud projects get-iam-policy PROJECT

# Logs
gcloud logging read 'severity>=ERROR' --limit 20 --freshness 1h

Terraform provider setup

# versions.tf
terraform {
  required_version = ">= 1.5"
  required_providers {
    google = { source = "hashicorp/google", version = "~> 6.0" }   # verify current major
  }
  backend "gcs" { bucket = "acme-tfstate-prod"  prefix = "app" }    # remote, locked state
}

provider "google" {
  project = var.project_id
  region  = var.region
  # Impersonate a deployer SA using ADC - no key file
  impersonate_service_account = var.deployer_sa
}

Create a custom-mode VPC + subnet + Cloud NAT

resource "google_compute_network" "vpc" {
  name                    = "app-vpc"
  auto_create_subnetworks = false        # custom mode
}

resource "google_compute_subnetwork" "app" {
  name                     = "app-us-central1"
  ip_cidr_range            = "10.10.0.0/20"
  region                   = "us-central1"
  network                  = google_compute_network.vpc.id
  private_ip_google_access = true         # Private Google Access
  secondary_ip_range {                    # for GKE pods, if needed
    range_name    = "pods"
    ip_cidr_range = "10.20.0.0/16"
  }
}

resource "google_compute_router" "rt" {
  name = "app-rt"  region = "us-central1"  network = google_compute_network.vpc.id
}
resource "google_compute_router_nat" "nat" {
  name   = "app-nat"  router = google_compute_router.rt.name  region = "us-central1"
  nat_ip_allocate_option             = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}

Create a Compute Engine VM (no external IP, Shielded)

resource "google_compute_instance" "app" {
  name         = "app-1"
  machine_type = "e2-standard-2"
  zone         = "us-central1-a"
  boot_disk { initialize_params { image = "debian-cloud/debian-12" } }
  network_interface {
    subnetwork = google_compute_subnetwork.app.id
    # no access_config block = no external IP
  }
  shielded_instance_config { enable_secure_boot = true  enable_vtpm = true  enable_integrity_monitoring = true }
  service_account { email = google_service_account.app.email  scopes = ["cloud-platform"] }
  metadata = { enable-oslogin = "TRUE" }
}

Create a hardened Cloud Storage bucket

resource "google_storage_bucket" "data" {
  name                        = "acme-app-data-prod"
  location                    = "US"
  uniform_bucket_level_access = true
  public_access_prevention    = "enforced"
  versioning { enabled = true }
  lifecycle_rule {
    condition { age = 30 }
    action { type = "SetStorageClass"  storage_class = "NEARLINE" }
  }
  # encryption { default_kms_key_name = google_kms_crypto_key.data.id }  # CMEK
}

IAM binding, service account, and a conditional binding

resource "google_service_account" "app" {
  account_id   = "app-runtime"
  display_name = "App runtime SA"
}

# Least-privilege: only object read on one bucket, to a GROUP
resource "google_storage_bucket_iam_member" "read" {
  bucket = google_storage_bucket.data.name
  role   = "roles/storage.objectViewer"
  member = "serviceAccount:${google_service_account.app.email}"
}

# Conditional project binding (time-boxed / resource-scoped)
resource "google_project_iam_member" "cond" {
  project = var.project_id
  role    = "roles/compute.viewer"
  member  = "group:oncall@example.com"
  condition {
    title      = "prod-hours"
    expression = "request.time.getHours('America/New_York') >= 8 && request.time.getHours('America/New_York') < 20"
  }
}

Create a Cloud Monitoring alert

resource "google_monitoring_notification_channel" "email" {
  display_name = "ops-email"  type = "email"
  labels = { email_address = "oncall@example.com" }
}

resource "google_monitoring_alert_policy" "cpu" {
  display_name = "VM CPU high"
  combiner     = "OR"
  conditions {
    display_name = "CPU > 85%"
    condition_threshold {
      filter          = "resource.type=\"gce_instance\" AND metric.type=\"compute.googleapis.com/instance/cpu/utilization\""
      comparison      = "COMPARISON_GT"
      threshold_value = 0.85
      duration        = "300s"
      aggregations { alignment_period = "60s"  per_series_aligner = "ALIGN_MEAN" }
    }
  }
  notification_channels = [google_monitoring_notification_channel.email.id]
}

State, structure, and CI/CD

• Remote, locked state: a GCS backend (object versioning on the state bucket) with state locking. Never keep prod state on a laptop; never commit state (it holds secrets).
• Modular structure: reusable modules (network, compute, data, iam, monitoring) composed per environment.
• Environment separation: separate state per env (workspaces or separate backends/prefixes) driven by dev.tfvars / prod.tfvars; separate projects and ideally separate deployer SAs/pipelines.
• CI/CD: run plan/apply in Cloud Build (or another pipeline) using an impersonated deployer SA via Workload Identity Federation - no keys. Gate apply with approvals; run plan on PRs for review.
• No secrets in code: reference Secret Manager / KMS by name; keep secret tfvars out of git.

gcp-infra/
  modules/
    network/   compute/   data/   iam/   monitoring/
  envs/
    dev/    main.tf  dev.tfvars   backend.tf
    prod/   main.tf  prod.tfvars  backend.tf
  cloudbuild.yaml
  README.md

18. Google Cloud Architecture Framework

The five pillars Google uses to review a design - operational excellence, security/privacy/compliance, reliability, cost optimization, and performance. Written for real architecture reviews: what each means, the services that support it, examples, mistakes, and a review checklist.

19. Learning Path

A structured route from Google Cloud fundamentals to enterprise-grade architecture, security, data, and AI - aimed at people coming from traditional infrastructure or another cloud. Each level lists what to learn, why, hands-on labs, common mistakes, and the outcome you should reach.

Beginner

Intermediate

Advanced

Certification checkpoints (optional)