KCNA Kubernetes Fundamentals Practice Question
A developer runs `kubectl apply -f pod.yaml` against a cluster running Kubernetes v1.29. The Pod manifest sets `spec.restartPolicy: Always` and `spec.containers[0].name: app`. The Pod starts successfully but the developer wants to change the container image from `nginx:1.24` to `nginx:1.25`. They edit the YAML file and re-run `kubectl apply -f pod.yaml`. What is the result?
⚠ Common exam trap
The trap here is assuming that `kubectl apply` can mutate any field of a live Pod, when in fact most Pod spec fields including the container image are immutable.
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
✓
The apply fails with an error indicating that the Pod spec is invalid or cannot be updated.
Pods have a largely immutable spec once created. Changing the container image via `kubectl apply` is rejected by the API server with an immutable-field error. The intended workflow for image updates is to use a controller such as a Deployment, which creates a new ReplicaSet and new Pods. For a bare Pod, you must delete it and recreate it with the new image.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The apply succeeds but the change is silently ignored because Pods are managed by the kubelet.
Why it's wrong here
The API server does not silently ignore invalid updates. It returns a clear validation error to the client. The kubelet only reconciles the Pod spec that the API server stores; it does not accept external edits to the Pod's image field. Silent ignoring would make debugging far harder and is not how the Kubernetes API behaves.
- ✓
The apply fails with an error indicating that the Pod spec is invalid or cannot be updated.
Why this is correct
Most fields of a running Pod's spec, including the container image, are immutable. The API server rejects the update attempt with a validation error stating that the field is immutable. To change the image you must delete and recreate the Pod, or manage it through a Deployment or similar controller that handles replacement for you.
- ✗
The existing Pod is patched in place and the container image is updated without restarting the Pod.
Why it's wrong here
Kubernetes does not support in-place mutation of a container image on a running Pod. The kubelet would need to stop and restart the container to switch images, and the API server prevents this class of update on Pod objects. Controllers like Deployments achieve image changes by creating new Pods, not by patching existing ones.
- ✗
The Pod is deleted and recreated with the new image because Pods are immutable.
Why it's wrong here
Pods are not fully immutable, but the container image field is not one of the fields that can be updated in place. The API server rejects the image change with a validation error rather than deleting and recreating the Pod. Deletion and recreation only happens if a controller such as a Deployment manages the Pod; a bare Pod applied directly is not recreated automatically.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA 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 KCNA exam.