CKA Diagnose ContainerCreating pod Practice Question
A user reports that a pod is stuck in 'ContainerCreating' state. Which command would you run first to diagnose the issue?
⚠ Common exam trap
The trap here is that candidates often jump to `kubectl logs` thinking it shows startup errors, but logs are only available after the container's entrypoint has executed, not during container creation failures.
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
✓
kubectl describe pod <pod-name>
The 'ContainerCreating' state indicates the pod has been scheduled but the container runtime is failing to start the container. `kubectl describe pod` provides detailed events, status conditions, and error messages from the kubelet, such as image pull failures, volume mount errors, or CNI plugin issues, which are the most direct source of diagnostic information for this state.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kubectl logs <pod-name>
Why it's wrong here
kubectl logs is ineffective because the container has not started; there is no container to stream logs from, and the command will fail with an error indicating the container isn't running. Logs only capture output from a successfully launched container, so this does not reveal why the container runtime failed to create or start the container, such as image pull issues or volume mount failures.
- ✓
kubectl describe pod <pod-name>
Why this is correct
kubectl describe pod is the correct diagnostic because it displays the pod's status, conditions, container states, and a list of recent Events aggregated for that pod. These Events will contain specific errors such as FailedCreatePodSandBox, ErrImagePull, FailedMount, or CreateContainerError, along with the underlying message from the kubelet or container runtime. This gives you exactly the information needed to resolve ContainerCreating.
- ✗
kubectl get events --watch
Why it's wrong here
kubectl get events --watch is wrong because it is a long-running, blocking command that streams only new events from all namespaces and does not surface the historical events that caused the ContainerCreating state. By the time you run it, the relevant kubelet events have already been recorded, so you would either miss them or be flooded with unrelated cluster events. The --watch flag does not replay existing events, making kubectl describe pod the targeted way to see that pod's event history.
- ✗
kubectl exec -it <pod-name> -- /bin/sh
Why it's wrong here
kubectl exec is invalid for a Pod in ContainerCreating because the container does not yet exist or is not running, so there is no process namespace to attach to and no shell to start. Exec requires a running container and a working container runtime, both of which are absent when the pod is still being created. Therefore it would simply return an error instead of providing any diagnostic information.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.
✓kubectl describe pod <pod-name>Correct answer▾
Why this is correct
kubectl describe pod is the correct diagnostic because it displays the pod's status, conditions, container states, and a list of recent Events aggregated for that pod. These Events will contain specific errors such as FailedCreatePodSandBox, ErrImagePull, FailedMount, or CreateContainerError, along with the underlying message from the kubelet or container runtime. This gives you exactly the information needed to resolve ContainerCreating.
✗kubectl logs <pod-name>Wrong answer — click to see why▾
Why this is wrong here
Logs require a running container; the pod is still ContainerCreating, so no logs exist.
✗kubectl get events --watchWrong answer — click to see why▾
Why this is wrong here
This shows all cluster events, not specifically the pod's issue; it's less direct than describe pod.
✗kubectl exec -it <pod-name> -- /bin/shWrong answer — click to see why▾
Why this is wrong here
Exec requires a running container; pod is not running.
Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
Key term
Volumes
In Kubernetes, a volume is a storage resource that outlives the pod it belongs to, enabling data to persist across container restarts and be shared between containers in the same pod.
About these practice questions
Courseiva writes every CKA question from scratch — 726 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.