CKA Workloads and Scheduling Practice Question
A StatefulSet named 'mysql' is deployed with 3 replicas. A developer reports that the pod 'mysql-0' is failing due to persistent volume issues. After fixing the underlying storage, they want to recreate 'mysql-0' while preserving its stable network identity. What is the correct approach?
⚠ Common exam trap
A common mix-up: candidates think scaling down and up is required to recreate a pod, but the StatefulSet controller automatically recreates a deleted pod with the same identity, making direct pod deletion the correct and minimal approach.
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
✓
Delete the pod 'mysql-0' using kubectl delete pod mysql-0, and let the StatefulSet controller recreate it
StatefulSet pods are managed by a controller that automatically recreates a pod with the same identity (name, hostname, and stable network identity) when it is deleted. Deleting the pod 'mysql-0' triggers the StatefulSet controller to create a new pod with the same ordinal index and persistent storage binding, preserving its stable network identity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete the StatefulSet and recreate it with the same configuration
Why it's wrong here
Deleting the entire StatefulSet terminates all running pods simultaneously, causing complete service downtime for the healthy replicas. While the underlying PersistentVolumeClaims are retained by default, this destructive action is highly disruptive and entirely unnecessary for recovering a single degraded pod.
- ✗
Use kubectl replace --force on the StatefulSet to recreate the pod
Why it's wrong here
Using the kubectl replace --force command on the StatefulSet configuration forces a destructive deletion and recreation of the controller resource itself. This operation targets the entire controller rather than the specific mysql-0 pod, triggering a rolling update or full termination of all managed replicas.
- ✗
Scale the StatefulSet down to 0 replicas, then scale back up to 3
Why it's wrong here
Scaling the StatefulSet down to 0 replicas terminates all three pods in reverse ordinal order, resulting in total application downtime. While scaling back up to 3 will eventually recreate mysql-0, this approach unnecessarily disrupts the healthy mysql-1 and mysql-2 replicas instead of surgically targeting the failed pod.
- ✓
Delete the pod 'mysql-0' using kubectl delete pod mysql-0, and let the StatefulSet controller recreate it
Why this is correct
Deleting the individual pod mysql-0 prompts the StatefulSet controller to automatically provision a replacement pod. The newly created pod will retain the exact same name, stable network identity, and will automatically reattach to the existing PersistentVolumeClaim associated with that ordinal index, ensuring zero data loss.
Go deeper
Related to this question
About these practice questions
This CKA question is part of Courseiva's 726-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 CKA 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 CKA exam.