A city recreation API should receive traffic only after its readiness probe succeeds. The Service currently has publishNotReadyAddresses set to true for a rare warm-up case that no longer applies. What should the developer do for normal app traffic?
Select an answer to reveal the explanation.
Short Explanation
Think of a restaurant that only seats guests once the kitchen says "ready." By default, Services wait for Ready Pods. Turning off publishNotReadyAddresses (or leaving it false) puts that gate back so half-baked Pods do not take live traffic.
Full Explanation
A city recreation API should receive traffic only after its readiness probe succeeds. If the Service currently has publishNotReadyAddresses set to true for a rare warm-up case that no longer applies, remove it or set publishNotReadyAddresses to false so Endpoints wait for Ready Pods before receiving Service traffic. Publishing NotReady addresses undermines readiness gating and can send users to Pods that are running but still warming up or failing readiness checks.
Deleting all readiness probes so every Pod is treated as Ready immediately removes the health signal instead of restoring correct Service publishing. Switching the Service type to ExternalName moves discovery to an external hostname and does not evaluate in-cluster Pod readiness for Endpoints the way a normal selector-based Service does. Adding a hostPort on every Pod to bypass Endpoints readiness gating weakens scheduling isolation and is not the readiness fix.
Exam caveat: publishNotReadyAddresses is an intentional exception used sparingly—know when it is on and turn it off for ordinary civic apps. Operational check: kubectl get svc -o yaml | grep publishNotReadyAddresses; set the field to false or remove it; fail readiness on one Pod and confirm it disappears from Endpoints; restore readiness and confirm it returns. Note the correction in the municipal recreation API release notes so on-call knows warm-up publishing is no longer intended.