KCNA - Cloud Native Application Delivery (16% of the exam) - Section 3.5
Explain how a running cloud native application is inspected and debugged.
Reading logs and events, exec into a container, port-forwarding, ephemeral debug containers, and the difference between liveness, readiness and startup probes when diagnosing an unhealthy workload.
kubectl logskubectl execport-forwardephemeral containersliveness, readiness and startup probes
A team keeps confusing two Kubernetes probe types. One probe decides whether a running container is healthy enough to keep, and when it fails repeatedly the kubelet restarts that container. The other probe decides whether a container is ready to receive traffic, and when it fails the container stays running but is removed from the Service endpoints. Which pairing correctly matches each behaviour to its probe?
AThe restart-on-failure behaviour is the liveness probe, and the remove-from-endpoints behaviour is the readiness probe.check_circle Correct
BThe restart-on-failure behaviour is the readiness probe, and the remove-from-endpoints behaviour is the liveness probe.
CThe restart-on-failure behaviour is the startup probe, and the remove-from-endpoints behaviour is the liveness probe.
DThe restart-on-failure behaviour is the readiness probe, and the remove-from-endpoints behaviour is the startup probe.
Distinguish liveness probes, which restart unhealthy containers, from readiness probes, which control Service endpoint membership. The kubelet acts differently per probe: a failed liveness probe triggers a container restart, whereas a failed readiness probe only causes the endpoint controller to drop the Pod from Service endpoints, so the container keeps running but stops receiving traffic.
Why A is correct: A failing liveness probe causes the kubelet to restart the container, while a failing readiness probe leaves the container running but pulls it out of the Service endpoints so it receives no traffic, which is exactly the described split.
Why B is wrong: This reverses the two probes, which is a common mix-up, because readiness never restarts a container and liveness never merely deregisters an endpoint.
Why C is wrong: The startup probe only gates when the other probes begin and does not itself remove endpoints, and liveness restarts rather than deregisters, so neither half matches.
Why D is wrong: Readiness does not restart containers and the startup probe governs initial start-up timing rather than endpoint membership, so both descriptions are attached to the wrong probe.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
Run kubectl exec -it against the Pod with /bin/sh to open a shell in the existing container
errorWhy it is wrong: This is the usual way to get a shell, which makes it tempting, but a distroless image has no /bin/sh, so exec fails immediately with an executable-not-found error.
A readiness probe, because it holds traffic back until the application has finished starting.
errorWhy it is wrong: A readiness probe does delay traffic during boot, which makes it tempting, but it does not stop the liveness probe from running and restarting the container, so the restart loop would continue.
A readiness probe, which prevents the container from being restarted while it is still initialising
errorWhy it is wrong: A readiness probe is tempting because it also concerns timing, but it only controls whether traffic is routed to the Pod and never suppresses or delays the liveness restart behaviour.