CKAD Application Observability and Maintenance Practice Question
A pod spec has terminationGracePeriodSeconds: 30. The main process ignores SIGTERM. After 30 seconds, what happens?
⚠ Common exam trap
Watch out — candidates often assume a process ignoring SIGTERM will cause the pod to hang forever, but Kubernetes enforces a hard kill after the grace period, making D the only correct answer.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
SIGKILL is sent to forcefully terminate the container
When the main process in a container ignores SIGTERM, Kubernetes waits for the duration specified in `terminationGracePeriodSeconds` (30 seconds) and then sends SIGKILL to forcefully terminate the container. This ensures that pods do not hang indefinitely during shutdown, as SIGKILL cannot be ignored by any process.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The pod remains running indefinitely
Why it's wrong here
A terminating pod cannot run indefinitely because the kubelet enforces a hard deadline. After terminationGracePeriodSeconds (default 30s) expires, the kubelet sends SIGKILL to the container’s main process, and the container is force-killed regardless of whether it had finished its cleanup. The grace period only delays the SIGKILL; it does not allow the pod to keep running past that timeout unless the deletion is blocked by finalizers — even then the container is not alive, just the Pod object lingers.
- ✗
The pod enters a CrashLoopBackOff state
Why it's wrong here
CrashLoopBackOff is a controller-managed state that arises when a container exits with a non-zero code or otherwise crashes immediately after startup, causing the kubelet to repeatedly restart it. During an intentional pod termination, the container receives SIGTERM and is not restarted by the kubelet; the pod is going away, not entering a restart loop. Even if the application exits with a non-zero code upon SIGTERM, the kubelet sees the pod is being terminated and does not initiate a backoff restart.
- ✗
The pod is rescheduled to another node
Why it's wrong here
The act of terminating a pod does not move it to a different node; the pod object is simply marked for deletion and removed after its containers exit. Rescheduling happens only if a higher-level controller such as a Deployment, ReplicaSet, or StatefulSet detects the pod’s absence and creates a replacement pod — which is a brand-new object, not a migration of the original pod. A bare pod with no owning controller is not rescheduled at all, and the node drain case still terminates the pod first before any replacement is created.
- ✓
SIGKILL is sent to forcefully terminate the container
Why this is correct
Once the grace period has elapsed, the kubelet sends SIGKILL (signal 9) to the container’s main process to force immediate termination. SIGKILL cannot be caught, handled, or ignored by the application, so the process dies instantly and the container is removed. This is the final step in the termination sequence: SIGTERM is sent first, and SIGKILL is the escalation when the process has not voluntarily exited within the configured terminationGracePeriodSeconds.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.