EX200 Manage containers Practice Test 3 — 15 Questions

Question 1

Which TWO options correctly describe the use of 'podman exec'? (Choose TWO.)

Accepted Answer

podman exec ls / runs the ls command inside the running container.. `podman exec ls /` executes the `ls /` command directly inside the specified running container, using the container's filesystem and environment. This is the primary purpose of `podman exec`: to run a new process in an already running container without creating a new container.

Answer

podman exec -it <container> /bin/bash attaches to an existing shell process.

Answer

podman exec can start a stopped container.

Answer

podman exec -it <container> /bin/bash runs an interactive shell in a new container.

Question 2

Which THREE statements about container storage in podman are correct? (Choose THREE.)

Accepted Answer

The --storage-opt flag can be used to set options for the container's writable layer.. The `--storage-opt` flag in Podman allows you to pass options directly to the container's storage driver, such as setting the size of the container's writable layer (e.g., `--storage-opt size=10G`). This is a feature of the container storage stack (containers/storage) that Podman uses, enabling fine-grained control over the writable layer's behavior without affecting the image layers.

Answer

Podman volumes can only be managed by podman volume commands, not manually.

Answer

Rootless containers cannot use the overlay filesystem driver.

Question 3

Which TWO commands show detailed information about a container image, including layers and configuration? (Choose TWO.)

Accepted Answer

podman image tree . `podman image tree ` displays the image's layer hierarchy, showing parent-child relationships and layer sizes. Option E is correct because `podman inspect ` returns detailed metadata in JSON format, including the image's configuration (e.g., environment variables, entrypoint) and layer digests. Both commands provide the detailed information about layers and configuration that the question asks for.

Answer

podman ps -a

Answer

podman images <image>

Answer

podman history <image>

Question 4

A DevOps engineer needs to run a container that stores persistent data in a location managed by Podman, ensuring the data survives container removal and can be easily backed up. Which approach should the engineer use?

Accepted Answer

Use a Podman volume (e.g., --volume myvol:/container/data). Podman volumes are managed by Podman itself, storing data in a dedicated directory (typically under /var/lib/containers/storage/volumes). This ensures data persists independently of the container lifecycle, survives container removal, and can be easily backed up using commands like `podman volume export` or by copying the volume directory. Unlike bind mounts, Podman volumes are fully managed, avoiding permission issues and providing a clean abstraction for persistent storage.

Answer

Use a bind mount (e.g., --volume /host/data:/container/data)

Answer

Use the --rm flag when running the container

Answer

Use a tmpfs mount (e.g., --tmpfs /container/data)

Question 5

Refer to the exhibit. A developer created this Containerfile to build a custom web server image. The build fails. Which TWO changes are necessary to make the Containerfile correct and allow the build to succeed?

Accepted Answer

Add a specific tag to the FROM line, e.g., ubi8/ubi:8.4. The Containerfile has two issues: the FROM line lacks a tag (e.g., ubi8/ubi:8.4), causing ambiguity; and the RUN instruction uses 'yum' instead of 'dnf', which is the package manager for Red Hat Enterprise Linux 8. Option B correctly adds a tag, and Option D changes yum to dnf. Option A is wrong because changing to ubi9/ubi is not necessary; the issue is the missing tag, not the base image version. Option C (EXPOSE 80) is documentation, not required to fix the build failure. Option E is unnecessary because a COPY instruction already exists.

Answer

Change the FROM line to use ubi9/ubi (Red Hat Universal Base Image 9)

Answer

Add an EXPOSE 80 instruction before the CMD

Answer

Add a second COPY instruction to copy the container configuration files

Question 6

An administrator creates a Podman pod named 'webpod' and adds two containers: 'webserver' and 'database'. Both containers are added using 'podman pod create --name webpod' followed by 'podman run --pod webpod --name webserver nginx' and 'podman run --pod webpod --name database postgres'. The administrator wants the webserver container to be able to reach the database container by the hostname 'database'. However, when the administrator executes 'podman exec webserver ping database', the ping fails with 'ping: database: Name or service not known'. Which of the following is the most likely cause and correct solution?

Accepted Answer

