CKA Troubleshooting Practice Question
Which TWO of the following commands are useful for debugging network connectivity between pods?
⚠ Common exam trap
A common mix-up: candidates confuse resource monitoring (`kubectl top`) or log inspection (`kubectl logs`) with active network probing, and may overlook that `ping` uses ICMP which is often filtered, while `wget` uses TCP which is more reliable for connectivity tests.
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 run test-pod --image=busybox --rm -it -- wget -O- http://service:port
Option B is correct because running an ephemeral busybox pod with `kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port` lets you test DNS resolution and HTTP connectivity from a separate pod to a target service, which is a standard way to isolate whether a connectivity problem is pod-specific or service-wide. Option E is correct because `kubectl exec <pod-name> -- ping <target-ip>` executes a network utility inside an existing pod, directly verifying ICMP reachability and basic IP-level connectivity between that pod and the target. Option A is not useful here because `kubectl top pod` only reports CPU and memory usage metrics, not network reachability. Option C is not useful because `kubectl edit deployment` modifies the deployment manifest and does not test connectivity. Option D is not useful because `kubectl logs` only retrieves container stdout/stderr output and does not actively probe network paths.
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 top pod <pod-name>
Why it's wrong here
kubectl top pod <pod-name> queries the metrics-server API to display current CPU and memory consumption for a pod. This is a performance-monitoring command that reveals resource pressure or throttling, not a network-troubleshooting tool. It will not help you determine whether a Service endpoint is reachable or why an application cannot connect to a backend service.
- ✓
kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port
Why this is correct
kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port launches a temporary, interactive busybox Pod that performs an HTTP request against the target Service from within the cluster network. The --rm flag ensures the Pod is deleted after the command finishes, and -it lets you see the output immediately. This is a classic debugging pattern for validating DNS resolution, Service routing, and application response without altering any existing workloads.
- ✗
kubectl edit deployment <deployment-name>
Why it's wrong here
kubectl edit deployment <deployment-name> opens the Deployment's desired-state manifest in your default editor, allowing you to modify replicas, container images, or environment variables. It is a mutating configuration operation that triggers a rollout when changes are saved; it provides no diagnostic information about runtime failures, network reachability, or pod status. Debugging requires inspection commands like logs, exec, or describe, rather than editing resources.
- ✗
kubectl logs <pod-name>
Why it's wrong here
kubectl logs <pod-name> retrieves the captured stdout and stderr streams from the containers in a Pod, making it invaluable for reviewing application-level errors, stack traces, or startup messages. However, it only shows what the process wrote to its own output; it cannot test TCP/UDP connectivity, DNS lookups, or Service discovery from inside the cluster. If the application is failing due to a network issue, logs will only reveal the symptom, not the underlying path or route.
- ✓
kubectl exec <pod-name> -- ping <target-ip>
Why this is correct
kubectl exec <pod-name> -- ping <target-ip> executes a command inside an already-running container, using that Pod's network namespace to probe reachability to another IP address. This is useful when you need to verify forwarding, firewall rules, or network policies from a specific Pod’s perspective. The limitation is that the container must have the ping binary and the Pod must be running; if it is CrashLoopBackOff or lacks networking tools, you would need an ephemeral container or a kubectl run test Pod instead.
Visual reference
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
Key term
Log Analysis
Log analysis is the process of reviewing and interpreting system-generated records to understand what happened in an application or infrastructure.
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.