This chapter provides a comprehensive comparison of GKE Autopilot and Standard modes, covering their architectures, use cases, pricing models, and operational differences. Understanding when to choose each mode is critical for the ACE exam, as questions on cluster deployment and management appear frequently — approximately 10-15% of exam questions touch this topic. By the end of this chapter, you will be able to select the appropriate mode based on workload requirements and operational constraints.
Jump to a section
Imagine you're planning a stay in a city. GKE Standard mode is like renting an entire apartment building. You get the whole building, and you are responsible for everything: you must hire a manager (the control plane), maintain the elevators (node upgrades), and ensure the security of the lobby (OS patches). You have access to all rooms and can configure them exactly as you like, but you pay for the entire building even if only a few rooms are occupied. GKE Autopilot is like booking a hotel room. You pay only for the room you use, and the hotel staff handles all maintenance, cleaning, and security. You don't have access to the boiler room or the roof, but you can still request room service (scale up) at any time. The hotel ensures the building is up to code and handles emergencies. In Autopilot, Google manages the control plane and nodes, and you only manage your workloads (pods). You lose some flexibility (e.g., you cannot SSH into nodes), but you gain operational simplicity and pay only for the resources your pods request, not the underlying nodes.
What Are GKE Autopilot and Standard Modes?
Google Kubernetes Engine (GKE) offers two modes of operation: Standard and Autopilot. Both allow you to run Kubernetes clusters on Google Cloud, but they differ significantly in terms of management responsibility, flexibility, and pricing.
Standard mode: You manage the underlying infrastructure — the node pools, node versions, scaling, and maintenance. You have full control over the cluster, including the ability to SSH into nodes, install custom software, and configure advanced networking features. This mode is suitable for teams that need fine-grained control or have existing Kubernetes expertise.
Autopilot mode: Google manages the entire cluster infrastructure, including the control plane and nodes. You only define your workloads (pods) and their resource requirements. Autopilot automatically provisions and manages nodes, handles upgrades, patching, and scaling. You pay only for the resources your pods request (CPU, memory, ephemeral storage), with no per-node charges.
How They Work Internally
Standard Mode Architecture:
You create a cluster with a specific Kubernetes version. The control plane (master) is managed by Google in Standard mode (though you can choose a regional or zonal control plane). Node pools consist of Compute Engine instances that you configure — you choose machine types, disk sizes, and scaling settings.
You are responsible for node upgrades, security patches, and OS maintenance. You can use node auto-upgrades and auto-repair features, but you still control when they happen.
You have full access to the node's underlying OS via SSH (if you enable OS Login or use SSH keys). You can install DaemonSets, use privileged containers, and configure advanced networking like custom VPCs, network policies, and Istio.
Billing is based on the underlying Compute Engine instances (vCPU, memory, persistent disk) plus a cluster management fee (currently $0.10 per hour per cluster for zonal, $0.15 for regional).
Autopilot Mode Architecture:
When you create an Autopilot cluster, Google automatically provisions and manages the control plane and nodes. You do not see node pools — instead, you define Pods with resource requests and limits.
Autopilot uses a custom scheduler that places pods onto optimally sized nodes. Google handles node lifecycle: it creates nodes as needed, upgrades them automatically, and removes them when not in use.
You cannot SSH into nodes, use privileged containers, or deploy DaemonSets that require host-level access. However, you can still use most Kubernetes features, including Services, Ingress, ConfigMaps, Secrets, and PersistentVolumeClaims.
Billing is based on the resources requested by pods: vCPU, memory, and ephemeral storage. There is no per-node or per-cluster management fee. You also pay for persistent disks and other resources your pods use (e.g., Load Balancers).
Key Components, Values, and Defaults
Standard Mode Defaults:
Default node image: Container-Optimized OS (COS) or Ubuntu.
Default disk size: 100 GB per node.
Default machine type: e2-medium (2 vCPU, 4 GB memory) for node pools.
Cluster management fee: $0.10 per hour (zonal) or $0.15 per hour (regional).
Node auto-upgrade: Enabled by default.
Node auto-repair: Enabled by default.
Autopilot Mode Defaults:
You cannot choose node image or machine type — Google selects the optimal configuration.
Pod resource requests must be within specific ranges: CPU between 0.25 and 96 vCPUs, memory between 0.5 GB and 624 GB, ephemeral storage between 10 GB and 10 TB.
There is no cluster management fee.
Autopilot clusters are always regional (spread across three zones).
Pods are charged per second with a 1-minute minimum.
Configuration and Verification Commands
Creating a Standard Cluster:
gcloud container clusters create my-standard-cluster \
--zone us-central1-a \
--num-nodes=3 \
--machine-type=e2-standard-2Creating an Autopilot Cluster:
gcloud container clusters create-auto my-autopilot-cluster \
--region us-central1Verifying Cluster Mode:
gcloud container clusters describe my-cluster --format='value(autopilot.enabled)'Returns true for Autopilot, false for Standard.
How They Interact with Related Technologies
Both modes support GKE features like Workload Identity, Cloud NAT, VPC-native clusters, and GKE Ingress. However, Autopilot imposes some restrictions:
No support for Istio (GKE Sandbox is not available).
No support for HostNetwork or HostPort pods.
No support for privileged containers (securityContext.privileged: true).
DaemonSets are supported but cannot run on all nodes — they run on a subset managed by Autopilot.
PersistentVolumeClaims using SSD persistent disks are supported, but you cannot use local SSDs.
Standard mode supports all these features, giving you full flexibility.
Assess Workload Requirements
Determine if your workloads require full control over the underlying nodes. If you need to install custom kernel modules, use privileged containers, or manage node-level configurations, Standard mode is necessary. For standard containerized applications that only need to run as pods, Autopilot is sufficient. Also consider compliance and security requirements — Autopilot enforces pod security policies (e.g., no privileged containers) by default, which may simplify compliance.
Evaluate Operational Overhead
Consider your team's expertise and time. Standard mode requires you to manage node upgrades, security patches, and scaling. Autopilot offloads these tasks to Google, reducing operational burden. If your team is small or lacks dedicated Kubernetes administrators, Autopilot is preferable. For teams that need to customize cluster behavior (e.g., custom kubelet configurations), Standard is required.
Analyze Cost Model
Compare pricing: Standard mode charges per Compute Engine instance plus a cluster management fee. Autopilot charges per pod resource request. For workloads with predictable, steady-state resource usage, Standard may be cheaper if you can fully utilize nodes. For bursty or variable workloads, Autopilot can be more cost-effective because you pay only for what you use. Autopilot also eliminates the cluster management fee.
Test for Feature Compatibility
List all Kubernetes features your application uses. Autopilot does not support: privileged containers, HostNetwork, HostPort, nodePort services (though NodePort is still accessible), and some DaemonSet configurations. If your application relies on any of these, you must use Standard mode. Also check for GKE-specific features like GKE Sandbox (not supported in Autopilot).
Deploy and Monitor
Create the cluster in the chosen mode. For Standard, configure node pools and scaling policies. For Autopilot, define pod resource requests and limits. Monitor cluster health using Cloud Monitoring and Logging. In Standard, you can also monitor node-level metrics. In Autopilot, node-level metrics are abstracted — you monitor pod-level metrics. Adjust resource requests as needed to optimize cost and performance.
Scenario 1: E-commerce Platform with Variable Traffic A retail company runs an e-commerce site with traffic spikes during sales events. They use GKE Autopilot because it automatically scales nodes based on pod resource requests. During Black Friday, traffic surges — Autopilot provisions additional nodes within minutes to accommodate increased pod demand. The company pays only for the resources consumed during the spike, avoiding over-provisioning costs. They also benefit from automatic node upgrades and security patches, reducing maintenance overhead. However, they must ensure their application does not require privileged containers or host-level access. They configure HorizontalPodAutoscaler to scale deployments based on CPU utilization, and Autopilot handles the underlying node scaling.
Scenario 2: Regulated Financial Services with Strict Compliance A bank needs to run a Kubernetes cluster with custom security agents (e.g., antivirus, intrusion detection) that must be installed on each node as privileged DaemonSets. They also require node-level logging and auditing. Standard mode is the only option because Autopilot does not allow privileged containers or SSH access. The bank creates a Standard cluster with custom node images that include the security agents. They configure node auto-upgrades but schedule maintenance windows to ensure compliance. They also use GKE Sandbox (available in Standard) to run untrusted code. The operational overhead is higher, but the control is necessary for regulatory compliance.
Scenario 3: Startup with Limited DevOps Team A startup of 10 engineers builds a microservices-based SaaS product. They have limited Kubernetes expertise and want to focus on development rather than cluster management. They choose Autopilot because it abstracts node management. They define pod resource requests based on profiling, and Autopilot handles scaling and upgrades. They use Workload Identity for GCP service account integration. The startup benefits from reduced operational costs (no cluster management fee) and faster time-to-market. They monitor costs using the Autopilot pricing dashboard and adjust resource requests to optimize spending.
Common Misconfiguration Pitfalls:
In Autopilot, forgetting to set resource limits can lead to unexpected costs because pods can burst and consume more resources. Always set both requests and limits.
In Standard, not enabling node auto-upgrades can leave nodes vulnerable to security issues. Enable auto-upgrades and configure maintenance windows.
Using Autopilot with workloads that require HostNetwork (e.g., some monitoring agents) will fail — always check feature compatibility before deployment.
The ACE exam tests your ability to choose between Autopilot and Standard based on given scenarios. Key objective codes: 3.1 (Deploying and Implementing GKE clusters). Common exam questions include:
Most Common Wrong Answers and Why: 1. "Autopilot is always cheaper" — Wrong. For steady-state workloads with high resource utilization, Standard can be cheaper because you pay for the entire node, not per-pod. Autopilot's per-pod pricing can be more expensive if you have many small pods with low utilization. 2. "Standard mode is fully managed" — Wrong. Standard mode is partially managed — Google manages the control plane, but you manage nodes. Autopilot is fully managed. 3. "Autopilot supports all Kubernetes features" — Wrong. Autopilot has restrictions: no privileged containers, no HostNetwork, no direct node access. The exam tests these restrictions. 4. "You can convert a Standard cluster to Autopilot" — Wrong. You cannot convert modes; you must create a new cluster.
Specific Numbers and Terms:
Autopilot CPU range: 0.25 to 96 vCPUs.
Autopilot memory range: 0.5 GB to 624 GB.
Autopilot ephemeral storage range: 10 GB to 10 TB.
Standard cluster management fee: $0.10/hr (zonal), $0.15/hr (regional).
Autopilot has no cluster management fee.
Autopilot clusters are always regional.
Edge Cases:
If a pod in Autopilot requests more than 96 vCPUs, the pod will fail to schedule.
Autopilot does not support node pools — you cannot isolate workloads to specific machine types.
Autopilot supports DaemonSets but they may not run on all nodes (e.g., nodes that are being terminated).
How to Eliminate Wrong Answers:
If the scenario mentions "need to SSH into nodes" or "privileged containers" — eliminate Autopilot.
If the scenario mentions "variable workloads" or "reduce operational overhead" — lean toward Autopilot.
If the scenario mentions "cost optimization for steady-state loads" — consider Standard.
If the scenario mentions "custom node image" or "kernel module" — only Standard works.
Always read the scenario carefully: the exam often includes a requirement that forces one mode over the other.
Autopilot is fully managed; Standard requires node management.
Standard allows SSH, privileged containers, custom images; Autopilot does not.
Autopilot charges per pod resource request; Standard charges per node plus cluster fee.
Autopilot clusters are always regional; Standard can be zonal or regional.
Autopilot CPU range: 0.25–96 vCPUs; memory: 0.5 GB–624 GB; ephemeral storage: 10 GB–10 TB.
You cannot convert between modes; create a new cluster to switch.
Autopilot does not support HostNetwork, HostPort, or privileged containers.
For steady-state workloads with high node utilization, Standard may be cheaper.
For variable workloads and minimal ops, Autopilot is preferred.
Always verify feature compatibility before choosing Autopilot.
These come up on the exam all the time. Here's how to tell them apart.
GKE Standard
You manage node pools, upgrades, and scaling.
Full control: SSH to nodes, custom images, privileged containers.
Billing: per Compute Engine instance + cluster management fee.
Supports zonal and regional clusters.
Suitable for steady-state workloads with high utilization.
GKE Autopilot
Google manages all nodes and control plane.
No node access: no SSH, no privileged containers.
Billing: per pod resource request (CPU, memory, storage).
Always regional (multi-zonal).
Suitable for variable workloads and reduced operational overhead.
Mistake
Autopilot is always cheaper than Standard.
Correct
False. For steady-state workloads with high node utilization, Standard can be cheaper because you pay for the entire node regardless of pod density. Autopilot charges per pod resource request, which can add up if you have many small pods. You must compare based on workload profiles.
Mistake
You can convert a Standard cluster to Autopilot.
Correct
False. There is no in-place conversion. To switch modes, you must create a new cluster and migrate workloads. The exam tests this — if a question asks about converting, the correct answer is to create a new cluster.
Mistake
Autopilot clusters are zonal.
Correct
False. Autopilot clusters are always regional (multi-zonal). Standard clusters can be zonal or regional. This is a specific exam detail — Autopilot's regional nature ensures high availability.
Mistake
Standard mode means Google manages everything.
Correct
False. In Standard mode, Google manages the control plane, but you manage node pools, upgrades, and scaling. Only Autopilot is fully managed (no node management).
Mistake
Autopilot supports all Kubernetes features.
Correct
False. Autopilot does not support: privileged containers, HostNetwork, HostPort, nodePort (though accessible), and some DaemonSet configurations. Always check feature compatibility.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, Autopilot supports VPC-native clusters. You can specify a custom VPC and subnet during cluster creation. The cluster will use that VPC for pod networking. This is a common exam scenario — Autopilot does not restrict VPC usage.
Yes, Autopilot supports GPU-accelerated workloads. You must add a node selector to your pod specification (e.g., `cloud.google.com/gke-accelerator: nvidia-tesla-t4`). Google provisions nodes with the requested GPU. However, you cannot choose the machine type — Autopilot selects the appropriate one.
You cannot directly convert. You must create a new Autopilot cluster, migrate your workloads (e.g., using Velero or re-deploying), and then delete the old cluster. The exam may ask about migration — the correct answer is to create a new cluster.
If a pod requests more than 96 vCPUs, 624 GB memory, or 10 TB ephemeral storage, the pod will fail to schedule. You must adjust resource requests to stay within limits. Autopilot does not support bursting beyond these limits.
No, Istio is not supported in Autopilot. GKE Sandbox is also not available. If you need service mesh features, you must use Standard mode and install Istio manually.
Autopilot automatically scales nodes based on pod resource requests. You do not need to configure node auto-scaling — it is built in. However, you can still use HorizontalPodAutoscaler for pod-level scaling.
The minimum CPU request is 0.25 vCPUs, and the minimum memory request is 0.5 GB. Ephemeral storage minimum is 10 GB. These values are important for exam questions about resource limits.
You've just covered GKE Autopilot vs Standard Mode — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?