CKA Services and Networking Practice Question
Which THREE components are required for a pod to resolve a Service DNS name?
⚠ Common exam trap
A common trap is confusing kube-proxy's role in Service traffic routing with DNS name resolution. kube-proxy handles load balancing of traffic to Service pods, but it does not resolve DNS names. DNS resolution relies solely on CoreDNS and the pod's resolv.conf configuration.
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 Service exists in the cluster
A Pod resolves a Service DNS name by querying the cluster's DNS service, which only returns an A/AAAA record if the Service object exists. Without the Service, the DNS name has no corresponding cluster IP to resolve, so the query fails with NXDOMAIN.
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 Service exists in the cluster
Why this is correct
The Service must exist in the cluster because the cluster DNS system only creates DNS A/AAAA records for Service objects, not for individual pods or arbitrary endpoints. When a Service is created, the DNS controller registers a name in the form <service>.<namespace>.svc.<cluster-domain>, and without that object there is no record for the resolver to return. This is a prerequisite independent of the DNS server itself or the pod's resolver configuration: even a healthy CoreDNS and correctly set resolv.conf cannot resolve a Service name that was never defined.
- ✓
CoreDNS is running and has a Service entry for the cluster domain
Why this is correct
CoreDNS must be running and must have a Service entry of its own for the cluster domain because it is the in-cluster DNS server that actually answers queries for Service names. Kubernetes publishes the cluster's DNS service under the name kube-dns in the kube-system namespace, and the kubelet uses that service's ClusterIP as the nameserver in /etc/resolv.conf. CoreDNS also needs a configured zone for the cluster domain (typically cluster.local) so that it can serve NDS records for Services; without this, even a Service existing in the cluster would have nowhere to be resolved.
- ✓
kubelet configures the pod's /etc/resolv.conf
Why this is correct
The kubelet configures the pod's /etc/resolv.conf based on the cluster DNS configuration and the pod's dnsPolicy, placing the CoreDNS Service ClusterIP as the nameserver and setting search domains like <namespace>.svc.cluster.local. This is the final piece that tells the pod's resolver where to send DNS queries; if the kubelet writes an incorrect or missing nameserver, the pod cannot reach CoreDNS even though the Service and CoreDNS are healthy. This step is what connects a pod's runtime resolver to the cluster's DNS infrastructure.
- ✗
kube-proxy is running in iptables mode
Why it's wrong here
kube-proxy running in iptables mode is not required for DNS resolution because kube-proxy only implements Service traffic load-balancing and kube-proxy's iptables rules do not affect how a pod resolves DNS names. DNS queries are normal UDP/TCP packets sent to the CoreDNS ClusterIP, and any kube-proxy mode (iptables, IPVS, or userspace) or even no kube-proxy at all would still permit DNS if the network path allows the packet to reach CoreDNS. In fact, CoreDNS itself is typically exposed as a ClusterIP Service, and kube-proxy's job is to forward the connection to a CoreDNS pod, but the resolution of the Service name depends on DNS records, not on the proxy's load-balancing mechanism.
- ✗
A CNI plugin is installed
Why it's wrong here
A CNI plugin is installed is not sufficient or necessary for DNS resolution because the CNI plugin only provides pod networking, IP addressing, and connectivity between pods and Services; it does not generate or serve DNS records. While a working CNI plugin is obviously needed for the pod to send packets at all, it does not contribute to name resolution—CoreDNS and the Service records are what turn a Service name into an IP. Many clusters have multiple CNI plugins (Calico, Flannel, Cilium) and DNS works identically because DNS is an application-layer service layered on top of the network, not a feature of the CNI implementation.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 302 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.