CKA Troubleshooting Practice Question
You are debugging a DNS issue from within a pod. The pod is running 'busybox'. Which command would you use to test DNS resolution for 'kubernetes.default.svc.cluster.local'?
⚠ Common exam trap
It's easy for candidates to choose Option B (curl) thinking it tests DNS, but curl tests HTTP connectivity, not resolution; or they choose Option C (kubectl run) which creates a new pod with default DNS settings, missing the specific pod's DNS configuration that may be the root cause of the issue.
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 -it my-pod -- nslookup kubernetes.default.svc.cluster.local
`kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` runs the `nslookup` command directly inside the running pod, which uses the pod's configured DNS resolver (typically CoreDNS) to resolve the Kubernetes service FQDN. This is the standard method to test DNS resolution from within a pod, as it bypasses any external DNS and validates the cluster's internal DNS chain.
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 describe svc kubernetes -n default
Why it's wrong here
The `kubectl describe svc kubernetes -n default` command retrieves detailed metadata about the Kubernetes API service, including its cluster IP, ports, and selectors. While useful for understanding service configuration, it does not perform a DNS lookup from within a pod. This command executes on the control plane or client machine, providing no insight into how a specific pod's DNS resolver is configured or if it can successfully resolve names.
- ✗
kubectl exec -it my-pod -- curl kubernetes.default.svc.cluster.local
Why it's wrong here
Using `kubectl exec -it my-pod -- curl kubernetes.default.svc.cluster.local` attempts to establish an HTTP connection to the specified service. While `curl` internally performs a DNS lookup, its primary function is to test application-layer connectivity, not solely DNS resolution. A failure could indicate a DNS issue, but also a network policy blocking traffic, a service not listening on the expected port, or an application error, making it an indirect and potentially misleading diagnostic for pure DNS problems.
- ✗
kubectl run test --image=busybox -- nslookup kubernetes.default.svc.cluster.local
Why it's wrong here
The `kubectl run test --image=busybox -- nslookup kubernetes.default.svc.cluster.local` command creates an entirely new `busybox` pod to execute the `nslookup` command. While this successfully tests DNS resolution within the cluster, it does so from a fresh pod with its own network configuration, which might differ from the original problematic pod. This approach does not debug the DNS issue *from within the specific pod* that is experiencing problems, failing to diagnose its unique network context or `resolv.conf` settings.
- ✓
kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local
Why this is correct
Executing `kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` is the most direct and effective method for debugging DNS resolution issues from within a specific pod. This command leverages `kubectl exec` to run `nslookup` directly inside `my-pod`, utilizing that pod's `/etc/resolv.conf` and its configured DNS server. It precisely tests whether the pod itself can successfully resolve the fully qualified domain name (FQDN) of the `kubernetes` service, providing immediate insight into its DNS capabilities.
Visual reference
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
CoreDNS
CoreDNS is a fast, flexible, and pluggable Domain Name System (DNS) server that is often used as the cluster DNS for Kubernetes, translating service names into IP addresses so containers can find each other.
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
This CKA question is part of Courseiva's 302-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.