CKA Pod can't reach service Practice Question
A pod is running but cannot be accessed via its ClusterIP service from another pod in the same namespace. The service endpoints list shows the pod's IP. What is the most likely cause?
⚠ Common exam trap
Watch out — candidates often assume a populated endpoints list guarantees connectivity, but they overlook that NetworkPolicies operate at a lower layer (L3/L4) and can block traffic even when the service and pod are correctly configured.
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
✓
A NetworkPolicy is blocking the traffic
A NetworkPolicy can explicitly deny ingress traffic to a pod even when the service endpoints are correctly populated. Since the endpoints list shows the pod's IP, the service and pod are communicating at the network layer, but a NetworkPolicy with an ingress rule that does not allow traffic from the source pod's labels or CIDR will cause the packet to be dropped by the node's iptables or eBPF rules, resulting in a connection timeout or reset from the client pod.
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 kube-proxy is not running on the node
Why it's wrong here
This would cause all Service ClusterIP traffic on that node to fail, not just from one pod. kube-proxy is responsible for programming iptables/IPVS rules that implement the Service's virtual IP and port mapping. If it were down, every pod on that node would lose connectivity to all Services, which is a broader symptom than the specific 'pod can't reach service' described.
- ✓
A NetworkPolicy is blocking the traffic
Why this is correct
NetworkPolicy is a namespace-scoped firewall that can restrict egress traffic from a specific pod (via podSelector) to a destination service's backing pod IP or CIDR. Even if the Service object and endpoints are intact, a NetworkPolicy denying egress from the source pod to the backend pod's IP or port will silently drop the packets, making the Service unreachable only for the affected pod(s).
- ✗
The service's targetPort is incorrect
Why it's wrong here
A wrong targetPort in the Service definition means the Service's clusterIP forwards to a port where the backend pod has no listener, resulting in connection refused for all clients of that Service. Because the problem specifically affects a single pod's ability to reach the Service, while other clients presumably work, this cannot be the cause; misconfigured targetPort would be global to the Service.
- ✗
The pod is running on a different node without proper routing
Why it's wrong here
If the CNI plugin does not provide inter-node routing, then all pod-to-pod traffic between those nodes would fail, and the problem would not be limited to Service traffic or to a single source pod. Additionally, Service traffic relies on the same cluster network: when kube-proxy DNATs to the backend pod IP, routing still uses the cluster network. A routing failure would manifest as broad connectivity loss, not as an isolated inability to reach one Service.
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.
✓A NetworkPolicy is blocking the trafficCorrect answer▾
Why this is correct
NetworkPolicy is a namespace-scoped firewall that can restrict egress traffic from a specific pod (via podSelector) to a destination service's backing pod IP or CIDR. Even if the Service object and endpoints are intact, a NetworkPolicy denying egress from the source pod to the backend pod's IP or port will silently drop the packets, making the Service unreachable only for the affected pod(s).
✗The kube-proxy is not running on the nodeWrong answer — click to see why▾
Why this is wrong here
kube-proxy issues would affect all services cluster-wide, not just one service with correct endpoints.
✗The service's targetPort is incorrectWrong answer — click to see why▾
Why this is wrong here
If targetPort were wrong, endpoints might still show but traffic would not reach the container; but endpoints are based on the container port, so if endpoints exist, targetPort matches.
✗The pod is running on a different node without proper routingWrong answer — click to see why▾
Why this is wrong here
ClusterIP services work across nodes; no extra routing needed.
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?”
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKA question from scratch — 302 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.