CKA Troubleshooting Practice Question
A pod runs but you cannot connect to its container port from another pod in the same namespace. 'kubectl exec' into the pod and 'curl localhost:8080' works. What is the MOST likely cause?
⚠ Common exam trap
Watch out — candidates often assume a Service issue (Option C) is the cause, but the question specifies direct pod-to-pod connectivity (not via a Service), so the real problem is the application binding to localhost, which is a classic application-layer misconfiguration rather than a Kubernetes networking misconfiguration.
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
✓
The pod is bound to localhost only, not 0.0.0.0
When `curl localhost:8080` works inside the pod but connections from other pods fail, the most likely cause is that the application is listening only on the loopback interface (127.0.0.1) instead of 0.0.0.0 (all interfaces). This means the container process binds to localhost, which is only reachable from within the same network namespace (the pod itself), not from external sources like other pods. Kubernetes networking relies on the container listening on 0.0.0.0 so that traffic arriving via the pod's eth0 interface (which has its own IP) can be accepted.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
There is a NetworkPolicy blocking ingress
Why it's wrong here
A NetworkPolicy can block ingress to a pod, but only at the cluster network layer, and it cannot make a loopback-only listener reachable. If the pod were listening on 0.0.0.0, traffic could still be blocked by a policy, but the symptom here is due to the application's binding. Since the correct answer is the loopback binding, this is not the cause.
- ✗
The container's port is not exposed in the pod spec
Why it's wrong here
The containerPort field in the Pod spec is purely descriptive for Kubernetes and does not actually open any firewall ports or affect the application's listening socket. A container can accept connections on any port it binds, even if that port is not declared, as long as the bind address is reachable. Thus, failing to expose it would not prevent external connectivity.
- ✗
The Service selector does not match the pod labels
Why it's wrong here
A Service selector mismatch would prevent the Service from forwarding traffic to the pod, but the pod could still be accessed directly via its IP or host network. Since the question states a pod runs but you cannot connect to its container port, it implies direct connectivity is failing, which points to the bind address rather than the Service configuration. Therefore, this is not the correct explanation.
- ✓
The pod is bound to localhost only, not 0.0.0.0
Why this is correct
Binding to localhost (127.0.0.1) restricts connections to only the same network namespace, which is isolated to the container itself. Kubernetes networking relies on the pod's IP address and virtual Ethernet interfaces, so a loopback bind cannot receive traffic from outside the pod. Listening on 0.0.0.0 makes the port available on all interfaces, including the pod's external-facing one.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
CNI Plugins
CNI plugins are modular software components that configure container network interfaces according to the Container Network Interface specification, allowing containers to communicate within a Kubernetes cluster.
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 — 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.