CKA ClusterIP unreachable Practice Question
A Service of type ClusterIP is not reachable from within the cluster. Pods backing the Service are running and healthy. What is the most likely cause?
⚠ Common exam trap
Candidates often assume a healthy Pod and Service object guarantee connectivity, overlooking that kube-proxy must actively program the underlying network rules to make the ClusterIP routable.
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
✓
kube-proxy not running or misconfigured
When Pods are healthy but a ClusterIP Service is unreachable from within the cluster, the most common cause is that kube-proxy is not running or is misconfigured. kube-proxy is responsible for implementing the ClusterIP virtual IP by programming iptables (or IPVS) rules on each node to forward traffic to the selected Pods. Without these rules, packets destined for the ClusterIP are dropped or rejected, even though the Service and Endpoints objects exist.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
DNS resolution failure
Why it's wrong here
DNS resolution failure is a symptom of a broader networking issue, not a cause of ClusterIP unreachability. ClusterIPs are virtual IPs programmed into iptables or IPVS by kube-proxy; even if DNS works perfectly, a Service's ClusterIP remains unreachable when kube-proxy's rules are absent or stale. DNS failures typically stem from CoreDNS pods being down, which is independent of the data path that routes ClusterIP traffic.
- ✓
kube-proxy not running or misconfigured
Why this is correct
kube-proxy is the component responsible for implementing the Service abstraction by installing iptables, IPVS, or eBPF rules on every node. If it is not running, misconfigured, or its rules are out of sync, packets destined for the ClusterIP have no forwarding rules and are silently dropped or rejected. This directly matches the symptom of an unreachable ClusterIP while the backing pods and their endpoints may still be healthy.
- ✗
Ingress controller not set up
Why it's wrong here
An Ingress controller operates at Layer 7 and provides HTTP/HTTPS routing based on hostnames and paths, but it has no role in making a ClusterIP reachable from within the cluster. ClusterIP traffic is handled entirely at Layer 4 by service proxy rules; Ingress is only relevant for external access to Services, often via NodePort or LoadBalancer, and cannot fix or cause a direct ClusterIP connectivity failure.
- ✗
Service type should be NodePort
Why it's wrong here
The Service type does not affect ClusterIP reachability because every Kubernetes Service, regardless of whether it is ClusterIP, NodePort, or LoadBalancer, is assigned a ClusterIP and is reachable at that address from inside the cluster. NodePort merely adds a static port on every node for external traffic; choosing NodePort would not resolve an internal ClusterIP connectivity problem. Changing the type would only expose the Service externally and would not repair the underlying missing or broken forwarding rules.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.
✓kube-proxy not running or misconfiguredCorrect answer▾
Why this is correct
kube-proxy is the component responsible for implementing the Service abstraction by installing iptables, IPVS, or eBPF rules on every node. If it is not running, misconfigured, or its rules are out of sync, packets destined for the ClusterIP have no forwarding rules and are silently dropped or rejected. This directly matches the symptom of an unreachable ClusterIP while the backing pods and their endpoints may still be healthy.
✗DNS resolution failureWrong answer — click to see why▾
Why this is wrong here
DNS resolves Service name to ClusterIP; connectivity fails after.
✗Ingress controller not set upWrong answer — click to see why▾
Why this is wrong here
Ingress is for external; ClusterIP is internal.
✗Service type should be NodePortWrong answer — click to see why▾
Why this is wrong here
ClusterIP works internally.
Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
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.