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.

• ✗

  ping kubernetes.default.svc.cluster.local

  Why it's wrong here

  ping sends ICMP Echo Request packets to an IP address, and while it does trigger a DNS lookup for the hostname, that lookup is incidental. The command's exit status and output depend on ICMP reachability, which is frequently blocked by network policies, firewall rules, or containers that lack ping binaries. A successful ping might still occur via cached /etc/hosts entries, and an unsuccessful ping could stem from ICMP filtering rather than a DNS fault, making it a misleading DNS diagnostic tool.

• ✗

  kubectl exec -it pod-name -- /bin/sh

  Why it's wrong here

  kubectl exec -it pod-name -- /bin/sh merely opens an interactive shell inside an existing container; it performs no name resolution against the cluster's DNS service. It might be a first step before running dig, nslookup, or cat /etc/resolv.conf, but by itself it cannot confirm or refute DNS failures. Furthermore, the command assumes the pod is Running and has a shell, so the common failure modes (e.g., CrashLoopBackOff or lack of /bin/sh) are totally unrelated to DNS.

• ✓

  dig kubernetes.default.svc.cluster.local

  Why this is correct

  dig is a dedicated DNS lookup utility that sends explicit DNS queries to the configured resolver and prints the full DNS response, including the resolved A/AAAA record and the answer section. When invoked from inside a pod, it directly interrogates the cluster DNS service (usually CoreDNS) for kubernetes.default.svc.cluster.local, so a successful answer proves that DNS resolution works end-to-end. It also distinguishes error types such as NXDOMAIN versus SERVFAIL, which makes it highly effective for isolating DNS-specific misconfigurations.

• ✗

  curl http://kubernetes.default.svc.cluster.local

  Why it's wrong here

  curl uses HTTP (or other protocols) to fetch a resource from a given URL; while it resolves the hostname first, its outcome is dominated by whether the target service is actually listening and serving the requested path. If the service is down or returns a connection refused error, curl fails even when DNS is perfectly healthy, and if it succeeds, it only proves that both DNS and the application layer work. As a result, curl conflates DNS health with application availability, making it a poor standalone test for a suspected DNS issue.

• ✓

  nslookup kubernetes.default.svc.cluster.local

  Why this is correct

  nslookup is a simple, interactive DNS query tool that sends a direct query for the given name to the nameserver and reports the resolved IP address. Running nslookup for kubernetes.default.svc.cluster.local from within a pod isolates DNS behavior because it does not depend on any higher-level protocol or application endpoint — only on the cluster's DNS resolving the service name. Its concise output and widespread availability in images like nginx or busybox (though sometimes via the dnsutils package) make it a practical choice for quick DNS verification.

Go deeper

Related to this question