Back to all posts

GCP Professional Cloud Architect Certification - Study Notes Part 7: Serverless & Compute Engine VMs

Sun, June 21, 2026
#google-cloud#professional-cloud-architect#notes#serverless

View all study notes here

Modern Serverless Application Architecture

Cloud Run (Serverless Microservices)

Fully managed container platform built on top of Knative, designed for deploying stateless HTTP-serving containers.

  • A single Cloud Run instance can handle multiple concurrent requests (up to 250+) per container, making it far more cost-efficient than per-request FaaS models.
  • Maximum request timeout of 60 minutes for web services.
    • For tasks longer than 60 minutes, use Cloud Run Jobs (batch/run-to-completion tasks), GKE, or Compute Engine.
  • Supports up to 8 vCPUs and 32 GB of RAM per instance.
  • Completely stateless
    • Local file system is in-memory only.
    • When a container scales to zero or restarts, all locally stored data is instantly destroyed.
    • Applications should stream uploads directly to Cloud Storage (GCS) to persist data across requests.

Cloud Run Jobs

  • Designed for run-to-completion workloads with no HTTP listener (batch processing, data pipelines, ML training scripts).
  • No 60-minute timeout constraint.
  • Can be triggered via Cloud Scheduler (cron-based) or Eventarc (event-based).
  • Supports task parallelism
    • Split a batch job into N independent tasks running concurrently.

Traffic Splitting & Deployment Patterns

Cloud Run tracks every deployment as an immutable Revision. Traffic can be split across revisions for safe rollouts.

  • Canary Deployment: Route 5% of traffic to the new revision; monitor error rates; gradually increase if healthy.
  • Blue/Green Deployment: Deploy the new revision with 0% traffic; switch 100% instantly when ready; old revision kept for instant rollback.
  • Traffic splits are defined as percentages summing to 100% across named revisions.

Ingress Controls (Restricting Inbound Access)

Cloud Run services receive a public URL by default, but ingress can be locked down:

  • Internal: Only allow requests originating from within the VPC or other Google Cloud services in the project.
  • Internal + Cloud Load Balancing: Block the direct Cloud Run URL; force all public internet traffic through an External HTTP(S) Application Load Balancer. Enables placing Cloud Armor (WAF/DDoS) and Cloud CDN in front of the serverless application.

Egress Controls (Accessing Private Resources)

By default, outbound Cloud Run traffic originates from random public Google IP addresses.

  • Problem: How does a Cloud Run service securely reach a private Cloud SQL instance or on-premises database over Interconnect/VPN?
  • Solution: Deploy a Serverless VPC Access Connector (VPC Access Bridge).
    • Routes all Cloud Run outbound traffic through a dedicated connector into a VPC subnet, then traverses the private network using internal IP addresses.
    • No database or internal resource needs to be exposed to the public internet.

When to Use Cloud Run

  • Zero server management and minimal operational effort desired.
  • Application is already containerized or uses a Buildpack-supported language (Java, Python, Node.js, Go, .NET).
  • Unpredictable or intermittent traffic
    • Scale-to-zero means no idle cost.
  • Workload fits within 60-minute request timeout and does not require kernel-level access or persistent local state.

Knative Overview

The open-source platform that extends Kubernetes to deploy and manage serverless, cloud-native applications. Cloud Run is Google’s managed, fully abstracted implementation of Knative.

Feature Standard Kubernetes Kubernetes with Knative
Minimum Scale 1 Pod (does not scale to zero) 0 Pods when idle
Scaling Metric CPU/memory via HPA Request concurrency via Knative Pod Autoscaler (KPA)
Routing & Ingress Manual Ingress controllers, Services, DNS Automatic dynamic routing with per-revision sub-routes
Deployment Config Multi-file YAML (Deployment, Service, HPA, Ingress) Single Service CRD
  • Knative Serving
    • Scale to Zero: Auto-scales down to 0 replicas when no incoming traffic; rapidly scales back up when a new request arrives.
    • Revisions: Generates an immutable point-in-time snapshot every time application code or configuration is updated, enabling safe rollbacks.
    • Traffic Splitting: Routes percentages of live traffic to different revisions for canary and blue/green deployments.
  • Knative Eventing
    • A collection of APIs enabling event-driven architecture for applications.
    • Sources (event producers) → Brokers (routing hub) → Triggers (filter rules) → Sinks (event consumers).
    • Uses the CloudEvents specification for standardized HTTP POST-based event delivery across any language.

