CKA ClusterIP Service not reachable Practice Question
A ClusterIP Service is not reachable from within the cluster. You verify that the Service has endpoints. Which of the following could be the cause? (Select two.)
⚠ Common exam trap
Candidates may think a failing readiness probe can cause unreachability even when endpoints exist, but that is not possible because the pod would be removed from endpoints upon probe failure.
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 is not running on the node.
Option A is correct because kube-proxy is the component that programs the iptables/IPVS rules on each node to implement ClusterIP Service virtual IP load balancing; if kube-proxy is not running on a node, pods on that node cannot reach the Service's ClusterIP even though endpoints exist. Option B is correct because the Service's targetPort must match the port the container actually listens on; if the container listens on a different port, traffic forwarded to the endpoint will be refused or dropped, making the Service unreachable despite having endpoints. Option C is not correct because a failing readiness probe would remove the pod from the Service's endpoints, but the scenario explicitly states that endpoints exist, so this cannot be the cause. Option D is not correct because Kubernetes Service names are limited to 63 characters by DNS label rules, but an overly long name would be rejected at creation time rather than causing a running Service with endpoints to be unreachable.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
kube-proxy is not running on the node.
Why this is correct
kube-proxy programs the iptables or IPVS rules that implement ClusterIP load balancing on each node. If it is not running, packets to the virtual IP are never translated to a pod endpoint, so the Service fails despite having healthy endpoints.
- ✓
The container is listening on a different port than the Service targetPort.
Why this is correct
Endpoints exist because the selector matched pod IPs, but kube-proxy forwards to targetPort; if the container listens elsewhere, connections are refused. This satisfies the stem's condition that endpoints are present yet the Service remains unreachable.
- ✗
The pod's readiness probe is failing.
Why it's wrong here
A failing readiness probe removes the pod from the Service's endpoint list, so the Service would have no endpoints — contradicting the stem. It is tempting because readiness gates traffic, but the scenario states endpoints exist, so this cannot be the cause.
- ✗
The Service name is too long.
Why it's wrong here
Service names are DNS labels with a 63-character limit; exceeding it prevents creation, yet the stem states the Service exists with endpoints, so length cannot cause unreachability. It is tempting because naming constraints are real, and would be correct if the Service had failed to create at all.
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 is not running on the node.Correct answer▾
Why this is correct
kube-proxy programs the iptables or IPVS rules that implement ClusterIP load balancing on each node. If it is not running, packets to the virtual IP are never translated to a pod endpoint, so the Service fails despite having healthy endpoints.
✗The Service name is too long.Wrong answer — click to see why▾
Why this is wrong here
Service name length does not affect connectivity.
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
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
Courseiva writes every CKA question from scratch — 726 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 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.