An open-data client in namespace analytics calls a short Service name that exists in both analytics and shared namespaces and resolves incorrectly. What DNS pitfall is involved?
Select an answer to reveal the explanation.
Short Explanation
Short names are like yelling “Alex” in a crowded hallway—DNS search paths decide which Alex answers. Cross-namespace calls need the full name on the mailbox.
Full Explanation
Short Service DNS names resolve using the Pod's DNS search domains. When an open-data client in namespace analytics calls a short name that exists in both analytics and shared and resolves incorrectly, the pitfall is that search domains can select an unintended same-named Service in another searched namespace. Use a fully qualified Service DNS name when cross-namespace intent matters—short names are like yelling "Alex" in a crowded hallway. Kubernetes does allow identical Service names in different namespaces; the scenario is common, not forbidden. Short names do not always pin to kube-system Services regardless of caller namespace; search order starts with the Pod's own namespace. ClusterIP collisions do not rewrite DNS answers alphabetically across namespaces as a DNS mechanism. Exam caveat: The FQDN form is my-svc.my-namespace.svc.cluster.local. On the exam, prefer FQDN for cross-namespace calls. Operational check: Dig the short name and FQDN from the client Pod, switch the app config to the FQDN for the intended shared Service, and retest analytics calls. 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.