Cloud Run Functions (Event-Driven FaaS)

A serverless, event-driven Functions as a Service (FaaS) platform running on top of the consolidated Cloud Run backend.

  • Purpose-built as a single-purpose event handler triggered asynchronously through Eventarc.
  • Common Trigger Sources:
    • Cloud Storage — process images or videos upon upload.
    • Pub/Sub — ingest data streams or execute transactional analytics.
    • Cloud Audit Logs — scan real-time infrastructure creations for automated security policy enforcement.
    • HTTP — direct webhooks, REST APIs, standard URL requests.
    • Firebase/Firestore — react to document write/create/delete events.

Cloud Functions (1st Gen) vs. Cloud Run Functions (2nd Gen)

Feature 1st Generation 2nd Generation (Cloud Run Functions)
Max Request Duration 9 minutes Up to 60 minutes for HTTP
Concurrency 1 request per instance Up to 1,000 concurrent requests per instance
Instance Size Up to 8 GB RAM / 2 vCPUs Up to 32 GB RAM / 8 vCPUs + optional NVIDIA GPU
Traffic Splitting Not supported natively Supported (canary deployments)
Storage Mounts Ephemeral space only Can mount Cloud Storage volumes
  • Always prefer 2nd Gen (Cloud Run Functions) for new development unless there is a specific reason to use 1st Gen.

Cloud Run Functions vs. Cloud Run

Feature Cloud Run Cloud Run Functions
Primary Deployment Built OCI/Docker container images Raw source code (Python, Node.js, Go, etc.)
Granularity Full applications, APIs, multiple endpoints Single-purpose, standalone event handlers
Environment Control High — any library, OS binary, or language Limited — restricted to supported runtimes
Concurrency Up to 250 requests/instance Up to 1,000 requests/instance
Request Timeout Up to 60 minutes Up to 60 min (HTTP) / 9 min (event-driven)
Hardware NVIDIA GPUs, custom CPU/memory shapes Up to 16 GB RAM / 4 vCPUs
  • Use Cloud Run Functions for single, lightweight code files handling isolated actions with zero build pipeline overhead.
  • Use Cloud Run for full applications or APIs with complex internal routing, custom Dockerfiles, or specialized runtimes.

Compute Engine (VMs)

Managed Instance Groups (MIGs)

Uses an Instance Template to create a cluster of identical VM instances whose lifecycle can be fully automated. The standard pattern for deploying scalable, highly available, VM-based applications.

  • Zonal MIG: All VMs in one Availability Zone (single point of zone failure risk).
  • Regional MIG: VMs automatically distributed across multiple zones within a single region. Regional MIGs provide high availability protection against zonal outages.
  • Autoscaling Triggers:
    • CPU utilization
    • Cloud Monitoring custom metrics
    • Pub/Sub queue depth
    • Load balancer capacity (e.g., target requests per second)
  • Connection Draining: When the autoscaler scales down, existing in-flight requests are allowed to finish before a VM is destroyed (default 300-second drain window).
  • Autohealing: A health check is attached to the MIG. If an instance fails the check (e.g., web server crashes), the MIG automatically deletes the VM and provisions a fresh replacement.
  • Rolling Updates: When the Instance Template is updated, VMs are replaced in configurable batches (e.g., one by one) to ensure zero downtime.
  • Canary Deployments: Roll out a new template to a small percentage of instances first; validate before completing the rollout.
  • Stateless MIGs: Auto-scale and auto-heal. Ideal for frontend web tiers and stateless API servers.
  • Stateful MIGs: Preserve underlying persistent data disks, machine metadata, and static network IP addresses even when instances undergo autohealing restarts or rolling deployments.

Unmanaged Instance Groups

A manually curated collection of heterogeneous VM instances grouped together.

  • No automation. Does not support autoscaling, autohealing, templates, or rolling updates.
  • Rarely used in modern architectures. Primarily exists to attach a mix of existing VMs to a legacy load balancer backend.

Enterprise VM Security & Operations

┌─────────────────────────────────────────────────────────────┐
│                COMPUTE ENGINE CONTROL PLANE                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  [ IAM Identity ] ──► OS Login ──► [ Linux / Windows VM ]   │
│                            │                                │
│                            ▼                                │
│          VM Manager (OS Config Agent Architecture)          │
│            ├── OS Patch Management (Zone-by-Zone)           │
│            └── OS Policies (Enforce Monitoring/Security)    │
└─────────────────────────────────────────────────────────────┘

