CKAD Services and Networking Practice Question
You are a platform engineer managing a Kubernetes cluster version 1.28. A development team has deployed a microservice application called 'order-processor' in the 'prod' namespace. The application consists of a frontend Pod 'frontend' and a backend Pod 'backend', each with a single container. The frontend needs to communicate with the backend using a headless Service named 'backend-svc' that selects Pods with label 'app:backend'. The backend Pods are expected to scale horizontally, and the frontend uses a DNS lookup to discover all backend Pod IPs for client-side load balancing. However, after deploying, the frontend is unable to resolve 'backend-svc' to any IP addresses. The backend Pod is running and has the correct label 'app:backend'. The Service 'backend-svc' is defined as a ClusterIP with clusterIP: None. The frontend container has the 'default' DNS policy. What is the most likely cause of the failure?
⚠ Common exam trap
Many candidates assume a headless Service always returns all matching Pod IPs regardless of readiness, but Kubernetes only publishes ready Pods to DNS unless explicitly configured otherwise.
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 headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.
A headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. If the backend Pod is running but not ready (e.g., due to a failing readiness probe or other conditions), the Service excludes it from DNS. Setting publishNotReadyAddresses: true on the Service would include all matching Pods regardless of readiness, allowing the frontend to discover the backend IPs. Since the frontend cannot resolve any IPs, the most likely cause is that the Service is not configured to serve not-ready Pods.
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 headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.
Why this is correct
In a headless Service (`clusterIP: None`), DNS records are generated per ready Pod rather than for a single virtual IP. By default, Kubernetes excludes Pods whose readiness condition is false from DNS A/AAAA record lists, which means a not-ready backend Pod will not appear as a DNS entry and the frontend cannot reach it by name. Adding `publishNotReadyAddresses: true` to the Service spec instructs the cluster DNS to publish the addresses of all backing Pods regardless of readiness, enabling the frontend to discover even not-ready backends. This is the only correct option because it identifies the missing configuration attribute that directly affects DNS population.
- ✗
The Service and frontend are in different namespaces; the DNS name must be fully qualified.
Why it's wrong here
The premise is factually incorrect: the frontend Pod and the backend Service are both defined in the 'prod' namespace. Within the same namespace, a Service can be addressed by just its simple DNS name (e.g., 'backend'), and Kubernetes' kubelet-generated /etc/resolv.conf automatically searches the pod's own namespace. A fully qualified domain name (e.g., 'backend.prod.svc.cluster.local') is only required when consuming the Service from a different Kubernetes namespace. Since both objects share the namespace, the short name is sufficient and this is not the cause of the resolution failure.
- ✗
The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.
Why it's wrong here
The absence of a readiness probe does not cause a Pod to be considered not ready. Kubernetes only marks a Pod as not ready when a readiness probe explicitly fails; if no readiness probe is defined, the Pod is assumed ready as soon as its containers have started and are running. Thus, the backend Pod would be regarded as ready, and its IP address would normally be included in the headless Service's DNS records (unless `publishNotReadyAddresses` intervenes). The real issue is not the lack of a readiness probe, but rather the headless Service's default behavior of omitting not-ready Pods from DNS.
- ✗
The frontend Pod's DNS policy is set to 'None' which disables DNS resolution.
Why it's wrong here
The frontend Pod's DNS policy is not 'None'; it is explicitly set to 'Default'. The `dnsPolicy` field in a Pod spec governs the contents of `/etc/resolv.conf` inside the container: a policy of 'None' would cause the pod to ignore the cluster DNS server and use only the `dnsConfig` entries you provide, effectively disabling cluster service discovery. With 'Default', the pod inherits the resolv.conf from the node on which it runs, which normally includes the cluster DNS server (e.g., kube-dns/CoreDNS). Therefore, DNS resolution is enabled and this cannot explain why the backend hostname is not resolving.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 160 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 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.