The parks department wants the Docker Engine itself to mark a running recreation-API container unhealthy when its local probe fails. Which image-level feature provides that hook?
Select an answer to reveal the explanation.
Short Explanation
HEALTHCHECK is the image’s way of asking “is this process still useful?” The Engine probes and stamps unhealthy when the answer is no. Orchestrator probes come later; this is the Docker-native hook.
Full Explanation
Docker’s image-level HEALTHCHECK tells the Engine how to probe the running recreation-API process and flip the container’s health status when the probe fails. That status is visible to docker ps, restart policies that honor unhealthy, and operators who need a local signal before any orchestrator exists. Embedding the probe in the image keeps the health contract with the artifact the parks department ships, so every run of that image carries the same check unless the runtime overrides it.
An OKE Deployment livenessProbe is valuable in Kubernetes, but it is an orchestrator concern and does not answer “what does the Docker Engine itself use on a standalone host.” Treating kube probes as a replacement for HEALTHCHECK skips the Docker-native hook the question asks for. A Dockerfile CMD that only starts the process defines how the container launches, not how the Engine decides the process is still useful. An OCI Monitoring alarm on Object Storage metrics for the image tar watches storage or object telemetry, not the live process inside the running container, so it cannot mark that container unhealthy.
Exam caveat: HEALTHCHECK failures mark the container unhealthy; they do not by themselves restart it unless a restart policy or external controller acts on that state. Operational check: run the image locally, break the probe endpoint deliberately, and confirm docker inspect shows Status=unhealthy after the configured retries—proving the Engine, not only a later cluster probe, owns that signal.