CKA Practice Question: Cluster Architecture, Installation & Configuration
You are a cluster administrator managing a multi-node Kubernetes cluster version 1.22. The cluster runs critical applications in the 'production' namespace. You have been asked to upgrade the control plane node to version 1.23 while minimizing downtime. The cluster uses a single control plane node (not HA). You have already backed up etcd and verified the backup is valid. You have also reviewed the upgrade notes and there are no breaking changes that affect your workloads.
You have drained the control plane node and ensured all pods are evicted. The node is now in 'Ready,SchedulingDisabled' state. You then run 'kubeadm upgrade plan' and see that upgrade to v1.23.0 is available. Next, you run 'kubeadm upgrade apply v1.23.0'. The command completes successfully. However, when you try to uncordon the node with 'kubectl uncordon <node>', you get an error: 'error: unable to update node: the object has been modified; please apply your changes to the latest version and try again'. What is the most likely cause and the correct next step?
⚠ Common exam trap
A common mix-up: candidates think the node is in a broken state requiring a restart or rejoin, when in fact the error is just a transient API conflict that is resolved by retrying the uncordon command.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Re-run the 'kubectl uncordon' command; the conflict is transient due to concurrent updates.
The error 'the object has been modified' indicates a resource conflict due to concurrent updates to the node object, typically from the kubelet or controller manager updating the node status simultaneously. This is a transient optimistic locking conflict in Kubernetes, and simply retrying the 'kubectl uncordon' command will resolve it because the conflict is temporary and the node is already upgraded and ready to be scheduled.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Re-drain the node to reset its state, then uncordon again.
Why it's wrong here
Re-draining an already-drained node is unnecessary and harmful: it flips the node back to unschedulable and evicts running pods, amplifying downtime without addressing the API server's 409 Conflict. The conflict comes from a resourceVersion mismatch on the Node object, not from an incomplete drain state. Retrying `kubectl uncordon` fetches the current resourceVersion and applies the `unschedulable: false` update, so no additional drain cycle is needed.
- ✓
Re-run the 'kubectl uncordon' command; the conflict is transient due to concurrent updates.
Why this is correct
`kubectl uncordon` performs a read-modify-write on the Node object; the API server rejects the write with 409 Conflict if the resourceVersion it sent is stale because the Node was concurrently updated by another actor (e.g., a controller or another admin). This is optimistic concurrency control to prevent lost updates—the conflict is transient, and re-running the command simply retrieves the latest resourceVersion and resubmits the `unschedulable=false` change. Unless the conflict persists repeatedly, no further node-level remediation is required.
- ✗
Restart the kubelet on the control plane node to refresh the node object.
Why it's wrong here
Restarting the kubelet on the control plane node is irrelevant because that kubelet only heartbeats its own Node object and does not participate in updating the target node's `spec.unschedulable` field. It would also restart kubelet-managed static pods on the control plane, risking disruption to control-plane components. The conflict is an API-level optimistic concurrency error, not a kubelet liveness issue, so bouncing the kubelet cannot refresh the target node's resourceVersion or resolve the 409.
- ✗
Generate a new bootstrap token and rejoin the node to the cluster.
Why it's wrong here
Generating a new bootstrap token and rejoining the node is a drastic and inappropriate response to a transient 409 Conflict. Bootstrap tokens are only needed during initial registration; `kubectl uncordon` edits an existing Node object and does not require reauthentication or re-registration. Deleting and rejoining would recreate the Node identity, wipe node leases and associated metadata, and cause unnecessary disruption—while the actual fix is simply retrying the uncordon with the latest resourceVersion.
Visual reference
Go deeper
Related to this question
Learn chapter
Workloads and Pod Basics
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.