TL;DR: Labels are key-value pairs on objects; a selector is a query over them. A Service holds a selector and continuously includes every pod that matches it and passes readiness. Nothing is registered or attached, so a label typo produces a Service with no endpoints and no error anywhere.
How to approach it
The point to land is that the relationship is a live query rather than a link. Once that is clear, the debugging answer follows immediately: if a Service is not working, ask it which pods it currently matches, and the answer is usually none. Show the command that does that.
A strong answer
A label is arbitrary metadata you attach to an object:
metadata:
labels:
app: checkout
tier: backend
A selector is a query. A Service says which labels it wants:
spec:
selector:
app: checkout
Kubernetes evaluates that continuously. Any pod in the same namespace carrying app: checkout is a candidate, and if it is passing its readiness probe it goes into the Service's endpoint list and starts receiving traffic. Delete the pod and it drops out. Add a new one with that label and it joins. Nothing announced itself.
This is the same mechanism everywhere. A Deployment's selector is how it finds the ReplicaSets and pods it owns. A NetworkPolicy uses selectors for both the pods it protects and the pods allowed to reach them. A ServiceMonitor uses one to find what to scrape.
Which makes the debugging move obvious. When a Service returns nothing, check what it actually matches:
kubectl get endpoints -n prod checkout
kubectl get pods -n prod -l app=checkout
endpoints empty and the labelled pod list empty means the selector and the pod labels disagree, which is nearly always app: checkout against app: checkout-service, or a label on the Deployment that never reached the pods. endpoints empty while pods exist means they are running but not ready, so the readiness probe is failing.
One detail that catches people out: labels on a Deployment are not automatically on its pods. The Deployment has its own metadata.labels, and separately a spec.template.metadata.labels for the pods it creates. The Service selects the pods, so it is the template labels that matter. Setting the first and not the second is a common and confusing mistake.
Another: a Deployment's spec.selector is immutable after creation. Change it and the apply is rejected, so you delete and recreate. That is deliberate, because changing it would orphan the existing ReplicaSet and its pods, which would keep running with nothing managing them.
Two conventions worth knowing. The app.kubernetes.io/name, app.kubernetes.io/instance and app.kubernetes.io/version labels are the standard set, and tooling expects them. And annotations are the other metadata field: same shape, but not queryable, meant for data tools read rather than data used for selection. Put a git commit in an annotation and an application name in a label.
What interviewers probe next
"How do you do a blue-green switch with labels?" Run both versions with a version label, and have the Service selector name one. Changing the selector moves all traffic at once. It is the simplest switch there is, with no gradual shift.
"What selector operators exist?" Equality, and set-based (in, notin, exists). Services only support equality; Deployments and NetworkPolicies support both through matchExpressions.
"Why does a pod keep receiving traffic after you delete it?" Removal from endpoints and removal from the node's routing rules happen concurrently, so there is a short window where traffic still arrives. That is why a preStop hook with a short sleep, plus graceful shutdown, is the standard pattern.
Common mistakes
Labelling the Deployment but not the pod template, then wondering why the Service matches nothing.
Debugging a Service without ever checking kubectl get endpoints, which answers the question directly.
Assuming an empty endpoint list means a networking problem, when a failing readiness probe produces the same symptom.
Putting high-cardinality values like a commit SHA in a label, which is what annotations are for.