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.

• ✗

  kubectl describe svc <service-name>

  Why it's wrong here

  kubectl describe svc displays the Service's spec, selector, and endpoint IPs from the control plane's perspective, but it never enters the pod's network namespace. It cannot prove whether CoreDNS/kube-dns will return a record for that name to a pod, because resolution depends on the pod's /etc/resolv.conf and search domains. This command is for inspecting the Service object, not for exercising cluster DNS.

• ✗

  kubectl logs <pod>

  Why it's wrong here

  kubectl logs streams the stdout/stderr of the pod's containers, showing application-generated messages and errors; it is a passive observation tool. Unless the application itself attempted a DNS lookup and logged the outcome, these logs contain no DNS resolution data. Running this command does not generate any query to the cluster's DNS service, so it cannot tell you whether a service name resolves.

• ✗

  kubectl attach <pod>

  Why it's wrong here

  kubectl attach attaches your terminal to the main process (PID 1) of a running container via its stdin/stdout/stderr, not to a shell that can execute new commands. It does not invoke any binary inside the container and cannot perform a DNS lookup unless the main process happens to be an interactive shell—which is rarely the case. For running a one-off diagnostic command like nslookup, kubectl exec is the correct API because it creates a new process in the container.

• ✓

  kubectl exec <pod> -- nslookup <service-name>

  Why this is correct

  kubectl exec <pod> -- nslookup <service-name> is correct because it starts the nslookup process directly inside the pod's container, using the same /etc/resolv.conf, search domains, and network stack that the application uses. This actually queries the cluster's DNS service and returns the ClusterIP (or pod IPs for headless services) associated with that Service in the same namespace. If the Service is in a different namespace, you can test the fully qualified name <service-name>.<namespace>.svc.cluster.local. It is the standard, non-invasive way to validate service discovery from a pod's perspective.

Go deeper

Related to this question