CKS Practice Question: A DevOps team is tasked with upgrading a…

Answer analysis

Option-by-option breakdown

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

• ✗

  Upgrade worker nodes first, then the control plane

  Why it's wrong here

  Upgrading worker nodes before the control plane places kubelet at a higher minor version than kube-apiserver, which violates the Kubernetes version skew policy. The policy only allows kubelet to be one minor version *older* than the API server, never newer. If a 1.22 kubelet communicates with a 1.21 API server, it may use API groups or features the server does not yet serve, leading to node registration failures or reconciliation errors. The control plane must always be upgraded first so it is the source of truth for the new version.

• ✗

  Upgrade etcd to 1.22 first, then the API server

  Why it's wrong here

  Upgrading etcd to 1.22 while the API server remains on 1.21 creates an unsupported version skew between the storage backend and kube-apiserver. Each Kubernetes release pairs the API server with a specific supported etcd minor version; 1.22 expects etcd 3.5.x, but a 1.21 API server expects etcd 3.4.x. Because etcd is part of the control plane, it should be upgraded in conjunction with the API server—specifically, kube-apiserver is upgraded first to establish the new storage version, then etcd is rolled. Doing etcd first risks data corruption or serialization mismatches when the older API server writes to the newer etcd.

• ✓

  Upgrade the control plane from 1.21 to 1.22 first, then upgrade worker nodes

  Why this is correct

  This is the supported upgrade path because the kube-apiserver must run at a higher or equal minor version than all other control-plane components and kubelets. By upgrading the control plane from 1.21 to 1.22 first, the API server can continue serving the existing 1.21 worker nodes without any version-skew violation; the policy explicitly allows kubelet to lag the API server by exactly one minor version. After the control plane is stable and the cluster object store is on the new version, each worker node is cordoned, drained, upgraded to 1.22, and uncordoned. This rolling approach keeps the cluster functional throughout and matches the kubeadm upgrade sequence.

• ✗

  Drain all nodes, then upgrade all components to 1.22 at once

  Why it's wrong here

  Draining all nodes before upgrading every component to 1.22 at once is dangerous because it removes all workloads and the control plane's availability before any piece is actually upgraded; if the upgrade fails, there is no running master to coordinate recovery. The official strategy is to upgrade the control plane first (one node at a time in HA), then drain and upgrade each worker node individually, keeping the rest of the cluster available. A simultaneous full upgrade also makes it impossible to attribute failure to a specific component and violates the version skew policy during the transition because the API server and kubelet would temporarily be at different versions. Rolling upgrades are intentionally sequential to guarantee an available apiserver at every step.

Go deeper

Related to this question