CKA Troubleshooting Practice Question
Which THREE of the following are valid steps to troubleshoot DNS issues in a Kubernetes cluster?
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 exec <pod> -- nslookup kubernetes.default'
To troubleshoot DNS, you can check the DNS pod logs, test resolution from a pod, and verify the DNS service endpoints.
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 exec <pod> -- nslookup kubernetes.default'
Why this is correct
Running `kubectl exec <pod> -- nslookup kubernetes.default` is a valid troubleshooting step because it tests DNS resolution from inside the pod's network namespace, exactly where application failures occur. If this command fails, it confirms the issue is with DNS resolution rather than with the application itself. It uses the pod's configured DNS settings (resolv.conf and search domains) to query the cluster's DNS service. Success indicates the cluster DNS is reachable and resolving service names, while failure isolates the problem to DNS configuration or CoreDNS.
- ✗
Check the /etc/resolv.conf on the host
Why it's wrong here
Checking /etc/resolv.conf on the host is not a relevant troubleshooting step because pods do not inherit the host's DNS configuration; kubelet generates each pod's resolv.conf based on the cluster DNS settings (the `--cluster-dns` flag) and the pod's `dnsPolicy`. Host-level resolv.conf may be used for node-level processes, but it has no bearing on pod DNS resolution. In most clusters, pods use CoreDNS as their DNS server, not the host's /etc/resolv.conf. Even if the host DNS is misconfigured, it would not directly affect cluster DNS queries from within pods.
- ✗
Restart all nodes in the cluster
Why it's wrong here
Restarting all nodes in the cluster is not a troubleshooting step; it is a drastic, disruptive action that can cause downtime and does not address the root cause of DNS failures. If CoreDNS is misconfigured or the kube-dns Service lacks endpoints, rebooting nodes will not fix the underlying service or configuration. Node restarts might temporarily mask an issue (e.g., by rescheduling pods) but they do not diagnose problems and can even worsen availability. Proper troubleshooting should focus on inspecting cluster components, logs, and resources, not rebooting infrastructure.
- ✓
Verify the kube-dns Service has endpoints
Why this is correct
Verifying the kube-dns Service has endpoints is a valid troubleshooting step because the Service selects the CoreDNS pods via labels; if no endpoints exist, the Service's ClusterIP has no backends, so any DNS query to it will get a connection refused or time out. `kubectl get endpoints -n kube-system` should show the IP addresses of the CoreDNS pods. If endpoints are missing, it usually means the CoreDNS pods are not running or the selector does not match the pods. Without endpoints, the DNS service cannot answer queries, even if the Service object exists.
- ✓
Check the logs of the CoreDNS pods
Why this is correct
Checking the logs of the CoreDNS pods is a valid troubleshooting step because CoreDNS writes logs that can reveal plugin errors, panics, or malformed queries. For example, `kubectl logs -n kube-system -l k8s-app=kube-dns` will show whether CoreDNS is receiving queries and if it is failing to resolve them. Errors like `SERVFAIL` or plugin failures often appear in these logs, pointing to misconfigurations in CoreDNS Corefile or connectivity issues. This provides direct evidence of the health of the DNS server itself, complementing endpoint and resolution checks.
Visual reference
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
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.
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
About these practice questions
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.