Use 'podman pod inspect webpod' to verify both containers are part of the pod; if not, remove and recreate the containers using '--pod webpod' correctly. Podman pods create a shared network namespace by default, enabling DNS-based container discovery. The ping failure indicates the containers are not sharing the same pod network namespace, likely due to a misconfiguration such as using 'podman run' without the '--pod' flag or a typo. Verifying with 'podman pod inspect webpod' and recreating the containers with '--pod webpod' ensures they are in the same pod, allowing DNS resolution of container names as hostnames.

Answer

Assign each container a unique hostname using the --hostname flag

Answer

Recreate both containers with --net=host to share the host's network stack

Answer

Add entries to the /etc/hosts file of the webserver container using --add-host database:$(podman inspect --format '{{.NetworkSettings.IPAddress}}' database)

Question 7

A production server running Red Hat Enterprise Linux 9 hosts multiple Podman containers. The system administrator wants to ensure that a critical container named 'payments' automatically starts when the host boots, even if no user is logged in. The administrator has already created a systemd service file at /etc/systemd/system/container-payments.service. The service file contains: [Unit] Description=Payments container [Service] ExecStart=/usr/bin/podman start -a payments ExecStop=/usr/bin/podman stop payments Type=forking Restart=always [Install] WantedBy=multi-user.target. After enabling the service with 'systemctl enable container-payments.service' and rebooting, the container does not start. The administrator checks 'systemctl status container-payments.service' and sees that the service is inactive (dead). What is the most likely reason and the correct fix?

Accepted Answer

Remove the manual unit and instead use 'podman generate systemd --new --name payments payments:latest' to create a proper systemd unit that includes container creation, then enable the generated service. The existing systemd unit file uses `ExecStart=/usr/bin/podman start -a payments`, which assumes the container already exists. On a fresh boot, Podman containers are not automatically recreated unless the systemd unit includes container creation. Using `podman generate systemd --new` produces a unit that includes `ExecStartPre` directives to create the container from the image before starting it, ensuring the container exists and starts on boot.

Answer

Configure podman auto-update to automatically start the container on boot

Answer

Add --restart=always to the ExecStart line in the existing unit file

Answer

Set RestartSec=0 in the [Service] section to eliminate any delay

Question 8

An administrator attempts to start a container with `podman run -d --name web -p 80:80 nginx`. The container fails to start and the logs show 'Error: cannot listen on port 80'. Which of the following is the most likely cause?

Accepted Answer

Port 80 is already in use on the host.. The error message 'cannot listen on port 80' is an application-level error, typically from nginx, indicating that the port it is trying to bind is already in use. If the container uses the default bridge networking, `-p 80:80` instructs podman to bind host port 80 and forward to container port 80. If the host port is already occupied, podman would fail immediately with a bind error before starting the container, so no container logs would exist. If the container starts but nginx logs this error, something else is bound to port 80 inside the container. Either way, the most likely cause among the options is that port 80 is already in use, making D the best answer.

Answer

SELinux is blocking the port.

Answer

The container image is corrupt.

Answer

The container is out of memory.

Question 9

A system administrator needs to ensure that data written to a container's `/var/lib/mysql` directory persists after the container is removed. Which TWO methods accomplish this requirement?

Accepted Answer

Create a named volume with `podman volume create` and mount it.. A named volume created with `podman volume create` is managed by Podman and persists independently of the container lifecycle. When mounted to `/var/lib/mysql`, data written to that directory is stored in the volume and remains available even after the container is removed. This is the recommended method for persistent data in production environments.

Answer

Use the `--read-only` flag.

Answer

Use the `--tmpfs` flag.

Answer

Use the `--rm` flag when running the container.

Question 10

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?

Accepted Answer

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

Answer

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.

Answer

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

Answer

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

Question 11

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?

Accepted Answer

podman start web1 && podman attach web1. `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.

Answer

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

Answer

podman start web1

Answer

podman restart web1 && podman attach web1

Question 12

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

Accepted Answer

--restart=unless-stopped. 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`).

Answer

--restart=on-failure

Answer

--restart=always

Answer

--restart=no

Question 13

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?

Accepted Answer

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

Answer

PODMAN_USER

Answer

ENV USER

Answer

RUN useradd

Question 14

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

Accepted Answer

podman start mycontainer. 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.

Answer

podman attach mycontainer

Answer

podman restart mycontainer

Answer

podman run mycontainer

Question 15

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?

Accepted Answer

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

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

Answer

Create a sysvinit script that calls podman commands.

Answer

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