CKA Troubleshooting Practice Question
You are a CKA managing a production cluster with 5 worker nodes. A developer reports that a new deployment 'payment-service' is not accessible from other pods via its Service 'payment-svc' in the 'default' namespace. The Service is of type ClusterIP with selector 'app: payment'. The deployment has 3 replicas, all showing 'Running' status. From a test pod, you run 'curl http://payment-svc:8080' and get 'Connection refused'. You verify that the pods are listening on port 8080 and the container's readiness probe passes. 'kubectl get endpoints payment-svc' shows no endpoints. 'kubectl describe svc payment-svc' shows the selector 'app=payment'. What is the most likely cause?
⚠ Common exam trap
Many exam-takers assume a NetworkPolicy or readiness probe issue when they see 'Connection refused', but the empty endpoints list directly points to a selector mismatch, which is a fundamental Kubernetes networking concept tested in the CKA.
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 pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.
The most likely cause is that the pods' labels do not match the Service's selector. The Service 'payment-svc' uses selector 'app: payment', but the pods have label 'app: payment-service'. Since the selector does not match any pods, the Service's endpoints list is empty, causing 'Connection refused' when trying to reach the ClusterIP. The pods are running and listening on port 8080, but the Service has no backends to forward traffic to.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A NetworkPolicy is blocking traffic from the test pod to the service IP.
Why it's wrong here
NetworkPolicy operates as a firewall rule at the pod's network interface, controlling allowed ingress/egress traffic based on peer selectors and ports. It does not influence the Kubernetes Endpoints controller, which discovers endpoints by comparing the service's label selector against pod labels. Therefore, even if a NetworkPolicy is blocking connectivity to the service IP, kubectl get endpoints would still list the matching pod IPs; an empty endpoints address list indicates a selector mismatch, not a network policy issue.
- ✗
The service type should be NodePort to allow in-cluster access.
Why it's wrong here
ClusterIP is a stable virtual IP reachable by any workload inside the cluster, including a test pod; NodePort is an external access layer that exposes the same ClusterIP on a static port on every node. Changing the service type to NodePort would not alter endpoint population because NodePort still uses the same selector logic. In-cluster access is already supported by ClusterIP, so empty endpoints are caused by a selector/label mismatch, not by the service type.
- ✗
The readiness probe is failing on all pods, causing them to be removed from service endpoints.
Why it's wrong here
Readiness probes control which pods are placed in the ready subset of an Endpoints object, but pods that fail the probe are still listed in the endpoints output under the "not ready" section when using kubectl get endpoints. An empty endpoints list means no pod IPs have been matched at all, which is a selector/label mismatch, not a probe failure. If no readiness probe is defined, a pod is considered ready by default, so this cannot explain a completely empty endpoints object.
- ✓
The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.
Why this is correct
A Service's spec.selector uses exact key-value matching to choose backing pods. If the selector is app: payment and the pods are labeled app: payment-service, the values are different, so the Endpoints controller does not add any pod IP to the Service's backend. Label matching is exact, not substring-based, so the Service will have no endpoints and in-cluster clients cannot connect to it.
Go deeper
Related to this question
Learn chapter
Configuring Core Cluster Components
Key term
ClusterIP NodePort LoadBalancer
ClusterIP, NodePort, and LoadBalancer are three types of Kubernetes Services that control how traffic reaches your application pods inside the cluster or from outside.
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
About these practice questions
Courseiva writes every CKA question from scratch — 302 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 CKA 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 CKA exam.