GCP Associate Cloud Engineer

What is Google Cloud?

• GCP is Google's public cloud — the same infrastructure that runs Search, YouTube, and Gmail
• Available in 40+ regions, each with multiple zones (typically 3) for high availability
• A region is a geographic area (e.g., us-central1); a zone is a single deployment area within a region (e.g., us-central1-a)
• Google's private fiber network (Jupiter, Andromeda) connects all regions — low-latency global routing
• GCP follows the shared responsibility model: Google manages physical infrastructure; you manage your workloads, data, and access controls

GCP Resource Hierarchy

• Organization — top-level node, maps to a Google Workspace or Cloud Identity domain
• Folder — optional grouping layer (e.g., by department or environment); enables IAM/Org Policy inheritance
• Project — the primary unit: billing, API enablement, and IAM boundaries. Every resource belongs to a project
• Resources — VMs, buckets, databases, etc. within a project
• IAM policies applied at a higher level inherit downward; lower-level policies can be more permissive but not more restrictive

Setting Up Your Environment

• Install the Cloud SDK: provides gcloud, gsutil (Storage), bq (BigQuery), and kubectl
• gcloud init — interactive setup: authenticate, set default project and region
• gcloud config set project PROJECT_ID — set active project
• gcloud config set compute/region us-central1 — set default region
• gcloud config configurations create my-config — manage multiple environments

Essential gcloud Commands

• gcloud compute instances list — list all VMs in current project
• gcloud compute instances create NAME --zone=ZONE --machine-type=e2-medium
• gcloud compute ssh INSTANCE --zone=ZONE — SSH with automatic key management
• gcloud services enable compute.googleapis.com — enable APIs (required before use)
• gcloud projects list — list all accessible projects

Billing Concepts

• Each project is linked to a billing account; billing accounts can cover multiple projects
• Labels (key-value pairs on resources) enable cost allocation and reporting per team/environment
• Set budgets and alerts in Cloud Billing to receive email or Pub/Sub notifications at spending thresholds (e.g., 50%, 80%, 100%)
• Use Cloud Cost Management and Recommender for rightsizing suggestions

Pricing Models

• Sustained Use Discounts (SUDs) — automatic discounts up to 57% for VMs running most of the month; no commitment required
• Committed Use Discounts (CUDs) — 1 or 3-year commitments for 57–70% off
• Spot VMs — up to 91% off, can be preempted with 30-second notice; ideal for batch workloads
• Free Tier — always-free products include: 1 f1-micro VM/month, 5 GB Cloud Storage, Cloud Functions invocations, BigQuery queries up to 1 TB/month

Machine Types

• General purpose (E2, N2, N2D, T2D) — balanced price/performance for most workloads
• Compute-optimized (C2, C3) — high CPU frequency for compute-intensive apps
• Memory-optimized (M2, M3) — large in-memory databases, SAP HANA
• Custom machine types — specify exact vCPU and memory for right-sizing
• Accelerator-optimized (A2, G2) — NVIDIA GPUs for ML/AI workloads

Boot Disks & Persistent Storage

• Standard Persistent Disk (pd-standard) — HDD, cost-efficient, sequential workloads
• Balanced Persistent Disk (pd-balanced) — SSD, good general purpose (recommended default)
• SSD Persistent Disk (pd-ssd) — high IOPS for databases
• Local SSDs — ephemeral NVMe attached directly to the host; very fast but data lost on VM stop
• Snapshots — incremental backups of persistent disks; stored in Cloud Storage; used for disaster recovery

VM Lifecycle

• States: Provisioning → Staging → Running → Stopping → Terminated
• Stopped VMs do not incur compute charges but retain disk storage costs
• Metadata server at 169.254.169.254 — VMs access instance metadata and service account tokens without needing key files

Instance Templates

• Define VM configuration once (machine type, disk, network, service account, startup script) — reuse for MIGs and Spot VMs
• Templates are immutable — create a new version to update; MIGs rolling updates use the new template

Managed Instance Groups (MIGs)

