CKAD Application Observability and Maintenance Practice Question
A container in a pod is expected to shut down gracefully within 30 seconds when it receives SIGTERM. How should you configure the pod to ensure the container is given enough time to shut down before being forcefully killed?
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
✓
Set spec.terminationGracePeriodSeconds: 35
terminationGracePeriodSeconds defines the time Kubernetes waits after sending SIGTERM before sending SIGKILL. Setting it to 35 seconds gives the container a 5-second buffer beyond the expected 30-second shutdown time. Option B is correct because 35 seconds provides sufficient time without being excessive. Option A uses an invalid field name (terminationGracePeriod instead of terminationGracePeriodSeconds). Option C sets the grace period to 300 seconds, which is excessively long and could delay pod termination. Option D sets the grace period to 20 seconds, which is too short and may not allow the container to shut down gracefully within the expected 30 seconds.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set spec.terminationGracePeriod: 35
Why it's wrong here
The Kubernetes pod spec does not contain a field named terminationGracePeriod. The correct API field is terminationGracePeriodSeconds, and the value must be an integer number of seconds. Using the wrong field name would cause the API server to reject the manifest with a validation error, so this option cannot run.
- ✓
Set spec.terminationGracePeriodSeconds: 35
Why this is correct
Setting spec.terminationGracePeriodSeconds to 35 is appropriate because this pod-level field defines the maximum time allowed between the kubelet sending SIGTERM and forcibly sending SIGKILL. With an expected shutdown time around 35 seconds, this value gives the container sufficient time to complete graceful cleanup without delaying cluster operations.
- ✗
Set spec.terminationGracePeriodSeconds: 300
Why it's wrong here
A grace period of 300 seconds is five minutes, which is far beyond the container's anticipated shutdown time. Overly long grace periods can hang pod eviction during node drains, slow down rolling deployments, and keep resources unused for too long. The value should be tuned to the application's real-world startup/cleanup behavior, not arbitrarily inflated.
- ✗
Set spec.terminationGracePeriodSeconds: 20
Why it's wrong here
At 20 seconds, this grace period is shorter than the expected shutdown time, so the container would be killed with SIGKILL before it finishes its graceful termination routine. Incomplete cleanup can lead to data corruption, abandoned state, or broken network connections. The grace period must be at least as long as the worst-case graceful shutdown duration.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.