Secure Access via OS Login

  • Eliminates the risk of manually managing and injecting raw public/private SSH key pairs via project metadata.
  • OS Login links operating system access directly to a user’s Google Cloud IAM identity.
  • If an employee leaves the company and their Cloud Identity account is deactivated, all SSH/RDP access to every VM across the organization is immediately and automatically revoked.
  • roles/compute.osLogin
    • Grants standard (non-sudo) SSH access.
  • roles/compute.osAdminLogin
    • Grants SSH access with sudo (administrator) privileges.
  • !! OS Login is the exam-preferred answer for any question about SSH access security. Manual SSH key injection into project metadata is a legacy anti-pattern.
  • Two-Factor Authentication (2FA): OS Login can be enforced with 2FA for an extra layer of terminal access security.

VM Manager (Fleet Governance)

A unified configuration management suite using an active OS Config agent running inside Compute Engine instances to maintain fleet compliance.

  • OS Patch Management
    • Automates OS security updates and software patches across Linux and Windows fleets at scale.
    • Define granular patch approval policies, set flexible maintenance windows, and configure disruption budgets (e.g., patch zone by zone, taking down no more than 25% of instances simultaneously).
    • !! For stateless MIGs, the correct patching pattern is NOT to use VM Manager directly. Update the Instance Template with the new OS image and trigger a Rolling Update.
  • OS Policies
    • Declarative policy definitions that continuously audit or auto-enforce system states across the fleet.
    • Ideal for ensuring required agents (Ops Agent, security software) are installed, running, and up to date across thousands of distributed VMs.
    • Supports two modes: VALIDATION (audit and report non-compliance) and ENFORCEMENT (automatically remediate non-compliant instances).

Shielded VMs

  • A set of security controls ensuring VM integrity against rootkit and boot-level malware.
  • Components:
    • Secure Boot: Only allows signed software to run during boot.
    • Virtual Trusted Platform Module (vTPM): Validates the boot integrity measurement chain.
    • Integrity Monitoring: Compares each boot measurement against a known-good baseline; alerts on deviation.
  • !! Use Shielded VMs for any workload handling regulated data (PCI, HIPAA) or in high-security environments.

Sole-Tenant Nodes

  • Physical Compute Engine servers dedicated exclusively to a single customer’s VMs.
  • Required when compliance mandates prohibit sharing physical hardware with other tenants (e.g., certain HIPAA or government workloads).
  • Also used for Bring Your Own License (BYOL) scenarios (e.g., Windows Server licenses that require physical core affinity).
  • Highly tested for financial and licensing use cases.
    • “Must use existing per-core on-premises licenses (BYOL)”
    • “Requires physical isolation for regulatory compliance”

Spot VM

Heavily discounted VM instances that provide identical hardware and performance to standard VMs but can be preempted or evicted without notice when provider needs capacity for full priced workloads.

  • Ideal for
    • Batch processing
      • Jobs that can be broken down and resumed
    • CI/CD pipelines
      • Software testing, building, integration tasks
    • Data analytics
      • Running stateless data crunching
    • Dev/test environments
  • Best practices
    • Use checkpointing
      • ensure application is configured to periodically save state so no data loss when abruptly terminated
    • Deploy in MIG
      • Use auto scaling groups so infrastructure can auto provision new Spot VM to replace evicted one once spare capacity returns

Compute Engine vs. Cloud Run

Choosing between VMs and serverless containers primarily comes down to connection persistence, infrastructure management overhead, and scaling cost profiles.

Feature Compute Engine / MIGs Cloud Run
Connection Model Stateful, persistent (lasts days/weeks) Ephemeral, hard maximum of 60 minutes
Scaling Speed Slow — minutes to boot new VMs Instant — seconds to spin up containers
Idle Costs Pay 100% of the time, even with 0 active users Pay $0 when scaled to zero
Management Effort High — OS updates, patching, networking Zero — Google manages the infrastructure
Persistent Local State Supported (persistent disks) Not supported (in-memory only)
Custom Kernel/OS Fully supported Not supported

