CKA Troubleshooting Practice Question
You are troubleshooting a scenario where a pod cannot communicate with another pod in the same namespace via service name. Which THREE steps would you take to diagnose the issue? (Select 3)
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
✓
Run 'kubectl get endpoints' to verify the service has healthy endpoints
Options B, C, and E are correct. Checking endpoints (B) verifies the service has healthy pods. Exec into the pod and using curl (C) tests connectivity to the service's cluster IP. Exec into the pod and running nslookup (E) checks DNS resolution of the service name. Option A checks node status, which is not directly related to pod-to-pod communication via service name. Option D checks logs of the target pod, which may not reveal network issues.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run 'kubectl get nodes' to check node status
Why it's wrong here
Node status reflects the overall health of the Kubernetes node (Kubelet, CRI, and kube-proxy) but does not expose the state of pod-to-pod communication paths. A pod can be unable to reach another pod's Service even when all nodes show Ready, because the fault may lie in the Service's endpoint selector, a NetworkPolicy, or iptables/IPVS forwarding rules. Checking node status is a coarse, low-yield diagnostic that won't identify the specific break in the Service-to-pod chain.
- ✓
Run 'kubectl get endpoints' to verify the service has healthy endpoints
Why this is correct
A Kubernetes Service only forwards traffic to Pod IPs listed in its Endpoints object, which are populated by the controller based on matching selectors and the readiness status of pods. If the selector matches no pods, or the pods are not Ready (e.g., failing readiness probes or CrashLoopBackOff), the Endpoints object is empty, so connections to the Service's ClusterIP are dropped or refused. Running 'kubectl get endpoints' is the quickest way to confirm whether the Service actually has healthy, Ready backends, directly exposing the most common cause of communication failure.
- ✓
Exec into the pod and use curl to test connectivity to the service's cluster IP
Why this is correct
Executing 'curl' from inside the pod directly to the Service's ClusterIP tests the actual network data path through kube-proxy, load-balancing rules, and the pod network, independent of DNS. If this curl fails, the problem is likely in network plumbing—such as missing iptables rules, a misconfigured NetworkPolicy, or the target pod not listening on the expected port—rather than in service name resolution. If it succeeds, you can narrow the issue to DNS or to how the application is addressing the Service, making this a precise, methodical troubleshooting step.
- ✗
Run 'kubectl logs' on the target pod to check application logs
Why it's wrong here
Pod logs contain what the application writes to stdout/stderr, which reflects application-level behavior and not the underlying network forwarding or Service routing. A connectivity failure often occurs before a packet reaches the target container—for example, a NetworkPolicy drop, a Service with no endpoints, or a wrong port—so the target application may never even receive a request and thus log nothing. Logs are useful only after you have confirmed that packets can reach the pod; they cannot reveal why the Service is not routing traffic or why DNS resolution failed.
- ✓
Exec into the pod and run nslookup to verify DNS resolution of the service name
Why this is correct
Executing 'nslookup' inside the pod queries the cluster's DNS (CoreDNS or kube-dns) and verifies that the Service's fully qualified name (e.g., myservice.namespace.svc.cluster.local) resolves to the correct ClusterIP. If resolution fails, you can inspect the pod's /etc/resolv.conf, the CoreDNS deployment, and the Service's namespace, because the name may be in a different namespace or the DNS DNS policy may be misconfigured. If resolution succeeds, you have isolated DNS as a healthy link and can focus on connectivity to the returned ClusterIP, avoiding the common pitfall of assuming a name-based request failure is always a DNS problem.
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.