# GCP Associate Cloud Engineer (ACE) — Part 5: GKE, Serverless & the Agent Platform

> **Series:** GCP Associate Cloud Engineer (ACE) (5 of 8)
> **Part 1:** `01-fundamentals-and-resource-hierarchy.md` (Fundamentals, Resource Hierarchy & Cloud Identity)
> **Part 2:** `02-billing-and-gcloud-tooling.md` (Billing, gcloud CLI & Cloud Tooling)
> **Part 3:** `03-iam-and-identity.md` (IAM & Identity)
> **Part 4:** `04-compute-engine-and-autoscaling.md` (Compute Engine & Autoscaling)
> **Part 5:** This file (GKE, Serverless & the Agent Platform)
> **Part 6:** `06-storage-and-managed-databases.md` (Storage & Managed Databases)
> **Part 7:** `07-networking-fundamentals.md` (Networking Resources)
> **Part 8:** `08-monitoring-logging-and-operations.md` (Monitoring, Logging & Operations)
> **Questions:** `questions.md`

> Assumes you're comfortable with Part 4's shared-responsibility framing. This chapter moves progressively toward the "Google manages more" end of that same spectrum, ending at a platform where you don't manage servers at all.

## Table of Contents

1. [What This Chapter Covers](#what-this-chapter-covers)
2. [GKE Autopilot vs. Standard: Billing, Requests, and Choosing](#gke-autopilot-vs-standard-billing-requests-and-choosing)
3. [Deploying a GKE Cluster](#deploying-a-gke-cluster)
4. [kubectl, Node Pools, and Cluster Access](#kubectl-node-pools-and-cluster-access)
5. [Pod Autoscaling: HPA, VPA, and Autopilot's Resource Model](#pod-autoscaling-hpa-vpa-and-autopilots-resource-model)
6. [GKE and Artifact Registry](#gke-and-artifact-registry)
7. [Cloud Run, Cloud Run Functions, and Traffic Splitting](#cloud-run-cloud-run-functions-and-traffic-splitting)
8. [Eventarc: Event-Driven Serverless](#eventarc-event-driven-serverless)
9. [GPUs and TPUs on GKE and Cloud Run](#gpus-and-tpus-on-gke-and-cloud-run)
10. [The Agent Runtime on the Gemini Enterprise Agent Platform](#the-agent-runtime-on-the-gemini-enterprise-agent-platform)
11. [Cloud Workstations: Standardized Developer Environments](#cloud-workstations-standardized-developer-environments)
12. [Notebooks: Agent Platform Workbench and BigQuery](#notebooks-agent-platform-workbench-and-bigquery)
13. [Choosing Between GKE, Cloud Run, and the Agent Runtime](#choosing-between-gke-cloud-run-and-the-agent-runtime)
14. [A Full Worked Example: Meridian's AI Dispatch Assistant](#a-full-worked-example-meridians-ai-dispatch-assistant)
15. [Real-World Scenario: The Autopilot Bill Nobody Understood](#real-world-scenario-the-autopilot-bill-nobody-understood)
16. [Second Real-World Scenario: The Cloud Workstation That Drifted From Production](#second-real-world-scenario-the-cloud-workstation-that-drifted-from-production)
17. [Part 5 kubectl and gcloud Cheat Sheet](#part-5-kubectl-and-gcloud-cheat-sheet)
18. [Pre-Flight Checklist: Is This Serverless/GKE Design Production-Ready?](#pre-flight-checklist-is-this-serverlessgke-design-production-ready)
19. [Common Mistakes and Interview Traps](#common-mistakes-and-interview-traps)
20. [Worked Practice Problems](#worked-practice-problems)
21. [Summary and What's Next](#summary-and-whats-next)

## What This Chapter Covers

🎯 By the end of this chapter, you'll be able to choose correctly between GKE, Cloud Run, and the newest addition to this exam domain, deploying an AI agent onto a managed runtime, and know which developer-facing tooling (Cloud Workstations, managed notebooks) belongs alongside each.

> [!NOTE]
> Google rebranded Vertex AI Agent Builder as the **Gemini Enterprise Agent Platform** in April 2026, and what was called Agent Engine is now internally referred to as **Deployments** within that platform's own product surface. The ACE exam guide itself still uses the term **Agent Runtime**, so that's the term this chapter (and the exam) uses; if you see "Deployments" in Google's own newer documentation, know it's referring to the same underlying managed runtime.

## GKE Autopilot vs. Standard: Billing, Requests, and Choosing

**GKE Standard** gives you full control over node pools: you choose machine types, manage node-level scaling, and pay for provisioned VMs whether or not Pods are using their full capacity. **GKE Autopilot** removes node management entirely: Google provisions and scales the underlying infrastructure automatically, and you're billed per Pod resource request (vCPU and memory), not per node.

| | GKE Standard | GKE Autopilot |
|---|---|---|
| Node management | You manage node pools directly | Fully Google-managed, no visible nodes to configure |
| Billing model | Per provisioned VM, 24/7, regardless of utilization | Per Pod resource request (vCPU-hour, GiB-hour) |
| Pod resource requests | Optional (though not recommended to omit) | **Mandatory**; Autopilot injects defaults if you don't set them |
| Best fit | High, consistent utilization (roughly above 75%), workloads needing node-level customization | Low or bursty utilization, teams that want zero node-management overhead |

> [!TIP]
> **Best Practice: let real utilization data decide, not a default preference.** At consistently high node utilization, Standard mode with properly sized nodes (and committed-use discounts) typically costs less, since Autopilot's per-Pod pricing carries a premium for the operational simplicity it provides. At low or spiky utilization, Autopilot usually wins, since Standard bills for idle node capacity around the actual Pod usage. Run both cost models against a real workload's actual utilization pattern before committing either way.

## Deploying a GKE Cluster

```bash
# Autopilot: a single command provisions a fully managed cluster
gcloud container clusters create-auto meridian-agent-cluster \
  --region=us-central1 \
  --project=meridian-freight-prod-8f2k

# Standard, regional (control plane replicated across 3 zones),
# private (nodes have no public IP)
gcloud container clusters create meridian-freight-cluster \
  --region=us-central1 \
  --num-nodes=2 \
  --enable-private-nodes \
  --enable-ip-alias \
  --workload-pool=meridian-freight-prod-8f2k.svc.id.goog
```

`--workload-pool` enables Workload Identity Federation for GKE (Part 3) at cluster creation, the current recommended default rather than something bolted on afterward. `--enable-private-nodes` means nodes have no public IP at all, reachable only through the cluster's internal network and (for control-plane access) Google's own private connection path, a meaningful reduction in attack surface for any production cluster.

## kubectl, Node Pools, and Cluster Access

`kubectl` is installed as a `gcloud` component (`gcloud components install kubectl`) and authenticated against a specific cluster via `gcloud container clusters get-credentials`, which writes the cluster's endpoint and a short-lived auth plugin configuration into your local kubeconfig.

**Node pools** (Standard mode only, since Autopilot has no visible nodes to pool) are a set of nodes sharing a common configuration; a cluster typically has several, letting you mix machine types or Spot/on-demand nodes for different workload classes within one cluster.

```bash
gcloud container clusters get-credentials meridian-freight-cluster --region=us-central1

# Add a Spot-backed node pool for fault-tolerant batch workloads
gcloud container node-pools create batch-spot-pool \
  --cluster=meridian-freight-cluster \
  --region=us-central1 \
  --spot \
  --machine-type=n2-standard-4 \
  --enable-autoscaling --min-nodes=0 --max-nodes=10
```

## Pod Autoscaling: HPA, VPA, and Autopilot's Resource Model

| Mechanism | Scales | Trigger |
|---|---|---|
| **Horizontal Pod Autoscaler (HPA)** | Number of Pod replicas | CPU/memory utilization or a custom Cloud Monitoring metric |
| **Vertical Pod Autoscaler (VPA)** | A Pod's own resource requests/limits | Historical usage, recommending or automatically applying right-sized requests |
| **Autopilot's resource enforcement** | Every Pod's requests, at admission | Autopilot rejects or adjusts Pods below its minimum resource thresholds, rather than letting an unset request silently default to nothing |

⚠️ On Autopilot, **every Pod must declare resource requests**, and Autopilot will modify a Pod that doesn't meet its minimum thresholds rather than schedule it as-is. This is a meaningful behavioral difference from Standard mode, where an un-requested Pod is technically schedulable (though never advisable) and simply competes uncontrolled for whatever capacity the node happens to have free.

## GKE and Artifact Registry

**Artifact Registry** is GCP's current container and package registry (the successor to the deprecated Container Registry), and GKE nodes need explicit IAM permission (`roles/artifactregistry.reader`, typically via the node's or workload's service account) to pull images from it. A cluster's Pods failing with `ImagePullBackOff` against a private Artifact Registry repository is almost always this permission missing, not a networking problem, the same "check enablement/permission before networking" instinct from Part 1's API troubleshooting habit.

## Cloud Run, Cloud Run Functions, and Traffic Splitting

**Cloud Run** runs a containerized application as a fully managed, autoscaling (including to zero) service, billed only while a request is being processed. **Cloud Run functions** (the current name for what was Cloud Functions 2nd gen) is the same underlying platform, framed around a single function handler rather than a full container you build yourself.

```bash
gcloud run deploy meridian-dispatch-api \
  --image=us-central1-docker.pkg.dev/meridian-freight-prod-8f2k/app-images/dispatch-api:v3 \
  --region=us-central1 \
  --no-allow-unauthenticated \
  --service-account=meridian-dispatcher@meridian-freight-prod-8f2k.iam.gserviceaccount.com

# Deploy a new revision without shifting any traffic to it yet
gcloud run deploy meridian-dispatch-api \
  --image=.../dispatch-api:v4 --no-traffic --tag=canary

# Shift 10% of traffic to the new revision, watch metrics, then promote
gcloud run services update-traffic meridian-dispatch-api \
  --to-tags=canary=10
```

```mermaid
sequenceDiagram
    participant Dev as Engineer
    participant CR as Cloud Run
    participant V3 as Revision v3 (90%)
    participant V4 as Revision v4 canary (10%)

    Dev->>CR: Deploy v4 with --no-traffic --tag=canary
    CR->>V4: v4 running, receiving 0% of traffic
    Dev->>CR: update-traffic --to-tags=canary=10
    Note over CR,V4: Real traffic now split 90/10
    CR->>V3: 90% of requests
    CR->>V4: 10% of requests
    Dev->>CR: Metrics look healthy, promote to 100%
    CR->>V4: 100% of requests
    CR-->>V3: Old revision kept, scaled to zero
```

**Caption:** the old revision isn't deleted on promotion, it scales to zero and stays available, which is exactly what makes an instant rollback (`update-traffic --to-revisions=v3=100`) possible if the canary's metrics turn bad after full promotion.

## Eventarc: Event-Driven Serverless

**Eventarc** routes events (a Cloud Storage object finalized, a Pub/Sub message published, an Audit Log entry, a direct custom event) to a target (Cloud Run, Cloud Run functions, GKE) using a standardized CloudEvents format, decoupling the event source from the handler so the same routing infrastructure works regardless of which service actually emits the event.

```bash
gcloud eventarc triggers create meridian-shipment-upload \
  --destination-run-service=meridian-shipment-processor \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=meridian-shipment-docs"
```

## GPUs and TPUs on GKE and Cloud Run

Both GKE and Cloud Run now support attaching GPUs directly to a Pod or service, letting a serverless or Kubernetes-native workload use accelerated compute without you provisioning a dedicated Compute Engine VM. The tradeoff versus a raw Compute Engine GPU instance (Part 4) is the same tradeoff that runs through this whole chapter: less infrastructure to manage, at the cost of some configuration flexibility (available GPU models and node-pool-level tuning are more constrained on Autopilot and Cloud Run than on a hand-managed Standard-mode node pool).

## The Agent Runtime on the Gemini Enterprise Agent Platform

The **Agent Runtime** is a managed, serverless execution environment specifically for deploying and running AI agents (built with a framework like the Agent Development Kit, or any framework packaged to its interface) without managing the underlying compute yourself, conceptually Cloud Run's autoscale-to-zero, pay-per-use model, but purpose-built for agent workloads: session state, tool-calling, and memory across a multi-turn interaction.

```bash
# Deploy a packaged agent to the Agent Runtime
gcloud ai agent-engines deploy meridian-dispatch-assistant \
  --project=meridian-freight-prod-8f2k \
  --region=us-central1 \
  --agent-package=./dispatch-assistant/
```

💡 The exam-relevant mental model: **Cloud Run runs your general-purpose container; the Agent Runtime runs your agent specifically**, with built-in primitives (conversational session state, tool invocation tracking) that a plain Cloud Run deployment would require you to build yourself on top of a database and a queue.

## Cloud Workstations: Standardized Developer Environments

**Cloud Workstations** provisions browser-accessible (or local-IDE-connected, via VS Code or JetBrains) development environments from a versioned **workstation configuration**, a template defining the machine type, persistent storage, and container image that defines the dev environment itself. Updating the configuration doesn't retroactively change a running workstation; the update applies the next time that workstation starts, the same "template edits don't touch existing instances until an explicit action" pattern from Part 4's MIG rolling updates.

> [!TIP]
> **Best Practice: build the workstation's container image from the same base image your CI pipeline uses to build production containers.** This is the actual mechanism that eliminates "works on my machine" drift, since the developer's environment and the CI build environment share a lineage rather than being independently maintained Dockerfiles that quietly diverge over time.

## Notebooks: Agent Platform Workbench and BigQuery

Managed notebooks appear in two contexts on the exam: **Gemini Enterprise Agent Platform Workbench** (the renamed Vertex AI Workbench) provides managed Jupyter notebooks pre-wired with authentication and libraries for ML development against the Agent Platform, while **BigQuery's own built-in notebook** lets an analyst iterate directly against BigQuery data without leaving the BigQuery console or provisioning any separate compute at all. The distinction to hold onto: Workbench notebooks are a general ML development environment; BigQuery notebooks are specifically for in-place data analysis against BigQuery datasets.

## Choosing Between GKE, Cloud Run, and the Agent Runtime

```mermaid
flowchart TD
    Start{"What are you deploying?"} -->|"An AI agent with<br/>session state and tool-calling"| Agent["Agent Runtime"]
    Start -->|"A general containerized<br/>service or function"| Serverless{"Need fine-grained node control,<br/>or a long-running stateful workload?"}
    Serverless -->|"No"| CloudRun["Cloud Run / Cloud Run functions"]
    Serverless -->|"Yes"| GKE["GKE (Autopilot or Standard)"]

    classDef accent fill:#f0e9fb,stroke:#6d43c0,color:#10161c
    classDef ok fill:#e5f5ea,stroke:#1f8a4c,color:#10161c
    classDef info fill:#e5f0fa,stroke:#1d6fb8,color:#10161c
    class Agent accent
    class CloudRun ok
    class GKE info
```

**Caption:** the first, decisive question is whether the workload is specifically an agent; everything else follows the same serverless-vs-Kubernetes tradeoff this course has already built intuition for.

## A Full Worked Example: Meridian's AI Dispatch Assistant

```bash
# 1. Cloud Workstation for the team building the assistant,
#    using the same base image as CI
gcloud workstations configs create dispatch-assistant-dev \
  --cluster=meridian-dev-workstations \
  --region=us-central1 \
  --container-custom-image=us-central1-docker.pkg.dev/.../dev-base:latest

# 2. Deploy the packaged agent to the Agent Runtime
gcloud ai agent-engines deploy meridian-dispatch-assistant \
  --region=us-central1 --agent-package=./dispatch-assistant/

# 3. Front it with a Cloud Run service handling auth and request shaping
gcloud run deploy dispatch-assistant-gateway \
  --image=.../gateway:v1 --no-allow-unauthenticated

# 4. Wire an Eventarc trigger so a new shipment document
#    automatically kicks off an agent session
gcloud eventarc triggers create dispatch-assistant-trigger \
  --destination-run-service=dispatch-assistant-gateway \
  --event-filters="type=google.cloud.storage.object.v1.finalized"
```

## Real-World Scenario: The Autopilot Bill Nobody Understood

Meridian's platform team migrated a bursty internal reporting service from GKE Standard to Autopilot expecting savings, based on a general "serverless is cheaper" assumption rather than actual usage analysis. The following month's bill was 40% *higher* than Standard mode had been. The immediate cause was that the service, despite being "bursty" in request volume, ran at consistently high CPU utilization whenever it was active, batch report generation that fully saturated its allocated resources for hours at a stretch, exactly the profile where Standard mode's flat per-VM pricing beats Autopilot's per-request-resource premium. The underlying condition: the team had applied a general industry heuristic ("serverless saves money for bursty workloads") without checking whether *this specific workload's* utilization pattern actually matched the heuristic's assumption. They reverted to Standard mode with a properly sized, autoscaling node pool and cut costs back below the original baseline.

## Second Real-World Scenario: The Cloud Workstation That Drifted From Production

An engineer's Cloud Workstation, provisioned eight months earlier from a configuration nobody had updated since, still had an older major version of a shared internal library baked into its container image. Code that worked perfectly in local testing on that workstation failed immediately in CI, which built against the current production base image. Two engineers lost most of a day tracing what looked like a flaky test before realizing the workstation's environment itself was the actual variable. The fix mirrors this chapter's own Best Practice callout: the workstation configuration's container image was repointed to build from the same base image tag as the CI pipeline, with a scheduled monthly check confirming the two hadn't silently diverged again.

## Part 5 kubectl and gcloud Cheat Sheet

| Task | Command |
|---|---|
| Create an Autopilot cluster | `gcloud container clusters create-auto NAME --region=REGION` |
| Create a Standard cluster with Workload Identity | `gcloud container clusters create NAME --workload-pool=PROJECT.svc.id.goog` |
| Get cluster credentials for kubectl | `gcloud container clusters get-credentials NAME --region=REGION` |
| Add a Spot node pool | `gcloud container node-pools create NAME --cluster=CLUSTER --spot` |
| Deploy to Cloud Run | `gcloud run deploy NAME --image=IMAGE --region=REGION` |
| Split traffic to a tagged revision | `gcloud run services update-traffic NAME --to-tags=TAG=PERCENT` |
| Create an Eventarc trigger | `gcloud eventarc triggers create NAME --destination-run-service=SERVICE --event-filters=...` |
| Deploy an agent to the Agent Runtime | `gcloud ai agent-engines deploy NAME --agent-package=PATH` |

## Pre-Flight Checklist: Is This Serverless/GKE Design Production-Ready?

- [ ] The Autopilot-vs-Standard decision was based on actual measured utilization, not a general cost heuristic
- [ ] Every GKE cluster uses Workload Identity Federation (`--workload-pool`), not node-level default credentials
- [ ] Cloud Run services default to `--no-allow-unauthenticated` unless genuinely public
- [ ] A rollback path (a previous revision, or `--to-revisions`) is confirmed working before a canary promotion, not assumed
- [ ] Cloud Workstation images are built from the same base as CI, on a checked, non-drifting cadence
- [ ] Any AI agent workload uses the Agent Runtime's built-in session/tool-calling primitives rather than reinventing them on plain Cloud Run

## Common Mistakes and Interview Traps

| Mistake | Why it's wrong | What to say instead |
|---|---|---|
| "Autopilot is always cheaper than Standard because it's serverless" | At high, consistent utilization, Standard's flat per-VM pricing typically wins | Choose based on measured utilization pattern, not a general serverless-equals-cheaper assumption |
| "Pod resource requests are optional on Autopilot, same as Standard" | Autopilot mandates them and adjusts non-compliant Pods at admission | Every Autopilot Pod must declare requests; Autopilot enforces or injects defaults |
| "Cloud Run functions and Cloud Run are different platforms" | Cloud Run functions is the same underlying platform, framed around a single function handler | Same platform, different authoring model |
| "The Agent Runtime is just Cloud Run with a different name" | It adds agent-specific primitives (session state, tool-calling) Cloud Run doesn't provide out of the box | Use the Agent Runtime specifically for agent workloads that need those primitives |
| "A Cloud Workstation configuration update immediately changes running workstations" | Like an instance template, it only applies the next time the workstation starts | Updates apply on next start, not retroactively to a running workstation |

## Worked Practice Problems

**Problem 1:** Meridian is deciding between GKE Autopilot and Standard for a workload with highly variable, spiky traffic that's idle roughly 70% of the day. Which mode fits better, and why?

*Answer:* Autopilot is the better fit here. Standard mode bills for provisioned node capacity around the clock regardless of whether Pods are using it, so a workload idle 70% of the time would still pay for that idle node capacity. Autopilot bills per Pod resource request only while Pods are actually running, meaning the idle periods cost nothing, exactly the profile Autopilot's pricing model is built to reward.

**Problem 2:** A Cloud Run canary deployment at 10% traffic shows an elevated error rate after fifteen minutes. What's the correct, safest next action, and why does keeping the previous revision around matter here?

*Answer:* Shift traffic back to the previous, known-good revision at 100% (`gcloud run services update-traffic --to-revisions=PREVIOUS=100`) rather than attempting to patch the new revision forward. This works instantly and safely specifically because Cloud Run never deletes a superseded revision on its own, it scales to zero and remains available, so a full rollback is a traffic-routing change, not a redeploy, and completes in seconds rather than however long a new build and deploy would take.

**Problem 3:** An engineer wants to build an internal tool that answers multi-turn questions about shipment status, calling out to several internal APIs mid-conversation and remembering context from earlier in the same conversation. Should this be built as a plain Cloud Run service, or deployed to the Agent Runtime, and why?

*Answer:* The Agent Runtime is the better fit. The requirement describes exactly what the Agent Runtime provides natively, multi-turn session state and tool-calling, both of which a plain Cloud Run service would require the team to build themselves on top of a database (for session state) and custom orchestration code (for tool-calling), duplicating infrastructure the Agent Runtime already offers as a managed primitive.

## Summary and What's Next

This chapter moved through the "Google manages more" end of the compute spectrum: GKE Autopilot versus Standard and their genuinely different billing models, Cloud Run's revision-based traffic splitting for safe rollouts, Eventarc for event-driven serverless, and the newest additions to this exam domain, the Agent Runtime for AI agent workloads, Cloud Workstations for standardized developer environments, and managed notebooks for ML and data work.

**Part 6** moves to where all of this compute's data actually lives: Cloud Storage, the expanded set of managed databases (including newer additions like Managed Service for Apache Kafka and Memorystore), and the operational disciplines, backup, CMEK, cost estimation, that keep a data layer both correct and defensible in an audit.