• MIGs deploy identical VM instances from a template, enabling autoscaling and autohealing
• Autoscaling — adds/removes VMs based on CPU utilization, HTTP load balancing capacity, or custom metrics
• Autohealing — uses health checks to detect and automatically replace unhealthy VMs
• Rolling updates — gradually deploy new templates across the MIG with configurable maxSurge and maxUnavailable
• Regional MIGs — spread instances across multiple zones for high availability

Load Balancer Types

• Global External HTTP(S) Load Balancer — Layer 7, URL routing, global Anycast IP, integrates with Cloud CDN and Cloud Armor
• Regional External TCP/UDP Network LB — Layer 4, non-proxy, preserves client IP, for non-HTTP protocols
• Internal TCP/UDP Load Balancer — Layer 4, private VPC traffic only
• Internal HTTP(S) Load Balancer — Layer 7, for microservices within VPC
• SSL Proxy and TCP Proxy LB — terminates SSL/TCP connections globally

Key Concepts

• Health checks — LBs use health checks to route only to healthy backends
• Backend services — define the backend (MIG, NEG) and health check for the LB
• URL maps — HTTP(S) LB routing rules (host/path-based)
• Cloud Armor — WAF and DDoS protection; attaches to the Global HTTP(S) LB

Cluster Modes

• GKE Standard — you manage node configuration, machine types, node pools; full control
• GKE Autopilot — Google manages node infrastructure; you only define pod specs; pay per pod not node
• Regional clusters — control plane and nodes replicated across 3 zones; no single zone is a SPOF; recommended for production
• Zonal clusters — single control plane in one zone; lower cost but less resilient

Node Pools

• A cluster can have multiple node pools with different machine types (e.g., standard pool + GPU pool)
• Node pools can be independently upgraded and scaled
• Cluster Autoscaler — automatically adds nodes when pods are pending; removes nodes when underutilized
• Node auto-provisioning — creates new node pools automatically for pending pods requiring specific resources

Core Objects

• Pod — smallest deployable unit; one or more containers sharing network/storage
• Deployment — manages stateless Pods with rolling updates and rollbacks; use for web apps and APIs
• StatefulSet — stateful workloads with stable network identity and persistent per-pod volumes; use for databases
• DaemonSet — ensures one Pod per node; use for log collectors, monitoring agents (Fluentd, Prometheus node exporter)
• CronJob — scheduled batch jobs on a cron schedule

Scaling

• Horizontal Pod Autoscaler (HPA) — scales Pod replicas based on CPU/memory or custom metrics
• Vertical Pod Autoscaler (VPA) — adjusts Pod resource requests/limits automatically
• kubectl scale deployment nginx --replicas=5 — manual scaling

Networking

• ClusterIP — internal service, reachable only within the cluster
• NodePort — exposes service on each node's IP at a static port
• LoadBalancer — provisions a GCP External Load Balancer for the service
• Ingress — HTTP(S) routing rules; on GKE creates a Global HTTP(S) Load Balancer

Workload Identity

• Workload Identity is the recommended way to grant GKE workloads access to GCP APIs
• Maps a Kubernetes Service Account (KSA) to a GCP Service Account (GSA)
• Pods use the KSA to impersonate the GSA — no key files stored in Secrets
• Enable at cluster creation: --workload-pool=PROJECT_ID.svc.id.goog

Other GKE Security Best Practices

• Use Private clusters — nodes have no external IPs; API server accessible only via authorized networks
• Enable Binary Authorization — only signed, approved container images can run
• Use Network Policies — restrict pod-to-pod traffic
• Cloud SQL Auth Proxy as a sidecar for database connections — handles IAM auth and TLS
• Enable Shielded GKE Nodes for protection against rootkits and bootkits

Cloud Run

• Runs stateless containers on a fully managed platform; scales to zero; pay per CPU/memory during request processing
• Supports any language/runtime packaged as a Docker container
• Traffic splitting — split traffic between revisions for canary deployments
• Invoke via HTTP or Pub/Sub push subscriptions

Cloud Functions (2nd gen)

• Event-driven serverless functions; trigger via HTTP, Pub/Sub, Cloud Storage, Firestore, etc.
• 2nd gen is built on Cloud Run — longer timeouts (up to 60 min), larger instances
• Pair with Cloud Scheduler for cron-like scheduled execution

