EX200 Manage containers Practice Question
A container exits immediately with status 1. The administrator runs 'podman logs container' but sees no output. What is the most likely reason for the missing logs?
⚠ Common exam trap
Red Hat often tests the misconception that missing logs are always due to a logging configuration issue, but the trap here is that an immediate exit with status 1 and no output points to a failure before any process runs, such as an exec format error.
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 binary is missing or has the wrong architecture (exec format error).
When a container exits immediately with status 1 and `podman logs` shows no output, the most common cause is that the container binary is missing or has the wrong architecture (e.g., an x86 binary on an ARM system). This results in an 'exec format error' that prevents the container's entrypoint from executing, so no stdout/stderr is ever written to the logging driver. The container exits before any process runs, leaving the log buffer empty.
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 container binary is missing or has the wrong architecture (exec format error).
Why this is correct
When a container exits immediately with status 1 and no output, the kernel often returns ENOEXEC ('exec format error') because the configured entrypoint or command is not a valid executable for the host architecture. This occurs when the image was built for a different CPU architecture (e.g., ARM on x86_64) or when a script's shebang points to a missing interpreter. The container's main process never actually runs, so no stdout/stderr is generated, making logs appear empty. Therefore, the correct action is to verify the image architecture and the executable's format using 'file' and 'podman inspect'.
- ✗
The container's logging driver is not configured to capture stdout.
Why it's wrong here
The logging driver determines where stdout/stderr streams are sent, not whether the container process can execute. Even if the driver were set to 'none' or misconfigured, the container's main process would still run and could exit with status 1; you simply would not be able to retrieve the output afterward. In Podman, the default journald logging driver captures stdout, and a logging driver misconfiguration would not cause an immediate exit. Thus, this option confuses log collection with process execution and does not explain the exit status.
- ✗
The log file is rotated and cleared.
Why it's wrong here
Log rotation is a host-level maintenance task that removes or archives existing log files based on size or time thresholds, but it has no effect on a running container's process lifecycle. An immediate exit with status 1 occurs because the main process terminates quickly, not because of any rotation event. For a container that just started and exited, there is no historical log to rotate, and even if a rotate occurred, it would not alter the exit code. This option incorrectly attributes the failure to file management rather than to the container's execution.
- ✗
The container is using a non-standard log location inside the container.
Why it's wrong here
Podman logs (and docker logs) only retrieve what the container's main process writes to stdout and stderr, not any application log files written inside the container filesystem. If an application logs to a file under a non-standard path, those logs are simply invisible to 'podman logs', but the container's exit status is unrelated to that location. The container exits with 1 because the process itself fails; the absence of logs is a symptom of the process not writing to stdout/stderr, not proof that logs are stored elsewhere. Therefore, this option misidentifies log-output location as a cause of process failure.
Go deeper
Related to this question
About these practice questions
One of 127 original EX200 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 EX200 practice question is part of Courseiva's free Red Hat 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 EX200 exam.