CKA Troubleshooting Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Verify that the kube-dns service has endpoints using 'kubectl get endpoints -n kube-system kube-dns'

  Why this is correct

  This command is a first-line check to confirm the Service named kube-dns actually has backend Pods behind it. In Kubernetes, a Service is only able to route traffic to Pods that match its selector; if the endpoints list is empty, no Pod is available to receive DNS queries, meaning the Service is not routing to any CoreDNS Pod. You would then inspect the CoreDNS Deployment or DaemonSet to determine whether the Pods are unscheduled, crashing, or carry the wrong labels.

• ✓

  Check the logs of the CoreDNS pods using 'kubectl logs -n kube-system -l k8s-app=kube-dns'

  Why this is correct

  CoreDNS is the actual authoritative DNS server in the cluster, and its logs contain plugin errors, upstream resolution failures, and fatal configuration issues. Running this command with the label selector k8s-app=kube-dns captures all CoreDNS Pods in the kube-system namespace, allowing you to see if CoreDNS is failing to start, hitting a bad Corefile, or unable to reach external resolvers. Unlike the Service-level view, these logs provide the internal reason why DNS endpoints might be absent or why queries are being refused.

• ✗

  Check the /etc/resolv.conf on the node

  Why it's wrong here

  The node's /etc/resolv.conf is used by node-level processes and is only indirectly referenced by the kubelet when generating a pod's DNS settings; pods do not read that file directly. A failure in pod DNS resolution is almost never caused by a misconfiguration in the node's own resolver, because the kubelet constructs each pod's resolv.conf from a base plus the cluster's DNS Service IP and search domains. Checking this file can be misleading and rarely pinpoints the root cause of in-cluster DNS problems, such as CoreDNS being down or a Service selector mismatch.

• ✗

  Restart all nodes to reset DNS settings

  Why it's wrong here

  Rebooting all nodes is a blunt, disruptive actions that does not reset any DNS configuration because DNS settings live in cluster objects like the CoreDNS ConfigMap, the kube-dns Service definition, and kubelet parameters, not in volatile memory or files that a restart would reset. It may temporarily hide a symptom by restarting CoreDNS Pods, but it does not fix the underlying misconfiguration, a failing CoreDNS plugin, or a network policy that blocks port 53. This approach is neither targeted nor standard for troubleshooting; it risks cluster downtime and could make the issue worse by re-scheduling pods unpredictably.

• ✓

  Run 'kubectl exec -it busybox -- nslookup kubernetes.default'

  Why this is correct

  Executing nslookup from inside a Pod with busybox is a definitive end-to-end test of DNS resolution as it exercises the exact same path that all workloads use: the Pod's resolv.conf points to the kube-dns ClusterIP, the request is routed by iptables or IPVS to a CoreDNS Pod, and CoreDNS resolves the synthetic service name kubernetes.default. A successful result proves that connectivity from the Pod network to the DNS Service works and that CoreDNS is functioning, while a timeout points to a network problem, a missing endpoint, or a CoreDNS crash. This command goes beyond the Service-level and logs checks by validating the behavior as seen by an application container.

Go deeper

Related to this question