KCNA Container Orchestration Practice Question
A pod named 'web-app' is not able to resolve the hostname 'db-service' from another namespace 'data'. The 'db-service' Service exists in the 'data' namespace. What is the most likely cause?
⚠ Common exam trap
Watch out — candidates often assume Kubernetes DNS automatically resolves service names across all namespaces, similar to how a flat network would work, but in reality, DNS resolution is namespace-scoped unless the FQDN is used.
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 trying to resolve 'db-service' without the namespace suffix
By default, Kubernetes DNS resolves service names only within the same namespace. To resolve a service from another namespace, the pod must use the fully qualified domain name (FQDN) in the format '<service>.<namespace>.svc.cluster.local'. Without the namespace suffix, the DNS query for 'db-service' fails because it is not found in the pod's own namespace.
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 is trying to resolve 'db-service' without the namespace suffix
Why this is correct
DNS resolution in Kubernetes is namespace-scoped: a bare name like `db-service` resolves only within the pod's own namespace. Cross-namespace lookups require the fully qualified form `db-service.data.svc.cluster.local`, so the missing namespace suffix is the constraint the stem describes.
- ✗
The Service 'db-service' is not exposed on a port
Why it's wrong here
Cross-namespace DNS resolution uses the fully qualified name db-service.data.svc.cluster.local; a missing container port would not prevent the name resolving, only connecting. Port exposure matters when clients reach a Service, not when CoreDNS answers queries, so it cannot explain an NXDOMAIN-style failure.
- ✗
The pod's DNS policy is set to 'None'
Why it's wrong here
Setting dnsPolicy to 'None' removes cluster DNS configuration entirely, so the pod cannot resolve any service, including those in its own namespace. It is tempting because it does break name resolution, but it would be the cause only if the pod also failed to resolve same-namespace services.
- ✗
The pod's container image lacks DNS utilities
Why it's wrong here
Missing DNS utilities inside the container image only prevent manual troubleshooting commands such as nslookup; Kubernetes DNS resolution for the pod is unaffected. It is tempting because absent tooling genuinely blocks interactive diagnosis, which would be the cause when a shell cannot query DNS at all.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 930 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 →
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.