CKA Workloads and Scheduling Practice Question
A Pod has an init container that writes a configuration file, and the main container reads that file. The init container runs successfully, but the main container fails with 'file not found'. What is the most likely cause?
⚠ Common exam trap
Watch out — candidates often assume init containers and main containers automatically share the same filesystem, but Kubernetes isolates container filesystems by default unless volumes are explicitly shared.
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 init container wrote the file to a different volume than the one mounted in the main container.
The most likely cause is that the init container wrote the configuration file to a volume that is not shared with the main container. In Kubernetes, init containers and main containers in the same Pod share the same filesystem only if they mount the same Volume. If the init container writes to a volume that is not mounted in the main container, or writes to a different path within the same volume, the main container will not see the file. This is a common misconfiguration when using emptyDir or hostPath volumes.
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 init container wrote the file to a different volume than the one mounted in the main container.
Why this is correct
Kubernetes containers within a pod, including init and main containers, have isolated filesystems by default. For an init container to share data, such as a configuration file, with a main container, they must both mount the same shared volume, like an `emptyDir`. If the init container wrote the file to its own ephemeral filesystem or a volume not also mounted by the main container, the main container would correctly report "file not found" as it cannot access that location.
- ✗
The main container restarted and the init container did not rerun.
Why it's wrong here
Init containers execute strictly once during a pod's initial startup phase, completing successfully before any application containers begin. If the main container subsequently restarts, the init container does not rerun. However, any files written by the init container to a *shared* volume would persist across main container restarts, meaning the file should still be present and accessible. This scenario would not cause a "file not found" error if the file was initially written correctly to a shared volume.
- ✗
The main container's command is incorrect.
Why it's wrong here
A "file not found" error specifically indicates that the operating system cannot locate the specified file at the given path, rather than an issue with the command's syntax or execution logic itself. While an incorrect command *could* indirectly lead to problems, this error message points directly to the absence of the file or an incorrect path reference within the command, assuming the command itself is syntactically valid. The command might be trying to access a file that simply isn't there.
- ✗
The init container did not complete before the main container started.
Why it's wrong here
Kubernetes enforces a strict execution order: all init containers must complete successfully before any of the pod's application containers are started. If an init container fails, the pod is restarted until all init containers succeed. Therefore, the main container cannot begin execution until the init container has finished writing the configuration file, making this scenario impossible under normal Kubernetes operation.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
This CKA question is part of Courseiva's 302-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.