EX200 Manage containers Practice Question
A system administrator wants to run a container as a systemd service that restarts automatically after a system reboot. Which approach follows Red Hat best practices?
⚠ Common exam trap
Test-takers frequently think any method that runs a command at boot (like cron or rc.local) is sufficient, but Red Hat specifically tests that systemd is the standard service manager in RHEL 8/9 and that `podman generate systemd` is the recommended way to create persistent container services with proper restart and dependency handling.
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
✓
Use 'podman generate systemd --new --name mycontainer' and enable the generated service.
`podman generate systemd --new --name mycontainer` creates a systemd unit file that defines the container as a transient service with `Restart=always` and `WantedBy=multi-user.target`, ensuring the container starts automatically after a reboot. This approach aligns with Red Hat best practices for managing containers as systemd services, leveraging systemd's native dependency and restart capabilities rather than relying on legacy or non-standard methods.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a cron job that checks if the container is running and starts it if not.
Why it's wrong here
A cron job that polls every minute (or longer) cannot reliably supervise a container: it only detects a non-running container at poll intervals, so a crash and immediate failure before the next poll will go unnoticed, and it does not model dependencies such as networking or storage being ready. systemd unit files provide Restart=always, StartLimitBurst, and ordered dependencies via After=, plus they capture the container's status for systemctl and log to the journal. Cron also risks starting two container instances if the container takes time to shut down or if the check races with a normal stop.
- ✗
Create a sysvinit script that calls podman commands.
Why it's wrong here
A System V init script relies on runlevels and symbolic links, an approach that is no longer used on RHEL 8+; systemd does not give V-scripts the same cgroup accounting, socket activation, or dependency tracking. Even though systemd can execute these scripts via the compatibility layer, calling podman from an init script lacks the container-specific integration that automatically sets service dependencies, removes stale containers, or preserves restart semantics across container and host reboots. The correct approach is to use podman generate systemd to produce an actual native unit file.
- ✗
Add 'podman run ...' to /etc/rc.local.
Why it's wrong here
/etc/rc.local is not a service unit; it is a shell script run by rc-local.service, and it executes commands exactly once during boot with no subsequent supervision, meaning a crashed container will stay stopped until the next reboot. It also has no defined ordering after the container storage or network stacks are available, so podman may fail with 'cannot open' or 'container not found' errors on boot. There is no systemctl stop, no restart policy, and no journal integration for the container's lifecycle, so this is not a proper systemd-managed solution.
- ✓
Use 'podman generate systemd --new --name mycontainer' and enable the generated service.
Why this is correct
podman generate systemd --new --name mycontainer generates a complete systemd service unit that records the exact podman command, container ID, and environment required to create and start the container fresh on every invocation of the service. Placing this unit in /etc/systemd/system and enabling it with systemctl enable --now makes systemd the supervisor: it sets up dependencies such as After=network-online.target, can apply Restart=on-failure, and will tear down the container cleanly on service stop. This is the intended way to manage a container's lifecycle as a systemd service.
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.