KCNA Kubernetes Fundamentals Practice Question
A service of type ClusterIP is created but pods cannot reach it using the service name. The pods are in the same namespace. What is a likely cause?
⚠ Common exam trap
The exam tests the distinction between DNS resolution failures and connectivity failures, trapping candidates who confuse a selector mismatch or port mismatch with a DNS issue, even though those would still allow the service name to resolve.
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 is not running or misconfigured
When a ClusterIP service cannot be reached by its DNS name from pods in the same namespace, the most common cause is that CoreDNS (the cluster DNS resolver) is not running or is misconfigured. Kubernetes relies on CoreDNS to resolve service names to ClusterIP addresses; if CoreDNS is down or its configuration is incorrect, DNS queries for the service name will fail, even though the service itself and its endpoints are healthy.
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 is not exposed externally
Why it's wrong here
ClusterIP services are internal-only by design, so external exposure is irrelevant to pod-to-service connectivity within the cluster. It is tempting because unreachable services often stem from exposure problems, but pods in the same namespace reach ClusterIPs directly; the fault lies with DNS resolution, not exposure.
- ✓
CoreDNS is not running or misconfigured
Why this is correct
CoreDNS resolves cluster-internal service names, so if it is not running or is misconfigured, pods cannot translate the ClusterIP service name into its virtual IP. Since the pods share the namespace, the fault lies in DNS resolution rather than NetworkPolicy or selector mismatch.
- ✗
The service port does not match the container port
Why it's wrong here
A mismatched service targetPort would cause connection refusals or timeouts after DNS resolution succeeds, not failure to reach the service by name. It is tempting because port mismatches are a frequent misconfiguration, but the stem describes name resolution failing, implicating CoreDNS or the service's DNS registration instead.
- ✗
The selector does not match any pod labels
Why it's wrong here
A selector matching no pod labels leaves the Endpoints object empty, so DNS resolves the service name but no backend exists to route traffic to. It is tempting because label mismatches are a common misconfiguration, yet the stem describes name resolution failing, which points to DNS or CoreDNS rather than endpoint selection.
Visual reference
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.