CKA Troubleshooting Practice Question
A pod is in CrashLoopBackOff. 'kubectl logs my-pod --previous' shows: 'Error: failed to start: exec: "/app/start.sh": stat /app/start.sh: no such file or directory'. What is the most likely cause?
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
✓
The container image is missing the startup script.
The error indicates the specified entrypoint script is missing. This is often due to the container image not containing the script at the expected path, or the command/args in the pod spec referencing a non-existent file.
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's service account lacks permissions.
Why it's wrong here
A missing service account permission would not produce a startup error like 'no such file or directory' for /app/start.sh. Instead, it would surface as HTTP 403 Forbidden responses when the container attempts to call the Kubernetes API, usually appearing later in the application logs after the process has started. Since the container crashes before or immediately during script execution, the log clearly points to a filesystem/command problem, not authorization.
- ✓
The container image is missing the startup script.
Why this is correct
The error 'no such file or directory' for /app/start.sh in the container logs directly indicates that the command or entrypoint defined in the pod spec references a script that does not exist within the container image. This typically happens when a Dockerfile fails to COPY the script into the image, or the image tag points to an older build without the file. Because the process cannot start, the container exits non-zero and Kubernetes enters CrashLoopBackOff.
- ✗
The pod's liveness probe is misconfigured.
Why it's wrong here
A misconfigured liveness probe would cause Kubernetes to restart the container only after the probe repeatedly fails, which requires the container to be running long enough for the kubelet to execute the probe. The logs would show probe timeout or application-level error messages, not a shell's complaint about a missing script file. In a CrashLoopBackOff with that log line, the failure is before the process even starts, so the probe is not the root cause.
- ✗
The pod has run out of memory.
Why it's wrong here
Running out of memory would trigger the kernel's OOM killer, setting the container's exit code to 137 and marking its status as OOMKilled in `kubectl describe pod`. The logs would not show a shell error like 'no such file or directory' because the process is killed by the kernel before it can execute the startup script, or the OOM event happens after the script runs and the application consumes memory. Thus, an OOM situation produces a different error signature and status.
Go deeper
Related to this question
Key term
Log Analysis
Log analysis is the process of reviewing and interpreting system-generated records to understand what happened in an application or infrastructure.
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.
About these practice questions
One of 726 original CKA 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 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.