CCNA Manage containers Questions

MCQeasy

Based on the exhibit, which command should be used to start the container named 'mycontainer'?

A.podman attach mycontainer

B.podman restart mycontainer

C.podman run mycontainer

D.podman start mycontainer

AnswerD

podman start is correct because it changes an existing, stopped container from the Exited state to the Running state without creating a new container or pulling an image. It resumes the container's configured entrypoint, command, and environment, making it the exact tool needed for the situation shown in the exhibit.

Why this answer

The correct command to start an existing but stopped container is 'podman start mycontainer'. 'podman start' resumes a container that has been created (via 'podman create') or previously stopped, without creating a new instance. Option D is correct because it directly addresses the requirement to start the container named 'mycontainer' that already exists.

Exam trap

The trap here is that candidates confuse 'podman run' (which creates and starts a new container) with 'podman start' (which starts an existing stopped container), leading them to choose option C when the container already exists.

How to eliminate wrong answers

Option A is wrong because 'podman attach' connects your terminal to a running container's standard input/output/error streams; it does not start a container. Option B is wrong because 'podman restart' stops and then starts a container that is already running or stopped, but the question asks specifically to 'start' the container, not to restart it; restart implies a stop followed by a start, which is unnecessary and potentially disruptive for a stopped container. Option C is wrong because 'podman run' creates and starts a new container from an image, but the container 'mycontainer' already exists (as implied by the exhibit), so 'run' would attempt to create a duplicate or fail if the name conflicts.

Practice this question →

MCQmedium

A team wants to run a container as a non-root user inside the container for security. Which instruction should be included in the Containerfile?

A.USER

B.PODMAN_USER

C.ENV USER

D.RUN useradd

AnswerA

The USER instruction is the standard Containerfile directive that sets the active user for subsequent instructions, including the final CMD/ENTRYPOINT runtime process. By specifying a non-root user or numeric UID (e.g., USER 1000), the container runs with least privilege. This is the only option here that directly changes the identity of the running container process.

Why this answer

The USER instruction in a Containerfile (Dockerfile) sets the user name or UID to use when running the container and for any subsequent RUN, CMD, or ENTRYPOINT instructions. By default, containers run as root (UID 0), which poses a security risk. Using USER to switch to a non-root user (e.g., USER 1001) ensures the container process runs with reduced privileges, aligning with the principle of least privilege.

Exam trap

The trap here is that candidates often confuse creating a user (RUN useradd) with actually running as that user, forgetting that the USER instruction is required to switch the runtime context, or they invent non-existent instructions like PODMAN_USER.

How to eliminate wrong answers

Option B (PODMAN_USER) is wrong because there is no such instruction in Containerfile/Dockerfile syntax; Podman uses the same standard instructions as Docker. Option C (ENV USER) is wrong because ENV sets environment variables (e.g., ENV USER=myuser) but does not change the runtime user identity; the container still runs as root unless a USER instruction is used. Option D (RUN useradd) is wrong because while useradd creates a user account inside the image, it does not switch the active user for subsequent instructions or the container's entrypoint; you must still use USER to actually run as that user.

Practice this question →

MCQhard

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?

A.Create a cron job that checks if the container is running and starts it if not.

B.Create a sysvinit script that calls podman commands.

C.Add 'podman run ...' to /etc/rc.local.

D.Use 'podman generate systemd --new --name mycontainer' and enable the generated service.

AnswerD

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.

Why this answer

