KCNA Kubernetes Fundamentals Practice Question
A Service of type ClusterIP is not resolving DNS names for pods. The pods are running and can communicate with each other via IP addresses. Which component should be checked first?
⚠ Common exam trap
A common misconception is that DNS failures are caused by kube-proxy or network proxy issues, when in fact DNS resolution is a separate layer handled by CoreDNS, and candidates should first verify the DNS pods themselves.
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
✓
CoreDNS pods in the kube-system namespace
DNS name resolution for Services in Kubernetes is handled by CoreDNS, which runs as pods in the kube-system namespace. When a ClusterIP Service fails to resolve DNS names but pods can communicate via IP addresses, the issue is almost certainly with the DNS resolver itself, not with network connectivity or Service endpoints. CoreDNS must be checked first to ensure it is running, has correct configuration, and can query the Kubernetes API for Service records.
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 kubelet on the node where the pod is running
Why it's wrong here
The kubelet starts containers and reports pod status on its node; it has no role in cluster DNS resolution. Pods running and reachable by IP already prove the kubelet is healthy. Checking it would be right if pods failed to start or crashed, not when names fail to resolve.
- ✗
The Service's endpoint slices
Why it's wrong here
Endpoint slices track which pods back a Service; they affect whether traffic reaches pods, not whether names resolve. Pods already communicating by IP shows connectivity is intact, so DNS is the failing layer. Endpoint slices would be the correct check if a Service resolved but forwarded traffic to no pods.
- ✗
kube-proxy on the nodes
Why it's wrong here
kube-proxy programs Service virtual IPs and load-balancing rules, not cluster DNS records; pods resolving each other by IP confirms networking works, so the failure sits in CoreDNS. Checking kube-proxy is tempting because it handles Service traffic, and it would be right if ClusterIP connections failed rather than name resolution.
- ✓
CoreDNS pods in the kube-system namespace
Why this is correct
CoreDNS provides cluster DNS resolution for Services, so its pods in kube-system are the first thing to verify. Since pod-to-pod IP communication already works, the CNI and kube-proxy are functioning; the failure is isolated to name resolution, which CoreDNS handles directly.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 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 KCNA 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 KCNA exam.