EX200 Manage containers Practice Question
A company runs a critical web application in a container on a Red Hat Enterprise Linux 9 server. The container is started via a systemd service called 'webapp.service'. The service unit file was generated using 'podman generate systemd --new --name webapp'. Recently, after a kernel update and reboot, the service fails to start the container. The administrator runs 'systemctl status webapp.service' and sees 'Active: failed (Result: exit-code)' and 'Process: 1234 ExecStart=/usr/bin/podman run ... (code=exited, status=125)'. The administrator also checks 'journalctl -u webapp.service' and sees: 'Error: unable to start container: container create failed: OCI runtime error: container_linux.go:380: starting container process caused: exec: "/usr/bin/app.sh": stat /usr/bin/app.sh: no such file or directory'. The container image was built locally using a Containerfile that includes 'COPY app.sh /usr/bin/app.sh'. The administrator verifies the image is present locally. What should the administrator do to resolve this issue?
⚠ Common exam trap
Test-takers frequently confuse a missing file inside the container image with a host-level issue (SELinux, service unit, or runtime environment) and overlook the need to rebuild the image with the correct build context.
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
✓
Rebuild the container image using 'podman build -t webapp .' to ensure the app.sh file is included, then restart the service.
The error indicates that the container image is missing the `/usr/bin/app.sh` file, even though the `COPY` instruction was in the Containerfile. The most likely cause is that the image was built before the `app.sh` script was added to the build context, or the build was incomplete. Rebuilding the image with `podman build -t webapp .` ensures the file is properly included in the image layers, resolving the OCI runtime error.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable SELinux with setenforce 0 and restart the service.
Why it's wrong here
There is no AVC denial in /var/log/audit/audit.log or the container's journal, so SELinux is not blocking the container startup. Running setenforce 0 only toggles SELinux to permissive until the next reboot and would not create the missing /usr/bin/app.sh inside the image. Even if the container then started, the web application would still fail later because the required script does not exist in the image.
- ✗
Remove the systemd service and regenerate it with 'podman generate systemd --new --name webapp'.
Why it's wrong here
podman generate systemd reads the current container's configuration and emits a unit file; --new makes that unit create a fresh container from the same webapp image each time it starts. That image still lacks /usr/bin/app.sh, so the regenerated service reproduces the identical failure rather than fixing it. Removing the unit does not remove or rebuild the defective image, so the root cause persists.
- ✗
Manually create the /usr/bin/app.sh file inside the container using podman exec.
Why it's wrong here
podman exec attaches to a running container's namespaces, but this container is in an exited state because the service failed before reaching a running condition. Attempting to run podman exec webapp touch /usr/bin/app.sh returns an error like 'container is not running' and cannot inject the file. Even if the container could be started, writing to the container's writable layer is ephemeral: a subsequent restart from the same image would discard the change. The fix must be applied at image build time.
- ✓
Rebuild the container image using 'podman build -t webapp .' to ensure the app.sh file is included, then restart the service.
Why this is correct
Rebuilding with podman build -t webapp . rereads the Dockerfile/Containerfile in the current directory and recreates the image; if that file contains a COPY app.sh /usr/bin/app.sh step, the new image will contain the missing script. Because the systemd unit references the webapp image tag, when the service restarts it will pull the updated local image with the same tag and use it to run a fresh container. This addresses the root cause, and restarting the service verifies the container starts cleanly.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX200 question from scratch — 127 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 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.