`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.

Exam trap

The trap here is that candidates may 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.

How to eliminate wrong answers

Option A is wrong because a cron job that polls for container status introduces unnecessary latency, race conditions, and complexity; it does not integrate with systemd's dependency-based startup ordering or provide reliable restart-on-failure behavior. Option B is wrong because sysvinit scripts are legacy in RHEL 8/9, which uses systemd as the default init system; using sysvinit bypasses systemd's native container management features and is not a supported Red Hat best practice. Option C is wrong because `/etc/rc.local` is executed after most services have started, offers no dependency management, and is considered a legacy workaround; it does not provide the restart policy or lifecycle control that systemd units offer.

Practice this question →

MCQhard

An administrator is tasked with deploying a containerized application on a Red Hat Enterprise Linux 8 server that is part of a high-security environment. The application must run as a non-root user inside the container. The container image is based on Red Hat Universal Base Image (UBI) and exposes port 443 for HTTPS. The administrator needs to ensure that the container can be restarted automatically if it crashes and that the application logs are persisted on the host in /var/log/app. The application requires a configuration file that is generated dynamically at startup and must be accessible to the container. The administrator has created a systemd service file for the container but wants to use Podman's built-in features to manage the container. Which approach meets all requirements?

A.Create a systemd service file using 'podman generate systemd' on a running container, then enable the service with 'systemctl enable --now container-myapp'. The container should be started with '--restart=always' and appropriate volume and port mappings.

B.Create a 'podman service' unit using 'podman service create' to manage the container with automatic restart and boot-start.

C.Run the container with 'podman run --restart=always -v /var/log/app:/var/log -p 443:443 myapp' and rely on the container's restart policy.

D.Use 'podman create --restart=on-failure -v /var/log/app:/var/log -p 443:443 myapp' and then start it with 'podman start'.

AnswerC

The '--restart=always' policy only works if the Podman process is running; it does not survive a system reboot without systemd.

Why this answer

Podman's built-in restart policy (`--restart=always`) ensures the container restarts automatically after a crash without requiring systemd. The volume mount persists logs at /var/log/app on the host, and the port mapping exposes port 443. This approach uses Podman's native features as desired, meeting all requirements.

Option A relies on a systemd service generated by Podman, which shifts management back to systemd instead of using Podman's built-in restart capability. Option B uses an invalid command. Option D uses `--restart=on-failure`, which only restarts on non-zero exit codes and may miss other crash scenarios.

Exam trap

Candidates may assume that Podman's `--restart` flag only works with systemd, but Podman supports restart policies natively for crash recovery. Systemd integration is required only for automatic restarts after host reboots, which is not stated as a requirement here.

How to eliminate wrong answers

Option B is wrong because 'podman service create' is not a valid Podman command; Podman does not have a 'service create' subcommand for managing containers—this is a Docker Swarm concept. Option C is wrong because '--restart=always' is not supported by Podman's 'podman run' command; Podman relies on external process managers like systemd for restart policies, and the container would not survive a host reboot or crash without systemd integration. Option D is wrong because 'podman create --restart=on-failure' is not a valid Podman option; Podman's '--restart' flag is only available with 'podman run' and is not recommended for production use without systemd, and 'podman start' does not enable automatic restart on crash or boot.

Practice this question →

MCQhard

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?

A.The container binary is missing or has the wrong architecture (exec format error).

B.The container's logging driver is not configured to capture stdout.

C.The log file is rotated and cleared.

D.The container is using a non-standard log location inside the container.

AnswerA

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'.

Why this answer

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.

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.

How to eliminate wrong answers

Option B is wrong because Podman's default logging driver (journald) captures stdout/stderr from the container's PID 1; if the container never starts a process, there is nothing to capture, so the driver is not the issue. Option C is wrong because log rotation or clearing would not cause an immediate exit with status 1 and zero logs; rotated logs would still show prior output if any existed. Option D is wrong because `podman logs` only reads from the container's configured log driver (stdout/stderr), not from files inside the container; a non-standard log location inside the container is irrelevant to the `podman logs` command.

Practice this question →

MCQeasy

A container named 'web1' was created and ran briefly before exiting with status 0. The administrator needs to restart it and attach to the running container's console. Which command should be used?

A.podman run --name web1 -it registry.access.redhat.com/ubi8/httpd-24

B.podman start web1

C.podman restart web1 && podman attach web1

D.podman start web1 && podman attach web1

AnswerD

This combination first uses podman start web1 to take the existing stopped container and transition it to the running state, preserving its filesystem and configuration. Then podman attach web1 connects your terminal to the container's primary process' STDIN and STDOUT, giving you the same interactive console session that existed when it was originally run. This is the correct lifecycle sequence for resuming an existing interactive container without recreating it.

Why this answer

`podman start web1` restarts the existing container that exited with status 0, and `podman attach web1` connects the current terminal to the container's main process console. The `&&` ensures the attach runs only after the container is successfully started, allowing the administrator to interact with the running container's console.

Exam trap

The primary trap is that candidates may think `podman restart` is required to resume an exited container, but `podman start` is the correct command. Additionally, candidates often forget to attach to the console after starting, leading them to choose option B. Note: `podman restart` does work on stopped containers, but it stops and starts the container unnecessarily; `podman start` is the appropriate command for resuming a container that exited with status 0.

How to eliminate wrong answers

Option A is wrong because `podman run` creates and runs a new container with the name 'web1', which will fail since a container named 'web1' already exists, and it does not restart the existing container. Option B is wrong because `podman start web1` only starts the container but does not attach to its console, so the administrator cannot interact with the running container. Option C is wrong because `podman restart web1` stops and then starts the container, which is unnecessary for a container that exited with status 0 and can be started directly; additionally, the `&&` syntax is valid but the restart is redundant and may cause a brief interruption.

Practice this question →

MCQhard

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?

A.Disable SELinux with setenforce 0 and restart the service.

B.Remove the systemd service and regenerate it with 'podman generate systemd --new --name webapp'.

C.Manually create the /usr/bin/app.sh file inside the container using podman exec.

D.Rebuild the container image using 'podman build -t webapp .' to ensure the app.sh file is included, then restart the service.

AnswerD

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.

Why this answer

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.

Exam trap

The trap here is that candidates may 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.

How to eliminate wrong answers

Option A is wrong because the error is a missing file inside the container, not a SELinux denial; disabling SELinux would not fix the missing binary and introduces a security risk. Option B is wrong because the systemd service unit is correctly generated and the issue is with the container image content, not the service definition; regenerating the unit would not add the missing file. Option C is wrong because `podman exec` requires a running container, but the container fails to start, so you cannot exec into it; even if you could, manual creation would be overwritten on restart and is not a proper fix.

Practice this question →

MCQeasy

A developer is running Podman as a non-root user on a Red Hat Enterprise Linux 8 system. The developer successfully runs a container, but notices that after logging out of the SSH session, the container stops. The developer wants the container to continue running even after disconnecting from the SSH session. The container is a simple web server that listens on port 8080. The developer has already enabled lingering for the user account using 'loginctl enable-linger'. However, the container still stops upon logout. What additional step should the developer take to ensure the container persists after logout?

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

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

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

D.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'

AnswerD

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.

Why this answer

Even with lingering enabled, a container started directly via `podman run` is tied to the user's login session and will be terminated when the session ends. To make the container persist independently of the SSH session, it must be managed as a systemd user service. The `podman generate systemd --new` command creates a systemd unit file that can be enabled with `systemctl --user`, ensuring the container starts automatically and continues running after logout.

Exam trap

The trap here is that candidates confuse `--detach` or `-d` with making a container persistent, when in fact those flags only detach the container from the terminal, not from the user's login session; the container still stops when the session ends unless it is managed by systemd.

How to eliminate wrong answers

Option A is wrong because `--restart=always` is a Docker flag, not a Podman flag; Podman uses `--restart` with policies like `always` or `on-failure`, but even if used, it only restarts the container if it exits, not if the user session ends. Option B is wrong because `--detach` (or `-d`) runs the container in the background but still ties it to the user's login session; when the SSH session ends, the container is killed because it is a child of the shell session. Option C is wrong for the same reason as Option B: `-d` is synonymous with `--detach` and does not decouple the container from the user's login session; it only detaches the container from the terminal, not from the session lifecycle.

Practice this question →

MCQeasy

Refer to the exhibit. A container named 'db' is running on the host. An administrator runs `podman inspect db` and sees the above output snippet. What can be concluded about the container's network configuration?

A.The container is using host networking mode.

B.The container cannot be reached from other containers.

C.The container's port 3306 is bound to all host interfaces.

D.The container is using bridge networking with a static IP.

AnswerC

The `PortBindings` map reveals that TCP port 3306 inside the container is published with `HostIp: 0.0.0.0` and `HostPort: 3306`, which tells Docker to bind the port on every IPv4 interface of the host machine. Consequently, any request sent to the host's IP address on port 3306 — whether on a local loopback, private LAN card, or public NIC — is forwarded through the bridge to the container. This is the opposite of binding to a single specific host interface, such as 127.0.0.1, and it is the standard way to expose a service to all external networks.

Why this answer

The output snippet from `podman inspect db` shows `"Ports": {"3306/tcp": [{"HostIp": "0.0.0.0", "HostPort": "3306"}]}`. This indicates that the container's port 3306 is mapped to port 3306 on all host interfaces (0.0.0.0), which is the default bridge networking port binding behavior. Therefore, option C is correct.

Exam trap

Red Hat often tests the distinction between host networking mode and bridge networking with port mapping, where candidates mistakenly think that any port binding to 0.0.0.0 implies host networking, but it actually indicates bridge mode with a published port.

How to eliminate wrong answers

Option A is wrong because host networking mode would show `"NetworkMode": "host"` in the inspect output, and the port mapping would not appear as a bind to 0.0.0.0; instead, the container would share the host's network stack directly. Option B is wrong because the container can be reached from other containers on the same bridge network via its IP address or container name, and the port mapping shown does not prevent inter-container communication. Option D is wrong because the inspect output does not show a static IP assignment; bridge networking with a static IP would require a custom network configuration with an explicit IP address, which is not indicated in the provided snippet.

Practice this question →

MCQhard

A system administrator is troubleshooting a container that fails to start with the error: 'Error: cannot start container: listen tcp4 :80: bind: address already in use'. The container is intended to serve HTTP traffic on port 80. What is the most appropriate first step to resolve this issue?

A.Add --force to the podman run command

B.Check which process is using port 80 and either stop that process or use a different host port

C.Add --replace to the podman run command

D.Use --net=host to bypass the port mapping

AnswerB

Start by identifying which process holds port 80 with `ss -tlnp` or `lsof -i :80`; the output shows the process ID and name. You can then stop that service with `systemctl stop` or `kill` if it is no longer needed, or simply run the container with a different host port mapping like `-p 8080:80` to avoid the conflict. This is the standard, correct approach because it either frees the required resource or selects an unused port.

Why this answer

The error 'address already in use' indicates that port 80 on the host is already occupied by another process. The correct first step is to identify that process using commands like `ss -tlnp` or `lsof -i :80` and either stop it or map the container to a different host port (e.g., `-p 8080:80`). This directly resolves the binding conflict without risking data loss or unintended behavior.

Exam trap

The trap here is that candidates may confuse container-level options like `--replace` or `--force` with host-level port management, or assume `--net=host` bypasses port conflicts, when in fact it still requires the port to be available on the host.

How to eliminate wrong answers

Option A is wrong because `--force` is not a valid flag for `podman run`; it is used with `podman rm` or `podman stop` to forcefully remove or stop a container, not to bypass port conflicts. Option C is wrong because `--replace` is used with `podman run` to stop and remove an existing container with the same name before starting a new one, but it does not address the underlying port binding conflict on the host. Option D is wrong because `--net=host` makes the container share the host's network stack, which would still require port 80 to be free on the host and does not resolve the conflict; it also reduces network isolation.

Practice this question →

MCQeasy

A user wants to run a container that will restart automatically unless explicitly stopped by the administrator. Which podman run option should be used?

A.--restart=on-failure

B.--restart=always

C.--restart=unless-stopped

D.--restart=no

AnswerC

--restart=unless-stopped is correct because it ensures the container is automatically restarted whenever it exits, for any reason, with one crucial exception: if an administrator explicitly issues 'docker stop', the container will not be restarted by the policy until it is manually started again. Docker distinguishes between a container that stopped on its own and one that was intentionally stopped, so this matches the requirement exactly. It also survives daemon restarts and host reboots, making it a robust production choice.

Why this answer

The `--restart=unless-stopped` policy ensures the container restarts automatically whenever it exits, unless the administrator explicitly stops it with `podman stop`. This matches the requirement exactly: the container will keep restarting even after system reboots or crashes, but will not restart if the admin manually stops it. The other policies either do not restart on manual stop (`always`) or only restart on non-zero exit codes (`on-failure`).

Exam trap

Candidates often choose `--restart=always` thinking it will restart automatically except when manually stopped. However, the key difference is that `--restart=always` will restart the container after a system reboot even if it was manually stopped before the reboot, whereas `--restart=unless-stopped` will not. The question's requirement 'unless explicitly stopped by the administrator' matches `unless-stopped` because it ensures the container does not restart after a manual stop, even across reboots.

How to eliminate wrong answers

Option A is wrong because `--restart=on-failure` only restarts the container when it exits with a non-zero exit code (indicating an error), not when it exits cleanly or is stopped by the administrator. Option B is wrong because `--restart=always` restarts the container regardless of why it stopped, including if the administrator explicitly stops it with `podman stop`, which violates the requirement. Option D is wrong because `--restart=no` is the default and never restarts the container automatically after it exits.

Practice this question →