A building-permits application hard-coded a Pod IP in its config and failed after the Pod was rescheduled to another node. Which change restores stable reachability for other in-cluster callers?
Select an answer to reveal the explanation.
Short Explanation
Hard-coding a Pod IP is like tattooing today's taxi plate on the office door — the next cab has a new plate. Point callers at a Service DNS/ClusterIP so Kubernetes keeps the directory up to date.
Full Explanation
A building-permits application that hard-coded a Pod IP in its config and failed after the Pod was rescheduled to another node should create a Service that selects the Pods by label and update callers to use the Service DNS name or ClusterIP instead of the Pod IP. That restores stable reachability for other in-cluster callers because the Service identity survives Pod reschedules while Endpoints update to the new Pod IP.
Pinning the Pod to a static HostNetwork IP equal to the node's primary address and disabling CNI is a brittle anti-pattern. Adding a PersistentVolumeClaim does not persist or reuse Pod IPs across restarts. Replacing the Deployment with a Job does not guarantee the same Pod object identity forever for a long-lived API.
Exam caveat: selector labels on Pods must match the Service or Endpoints stay empty. Operational check: create the Service with the correct selector, point permits callers at the Service DNS name, delete the Pod, and confirm callers still connect via the updated Endpoints. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.