GKE has two modes of operation: Autopilot and Standard. They produce the same Kubernetes cluster from your application's perspective, but the operational model is completely different. This article covers what each mode does, the trade-offs, and how the Associate Cloud Engineer exam tests the choice between them.
It does not cover deep cost comparisons, every Autopilot restriction on workload configurations, or how to migrate between the two modes. The goal here is to give you the ACE exam version, which is mostly about recognizing which mode is appropriate for a given scenario.
In GKE Standard mode, you manage the nodes. You decide how many nodes to run, what machine type each node uses, when to upgrade them, how to scale them. GKE provisions and runs the control plane for you, but the worker nodes are yours to configure.
In GKE Autopilot, Google manages the nodes. You do not pick machine types. You do not configure node pools. You do not run a cluster autoscaler. You deploy your pods, and Google figures out where to run them and how many nodes to keep around. You pay per pod for the resources your pods actually request, not for the nodes themselves.
That is the entire mental model. Standard means "you run the nodes." Autopilot means "Google runs the nodes."
When you use Autopilot, GKE handles a list of operational tasks that you would otherwise have to handle yourself in Standard mode. Node provisioning. Node sizing. Node repairs when something goes wrong with a node. Security patches and OS updates on the underlying node images. Scaling the node pool up and down based on pod demand. Enforcing best-practice configurations like resource requests on every pod.
The trade-off is that Autopilot also restricts what you can do. You cannot SSH into nodes. You cannot use privileged pods. You cannot use certain DaemonSets that need direct node-level access. You cannot use every machine type. For most application workloads, none of these restrictions matter. For specialized cases, they can be blocking.
Standard mode is the right choice when you genuinely need control over the nodes. Cases where this comes up include workloads that require specific machine types not supported by Autopilot, applications that need privileged containers or host access, custom DaemonSets for monitoring agents that hook into the node OS, very tight cost optimization where you want to over-provision intentionally to avoid scaling lag, and clusters where you want to use specific GPU configurations or sole-tenant nodes.
For a typical microservices stack, none of those things matter. You just want to deploy pods, scale them, and not think about nodes. That is the case Autopilot was built for.
Pricing is one of the most-tested aspects of this comparison.
In Standard mode, you pay for nodes. If you have ten n1-standard-4 nodes running, you pay for ten n1-standard-4 VMs whether your pods are using all that capacity or not. Idle node capacity is wasted spend.
In Autopilot, you pay for pods. Specifically, you pay for the CPU, memory, and ephemeral storage that your pods request, plus a small per-pod premium. There is no concept of unused node capacity from your perspective, because you do not see the nodes.
For workloads with steady, predictable demand, Standard can be cheaper because you can size nodes tightly. For bursty or low-utilization workloads, Autopilot is often cheaper because you are not paying for capacity sitting idle. There are also cases where Autopilot's per-pod overhead makes it more expensive at scale.
The exam tests this in a few patterns.
The first pattern is a scenario where a team wants to focus on application development without managing infrastructure. The answer is Autopilot. If the question mentions "minimize operational overhead," "team wants to focus on the application layer," or "Google manages the cluster," Autopilot is the answer.
The second pattern is the inverse. The scenario describes a workload with specific node-level requirements, like custom machine types, privileged access, or specialized hardware. The answer is Standard mode. If you see "needs custom node configuration," "requires SSH access to nodes," or specific hardware requirements, Standard is what is being tested.
If you see "managed nodes" or "no node management" in a GKE question, think Autopilot. If you see "specific machine type" or "node-level access," think Standard.
Autopilot and Standard are two operational models for the same underlying GKE service. Autopilot is the right default for most application workloads. Standard is the right choice when you need control over the nodes for specific reasons.
The Associate Cloud Engineer exam tests this as a choice between operational simplicity (Autopilot) and infrastructure flexibility (Standard). If the scenario does not call out specific node requirements, Autopilot is usually the answer.
My Associate Cloud Engineer course covers Autopilot and Standard mode in the GKE section, alongside how each mode interacts with node pools, autoscaling, and the GKE release channels.
