CKA Troubleshooting Practice Question
A pod is not able to communicate with another pod in the same namespace. Both pods are running and have IP addresses. Which command can you use to test connectivity from the first pod to the second pod's IP?
⚠ Common exam trap
The trap here is that candidates might choose Option D, thinking any ping between pods is equivalent, but the question specifically asks to test connectivity from the first pod to the second pod's IP, not the reverse direction.
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
✓
kubectl exec first-pod -- ping <second-pod-ip>
`kubectl exec first-pod -- ping <second-pod-ip>` runs the `ping` command inside the first pod, which uses ICMP to test IP-level connectivity to the second pod's IP address. This directly verifies whether the network path between the two pods is functional, including any CNI plugin, overlay network, or network policy rules.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
kubectl exec first-pod -- ping <second-pod-ip>
Why this is correct
kubectl exec first-pod -- ping <second-pod-ip> is the correct diagnostic because it enters the network namespace of the first pod and sends ICMP echo requests directly to the second pod's IP address. This actively tests layer 3 connectivity along the exact path the failing application would use, rather than relying on any proxy, load balancer, or DNS resolution. A successful reply confirms the network route and firewall rules permit traffic, while a failure localizes the problem to the pod-to-pod networking layer.
- ✗
kubectl logs first-pod
Why it's wrong here
kubectl logs first-pod merely retrieves the combined stdout/stderr output that containers inside the first pod have already written to their logging buffers or files. It does not generate or observe live network packets, and it cannot initiate a probe to the second pod. Even if the log contains an error like 'connection refused,' that is retrospective application data, not a direct connectivity test; you would still need an active probe to confirm current reachability.
- ✗
kubectl top pod first-pod
Why it's wrong here
kubectl top pod first-pod uses the metrics-server API to display real-time CPU and memory consumption of the pod's containers. These resource utilization metrics are collected from cgroups and kubelet, completely independent of network packet flows. High or low resource usage has no bearing on whether the pod can send packets to another pod, and the command does not attempt any network operation, so it gives zero insight into pod-to-pod connectivity.
- ✗
kubectl exec second-pod -- ping <first-pod-ip>
Why it's wrong here
kubectl exec second-pod -- ping <first-pod-ip> checks reachability from the second pod back to the first pod, which is the reverse direction of the reported failure. The scenario states that the first pod cannot communicate with the second pod, so any test must originate from the first pod's perspective. Reverse connectivity could be intact even when the forward direction is broken—for example, due to an asymmetric network policy or firewall rule—making this command unable to confirm or deny the actual issue.
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.