A readinessProbe on every permits API Pod calls a shared external payment dependency. During a brief payment outage, all Pods become NotReady. What is the main pitfall?
Select an answer to reveal the explanation.
Short Explanation
If every cashier’s ‘open’ light depends on one flaky credit terminal, the whole store looks closed during a blip. Tying readiness to a fragile external dependency can mark every Pod NotReady and empty Endpoints. Prefer checks that reflect this Pod’s ability to take work, with careful dependency policy.
Full Explanation
When a readinessProbe on every permits API Pod calls a shared external payment dependency, a brief payment outage can mark all Pods NotReady and drain every backend from the Service. The main pitfall is over-coupling readiness to a fragile external dependency, turning a payment blip into a total municipal API outage even though the permits process itself could still answer non-payment routes or degrade gracefully.
Why the other options fail by concept: Readiness can and does remove Pods from Endpoints—that is its job—so claiming traffic was unaffected is wrong. Liveness does not always restart Pods on slow dependencies, and it would not automatically scale the Deployment up. The API server does not generally reject Pods merely because probes mention external hostnames (though doing so is still a bad design).
Exam caveat: Readiness should reflect “this Pod can accept traffic now,” ideally based on local process health; check deep dependencies in synthetic monitors or partial readiness patterns. If payment is mandatory for all requests, deliberate shedding may be desired—but document that as a product choice, not an accident. Circuit breakers inside the app often beat probe-level coupling.
Operational check: Review probe targets for external hosts; redesign readiness to local /readyz. Simulate payment outage and confirm the Service retains backends while the app returns controlled errors for payment paths. Monitor EndpointSlice emptiness alerts as a signal of this anti-pattern.