KCNA Container Orchestration Practice Question
A cluster administrator deploys a web application as a Deployment named 'web' with 4 replicas. Users report that requests to the application sometimes reach a Pod that is still starting up and not ready to serve traffic. Which Kubernetes object should the administrator configure to ensure only ready Pods receive traffic?
⚠ Common exam trap
It's easy for candidates to confuse liveness probes, which restart containers, with readiness probes, which control Service endpoint membership.
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
✓
A readiness probe on the Pod template
Readiness probes control whether a Pod's IP is included in a Service's endpoints. When the probe fails, the Pod is marked NotReady and removed from load balancing. Liveness probes restart containers, startup probes delay other probes, and PodDisruptionBudgets govern voluntary evictions. Only a readiness probe directly ensures traffic goes solely to Pods ready to serve requests.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A startup probe on the Pod template
Why it's wrong here
A startup probe delays liveness and readiness checks until the application has started, but it does not itself determine Service endpoint membership. Without a readiness probe, the Pod may still be added to endpoints prematurely. It is useful for slow-starting containers, but not the direct solution here.
- ✓
A readiness probe on the Pod template
Why this is correct
A readiness probe determines whether a container is ready to accept traffic. When a Pod is not ready, the kubelet sets its Ready condition to False, and the Endpoints controller removes its IP from the Service's endpoints. This directly prevents traffic from reaching starting or unhealthy Pods, matching the administrator's goal.
- ✗
A PodDisruptionBudget on the Deployment
Why it's wrong here
A PodDisruptionBudget limits voluntary disruptions such as node drains. It does not control whether a Pod is considered ready for Service traffic. It is unrelated to the symptom of requests reaching starting Pods, so it would not fix the issue.
- ✗
A liveness probe on the Pod template
Why it's wrong here
A liveness probe checks whether a container is still running. If it fails, the kubelet restarts the container. It does not influence Service endpoint membership, so a starting Pod could still receive traffic. This does not solve the problem of requests reaching unready Pods.
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-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 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.