CKA Services and Networking Practice Question
A pod cannot resolve a service DNS name. The cluster uses CoreDNS. Which of the following is the most likely cause if the pod's /etc/resolv.conf contains 'nameserver 10.96.0.10' and the CoreDNS pod is running?
⚠ Common exam trap
Watch out — candidates often assume a running CoreDNS pod and correct `nameserver` IP guarantee DNS resolution, overlooking that CoreDNS must be configured with the correct cluster domain to handle service DNS names.
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
✓
The CoreDNS ConfigMap does not have the correct cluster domain.
If the CoreDNS ConfigMap does not specify the correct cluster domain (e.g., `cluster.local`), CoreDNS will not respond to queries for service DNS names within that domain. The pod's `resolv.conf` shows the correct ClusterIP of the CoreDNS service (10.96.0.10), and the CoreDNS pod is running, so the issue is likely a misconfiguration in the CoreDNS plugin settings, specifically the `kubernetes` plugin's `clusterDomain` parameter.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The CoreDNS ConfigMap does not have the correct cluster domain.
Why this is correct
CoreDNS's kubernetes plugin reads a ConfigMap (typically named 'coredns' in the kube-system namespace) to determine the cluster domain, usually 'cluster.local.' If the 'kubernetes' block in that ConfigMap specifies a mismatched or missing domain, CoreDNS will not append the correct search domain, so fully qualified service names like 'my-svc.my-ns.svc.cluster.local' will fail to resolve. Since the pod is running, a static misconfiguration in the ConfigMap is a primary suspect and directly explains the symptom.
- ✗
The pod's DNS policy is set to 'Default'.
Why it's wrong here
When a pod's dnsPolicy is set to 'Default', it inherits the resolv.conf from the node where it runs. That file typically points to the node's upstream DNS servers (e.g., systemd-resolved or a corporate resolver), not to the cluster's CoreDNS Service IP. As a result, cluster-local names such as 'my-svc.my-ns.svc.cluster.local' are sent to external resolvers that have no knowledge of the cluster domain, so they return NXDOMAIN. This is distinct from a CoreDNS misconfiguration because CoreDNS is never consulted at all.
- ✗
The CoreDNS pod is in CrashLoopBackOff.
Why it's wrong here
If the CoreDNS pod were in CrashLoopBackOff, CoreDNS would not be running to serve DNS queries at all, causing everything to fail—including even the cluster domain itself. However, the question explicitly states that the cluster uses CoreDNS and implies it is running; a CrashLoopBackOff would also be accompanied by crash-related events and restarts, which are not indicated. Therefore, this is not the likely cause given the provided information.
- ✗
The service's DNS name is misspelled.
Why it's wrong here
A misspelled service DNS name would produce a 'server can't find' error, but it would affect only queries using that exact incorrect string, while other correctly spelled service names would still resolve. The question suggests a broader inability to resolve, which points to a systemic configuration issue rather than a typo. Additionally, if the cluster domain is correct, a correctly spelled name should resolve unless another problem exists, making this a less probable explanation.
Visual reference
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
ClusterIP NodePort LoadBalancer
ClusterIP, NodePort, and LoadBalancer are three types of Kubernetes Services that control how traffic reaches your application pods inside the cluster or from outside.
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.
About these practice questions
Courseiva writes every CKA question from scratch — 302 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.