CKAD Practice Question 5: Startup Probe Slow Start
Certified Kubernetes Application Developer (CKAD) · Test 1 · question 5 of 10
A legacy application warms a large in-memory cache at boot. Depending on cache state, it becomes responsive anywhere between 30 seconds and 5 minutes after the container starts. Its liveness probe uses periodSeconds: 10 and failureThreshold: 3, so the kubelet restarts the container after 30 seconds and the Pod sits in CrashLoopBackOff.
Once the application is actually up, restart protection must engage immediately and must still detect a hang within about 30 seconds. What should you configure?
Show answer and explanation
Answer:
A startup probe exists for exactly this problem. While it is running, the kubelet disables the liveness and readiness probes entirely, so a slow boot cannot trigger a restart. The container is given failureThreshold * periodSeconds to come up; for example failureThreshold: 30 with periodSeconds: 10 allows 300 seconds. The moment the startup probe succeeds, it never runs again and the unchanged liveness probe takes over, so a hang is still caught in 30 seconds. It also adapts: an instance that warms up in 30 seconds gets liveness protection at 30 seconds.
Option A trades one problem for another. initialDelaySeconds: 300 is a fixed blind window; a container that is ready in 30 seconds still has no liveness protection for the next four and a half minutes, violating the "engage immediately" requirement.
Option C permanently weakens detection. With failureThreshold: 30, a deadlock in a long-running container would go unnoticed for five minutes rather than 30 seconds, which the stem rules out.
Option D removes the restart behaviour altogether. Readiness only controls Service membership; a wedged process would stay wedged forever with no recovery. Readiness and liveness are complements, not substitutes.