Google ACE Practice Question: Ensuring Successful Operation of a Cloud Solution

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a new cluster with the desired version and migrate workloads

  Why it's wrong here

  Creating a new cluster and migrating workloads avoids the in-place control plane and node pool upgrade that the scenario explicitly requires, as GKE supports zonal or regional control plane upgrades and node pool surge upgrades without cluster recreation. This approach is tempting because it is a valid strategy for a major version jump or a complete environment refresh, where rebuilding from scratch ensures a clean state and avoids potential upgrade path conflicts.

• ✗

  Drain all nodes using kubectl drain before upgrading

  Why it's wrong here

  Draining nodes with `kubectl drain` is unnecessary and potentially harmful for a standard GKE upgrade. GKE's managed upgrade process uses a surge or rolling node pool upgrade that automatically cordons, drains, and reschedules pods in a controlled manner. Manually draining nodes first can create transient downtime and conflicts with the upgrade orchestration, especially since the control plane must be upgraded before any node-level operations. This option also ignores the correct command-line tool for upgrades, `gcloud container clusters upgrade`.

• ✗

  Manually update the kubelet version on each node

  Why it's wrong here

  Manually updating the kubelet version on each node is not supported on GKE because node kubelet versions are managed as part of the node pool's version and configuration. SSHing into nodes and editing kubelet settings would be overwritten by the managed instance group or violate the GKE security and support model. The correct approach is to use `gcloud container node-pools upgrade`, which performs a rolling or surge replacement of nodes with the desired Kubernetes version. Any manual change to a node's kubelet also risks putting nodes out of the supported version skew relative to the control plane.

• ✓

  Upgrade the cluster's control plane using gcloud container clusters upgrade

  Why this is correct

  Upgrading the cluster's control plane with `gcloud container clusters upgrade` is the correct first step because GKE enforces a maximum version skew between the control plane and node pools—typically one minor version. The control plane must be on the target version before node pools can be upgraded, and this command without a `--node-pool` flag updates only the control plane. This ensures the Kubernetes API server and scheduler are consistent with the target version, reducing the risk of API deprecations or incompatibility. It is the only supported way to perform an in-place control plane upgrade while preserving cluster identity and state.

• ✓

  Upgrade node pools using gcloud container node-pools upgrade

  Why this is correct

  After the control plane is upgraded, node pools must be upgraded separately using `gcloud container node-pools upgrade` to match the control plane version cluster-wide. The node pool upgrade performs a surge upgrade (or rolling upgrade for regional clusters) by creating temporary nodes with the new kubelet version, draining the old nodes, and then removing them. This step is necessary because GKE does not automatically upgrade node pools when the control plane is upgraded—you must explicitly issue the command for each pool. Running this command brings all nodes to the same Kubernetes version, eliminating version skew and ensuring cluster health.

Go deeper

Related to this question