A permits desk app must talk to a legacy database that runs outside the cluster at a fixed IP. Which Service approach maps a stable in-cluster DNS name to that external backend?
Select an answer to reveal the explanation.
Short Explanation
When the backend is not a Pod, you hand-wire the address book. A Service with no selector plus a manual Endpoints (or EndpointSlice) entry points cluster DNS at that external DB IP. Selectors alone cannot invent Pods that do not exist.
Full Explanation
A permits desk app that must talk to a legacy database running outside the cluster at a fixed IP should use a selector-less Service paired with a matching Endpoints (or EndpointSlice) object that lists the external database IP and port. The Service provides a stable in-cluster DNS name; the manual Endpoints object supplies the external backend. That pattern maps municipal workloads to fixed external systems without pretending the database is a Pod selected by labels.
Creating a ClusterIP Service with a selector matching nonexistent Pod labels and hoping DNS invents the IP leaves Endpoints empty and never reaches the external database. Using only a NodePort Service without Endpoints does not make kube-proxy invent a correct route to an arbitrary fixed IP. Exposing the database with an Ingress path and skipping Service and Endpoints objects is the wrong abstraction for typical database protocols and still requires correct backends.
Exam caveat: omit the Service selector when you manage Endpoints manually so the endpoints controller does not overwrite your external IP entries. Operational check: create the selector-less Service, create Endpoints with the DB IP and port, resolve the Service DNS from an app Pod, and test database connectivity. Document the external IP, port, TLS requirements, and firewall allows in the city’s CMDB so the permits desk dependency remains supportable during incidents and audits.