A county GIS team wants pods that are still warming up to stay off Service traffic until they can serve requests. Which probe controls that behavior?
Select an answer to reveal the explanation.
Short Explanation
Readiness is the velvet rope at the club door—until the app says it is ready, the Service will not send it guests. Liveness is about restarting a stuck process, not about joining the endpoint list.
Full Explanation
A county GIS team that wants pods still warming up to stay off Service traffic until they can serve requests should use a readiness probe that must succeed before the Pod is added to Service endpoints. Readiness gates traffic: failing or not-yet-successful readiness keeps the Pod out of Endpoints/EndpointSlices so citizens are not sent to cold GIS backends. Once the probe passes, the Pod joins the Service and receives traffic.
A liveness probe that only increases the Deployment's replica count misstates liveness—liveness restarts unhealthy containers; it does not scale replicas. A startup probe that rewrites the Service selector when the JVM finishes loading invents a mechanism; startup delays other probes but does not rewrite selectors. An exec probe mounted as a ConfigMap volume at /healthz confuses probe configuration with volume mounts.
Exam caveat: readiness controls Endpoints membership; liveness controls restarts; startup protects slow booters from premature liveness kills. Operational check: configure readiness on GIS Pods, watch Endpoints during startup, and confirm traffic only hits Pods that pass readiness. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.