Key Terms & Definitions

  • HPA (Horizontal Pod Autoscaler) — Scales the number of Pod replicas based on CPU, memory, or custom metrics.
  • VPA (Vertical Pod Autoscaler) — Adjusts CPU/memory resource requests on existing Pods to right-size them.
  • Cluster Autoscaler — Adds or removes Compute Engine nodes from a GKE node pool based on pending Pod capacity needs.
  • GKE Autopilot — Google-managed Kubernetes where you pay per Pod resource requested; no node management.
  • GKE Standard — User-managed Kubernetes node pools; full control including privileged containers and kernel access.
  • GKE Workload Identity — Binds a Kubernetes Service Account to a GCP Service Account so Pods authenticate to GCP without key files.
  • Private Cluster — GKE cluster where worker nodes have no public IPs; control plane accessible only via private endpoint.
  • GKE Fleet — Logical grouping of multiple clusters for unified governance, multi-cluster ingress, and GitOps config sync.
  • Cloud Run Revision — An immutable snapshot of a Cloud Run deployment; enables traffic splitting across versions.
  • Cloud Run Jobs — Run-to-completion batch tasks on Cloud Run; no HTTP listener, no 60-minute timeout.
  • Serverless VPC Access Connector — Private network bridge allowing Cloud Run/Functions to reach VPC-internal resources.
  • MIG (Managed Instance Group) — A cluster of identical VMs managed via an Instance Template with autoscaling, autohealing, and rolling updates.
  • OS Login — Links SSH/RDP access to GCP IAM identity; eliminates manual SSH key management.
  • Shielded VM — A VM with Secure Boot, vTPM, and Integrity Monitoring enabled to prevent boot-level compromise.
  • StatefulSet — Kubernetes workload controller for stateful applications requiring stable identity and persistent storage.
  • DaemonSet — Kubernetes workload controller ensuring one Pod per node (used for logging/monitoring agents).
Feature GKE Cloud Run Cloud Run functions
Primary Unit Kubernetes Pod / Cluster Container Image Code Function / Snippet
Control Level Maximum (Full infrastructure & network) Medium (Container level environment) Minimum (Code logic only)
Scale to Zero? No (Except via strict scale-down or Autopilot constraints) Yes (Instant) Yes (Instant)
Pricing Model Paid per node/resource allocation Paid per millisecond of request execution Paid per invocation and compute time
Statefulness Supports stateful apps & persistent volumes Strictly stateless Strictly stateless

Google Kubernetes Engine (GKE)

The Container Heavyweight GKE is a fully managed Kubernetes orchestration platform. It gives you deep, enterprise-grade control over your infrastructure, networking, and security.

  • How it works: You manage a cluster of Virtual Machines (nodes) and deploy your applications as containers using Kubernetes manifests (YAML).
  • Scaling: Scales automatically based on CPU/Memory metrics using the Kubernetes Horizontal Pod Autoscaler, but it does not natively scale to zero (you are paying for the underlying nodes/cluster infrastructure, unless using Autopilot, though even then a baseline remains).
  • Best for: Complex microservice architectures (dozens of interacting services), stateful applications (like running databases or message queues), workloads requiring highly specific custom networking, or heavy AI workloads needing massive GPU/TPU cluster configurations.

Cloud Run

The Serverless Container Default Cloud Run is a fully managed, serverless container platform. It abstracts away all the Kubernetes cluster infrastructure while still letting you deploy any application, language, or binary—as long as it’s packaged in a Docker container.

  • How it works: You give Cloud Run a container image (or let it build one from your source code), and Google handles all provisioning, configuration, and scaling.
  • Scaling: It scales instantly from zero to thousands of instances based on incoming web traffic. If nobody is using your application, it costs you $0.
  • Best for: Web apps, REST APIs, internal microservices, and lightweight machine learning inference. It is the default starting point for most new containerized projects on GCP.

Cloud Run functions (Formerly Cloud Functions)

The Event-Driven Snippet Cloud Run functions is a Function-as-a-Service (FaaS) offering. It represents the highest level of abstraction. In fact, modern Cloud Run functions actually build and run on top of the Cloud Run infrastructure under the hood, but they hide the container logic entirely from you.

  • How it works: You don’t think about containers, Dockerfiles, or web servers. You simply write a single code function (in Node.js, Python, Go, etc.) that responds to an event and upload it.
  • Scaling: Completely automated, request-driven scaling from zero.
  • Best for: “Glue code” and event-driven automation. For example: automatically resizing an image the moment it’s uploaded to Cloud Storage, executing a webhook, or processing a message from a Pub/Sub queue