CKAD Services and Networking Practice Question
A Service uses a selector to target Pods. After updating the Pod labels, you notice the endpoints list is empty. What is the most likely reason?
⚠ Common exam trap
Many exam-takers assume updating Pod labels will automatically update the Service's endpoint list, but they forget that the Service selector must explicitly match the new labels for endpoints to be populated.
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 new labels do not match the Service selector
A Service uses a label selector to dynamically discover Pods and populate its endpoints. When Pod labels are updated, the selector remains unchanged; if the new labels do not match the selector, the Service cannot find any matching Pods, resulting in an empty endpoints list. This is the most direct and common cause of the issue.
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 Service port was changed
Why it's wrong here
Changing the Service port affects the port number that clients use to reach the Service, but it does not influence pod discovery. The endpoints controller selects pods solely based on the Service's selector and the pods' labels, ignoring the Service port field. As long as the selector matches the pods' labels, endpoints are generated even if the port number changes. Therefore, a port change cannot explain the absence of endpoints; the real culprit is a selector mismatch.
- ✓
The new labels do not match the Service selector
Why this is correct
The Service's selector is a label query that must exactly match the labels present on the pod's metadata, and the endpoints controller is continuously reconciling based on that query. Once the pods' labels are updated and no longer satisfy all key-value pairs in the selector, the controller removes the pod IPs from the Endpoints object, leaving the Service with zero ready endpoints. This is the classic cause of connection failures after a deployment label change, even when all pods are Running and Ready.
- ✗
The Service type changed to ExternalName
Why it's wrong here
ExternalName is a special Service type that maps the Kubernetes Service to a DNS name using the externalName field, and it intentionally does not contain a selector. If the Service were switched to ExternalName, the endpoints controller would not create endpoints at all because the spec.selector is absent. However, the scenario specifically mentions updating the pods' labels, not modifying the Service type, so the fundamental cause remains a selector mismatch in a normal ClusterIP/NodePort Service.
- ✗
The Pods have a different container port
Why it's wrong here
A pod's containerPort is an informational field used to identify the targetPort for Service traffic, but it has no bearing on whether the pod matches the Service selector. The endpoints controller only cares about the pod's labels and readiness; it will add the pod IP (and the correct port mapping) to the Endpoints resource as long as the labels align with the Service's selector. Even if the container port were changed and the Service's targetPort updated accordingly, endpoints would still be populated if the selector matched.
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.