CKA Troubleshooting Practice Question
You are troubleshooting a network connectivity issue between two pods in different namespaces. The pods have the following labels: pod-a in namespace 'foo' with labels {app: web}, pod-b in namespace 'bar' with labels {app: db}. You verify that both pods have IP addresses and can ping the Kubernetes service IP. However, pod-a cannot connect to pod-b on port 5432. What should you check first?
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 a NetworkPolicy exists that denies ingress traffic to pod-b from namespace 'foo'
Since pod-a can reach the Kubernetes service IP, the issue is likely a NetworkPolicy that denies ingress traffic from namespace 'foo' to pod-b on port 5432. NetworkPolicies can restrict cross-namespace traffic. Options A, C, and D are less likely because kube-proxy, container runtime, and DNS are not the primary suspects when connectivity to the service IP works.
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 if the kube-proxy is running on the node hosting pod-b
Why it's wrong here
Checking kube-proxy on the node hosting pod-b is a red herring because kube-proxy only manages ClusterIP service traffic via iptables or IPVS rules. Direct pod-to-pod communication uses the pod's IP address and is forwarded by the CNI plugin (e.g., Calico, Cilium, Flannel) through a virtual bridge or overlay network, not through kube-proxy. Since the user can already ping the Kubernetes service IP, kube-proxy is demonstrably alive and functional; even if it were not running, it would not affect a direct connection to pod-b's IP on port 5432.
- ✓
Check if a NetworkPolicy exists that denies ingress traffic to pod-b from namespace 'foo'
Why this is correct
A NetworkPolicy is a namespaced Kubernetes resource that acts as a pod-level firewall, and if cluster networking is configured with a CNI that enforces it, any ingress rule can explicitly deny traffic from pods in other namespaces. The default behavior is allow-all only when no NetworkPolicy selects the pod; once one exists, the default becomes deny for anything not matched by its rules. If a policy selects pod-b and its ingress list does not include namespace 'foo' or a matching podSelector, it will silently drop the TCP SYN packets from pod-a, making the port 5432 connection time out or refuse while the service IP ping still succeeds.
- ✗
Check if the container runtime is Docker
Why it's wrong here
The container runtime (whether Docker, containerd, or CRI-O) is irrelevant to pod-to-pod connectivity at the layer this symptom describes. Kubernetes delegates all networking to the CNI plugin, which is responsible for allocating pod IPs, creating virtual interfaces, and enforcing routing rules; the runtime merely launches containers and attaches them to the network namespace the CNI prepared. Docker's own bridge network is never used for pod IPs when Docker is run via cri-dockerd, and the runtime choice does not affect NetworkPolicy enforcement, route tables, or iptables rules.
- ✗
Check if the DNS resolution for pod-b's service is correct
Why it's wrong here
DNS alone cannot be the culprit because the failure is observed at the connection level to a specific port (5432), not at the name-resolution stage. If the user is connecting directly by pod-b's IP or via a service, an incorrect DNS record would typically produce an NXDOMAIN error or a resolution to the wrong ClusterIP, not a refused or timed-out TCP connection. Moreover, even if the service name resolves correctly, the subsequent packets still pass through kube-proxy DNAT into pod-b's namespace, where a NetworkPolicy can still drop the traffic based on the source namespace 'foo'.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
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 — 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.