CKAD Services and Networking Practice Question
A ClusterIP Service named 'db' in namespace 'data' is not reachable from a pod in namespace 'app'. Which DNS name should the pod use to resolve the service?
⚠ Common exam trap
The trap here is that candidates often forget to include the service's namespace in the DNS name when accessing a service from a different namespace, mistakenly using the short form or the pod's own namespace.
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
✓
db.data.svc.cluster.local
A pod in namespace 'app' must use the fully qualified DNS name 'db.data.svc.cluster.local' to resolve a ClusterIP Service named 'db' in namespace 'data'. Kubernetes DNS appends the service's namespace before 'svc.cluster.local', so the format is <service>.<namespace>.svc.cluster.local. This allows cross-namespace service discovery.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
data.db.svc.cluster.local
Why it's wrong here
This string reverses the required order of the DNS name. Kubernetes constructs the FQDN for a Service as <service-name>.<namespace>.svc.<cluster-domain>, so putting the namespace (data) before the service name (db) tells the resolver to look for a Service named "data" inside a namespace called "db", which does not exist. Even though both tokens are present, their positions are swapped, so this name will not resolve to the db Service.
- ✗
db.app.svc.cluster.local
Why it's wrong here
This name uses the wrong Kubernetes namespace in the DNS path. The db Service is defined in the data namespace, not in app, so the correct namespace segment must be data. A DNS lookup for db.app.svc.cluster.local will either fail or, if an unrelated Service named db happens to exist in app, it will resolve to an entirely different object. Cross-namespace resolution only works when the namespace portion exactly matches the Service's namespace.
- ✗
db.svc.cluster.local
Why it's wrong here
This omits the namespace segment, producing an incomplete FQDN. The canonical DNS format for a Service is <service>.<namespace>.svc.cluster.local, and dropping data makes the name ambiguous and non-resolvable from other namespaces. While a short name like db can work within the same namespace using Kubernetes search domains, db.svc.cluster.local as a standalone FQDN is not a valid Service DNS name and will not route traffic to the db Service in the data namespace.
- ✓
db.data.svc.cluster.local
Why this is correct
This is the correct DNS name for the db Service. In Kubernetes, the fully qualified domain name for a ClusterIP Service follows the pattern <service-name>.<namespace>.svc.<cluster-domain>, so db (the Service name) comes first, followed by data (the namespace), then the svc and cluster.local suffixes. This FQDN resolves to the Service's ClusterIP and is the standard way to reach the db Service from any namespace within the cluster.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD 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 CKAD 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 CKAD exam.