Parks staff created an ExternalName Service pointing at an in-cluster app hostname instead of using a normal selector-based Service. What is wrong with that choice?
Select an answer to reveal the explanation.
Short Explanation
ExternalName is a DNS nickname for something outside—or at least a CNAME target—not a Pod picker. For in-cluster apps, use a selector-based Service, not a CNAME costume.
Full Explanation
ExternalName Services return a CNAME to an external DNS name and do not select in-cluster Pod endpoints the way ClusterIP Services with selectors do. Parks staff pointing ExternalName at an in-cluster app hostname are using the wrong tool for ordinary in-cluster app exposure—use a selector-based Service, not a CNAME costume. ExternalName is not limited to PersistentVolume names as targets; it targets DNS names, but that still does not make it a Pod selector. ExternalName Services can exist in the default namespace; namespace location is not the defect here. ExternalName does not automatically upgrade to LoadBalancer after five minutes. Exam caveat: ExternalName is for aliasing external services into cluster DNS. For in-cluster apps, ClusterIP/NodePort/LoadBalancer with selectors (or explicit Endpoints) is correct. Operational check: Replace the ExternalName Service with a selector-based ClusterIP Service matching the parks Pods, verify Endpoints, and retest in-cluster clients. In municipal production practice, record the finding in the incident ticket with command output snippets, confirm the fix under change control, and re-validate the user-facing civic service before closing the change window.