CKAD Services and Networking Practice Question
You are responsible for a multi-tier application running in a Kubernetes cluster. The frontend Pods communicate with backend Pods via a Service named 'backend' in the same namespace. Recently, the frontend team reported that the backend Service is intermittently unreachable. You inspect the backend Pods and notice that they are all running and ready, but the Endpoints object for the 'backend' Service shows only a subset of the Pod IPs. You also notice that the backend Pods have a readiness probe configured that checks an HTTP endpoint '/healthz'. The readiness probe has a periodSeconds of 5 and failureThreshold of 3. The application logs show occasional spikes in response time on the /healthz endpoint, sometimes exceeding 15 seconds. You need to resolve the intermittent unavailability without removing the readiness probe. Which action should you take?
⚠ Common exam trap
The trap here is that candidates might think removing the readiness probe (Option A) is a quick fix, but the CKAD exam emphasizes that readiness probes are essential for traffic routing and should be tuned, not removed, to handle transient issues.
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
✓
Increase the failureThreshold to 10 and periodSeconds to 10 to tolerate transient slowness
Increasing the failureThreshold to 10 and periodSeconds to 10 gives the readiness probe more time (100 seconds total) to tolerate transient slowness on the /healthz endpoint, preventing premature removal of Pod IPs from the Endpoints object. This keeps all backend Pods in the ready state during response time spikes, ensuring the Service remains reachable.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove the readiness probe configuration from the backend Pods
Why it's wrong here
Removing the readiness probe from the backend Pods eliminates the health gate that the Service uses to decide which Pods become endpoints. Without a readiness probe, the kubelet never marks a Pod as not-ready, so the Service will route traffic to Pods even when the application cannot serve requests (e.g., during dependency outages or resource exhaustion). This directly defeats the purpose of the probe and would cause the user-facing tier to send traffic into unhealthy backends, worsening the situation rather than tolerating transient slowness.
- ✗
Add a second readiness probe on a different endpoint to increase redundancy
Why it's wrong here
Adding a second readiness probe on a different endpoint makes the problem worse because Kubernetes requires all readiness probes to pass for a Pod to be considered ready. The backend is already slow to respond on the existing probe; a second probe would add another failure condition that must also succeed, increasing the likelihood that the Pod is removed from Service endpoints more often. Instead of increasing resilience, this compounds the flapping effect because any single probe failure on either endpoint marks the Pod unready, reducing overall availability for a transient downturn.
- ✗
Change the Service type from ClusterIP to NodePort to bypass endpoint issues
Why it's wrong here
Changing the Service type from ClusterIP to NodePort has no effect on how the Service populates its endpoints or how readiness probes are evaluated. The controller manager still filters endpoints based on Pod readiness status, regardless of whether the Service is ClusterIP, NodePort, or LoadBalancer. Since the issue is the readiness probe's threshold being too low, altering the Service type does not change the probe's sensitivity to slowness, so the endpoints would continue to be removed just as frequently; it merely exposes the same endpoints on a different network path.
- ✓
Increase the failureThreshold to 10 and periodSeconds to 10 to tolerate transient slowness
Why this is correct
Increasing failureThreshold to 10 and periodSeconds to 10 gives the readiness probe a much larger tolerance window: the kubelet would need 10 consecutive failed probes spaced 10 seconds apart (i.e., about 90 seconds of continuous failures) before marking the backend Pod unready. This directly addresses transient slowness because brief spikes in latency or occasional failed HTTP responses will not cause the Pod to be dropped from Service endpoints. The tradeoff is that truly dead backends take longer to be removed, but for a multi-tier app that only needs to tolerate temporary degradation, this is the correct, targeted tuning.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 160 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.