EX200 Manage containers Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Add the --restart=always flag to the podman run command

  Why it's wrong here

  The --restart=always flag configures Podman's restart policy, but that policy only reacts to the container's own exit and attempts to restart it if it stops or crashes. It does not create a systemd service unit or make the container independent of the user session. In rootless Podman, restart enforcement is tied to the user's systemd instance; when that instance ends after logout, the container is killed and the restart policy is no longer being evaluated. Therefore, --restart=always cannot keep the container alive across session logout unless it is combined with a systemd user service and lingering.

• ✗

  Use podman run --detach to run the container in the background

  Why it's wrong here

  Using podman run --detach (the long form) runs the container in the background, but 'detach' only means the terminal is released—it does not remove the container from the user's login session process tree. When the session ends, the systemd user instance (or the session leader) terminates the container's processes, so a detached container dies with the session. There is no systemd unit generated, no lingering enabled, and no supervision by systemd --user, so the container's lifetime remains tied to the session that launched it.

• ✗

  Use podman run -d to run the container in detached mode

  Why it's wrong here

  The -d flag is simply the short alias for --detach, so it provides the same behavior as the long option: it backgrounds the container and returns control of the terminal, but it does not daemonize the container into a system-managed service. A common misconception is treating -d as a 'daemon' flag analogous to what a systemd service does, but Podman's -d only separates the container from the interactive terminal. Without generating a systemd unit and enabling it under systemctl --user, the container will be stopped and cleaned up when the user logs out.

• ✓

  Create a systemd user service by running 'podman generate systemd --new --name mywebcontainer' and then enable and start the service with 'systemctl --user enable --now container-mywebcontainer.service'

  Why this is correct

  For a rootless Podman container to persist after logout, the correct approach is to make it a systemd user service: podman generate systemd --new --name mywebcontainer creates a unit that will recreate and start the container each time the service is started, and systemctl --user enable --now container-mywebcontainer.service both enables the unit and starts it immediately. This places the container under the user's systemd manager rather than under the login session's process tree. To survive logout entirely, the user must also have lingering enabled (loginctl enable-linger <user>) so that the systemd user instance persists after the last session closes. This is the only option that actually ties the container to systemd and provides session-independent lifecycle management.

Go deeper

Related to this question