A multi-container Pod has a main city-maps API and a log-shipping sidecar. Probes were attached only to the sidecar, which never serves /healthz. What should the developer fix?
Select an answer to reveal the explanation.
Short Explanation
Probes live on a specific container, not ‘the Pod in general.’ If /healthz is on the maps API, put the probe on that container—not on the log sidecar. Wrong target means you’re checking the neighbor’s doorbell.
Full Explanation
In a multi-container Pod with a main city-maps API and a log-shipping sidecar, probes must be defined on the main API container that actually exposes /healthz. Probing only the sidecar—which never serves /healthz—produces meaningless failures or false confidence and does not reflect whether residents can use the maps API. CKAD expects probes on the container whose health matters for the workload’s purpose.
Why the other options fail by concept: Keeping probes on the sidecar and publishing /healthz only on the node’s kubelet port does not health-check the API container. Moving probes to the Pod spec root outside any container is invalid—probes are per container. Deleting the main container so only the sidecar remains abandons the application.
Exam caveat: Each container can have its own probes; sidecars may need separate readiness if the Pod should not be Ready until log shipping starts—but that is an explicit product decision. For ordinary API+sidecar Pods, main-container readiness usually gates Service traffic. Use startupProbe on the main container if maps API init is slow.
Operational check: Place httpGet readiness/liveness on the maps API container with path /healthz, apply, and kubectl describe pod to see probe results on that container. Confirm Service Endpoints track the main API’s readiness, not the sidecar’s.