CKAD Application Design and Build Practice Question
You are tasked with deploying a stateless web application on a Kubernetes cluster. The application is containerized and listens on port 8080. You have created a Deployment named 'webapp' with 3 replicas, and a ClusterIP Service named 'webapp-svc' exposing port 80 targeting the application's port 8080. During testing, you notice that some requests to the service return errors while others succeed. You have verified that all Pods are running and ready. The application logs show no errors. What is the most likely cause of the intermittent failures?
⚠ Common exam trap
CNCF often tests the distinction between 'Pod is Running' (container process started) and 'Pod is Ready' (application is healthy and can serve traffic), trapping candidates who assume that a Running Pod is automatically ready to receive Service traffic.
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 Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.
The intermittent failures are most likely caused by the absence of a readiness probe in the Deployment. Without a readiness probe, the Service's EndpointSlice controller considers all Pods with a matching label selector as ready endpoints, even if the application inside the container has not finished initializing or is temporarily unable to serve traffic. This results in the ClusterIP Service load-balancing requests to Pods that are not actually ready, causing some requests to fail while others succeed.
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 ClusterIP Service type does not support load balancing.
Why it's wrong here
ClusterIP Services expose a stable virtual IP and do perform internal load balancing across the selected Pods through iptables or IPVS rules managed by kube-proxy. They lack external load-balancing capabilities, but for traffic originating within the cluster, they distribute connections fairly among healthy endpoints. Therefore, claiming that ClusterIP does not support load balancing is factually incorrect; the intermittent failures must stem from another cause.
- ✗
The Service is not configured with enough endpoints.
Why it's wrong here
The endpoint controller dynamically reconciles Service endpoints from the Pods that match the Service’s label selector and are marked Ready. If the Deployment’s Pods exist but are not passing readiness checks, the Service automatically removes their IPs from the endpoint list, so 'not enough endpoints' is a symptom, not a root cause. A fixed number of endpoints is never preconfigured; the system adjusts in real time, making this option an oversimplification.
- ✗
The Service's targetPort is set incorrectly, causing traffic to be misrouted.
Why it's wrong here
A targetPort directs Service traffic to a specific container port; here it is set to 8080, which matches the application’s listening port. If targetPort were wrong, every request would fail consistently (e.g., connection refused or timeout), not just intermittently. Because the symptoms are sporadic, a misconfigured targetPort cannot be responsible; the failure mode is all-or-nothing, not partial.
- ✓
The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.
Why this is correct
Without a readiness probe, kube-proxy considers a Pod 'Ready' as soon as its containers are running, even if the application inside is still initializing, warming up, or temporarily unable to handle traffic. This causes the Service to include such Pods as endpoints, so some requests get routed to a Pod that will sporadically return 5xx errors or drop the connection. A readiness probe solves this by marking the Pod Ready only when it responds successfully to a health check, ensuring the Service’s endpoint list contains only truly available Pods.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 160-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 CKAD 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 CKAD exam.