A library bot on AKS should not receive traffic until its model client is warm. Which probe configuration addresses that requirement?
Select an answer to reveal the explanation.
Short Explanation
A cold model client is like a librarian still unlocking the doors—you wouldn’t send patrons in yet. A readiness probe keeps the AKS Service from routing library-bot traffic until the warm-up check passes.
Full Explanation
Readiness probes determine when a pod should receive Service traffic. For a library bot on AKS whose model client needs warm-up, configure a readiness probe that fails until the client is ready, such as a local HTTP check that verifies model connectivity. Kubernetes keeps the pod out of Service endpoints until the probe passes, so residents are not routed to a cold instance. Liveness probes restart unhealthy containers; readiness specifically gates traffic, which is the needed behavior. Disabling probes and letting Kubernetes mark the pod Ready as soon as the container starts fails to protect warm-up and sends traffic to a cold model client. Using only a one-shot Job and never exposing a Service does not provide the long-running Service pattern the bot needs. Relying on residents to retry until the cold container eventually answers fails operationally and shifts platform responsibility onto patrons. Exam caveat: Readiness, liveness, and startup probes serve different purposes. Startup probes help slow-starting containers avoid liveness kills, while readiness controls Service membership. Avoid an aggressive liveness probe that kills a pod still warming; the requirement here is traffic gating. Practical check: Deploy a readiness endpoint that remains non-ready during model-client warm-up, watch Endpoints or EndpointSlices exclude the pod, then verify it is included when ready. Generate traffic only after readiness succeeds and compare rollout error rates with probe-less deployments.