CKAD Services and Networking Practice Question
A company runs a web application in a Kubernetes cluster. The application consists of a frontend service and a backend service. The frontend needs to communicate with the backend using a DNS name that does not change even if the backend pods are recreated. Which Kubernetes resource should the frontend use to reach the backend?
⚠ Common exam trap
Many candidates confuse a headless Service with a regular ClusterIP Service, thinking that because headless Services also provide DNS, they are suitable for stable communication, but they fail to realize that headless Services return a dynamic list of pod IPs rather than a fixed virtual IP, which violates the requirement for an unchanging DNS name.
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
✓
A regular ClusterIP Service
A regular ClusterIP Service provides a stable virtual IP and DNS name (e.g., <service-name>.<namespace>.svc.cluster.local) that remains constant regardless of pod churn. The frontend can use this DNS name to reach the backend, and the service load-balances traffic to the current set of backend pods via its label selector. This meets the requirement of a fixed DNS name that survives pod recreation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
An EndpointSlice
Why it's wrong here
An EndpointSlice is a low-level API object that tracks the IP addresses and ports of the pods backing a Service, but it is not designed for application-level discovery. Instead, kube-proxy and other internal controllers consume EndpointSlices to program load-balancing rules. Applications should rely on a Service's stable DNS name and virtual IP, not directly query EndpointSlices, which are an implementation detail of the control plane.
- ✓
A regular ClusterIP Service
Why this is correct
A regular ClusterIP Service is the correct choice for internal service discovery because it exposes a stable virtual IP and a DNS name that load-balances across the pods in its selector. This provides a reliable, single endpoint for other applications to reach the web app, regardless of pod churn or scaling. It is the standard Kubernetes abstraction for east-west traffic between workloads.
- ✗
An Ingress resource
Why it's wrong here
An Ingress resource is a layer-7 routing object that controls external HTTP/HTTPS traffic from outside the cluster to Services, typically through an Ingress controller. It does not provide internal service discovery or a stable cluster IP for pod-to-pod communication. Using Ingress for internal traffic would unnecessarily expose the application externally and is not its intended purpose.
- ✗
A headless Service
Why it's wrong here
A headless Service intentionally has no cluster IP; instead, it returns the DNS records of the individual backing pods, enabling direct pod-to-pod resolution. This is useful for stateful workloads that need a stable pod identity, but it does not provide a load-balanced virtual IP. For the web app, which likely needs simple, stable service discovery, a ClusterIP Service is more appropriate.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 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.