KCNA Kubernetes Fundamentals Practice Question
A pod in the 'default' namespace cannot reach a pod in the 'backend' namespace by service name 'db-service'. Both namespaces exist and the service is running. What is the most likely cause?
⚠ Common exam trap
Candidates often assume service names are globally unique across namespaces, but Kubernetes DNS scopes them to the namespace, so cross-namespace access requires the fully qualified domain name (FQDN).
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 pod is using the wrong service name format for cross-namespace access
D is correct because in Kubernetes, a pod in one namespace cannot reach a service in another namespace using just the service name (e.g., 'db-service'). Cross-namespace service discovery requires the fully qualified DNS name in the format <service>.<namespace>.svc.cluster.local (e.g., 'db-service.backend.svc.cluster.local'). Using only the service name resolves within the same namespace, causing the connection to fail.
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 pod does not have network policy allowing cross-namespace traffic
Why it's wrong here
Network policies govern pod-to-pod traffic, not DNS resolution of service names. The failure is name resolution: the pod's resolv.conf search domains only cover its own namespace, so 'db-service' must be qualified as 'db-service.backend'. Network policies would be the answer if connectivity worked but traffic were blocked.
- ✗
The service is not exposed on a port
Why it's wrong here
A Service without exposed ports would still resolve by DNS; the ClusterIP and name exist regardless of port configuration, so resolution would succeed and only the connection would fail. Port exposure matters when diagnosing connection refused errors, not name lookup failures across namespaces.
- ✗
The kube-proxy is not running
Why it's wrong here
kube-proxy implements Service VIP routing, so its absence breaks connectivity to ClusterIPs cluster-wide, not just cross-namespace lookups. DNS resolution of 'db-service' would still fail here because the search domain omits the 'backend' namespace; kube-proxy would be the answer if all Service traffic failed.
- ✓
The pod is using the wrong service name format for cross-namespace access
Why this is correct
Cross-namespace DNS resolution requires the fully qualified domain name `db-service.backend.svc.cluster.local`; a bare service name resolves only within the pod's own namespace. Since the stem confirms both namespaces and the service exist, the wrong name format is the most likely cause of the failed lookup.
Visual reference
Go deeper
Related to this question
Learn chapter
Cluster Architecture and Lifecycle Management
Key term
Namespaces
A Namespace in Kubernetes is a virtual cluster within a physical cluster that allows you to organize and isolate resources, like an apartment building with separate units for different tenants.
Key term
ReplicaSet and Replication
A ReplicaSet ensures a specified number of identical pod instances are running at all times in Kubernetes, using replication to maintain availability and stability.
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.