KCNA Kubernetes Fundamentals Practice Question
A developer creates a Service of type ClusterIP in namespace 'default'. They attempt to reach the Service from another pod in the same namespace using the Service name 'my-svc'. The connection fails. What is the most likely cause?
⚠ Common exam trap
Many candidates assume the issue is with the Service configuration (selector or port) rather than the underlying DNS infrastructure, because they forget that name resolution is a prerequisite for Service discovery within the cluster.
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 cluster DNS service (CoreDNS) is not running or misconfigured
The most likely cause is that the cluster DNS service (CoreDNS) is not running or misconfigured. When a pod attempts to reach a Service by its DNS name (e.g., 'my-svc'), Kubernetes relies on CoreDNS to resolve that name to the ClusterIP. If CoreDNS is down, misconfigured, or the pod's DNS resolver is not pointing to it, the name resolution fails, causing the connection to fail even if the Service itself is correctly configured.
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 port does not match the container port
Why it's wrong here
If ports don't match, the connection would reach the service but fail at the container; however, the symptom would be connection refused, not DNS failure.
- ✓
The cluster DNS service (CoreDNS) is not running or misconfigured
Why this is correct
DNS is required for Service name resolution.
- ✗
The Service type should be NodePort
Why it's wrong here
NodePort is for external access; internal access works with ClusterIP.
- ✗
The Service selector does not match any pod labels
Why it's wrong here
If selectors don't match, the Service has no endpoints, but the connection might still reach an empty set.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 833 original KCNA 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 →
Same concept, more angles
1 more way this is tested on KCNA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. 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?
hard- A.The kubelet on the node where the pod is running
- B.The Service's endpoint slices
- C.kube-proxy on the nodes
- ✓ D.CoreDNS pods in the kube-system namespace
Why D: 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.
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.