CKA First step service unreachable Practice Question
You need to investigate why a service is not reachable from within the cluster. Which of the following is the first step?
⚠ Common exam trap
The trap here is that candidates often jump to DNS or kube-proxy issues because those are common networking topics, but the CKA exam expects you to follow a logical troubleshooting hierarchy, starting with the simplest check—whether the service has any backing pods.
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
✓
Check if the service has endpoints
The most fundamental check when a service is unreachable from within the cluster is to verify whether the service has any endpoints. A service without endpoints means no pods are matching its selector, so traffic cannot be forwarded regardless of DNS or kube-proxy status. The `kubectl get endpoints <service>` command directly reveals this, making it the logical first step before deeper diagnostics.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Check kube-proxy logs on the nodes
Why it's wrong here
Checking kube-proxy logs is a later diagnostic step, not a first-step check. Kube-proxy continuously reconciles iptables or IPVS rules based on Service and EndpointSlice objects; if the Service's selector matches no pods, the Endpoints object is empty, and no amount of kube-proxy log inspection will reveal a rule problem. Even if kube-proxy were misconfigured, you'd first want to confirm that backends exist. In a troubleshooting workflow, verifying Endpoints is faster, has no logs to parse, and covers the most common failure mode.
- ✗
Check DNS resolution
Why it's wrong here
Checking DNS resolution addresses a symptom where a Service name cannot be resolved, but the question describes an unreachable Service, not a name-resolution failure. If the Service itself has no endpoints, ClusterIP traffic will be dropped regardless of whether DNS correctly returns the service IP. DNS checks are relevant only when the client gets 'host not found' errors, which is a different failure domain (CoreDNS vs. endpoint selection). Therefore, inspect the Service's Endpoints before investigating DNS.
- ✓
Check if the service has endpoints
Why this is correct
The first and most decisive troubleshooting step is to run `kubectl get endpoints <service>` (or `kubectl describe service`) and confirm the endpoint list is non-empty. If the selector doesn't match any pod, or the matched pods are NotReady, the EndpointSlice controller generates zero addresses, leaving kube-proxy with no valid destination for the service IP. This explains why the Service is unreachable even though the Service object itself appears healthy. Checking endpoints isolates the problem to label selectors or pod readiness immediately.
- ✗
Restart the service
Why it's wrong here
Restarting the Service object is not a meaningful action because Services are declarative control-plane objects with no embedded state or process to restart; the Kubernetes API doesn't act on a 'restart' for Services. Even if you delete and recreate the Service, the same selector and missing endpoints will reproduce the identical failure. The real issue is almost always the backing pods or their readiness, and a restart masks the symptom while adding no diagnostic value. Instead, you should inspect the Endpoints and the pods' labels and readiness status.
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.
✓Check if the service has endpointsCorrect answer▾
Why this is correct
The first and most decisive troubleshooting step is to run `kubectl get endpoints <service>` (or `kubectl describe service`) and confirm the endpoint list is non-empty. If the selector doesn't match any pod, or the matched pods are NotReady, the EndpointSlice controller generates zero addresses, leaving kube-proxy with no valid destination for the service IP. This explains why the Service is unreachable even though the Service object itself appears healthy. Checking endpoints isolates the problem to label selectors or pod readiness immediately.
✗Check kube-proxy logs on the nodesWrong answer — click to see why▾
Why this is wrong here
More advanced step; start with endpoints.
✗Check DNS resolutionWrong answer — click to see why▾
Why this is wrong here
DNS is for service discovery, not connectivity.
✗Restart the serviceWrong answer — click to see why▾
Why this is wrong here
Restarting is not troubleshooting.
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
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.