App Engine

• Standard environment — language-specific runtimes (Python, Node.js, Go, Java, PHP, Ruby); scales to zero; fast startup
• Flexible environment — custom Docker containers; minimum 1 instance (cannot scale to zero); use when Standard constraints are too limiting
• Versions and traffic splitting enable canary and blue/green deployments

Storage Classes

• Standard — frequently accessed data; no minimum storage duration
• Nearline — accessed at most once per month; 30-day minimum; ~50% cheaper than Standard
• Coldline — accessed at most once per 90 days; 90-day minimum
• Archive — long-term archive; <1 access/year; 365-day minimum; cheapest per GB

Key Features

• Object Lifecycle Management — rules to auto-transition or delete objects based on age, version count, etc.
• Versioning — retains every version with a generation number; enables accidental deletion recovery
• Uniform bucket-level access — disables ACLs; IAM-only access control (recommended)
• Signed URLs — time-limited, pre-signed URLs for unauthenticated access to specific objects
• Retention policies — prevent objects from being deleted or modified before a minimum age

Cloud SQL

• Fully managed MySQL, PostgreSQL, or SQL Server; regional (not global)
• High Availability (HA) — synchronous standby in a different zone; automatic failover
• Read replicas — asynchronous copies for read-heavy workloads; reduce primary load
• Connect securely via Cloud SQL Auth Proxy (recommended) or authorized networks
• Automated backups and point-in-time recovery (PITR) up to 7 days

Cloud Spanner

• Globally distributed, horizontally scalable relational database with ACID transactions
• 99.999% SLA for multi-region instances — use when Cloud SQL's regional scope is insufficient
• Ideal for: global financial apps, inventory systems, gaming leaderboards requiring strong consistency at scale
• Significantly more expensive than Cloud SQL — use it only when global distribution is truly required

Firestore

• Serverless NoSQL document database; real-time sync; offline support
• Best for: mobile apps, web apps, user profiles, content management
• Two modes: Native mode (new apps, real-time) and Datastore mode (server-side, legacy)

Cloud Bigtable

• Fully managed, wide-column NoSQL database; petabyte scale; millisecond latency
• Best for: time-series data, IoT sensor data, financial data, ML training datasets
• HBase-compatible API; integrates with Hadoop, Dataflow, Dataproc
• NOT suitable for: transactions, complex queries, small datasets (<1 TB)

Memorystore

• Fully managed Redis and Memcached — no infrastructure management
• Use for: session caching, real-time leaderboards, message queuing, rate limiting
• In-VPC only — not publicly accessible

VPC Concepts

• GCP VPCs are global — a single VPC spans all regions (unlike AWS where VPCs are regional)
• Subnets are regional — each subnet has an IP range in a specific region
• Auto mode VPC — one /20 subnet per region created automatically; easy to start but can complicate peering
• Custom mode VPC — you define all subnets; recommended for production (avoid IP overlap)
• VMs in the same VPC communicate using internal IPs regardless of region — no VPC peering needed

Firewall Rules

• VPCs have an implicit deny-all ingress and allow-all egress by default
• Rules are stateful — established connections are tracked; return traffic is automatically allowed
• Target with tags or service accounts to apply rules to specific VMs
• Priority 0–65535 (lower = higher priority); 0.0.0.0/0 = all sources

Hybrid Connectivity

• Cloud VPN — IPsec tunnels over the public internet; up to 3 Gbps per tunnel; simple setup
• Dedicated Interconnect — direct physical connection to Google's network; 10 or 100 Gbps; 99.99% SLA with redundancy
• Partner Interconnect — connect via a service provider; for locations without Dedicated Interconnect PoPs
• Cloud NAT — allows VMs without external IPs to make outbound internet connections

IAM Principals

• Google Account — individual user account (user@gmail.com)
• Service Account — machine identity for workloads (apps, VMs, functions)
• Google Group — set of users/service accounts; apply one IAM binding to many principals
• Workspace/Cloud Identity Domain — all users in your organization's domain
• allUsers — anyone on the internet (unauthenticated); use cautiously
• allAuthenticatedUsers — any signed-in Google account

