A Service routes to matching eligible endpoints. Labels and selectors form the relationship between the stable service and changing Pods.
Before you start
You should understand Pods, Deployments and Services. Read desired configuration separately from observed cluster state. Use a development cluster when trying changes, and inspect events and status rather than assuming that an accepted manifest means the workload is ready to serve traffic.
The practical goal is to reason through this situation: A label typo can leave a Service with no usable endpoints. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Compare labels and selectors
The Service only selects Pods matching its declared relationship.
Step 2: Inspect eligible endpoints
Ready selected Pods must appear in the relevant endpoint information.
Step 3: Verify ports and listeners
Correct selection still cannot repair a wrong target port.
Worked scenario
A label typo can leave a Service with no usable endpoints.
An application Pod is healthy with label app=accounts, while the Service selects app=account. The Service has no intended endpoints. Fixing the label relationship restores discovery only if its targetPort also matches the application’s listening port and the network permits traffic.
Common mistake
A healthy Pod does not prove the Service selects it.
Verify the behavior
Inspect selectors, EndpointSlices, readiness and target-port behavior sequentially.
Interview exercise
Troubleshoot a unreachable service.
Answer and reasoning
Compare selectors and Pod labels, inspect endpoint readiness and verify target ports and application listening behavior.
Continue learning
Compare the scenario with the Kubernetes interview questions and test your understanding with the Kubernetes MCQs. For terminology and implementation details, consult the reference material.