CKA Debug CoreDNS pod methods Practice Question
Which of the following are valid methods to debug a failing CoreDNS pod? (Select TWO)
⚠ Common exam trap
Many candidates confuse debugging actions (like checking logs or endpoints) with recovery actions (like deleting or scaling pods), and they may also mistake client-side DNS tests (like `nslookup`) for pod-level debugging, which only confirms the symptom, not the cause.
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 logs -n kube-system -l k8s-app=kube-dns
`kubectl logs -n kube-system -l k8s-app=kube-dns` retrieves the logs from all CoreDNS pods (which are labeled `k8s-app=kube-dns` in the `kube-system` namespace). This is a direct method to inspect errors, crashes, or misconfigurations in the DNS service. Option C is correct because `kubectl get endpoints -n kube-system kube-dns` shows the IP addresses of the pods backing the `kube-dns` service; if the endpoint list is empty, it indicates that no CoreDNS pods are ready to serve DNS requests, which is a common failure point.
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 logs -n kube-system -l k8s-app=kube-dns
Why this is correct
This command retrieves the current logs from every CoreDNS pod by targeting the standard label selector `k8s-app=kube-dns` in the `kube-system` namespace. Since CoreDNS is normally deployed as a Deployment with multiple replicas, the `-l` flag aggregates output from all pods, allowing you to spot query processing errors, panics, or plugin misconfigurations (e.g., kubernetes plugin failures, upstream resolution timeouts) that would not be visible if you inspected only a single pod. Logs directly reveal whether DNS requests are reaching CoreDNS and how it handles them, making this the first-line diagnostic method.
- ✗
kubectl delete pod -n kube-system -l k8s-app=kube-dns
Why it's wrong here
Deleting the CoreDNS pods is a recovery/restart action, not a debugging technique, and it actively destroys the very diagnostic evidence you need — such as crash-loop stack traces, concatenated error logs, and pod-level events. If a pod is in a CrashLoopBackOff, deleting it may merely reschedule a new instance, and the same underlying misconfiguration (Corefile syntax error, missing ConfigMap, conflicting port bindings) will immediately reappear. This command can also cause temporary DNS outages for all cluster workloads, so you should only ever consider it as a last-resort remediation after inspecting `kubectl describe pod` and `kubectl logs`.
- ✓
kubectl get endpoints -n kube-system kube-dns
Why this is correct
Checking the `kube-dns` Endpoints object verifies that the Service's label selector correctly matches CoreDNS pods that have passed their readiness probes. An empty `ENDPOINTS` column means either the pod labels do not match the Service selector or the CoreDNS pods are not ready (failed readiness probe, container not starting), which is a common root cause of ClusterDNS failures. This command isolates the fault to the Service-to-pod wiring layer rather than the CoreDNS application logic, complementing log inspection by confirming whether traffic is even routed to healthy backends.
- ✗
kubectl scale deployment coredns --replicas=2
Why it's wrong here
Scaling the `coredns` Deployment changes the desired replica count, so it is a capacity or availability adjustment, not a diagnostic step. It provides no information about why CoreDNS is not responding — for example, it cannot reveal a ZoneNotAuthoritative plugin error, a bad forward directive, or a readiness probe failure. Running this command may actually mask a horizontal scaling misconfiguration or worsen resource contention, and the correct debugging practice is to use `kubectl get deployment coredns -n kube-system` and `kubectl describe` to inspect the deployment's status, events, and rollout conditions before considering any scaling action.
- ✗
kubectl run -it --rm test --image=busybox -- nslookup kubernetes.default
Why it's wrong here
This command launches an ephemeral busybox pod and runs `nslookup kubernetes.default`, which is a client-side end-to-end validation of DNS resolution from inside the cluster, not a method for debugging the CoreDNS pods themselves. A successful lookup only indicates that the DNS server answered; a failure could be caused by many layers unrelated to CoreDNS, including CNI network policies, kube-proxy iptables rules, service discovery search domains, or even the test pod's own `/etc/resolv.conf`. It is useful as a smoke test after applying a fix, but it gives no visibility into CoreDNS internals, so it is not an appropriate debugging command for diagnosing a broken CoreDNS pod.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.
✓kubectl logs -n kube-system -l k8s-app=kube-dnsCorrect answer▾
Why this is correct
This command retrieves the current logs from every CoreDNS pod by targeting the standard label selector `k8s-app=kube-dns` in the `kube-system` namespace. Since CoreDNS is normally deployed as a Deployment with multiple replicas, the `-l` flag aggregates output from all pods, allowing you to spot query processing errors, panics, or plugin misconfigurations (e.g., kubernetes plugin failures, upstream resolution timeouts) that would not be visible if you inspected only a single pod. Logs directly reveal whether DNS requests are reaching CoreDNS and how it handles them, making this the first-line diagnostic method.
✗kubectl delete pod -n kube-system -l k8s-app=kube-dnsWrong answer — click to see why▾
Why this is wrong here
Deleting a pod is a fix, not a debug method.
✗kubectl scale deployment coredns --replicas=2Wrong answer — click to see why▾
Why this is wrong here
Scaling is a fix, not debugging.
✗kubectl run -it --rm test --image=busybox -- nslookup kubernetes.defaultWrong answer — click to see why▾
Why this is wrong here
This tests DNS resolution, not debugging CoreDNS pod itself.
Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
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
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.
About these practice questions
Courseiva writes every CKA question from scratch — 726 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.