Roles

• Basic roles — Owner, Editor, Viewer; coarse-grained; avoid in production
• Predefined roles — curated by Google for specific services (e.g., roles/storage.objectViewer)
• Custom roles — define exact permissions needed; enforce least privilege

Best Practices

• Principle of least privilege — grant only the minimum permissions required
• Prefer predefined roles over basic roles
• Use service accounts for workloads — never use personal accounts
• Avoid creating service account keys when possible — use Workload Identity or metadata server instead
• Organization Policy Service — enforce constraints organization-wide (e.g., prevent public IPs, restrict allowed regions)

Cloud KMS (Key Management Service)

• Manages encryption keys for GCP services
• Google-managed keys — default; Google handles rotation; no visibility to customer
• Customer-managed keys (CMEK) — you create/manage keys in Cloud KMS; GCP services use them to encrypt your data
• Customer-supplied keys (CSEK) — you provide raw key material; used for Compute Engine persistent disks
• Key rotation, audit logs, and IAM-controlled access to keys

VPC Service Controls

• Creates a security perimeter around GCP services (Storage, BigQuery, etc.)
• Restricts access to resources to only requests from authorized VPCs or IP ranges
• Prevents data exfiltration by blocking data from leaving the perimeter

Cloud Armor

• WAF (Web Application Firewall) and DDoS mitigation attached to the Global HTTP(S) LB
• Rules for: IP allowlisting/blocklisting, SQL injection protection, XSS protection, rate limiting, geo-based access
• Adaptive Protection — ML-based detection for volumetric DDoS attacks

Cloud Monitoring (formerly Stackdriver)

• Collects metrics from GCP resources, AWS, and on-premises with the Ops Agent
• Metrics Explorer — query and visualize any metric
• Dashboards — custom or pre-built resource dashboards
• Alerting policies — trigger notifications via email, Pub/Sub, PagerDuty, Slack when metrics breach thresholds
• Uptime checks — periodic HTTP/HTTPS/TCP checks to verify service availability globally
• Ops Agent — required on Compute Engine VMs to collect system metrics and logs; install with one command

Cloud Trace & Profiler

• Cloud Trace — distributed tracing; analyzes latency across microservices; identifies slow operations
• Cloud Profiler — continuous CPU and memory profiling for production workloads
• Error Reporting — aggregates application exceptions and errors; groups similar errors; notifies on new error types

Cloud Logging

• Centralized log management for GCP services, VMs (with Ops Agent), and custom applications
• Log sinks — route log entries to Cloud Storage, BigQuery, Pub/Sub, or Splunk for archiving and analytics
• Log-based metrics — create custom metrics from log patterns to trigger alerts
• Retention: Admin Activity logs = 400 days; Data Access logs = 30 days (default)

Cloud Audit Logs

• Admin Activity — records API calls that modify resources (always on, no charge)
• Data Access — records API calls that read resource configurations or data (disabled by default; can generate very high volume)
• System Event — Google-generated system events (always on)
• Policy Denied — records when access is denied by VPC Service Controls

Deployment Options

• Cloud Deployment Manager — GCP-native IaC using YAML/Python/Jinja templates; older tooling
• Terraform — industry standard IaC; GCP provider; state stored in Cloud Storage GCS backend; multi-cloud capable
• Use Terraform for new projects — better community support, state management, and multi-cloud portability

CI/CD on GCP

• Cloud Build — fully managed CI/CD service; runs build steps in containers; triggered by GitHub, Cloud Source Repositories, or manually
• Artifact Registry — stores Docker images, Maven, npm, Python packages; replaces Container Registry
• Cloud Deploy — managed continuous delivery to GKE and Cloud Run; enforces deployment pipelines with approvals
• Typical pipeline: git push → Cloud Build (build + test + push image) → Artifact Registry → Cloud Deploy/gcloud deploy

Exam-Relevant Scenarios

• "Store Terraform state for team collaboration" → GCS backend bucket with versioning
• "Build and deploy containers automatically on merge" → Cloud Build + Artifact Registry + Cloud Run
• "Enforce only approved images run on GKE" → Binary Authorization