Courseiva

CCNA Manage Containers Questions

50 questions · Manage Containers topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
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

Correct. This starts the existing container that exited.

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 →
2
Multi-Selecthard

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?

Select 2 answers
A.Use the `--read-only` flag.
B.Use the `--tmpfs` flag.
C.Create a named volume with `podman volume create` and mount it.
D.Mount a host directory using `-v /host/data:/var/lib/mysql`.
E.Use the `--rm` flag when running the container.
AnswersC, D

Named volumes are managed by Podman and persist even after the container is removed, unless explicitly deleted.

Why this answer

Options B and E are correct. Mounting a host directory (B) and using a named volume (E) both persist data outside the container's writable layer. Option A is incorrect because --rm removes the container and its anonymous volumes.

Option C is incorrect because --read-only makes the filesystem read-only, preventing writes. Option D is incorrect because --tmpfs creates a temporary in-memory filesystem that is lost when the container stops.

Practice this question →
3
Multi-Selecthard

A container is running but cannot be accessed from the network. Which TWO commands could help diagnose the issue? (Select exactly two.)

Select 2 answers
A.podman logs
B.podman port
C.podman inspect
D.podman exec
E.podman top
AnswersB, C

Shows which host ports are mapped to the container.

Why this answer

Option B is correct because `podman port` lists the port mappings for a container, showing which host ports are mapped to container ports. If a container is running but unreachable from the network, this command reveals whether the expected port mapping exists and is correctly configured. Without a proper mapping, external traffic cannot reach the container's service.

Exam trap

Red Hat often tests the distinction between commands that inspect container metadata (`podman inspect`) versus commands that interact with running processes (`podman exec`, `podman top`), leading candidates to choose the latter for network issues.

Practice this question →
4
MCQeasy

A system administrator wants to run a container that uses the rootless mode available in Podman. Which requirement must be met for rootless containers to work correctly?

A.The container must be run with the '--privileged' flag.
B.The user must have entries in /etc/subuid and /etc/subgid for user namespace mapping.
C.The system must have cgroups v2 enabled.
D.The user must have root privileges to run the container.
AnswerB

Subuid/subgid mappings are required for rootless containers to allocate UIDs/GIDs.

Why this answer

Rootless Podman containers require user namespace mapping to assign subordinate UIDs and GIDs from the host to the container. Without entries in /etc/subuid and /etc/subgid for the user, Podman cannot allocate the necessary ID ranges, and the container will fail to run in rootless mode.

Exam trap

Red Hat often tests the misconception that rootless containers require root privileges or special flags like '--privileged', when in fact they rely on user namespace mapping configured in /etc/subuid and /etc/subgid.

How to eliminate wrong answers

Option A is wrong because the '--privileged' flag grants elevated capabilities and disables user namespace isolation, which is the opposite of what rootless mode requires. Option C is wrong because cgroups v2 is not a strict requirement for rootless containers; Podman can use cgroups v1 with rootless mode, though v2 is recommended for better resource management. Option D is wrong because rootless mode explicitly allows non-root users to run containers, so requiring root privileges contradicts the purpose of rootless containers.

Practice this question →
5
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

Correct. The USER instruction sets the active user for subsequent instructions.

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 →
6
MCQmedium

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?

A.Assign each container a unique hostname using the --hostname flag
B.Recreate both containers with --net=host to share the host's network stack
C.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
D.Add entries to the /etc/hosts file of the webserver container using --add-host database:$(podman inspect --format '{{.NetworkSettings.IPAddress}}' database)
AnswerC

The most likely cause is that the containers were not properly added to the same pod; inspecting the pod will confirm their membership, and recreating them with the correct flag will enable automatic DNS resolution.

Why this answer

Option C is correct because 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.

Exam trap

Red Hat often tests the misconception that container-to-container communication requires manual IP or host configuration, when in fact Podman pods provide automatic DNS resolution for container names within the same pod.

How to eliminate wrong answers

Option A is wrong because the --hostname flag sets the container's internal hostname, but DNS resolution within a pod relies on the pod's shared network namespace and the embedded DNS resolver (e.g., aardvark-dns), not individual hostnames. Option B is wrong because --net=host bypasses the pod's network namespace entirely, breaking pod-level DNS and defeating the purpose of using a pod; it also exposes containers directly on the host network, which is not the intended solution. Option D is wrong because manually adding /etc/hosts entries is unnecessary and fragile; Podman pods automatically provide DNS resolution for container names within the pod, and the IP address may change on container restart, making this approach unreliable.

Practice this question →
7
MCQhard

An administrator is building a container image with a Containerfile. They want to ensure that a specific RUN command always executes without using the build cache. Which build option should they use?

A.--layers=false
B.--squash
C.--force-rm
D.--no-cache
AnswerD

Correct. This disables the build cache entirely.

Why this answer

Option D is correct because the `--no-cache` build option instructs Podman or Docker to rebuild every layer from scratch, ignoring any cached intermediate layers. This ensures that the specific RUN command always executes fresh, which is essential when the command's outcome depends on dynamic external data or must not reuse stale cached results.

Exam trap

Red Hat often tests the distinction between cache-related flags and cleanup-related flags, so candidates may confuse `--no-cache` with `--force-rm` or mistakenly think `--squash` disables caching.

How to eliminate wrong answers

Option A is wrong because `--layers=false` is not a valid build option in Podman or Docker; the correct flag to disable layer caching is `--no-cache`. Option B is wrong because `--squash` merges all filesystem layers into a single layer after the build completes, but it does not prevent the use of the build cache during the build process. Option C is wrong because `--force-rm` forces removal of intermediate containers after a successful build, but it does not affect whether cached layers are used for RUN commands.

Practice this question →
8
MCQhard

A container running a database service needs to persist data across restarts. The administrator decides to use a named volume. Which command creates a named volume and mounts it correctly?

A.podman run -v /var/lib/mysql:/var/lib/mysql mydb
B.podman volume create dbdata && podman run -v dbdata:/var/lib/mysql mydb
C.podman run --mount type=bind,src=dbdata,dst=/var/lib/mysql mydb
D.podman run --mount type=tmpfs,dst=/var/lib/mysql mydb
AnswerB

Creates a named volume and mounts it correctly.

Why this answer

Option B is correct because it first creates a named volume with `podman volume create dbdata`, then mounts that named volume to the container's `/var/lib/mysql` directory using the `-v` flag. Named volumes are managed by Podman and persist data independently of the container lifecycle, ensuring data survives container restarts or removal.

Exam trap

The trap here is that candidates confuse bind mounts with named volumes, assuming `-v` always creates a named volume when the source is not an absolute path, but Podman treats a non-absolute source as a host-relative path or volume name depending on context, and the exam tests the explicit use of `podman volume create` for named volumes.

How to eliminate wrong answers

Option A is wrong because `-v /var/lib/mysql:/var/lib/mysql` creates a bind mount from a host directory, not a named volume; this requires the host path to exist and does not leverage Podman's volume management. Option C is wrong because `--mount type=bind,src=dbdata,dst=/var/lib/mysql` specifies a bind mount, not a named volume; `src=dbdata` is interpreted as a host directory path, not a volume name. Option D is wrong because `--mount type=tmpfs` creates a temporary filesystem in memory, which does not persist data across container restarts or host reboots.

Practice this question →
9
Multi-Selecthard

A containerized application requires persistent storage and must be able to run with SELinux enforcing. The administrator runs a container with the volume mount: `podman run -v /host/data:/container/data:Z myimage`. Which TWO statements are true about this configuration?

Select 2 answers
A.The SELinux context of files in /host/data remains unchanged.
B.The /host/data directory is created automatically if it does not exist.
C.The volume mount persists after the container is removed.
D.The container cannot write to /container/data if SELinux is enforcing.
E.Files in /host/data will be relabeled with a container-specific SELinux context.
AnswersC, E

Bind mounts persist independent of container lifecycle.

Why this answer

Option C is correct because the `-v` flag with a bind mount persists the data in `/host/data` on the host filesystem even after the container is removed. The `:Z` flag tells Podman to relabel the host directory with a container-specific SELinux context, which is why Option E is also correct. This ensures the container can write to the mount point even when SELinux is enforcing.

Exam trap

The trap here is that candidates confuse the `:Z` (relabel for single container) and `:z` (relabel for shared use) flags, or assume SELinux enforcing always blocks writes, missing that the `:Z` flag explicitly enables write access by relabeling.

Practice this question →
10
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

This generates a proper systemd unit file with correct dependencies and restart behavior.

Why this answer

Option D is correct because `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 →
11
MCQmedium

A developer reports that a container running a custom web application is failing to start on a Red Hat Enterprise Linux 8 host. The container image is built from a Dockerfile that uses 'EXPOSE 8080'. The host firewall is enabled. Which action is most likely required to allow external access to the application?

A.Start the container with the '-p 8080:8080' option to publish the port.
B.Open port 8080 in the host firewall using firewall-cmd.
C.Disable the host firewall to allow all incoming traffic.
D.Ensure the container image includes an EXPOSE instruction for port 8080.
AnswerA

Publishing the container port with '-p' makes it accessible through the host.

Why this answer

The container image's EXPOSE 8080 instruction is metadata that documents the intended port but does not actually publish it. To make the container's port 8080 accessible from the host's network, you must use the '-p 8080:8080' option when starting the container with 'podman run' or 'docker run'. This creates a port mapping from the host's port 8080 to the container's port 8080, allowing external traffic to reach the application.

Exam trap

The trap here is that candidates often confuse the EXPOSE instruction (which is just metadata) with actual port publishing, leading them to think the port is automatically accessible or that firewall changes are the primary fix.

How to eliminate wrong answers

Option B is wrong because the host firewall is not the primary issue; even if port 8080 is opened in the firewall, the container's port is not mapped to the host, so traffic cannot reach the container. Option C is wrong because disabling the firewall is an insecure and unnecessary step; the correct approach is to publish the port while keeping the firewall enabled and properly configured. Option D is wrong because the EXPOSE instruction is already present in the Dockerfile and does not affect runtime port publishing; it only serves as documentation.

Practice this question →
12
Drag & Dropmedium

Put the steps to configure NFS server to export /nfsshare to a specific client in order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

NFS export configuration involves creating the directory, editing /etc/exports, exporting, and starting services.

Practice this question →
13
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'.
AnswerA

This integrates with systemd for boot-start and restart, and allows non-root user via '--user' in the container.

Why this answer

Option A is correct because 'podman generate systemd' creates a systemd service unit file that integrates Podman containers with systemd's process management, enabling automatic restart on crash via systemd's restart behavior (e.g., Restart=always) and boot-start with 'systemctl enable --now'. The volume mount (-v /var/log/app:/var/log) persists logs on the host, and the port mapping (-p 443:443) exposes HTTPS. This approach meets all requirements: non-root user (specified in the container image or via --user), dynamic config file (generated at startup and mounted or injected), and systemd-managed restart.

Exam trap

The trap here is that candidates confuse Podman's '--restart' flag (which is not supported) with Docker's restart policies, or assume 'podman service create' is a valid command, when the correct approach is to generate a systemd unit file with 'podman generate systemd' and manage the container via systemd.

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 →
14
Multi-Selectmedium

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

Select 3 answers
A.Podman volumes can only be managed by podman volume commands, not manually.
B.The --storage-opt flag can be used to set options for the container's writable layer.
C.Rootless containers cannot use the overlay filesystem driver.
D.Bind mounts mount a host directory into the container.
E.Container images are stored in layers, each representing a set of filesystem changes.
AnswersB, D, E

Allows advanced storage configuration.

Why this answer

Option B is correct because 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.

Exam trap

Red Hat often tests the misconception that rootless containers cannot use overlay filesystems, but in modern Linux kernels (5.11+) with `userxattr` or via `fuse-overlayfs`, rootless overlay is fully supported.

Practice this question →
15
MCQmedium

Based on the exhibit, which statement about the container 'webserver' is true?

A.Container port 80 is mapped to host port 8080.
B.The container uses the host network.
C.Container port 8080 is mapped to host port 80.
D.No port mapping exists.
AnswerA

Correct. The output shows container port 80/tcp with HostPort 8080.

Why this answer

The exhibit shows the container 'webserver' with port mapping '0.0.0.0:8080->80/tcp'. This indicates that host port 8080 is mapped to container port 80, meaning traffic arriving at the host on port 8080 is forwarded to port 80 inside the container. Therefore, option A is correct.

Exam trap

The trap here is that candidates often confuse the order of port mapping, thinking the first number is the container port and the second is the host port, when in fact the syntax is `host_port:container_port`.

How to eliminate wrong answers

Option B is wrong because the container uses bridge networking by default (as seen by the port mapping syntax), not host networking; host networking would show '--network host' and no port mapping. Option C is wrong because it reverses the mapping: the exhibit shows host port 8080 to container port 80, not container port 8080 to host port 80. Option D is wrong because the exhibit explicitly shows a port mapping (0.0.0.0:8080->80/tcp), so port mapping does exist.

Practice this question →
16
MCQeasy

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?

A.Use a bind mount (e.g., --volume /host/data:/container/data)
B.Use the --rm flag when running the container
C.Use a Podman volume (e.g., --volume myvol:/container/data)
D.Use a tmpfs mount (e.g., --tmpfs /container/data)
AnswerC

Podman volumes are fully managed by Podman, persist across container lifecycles, and are easy to back up or migrate.

Why this answer

Option C is correct because 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 backup` 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.

Exam trap

The trap here is that candidates confuse bind mounts (Option A) with Podman volumes, assuming both are equally managed, but bind mounts require explicit host path management and lack Podman's lifecycle commands, making them less suitable for automated backup and portability scenarios tested in EX200.

How to eliminate wrong answers

Option A is wrong because a bind mount directly maps a host directory into the container, which ties the data to a specific host path and requires manual management of permissions and backups; it does not leverage Podman's managed storage layer. Option B is wrong because the `--rm` flag automatically removes the container and its writable layer upon exit, but it does not affect volumes or persistent data; it is used for ephemeral containers, not for ensuring data survival. Option D is wrong because a tmpfs mount stores data in the host's memory (RAM), which is volatile and lost when the container stops or the host reboots; it is not suitable for persistent data that must survive container removal.

Practice this question →
17
Multi-Selectmedium

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?

Select 2 answers
A.Change the FROM line to use ubi9/ubi (Red Hat Universal Base Image 9)
B.Add a specific tag to the FROM line, e.g., ubi8/ubi:8.4
C.Add an EXPOSE 80 instruction before the CMD
D.Change yum to dnf in the RUN instruction
E.Add a second COPY instruction to copy the container configuration files
AnswersB, D

The FROM line should include a tag to pin the image version; otherwise, Podman defaults to 'latest' which may not exist or be unintended.

Why this answer

Option A is needed because the FROM line must specify a tag (e.g., ubi8/ubi:latest or a specific version) to avoid ambiguity. Option B is required because Red Hat Enterprise Linux 8 uses dnf instead of yum for package installation. Option C (EXPOSE 80) is not required to fix the build failure; it is documentation for port mapping.

Option D (changing FROM to ubi9) is not necessary; the issue is the missing tag, not the base image version. Option E (adding COPY) already exists; an additional COPY is not needed to fix the build.

Practice this question →
18
MCQmedium

A system administrator needs to run a container that remains running in the background and executes a web server. Which podman command will correctly run the container detached and map host port 8080 to container port 80?

A.podman run -d -p 8080:80 nginx
B.podman run -d -p 80:8080 nginx
C.podman run -d --expose 80 nginx
D.podman run -d -P 8080:80 nginx
AnswerA

Correct: -d for detached, -p 8080:80 maps host 8080 to container 80.

Why this answer

Option A is correct because `podman run -d` runs the container in detached mode (background), and `-p 8080:80` maps host port 8080 to container port 80, which is the standard port for the nginx web server. This allows external traffic on host port 8080 to be forwarded to the nginx service inside the container.

Exam trap

The trap here is confusing the order of the port mapping (`host_port:container_port`) with the reverse, and mistaking `--expose` for a functional port publishing mechanism instead of a documentation-only flag.

How to eliminate wrong answers

Option B is wrong because it maps host port 80 to container port 8080, which would not serve the web server (nginx listens on port 80 by default) and would require the container to be configured to listen on port 8080. Option C is wrong because `--expose 80` only documents that port 80 is exposed in the container metadata but does not publish any ports to the host, so the web server would not be accessible from outside. Option D is wrong because `-P` (capital P) automatically publishes all exposed ports to random high-numbered host ports, and the syntax `-P 8080:80` is invalid; `-P` does not accept a port mapping argument.

Practice this question →
19
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

Exec format error often occurs before the application produces any output; logs appear empty.

Why this answer

Option A is correct because 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 →
20
MCQeasy

A container fails to start because the port it needs is already in use. Which command can the administrator use to identify the process using the port?

A.podman logs <container>
B.ss -tlnp
C.podman port -l
D.firewall-cmd --list-ports
AnswerB

Correct. This displays listening ports and the associated process IDs.

Why this answer

Option B is correct because the `ss -tlnp` command displays listening TCP sockets (`-t`), numeric addresses (`-n`), and the associated process information (`-p`). This allows the administrator to identify which process (PID and program name) is bound to a specific port, directly addressing the container startup failure caused by a port conflict.

Exam trap

The trap here is that candidates often think `podman port -l` or `podman logs` can diagnose host-level port conflicts, but these commands only show container-specific information and cannot identify processes outside the container namespace.

How to eliminate wrong answers

Option A is wrong because `podman logs <container>` shows the log output of a container, not the processes using ports on the host; it cannot identify which external process is occupying the port. Option C is wrong because `podman port -l` lists port mappings for the last created container, but it does not show which process on the host is using a port; it only shows the container's port bindings. Option D is wrong because `firewall-cmd --list-ports` lists ports opened in the firewall configuration, not the actual processes or sockets using those ports; a port can be in use by a process even if it is not listed in the firewall rules.

Practice this question →
21
MCQmedium

Refer to the exhibit. A user attempts to start a new container named 'web3' but receives an error. The user wants to reuse the name 'web3'. Which command should be run first to resolve the issue?

A.podman rmi registry.access.redhat.com/ubi8/nginx-118
B.podman rm web3
C.podman kill web2
D.podman stop web1
AnswerB

Removes the existing container named web3, freeing the name.

Why this answer

The error occurs because a container named 'web3' already exists, even if it is not running. To reuse the name, the existing container must be removed first. Option B, `podman rm web3`, removes the stopped container, freeing the name for a new container.

Exam trap

Red Hat often tests the distinction between container removal (`podman rm`) and image removal (`podman rmi`), leading candidates to mistakenly try to delete the image when the actual conflict is a container name.

How to eliminate wrong answers

Option A is wrong because `podman rmi` removes an image, not a container; the issue is a container name conflict, not an image conflict. Option C is wrong because `podman kill web2` sends a SIGKILL to a running container named 'web2', which does not affect the existing 'web3' container. Option D is wrong because `podman stop web1` gracefully stops a container named 'web1', which is unrelated to the 'web3' name conflict.

Practice this question →
22
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

Start the stopped container, then attach to it.

Why this answer

Option D is correct because `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 trap here is that candidates may confuse `podman restart` (which stops and starts the container) with `podman start` (which directly resumes an exited container), or forget that `podman start` alone does not attach to the console, leading them to choose option B or C.

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 →
23
Matchingmedium

Match each log file to its typical content.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

General system log (most non-critical messages)

Authentication and security events

Audit records from auditd

Cron job execution logs

Why these pairings

These log files are commonly monitored by sysadmins.

Practice this question →
24
MCQeasy

An administrator needs to list all container images stored locally, including intermediate layers. Which command should be used?

A.podman images -q
B.podman images --all
C.podman images --no-trunc
D.podman images -a
AnswerD

Correct. The -a flag shows all images including intermediate layers.

Why this answer

Option D (`podman images -a`) is correct because the `-a` (or `--all`) flag instructs Podman to list all images in the local storage, including intermediate layers that are not tagged and are used as building blocks for other images. Without this flag, only top-level (tagged) images are shown, which would omit the intermediate layers the administrator needs to see.

Exam trap

The trap here is that candidates confuse `-a` (all images including intermediates) with `-q` (quiet mode) or `--no-trunc` (full output), mistakenly thinking those flags also reveal hidden layers.

How to eliminate wrong answers

Option A (`podman images -q`) is wrong because the `-q` flag only shows image IDs in quiet mode, not a full listing, and it does not include intermediate layers. Option B (`podman images --all`) is wrong because `--all` is not a valid flag for `podman images`; the correct equivalent is `-a` or `--all` is actually accepted in some versions, but the standard syntax is `-a` and the option is listed as `-a` in the EX200 objectives. Option C (`podman images --no-trunc`) is wrong because `--no-trunc` prevents truncation of output (e.g., showing full image IDs), but it does not affect whether intermediate layers are included; it only changes the display format.

Practice this question →
25
Multi-Selecthard

Which THREE actions are required to enable a non-root user to run containers using Podman on Red Hat Enterprise Linux 8?

Select 3 answers
A.Ensure the user has a running systemd user instance (loginctl enable-linger).
B.Configure subordinate UID and GID ranges for the user in /etc/subuid and /etc/subgid.
C.Add the user to the 'docker' group to access the Docker socket.
D.Enable user namespaces in the kernel if not already enabled.
E.Grant the user sudo privileges to run podman commands.
AnswersA, B, D

Enables systemd --user for managing containers.

Why this answer

Option A is correct because `loginctl enable-linger` ensures that the user's systemd user instance starts at boot and remains running after the user logs out. This is required for Podman to manage containers using systemd user services, such as auto-starting containers with `podman generate systemd`.

Exam trap

The trap here is that candidates may think adding a user to the 'docker' group is required for Podman, but Podman uses a different architecture (no daemon, no socket) and relies on user namespaces and subordinate ID ranges for rootless operation.

Practice this question →
26
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 the image creates a new image with the file, which will be used when the service starts the container.

Why this answer

Option D is correct because 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 →
27
MCQmedium

A container running a web server exits immediately after starting. The administrator runs 'podman logs <container>' and sees 'Error: listen tcp :80: bind: address already in use'. What is the most likely cause and solution?

A.The host port 80 is occupied; use -p 8080:80 to map a different host port.
B.SELinux is preventing the container from binding to the port; set enforce to permissive.
C.The container does not have network access; add --network host.
D.The firewall is blocking outbound connections; disable firewalld.
AnswerA

Error clearly states address already in use; remapping host port resolves it.

Why this answer

The error 'address already in use' indicates that port 80 on the host is already occupied by another process. By default, Podman maps container port 80 to host port 80. Using `-p 8080:80` maps the container's port 80 to an unused host port 8080, resolving the conflict without changing the container's internal configuration.

Exam trap

Red Hat often tests the misconception that SELinux or firewall rules are the cause of port binding errors, when in fact the error message 'address already in use' explicitly points to a port conflict that must be resolved by changing the host port mapping.

How to eliminate wrong answers

Option B is wrong because SELinux does not produce 'address already in use' errors; it would generate AVC denial messages, and setting it to permissive is unnecessary and insecure for this issue. Option C is wrong because the container already has network access (it attempted to bind), and `--network host` would share the host's network stack, which would still conflict with the occupied port 80. Option D is wrong because the firewall does not cause 'address already in use' errors; it blocks traffic at the network layer, not bind operations, and disabling it would not free the occupied port.

Practice this question →
28
MCQmedium

An administrator needs to pass environment variables from the host to a container without exposing them in the command line. Which method should be used?

A.--env
B.--env-file
C.--secret
D.-e
AnswerB

Correct. It reads variables from a file, avoiding command line exposure.

Why this answer

Option B (--env-file) is correct because it allows environment variables to be passed to a container by reading them from a file, avoiding exposure in the command line or process list. This method is secure as the file can be restricted with file permissions, and the variables are not visible in commands like `ps aux` or shell history.

Exam trap

Red Hat often tests the distinction between `--env`/`-e` and `--env-file`, where candidates mistakenly choose `-e` because it is the most common flag, overlooking the security requirement to avoid command-line exposure.

How to eliminate wrong answers

Option A is wrong because `--env` is a valid flag for setting environment variables but it requires the variable to be specified directly in the command line, which exposes it to process listings and shell history. Option C is wrong because `--secret` is not a valid Docker or Podman flag for passing environment variables; secrets are managed via dedicated secret mechanisms (e.g., Docker secrets or Podman secrets) and are not used for general environment variable injection. Option D is wrong because `-e` is a shorthand for `--env` and similarly exposes the variable value in the command line, failing the requirement to avoid exposure.

Practice this question →
29
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

Generating a systemd user service allows the container to be managed independently of the user session; enabling lingering ensures the user's systemd instance persists, and the service keeps the container running after logout.

Why this answer

Option D is correct because 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 →
30
Multi-Selecteasy

Which TWO options to podman run can be used to persist data outside the container? (Select exactly two.)

Select 2 answers
A.--mount
B.--read-only
C.--tmpfs
D.-v
E.--squash
AnswersA, D

Also creates mounts, with more options.

Why this answer

The `--mount` option (A) and `-v` (D) are both used to mount host directories or volumes into a container, allowing data to persist outside the container's writable layer. `--mount` provides a more explicit syntax for specifying mount type, source, and destination, while `-v` is a shorter alias for `--volume` that also binds host paths or named volumes. Both ensure data survives container removal.

Exam trap

Red Hat often tests the distinction between ephemeral storage options like `--tmpfs` and persistent storage options like `--mount`/`-v`, and candidates mistakenly select `--tmpfs` thinking it persists data because it is writable, but it is memory-backed and lost on container stop.

Practice this question →
31
Multi-Selectmedium

Which TWO statements are true regarding container images and containers in Podman?

Select 2 answers
A.A container can only be created from an image that is stored locally.
B.A container is a running or stopped instance of an image with a writable layer.
C.A container image is a read-only template used to create containers.
D.When a container is stopped, its writable layer is automatically removed.
E.A container image must be built using a Dockerfile.
AnswersB, C

Correct: containers have a writable layer on top of the image.

Why this answer

Option B is correct because a container in Podman is an instantiation of an image that adds a writable layer on top of the image's read-only layers. This writable layer persists changes made during the container's runtime, even after the container is stopped, unless explicitly removed.

Exam trap

Red Hat often tests the misconception that a container's writable layer is ephemeral and automatically deleted when the container stops, but in Podman (and Docker) the writable layer persists until the container is explicitly removed.

Practice this question →
32
MCQmedium

A containerized application writes logs to stdout. The administrator wants to view only the last 50 lines of logs from a container named 'app1'. Which command accomplishes this?

A.podman logs --lines 50 app1
B.podman logs app1
C.podman logs -n 50 app1
D.podman logs --tail 50 app1
AnswerD

--tail specifies number of lines from the end.

Why this answer

The `podman logs --tail 50 app1` command is correct because `--tail` is the Podman option to specify the number of lines from the end of the log to display. This directly fulfills the requirement to view only the last 50 lines of logs from the container named 'app1'.

Exam trap

The trap here is that candidates may confuse `--tail` with `--lines` or `-n`, which are common in other tools like `tail` or `kubectl logs`, but Podman specifically uses `--tail` for this purpose.

How to eliminate wrong answers

Option A is wrong because `--lines` is not a valid option for `podman logs`; Podman uses `--tail` to specify the number of lines from the end. Option B is wrong because `podman logs app1` without any options displays all logs from the container, not just the last 50 lines. Option C is wrong because `-n` is not a valid shorthand for `--tail` in `podman logs`; the correct shorthand is `-t` for timestamps, and `-n` is not recognized for line count.

Practice this question →
33
MCQmedium

An administrator wants to run a container with --user 1001:1001 to avoid running as root. After starting, the container cannot write to a bind-mounted directory owned by root. What is the best practice to allow write access?

A.Run the container with --privileged.
B.Add the user 1001 on the host to the root group.
C.Use 'podman unshare chown 1001:1001 /host/dir' to change host directory ownership.
D.Set setuid bit on the host directory.
AnswerC

This changes UID/GID on the host to match the container user, allowing write.

Why this answer

Option C is correct because `podman unshare chown 1001:1001 /host/dir` changes the ownership of the host directory to UID/GID 1001, matching the container's user. This is the best practice in rootless Podman environments, as it avoids running the container with elevated privileges while ensuring the container user can write to the bind-mounted directory.

Exam trap

The trap here is that candidates often choose `--privileged` or setuid as a quick fix, not realizing that rootless Podman requires explicit ownership changes via `podman unshare` to maintain security and proper UID mapping.

How to eliminate wrong answers

Option A is wrong because `--privileged` grants the container all capabilities and access to host devices, which defeats the purpose of running as a non-root user and introduces unnecessary security risks. Option B is wrong because adding user 1001 to the root group on the host does not grant write access to a directory owned by root unless the directory's group permissions allow it (e.g., 775), and it violates the principle of least privilege. Option D is wrong because setting the setuid bit on the host directory does not affect write permissions for a non-root container user; setuid is for executable files, not directories, and does not change ownership for file creation.

Practice this question →
34
Multi-Selecteasy

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

Select 2 answers
A.podman exec <container> ls / runs the ls command inside the running container.
B.podman exec can run commands as a different user with --user.
C.podman exec -it <container> /bin/bash attaches to an existing shell process.
D.podman exec can start a stopped container.
E.podman exec -it <container> /bin/bash runs an interactive shell in a new container.
AnswersA, B

Correct: runs command in existing container.

Why this answer

Option A is correct because `podman exec <container> 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.

Exam trap

The trap here is confusing `podman exec` (which runs a new process in an existing running container) with `podman attach` (which connects to an existing process) or `podman run` (which creates a new container), leading candidates to incorrectly select options about attaching to existing shells or starting stopped containers.

Practice this question →
35
MCQhard

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?

A.Configure podman auto-update to automatically start the container on boot
B.Add --restart=always to the ExecStart line in the existing unit file
C.Set RestartSec=0 in the [Service] section to eliminate any delay
D.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
AnswerD

The podman generate systemd --new command creates a service unit that automatically creates and starts the container, ensuring it exists and is managed correctly by systemd. The manual unit fails because the container may not exist or the start command is not appropriate for boot-time startup.

Why this answer

Option D is correct because 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.

Exam trap

The trap here is that candidates assume a manually written systemd unit with `ExecStart=/usr/bin/podman start` will work, but they overlook that Podman containers do not survive a reboot unless the unit also creates the container, which is exactly what `podman generate systemd --new` does.

How to eliminate wrong answers

Option A is wrong because `podman auto-update` is used to update containers to newer images, not to start containers on boot. Option B is wrong because adding `--restart=always` to the ExecStart line is not a valid Podman flag; Podman's restart policy is set via `--restart` when running the container, not in the systemd ExecStart command. Option C is wrong because `RestartSec=0` controls the delay between restart attempts by systemd, but the core issue is that the container does not exist after reboot, so no amount of restart timing will fix a missing container.

Practice this question →
36
MCQhard

An administrator needs to ensure that a container always runs with a specific SELinux context for security reasons. The container uses a volume mount from the host. Which command should be used to start the container?

A.podman run --label selinux_context=container_t -v /host/data:/data myimage
B.podman run --privileged -v /host/data:/data myimage
C.podman run --selinux-context container_t -v /host/data:/data myimage
D.podman run --security-opt label=type:container_t -v /host/data:/data myimage
AnswerD

'--security-opt label=type:container_t' correctly sets the SELinux context for the container.

Why this answer

Option D is correct because `--security-opt label=type:container_t` explicitly sets the SELinux type for the container process to `container_t`, ensuring the container runs with the required SELinux context. This is the proper way to assign a specific SELinux type when using `podman run`, especially when volume mounts are involved, as it avoids permission conflicts with the host's SELinux policy.

Exam trap

The trap here is that candidates often confuse `--label` (for metadata) with SELinux labeling, or assume `--privileged` is a quick fix for SELinux issues, but the exam specifically tests the correct `--security-opt label=type:` syntax for setting SELinux contexts in Podman.

How to eliminate wrong answers

Option A is wrong because `--label` is used to add metadata labels to the container (e.g., for Podman or Docker), not to set SELinux contexts; `selinux_context` is not a valid option for `--label`. Option B is wrong because `--privileged` grants the container full access to the host, including disabling SELinux enforcement, which bypasses the requirement to run with a specific SELinux context and is insecure. Option C is wrong because `--selinux-context` is not a valid flag in Podman; the correct syntax uses `--security-opt label=type:` to specify the SELinux type.

Practice this question →
37
MCQhard

An administrator creates a pod named 'webpod' containing two containers: 'nginx' and 'logger'. The goal is for the nginx container to access the logger container via hostname 'logger'. Which network configuration is required?

A.No special configuration; containers in a pod can communicate via container names.
B.Use 'podman network create' and connect both containers to that network.
C.Set environment variable LOGGER_HOST in nginx container.
D.Create a network with --internal and --ip-range.
AnswerA

Podman pods provide shared network namespace; containers can resolve each other.

Why this answer

In Kubernetes (and by extension, OpenShift, which is the focus of EX200), containers within the same Pod share the same network namespace. This means they can communicate with each other using localhost or, more commonly, the container name as a hostname, which is resolved via the Pod's internal DNS or /etc/hosts. No additional network configuration is required for inter-container communication within a Pod.

Exam trap

The trap here is that candidates confuse standalone container networking (e.g., Podman or Docker) with Kubernetes Pod networking, assuming they need to create a custom network or use environment variables for inter-container communication, when in fact the shared network namespace handles it automatically.

How to eliminate wrong answers

Option B is wrong because 'podman network create' is used for Podman standalone containers, not for containers within a Kubernetes Pod; Pods have an implicit shared network namespace. Option C is wrong because setting an environment variable like LOGGER_HOST is not a network configuration and does not enable hostname resolution; the nginx container can already reach the logger container via the hostname 'logger' without any environment variables. Option D is wrong because creating a network with --internal and --ip-range is unnecessary and would isolate the Pod from external networks, which is not the goal; the default Pod network already supports inter-container communication.

Practice this question →
38
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 HostIp 0.0.0.0 means the port is exposed on every network interface of the host.

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 →
39
MCQeasy

An administrator needs to pull a container image from a private registry at registry.example.com:5000. The registry requires authentication. Which command should be used first?

A.podman login registry.example.com:5000
B.podman tag registry.example.com:5000/myimage
C.podman images
D.podman pull registry.example.com:5000/myimage
AnswerA

Authenticates to the registry, then pull can succeed.

Why this answer

Option A is correct because `podman login` authenticates the user to the specified private registry (registry.example.com:5000) before any pull or push operation. Without prior authentication, Podman cannot access the registry's content, and the pull command will fail with an authentication error.

Exam trap

Red Hat often tests the prerequisite step of authentication before interacting with a private registry, and the trap here is that candidates may jump directly to `podman pull` (option D) thinking it will prompt for credentials, but Podman does not prompt interactively in non-TTY environments and requires explicit prior login.

How to eliminate wrong answers

Option B is wrong because `podman tag` is used to assign a new name or alias to an existing local image, not to authenticate or pull from a registry; it requires a source image and a target tag. Option C is wrong because `podman images` lists only locally stored images and does not interact with remote registries or handle authentication. Option D is wrong because `podman pull registry.example.com:5000/myimage` attempts to download the image directly, but without prior authentication (via `podman login`), the pull will fail if the registry requires credentials.

Practice this question →
40
MCQmedium

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?

A.SELinux is blocking the port.
B.The container image is corrupt.
C.The container is out of memory.
D.Port 80 is already in use on the host.
AnswerD

The error 'cannot listen on port 80' directly indicates the port is occupied by another process or container.

Why this answer

Option D is correct because the error message 'cannot listen on port 80' indicates that the host's port 80 is already bound by another process. The `-p 80:80` flag maps host port 80 to container port 80, and if another service (e.g., another container or a system daemon like httpd) is already using that port, `podman run` will fail immediately. This is a common port conflict scenario in container management.

Exam trap

The trap here is that candidates may assume SELinux is the cause of all port-related failures in Red Hat environments, but the specific error message 'cannot listen on port 80' directly points to a port conflict, not a MAC policy denial.

How to eliminate wrong answers

Option A is wrong because SELinux blocking the port would typically produce an AVC denial message in the audit log (e.g., 'Permission denied' or 'Operation not permitted'), not a 'cannot listen on port 80' error; SELinux does not prevent binding to a port that is already in use. Option B is wrong because a corrupt container image would cause errors during image pull or extraction (e.g., 'layer not found' or 'checksum mismatch'), not a port binding failure at container start. Option C is wrong because out-of-memory (OOM) conditions result in the container being killed by the kernel OOM killer, producing a '137' exit code or 'container process exited' message, not a specific 'cannot listen on port 80' error.

Practice this question →
41
Multi-Selectmedium

Which THREE options to podman run can be used to publish container ports to the host? (Select exactly three.)

Select 3 answers
A.-p
B.--publish
C.--expose
D.-P
E.--port
AnswersA, B, D

Maps a container port to a host port.

Why this answer

Option A (-p) is correct because it is the short form of --publish, which maps a container port to a host port. Option B (--publish) is the long form of -p and explicitly publishes container ports to the host. Option D (-P) is correct because it publishes all exposed container ports to random high-numbered ports on the host (typically in the range 32768-60999).

Exam trap

Red Hat often tests the distinction between --expose (which does not publish ports) and -p/--publish (which does), and the fact that --port is not a valid podman option, causing candidates to confuse it with the correct --publish flag.

Practice this question →
42
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

The correct approach is to identify the conflicting process, stop it if possible, or map the container to an unused host port (e.g., -p 8080:80).

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 →
43
MCQeasy

An administrator needs to run a container with a bind mount of the host directory /data to /var/lib/data inside the container. The container image is web:latest. Which command correctly achieves this?

A.podman run -V /data:/var/lib/data web:latest
B.podman run -v /data:/var/lib/data web:latest
C.podman run -v /var/lib/data:/data web:latest
D.podman run -v /data::/var/lib/data web:latest
AnswerB

Correct syntax: host directory /data mounted to container path /var/lib/data.

Why this answer

Option B is correct because the `-v` flag in Podman creates a bind mount from the host directory `/data` to the container directory `/var/lib/data`. The syntax `-v /host/path:/container/path` is the standard way to specify a bind mount, and this command correctly maps the host directory to the intended container path.

Exam trap

The trap here is that candidates often confuse the order of paths in the bind mount syntax, incorrectly placing the container path before the host path, or they mistakenly use an invalid flag like `-V` instead of the correct `-v`.

How to eliminate wrong answers

Option A is wrong because it uses the uppercase `-V` flag, which is not a valid Podman option; Podman uses lowercase `-v` for volume or bind mount operations. Option C is wrong because it reverses the bind mount syntax, mapping the host directory `/var/lib/data` to the container directory `/data`, which does not match the requirement of mounting `/data` to `/var/lib/data`. Option D is wrong because it contains an extra colon (`::`) in the mount specification, which is syntactically incorrect and would cause Podman to fail with an invalid argument error.

Practice this question →
44
MCQhard

A database container crashes repeatedly. The administrator wants to see the last 10 lines of the container's logs before it exited. Which command should be used?

A.podman logs --tail 10 <container>
B.podman logs -f <container>
C.podman logs --since 10m <container>
D.podman inspect <container>
AnswerA

Correct. Displays the last 10 lines of logs.

Why this answer

The `podman logs --tail 10 <container>` command retrieves the last 10 lines of the container's log output, which is exactly what the administrator needs to see the final log entries before the container exited. The `--tail` flag specifies the number of lines from the end of the log, making it ideal for troubleshooting a crash without viewing the entire log history.

Exam trap

The trap here is that candidates confuse `--tail` with `-f` (follow) or `--since`, thinking they all show recent logs, but only `--tail` precisely limits output to the last N lines of the container's entire log history.

How to eliminate wrong answers

Option B is wrong because `podman logs -f` follows (tails) the log output in real time, which is useful for live monitoring but does not show only the last 10 lines of the exited container's logs. Option C is wrong because `podman logs --since 10m` shows log entries from the last 10 minutes, which may include many lines or miss the final crash logs if the container exited more than 10 minutes ago. Option D is wrong because `podman inspect` returns detailed metadata about the container (e.g., configuration, state, mounts) but does not display log content.

Practice this question →
45
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

Correct. This ensures restart unless the container is explicitly stopped.

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

The trap here is that candidates often confuse `--restart=always` with `--restart=unless-stopped`, assuming 'always' means 'always unless I stop it', but in Podman (and Docker), `always` will restart the container even after a manual stop, which is not the behavior described in the question.

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 →
46
MCQeasy

Which file should be present in a directory to build a container image using 'podman build'?

A.docker-compose.yml
B.container.json
C.Dockerfile (or Containerfile)
D..dockerignore
AnswerC

podman build defaults to looking for Dockerfile or Containerfile.

Why this answer

The `podman build` command requires a Dockerfile or Containerfile in the build context directory to define the container image layers and instructions. Podman follows the OCI (Open Container Initiative) image specification and uses the Dockerfile format by default, making option C the only correct choice for building an image.

Exam trap

Red Hat often tests the distinction between files used for building images (Dockerfile/Containerfile) versus files used for orchestrating containers (docker-compose.yml) or excluding files (.dockerignore), leading candidates to mistakenly select A or D as required files.

How to eliminate wrong answers

Option A is wrong because docker-compose.yml is used by Docker Compose (or Podman Compose) to define multi-container applications, not for building a single container image. Option B is wrong because container.json is not a standard file recognized by Podman or Docker for image builds; it is not part of the OCI or Dockerfile specification. Option D is wrong because .dockerignore is an optional file that excludes files from the build context, but it is not required and cannot replace the Dockerfile or Containerfile as the build instruction source.

Practice this question →
47
MCQhard

Based on the exhibit, what is the most likely cause of the error?

A.The container registry is unreachable due to a firewall blocking port 443.
B.The image name is invalid.
C.The container registry is unreachable due to a network outage.
D.DNS resolution failure is preventing the registry hostname from being resolved.
AnswerD

Correct. The dial tcp: lookup ... timeout indicates DNS query failure.

Why this answer

Option C is correct because the error shows a DNS lookup failure (timeout on port 53). Option A would show connection refused. Option B would show timeout on port 443 or similar.

Option D would show 'image not found'.

Practice this question →
48
MCQmedium

A containerized web server needs to persist logs outside the container. Which podman run option allows the administrator to specify a bind mount with mount propagation options?

A.--mount
B.--volume
C.--bind
D.-v
AnswerA

Correct. The --mount option allows specifying mount type, source, destination, and propagation.

Why this answer

Option A is correct because the `--mount` flag in `podman run` provides the most granular control over bind mounts, including the ability to specify mount propagation options (e.g., `shared`, `slave`, `private`) via the `propagation` parameter. This is essential for persisting container logs to the host filesystem while controlling how mount events are propagated between the container and the host.

Exam trap

The trap here is that candidates confuse `--volume`/`-v` with `--mount`, assuming both support the same options, but only `--mount` allows explicit mount propagation settings, which is a key differentiator tested in the EX200 exam.

How to eliminate wrong answers

Option B is wrong because `--volume` (or `-v`) in Podman creates a volume managed by Podman, not a bind mount, and does not support mount propagation options directly; it is designed for persistent storage managed by Podman's volume driver. Option C is wrong because `--bind` is not a valid `podman run` option; the correct syntax for bind mounts uses `--mount type=bind` or `-v` with a host path. Option D is wrong because `-v` (short form of `--volume`) can create bind mounts when a host path is specified, but it does not support mount propagation options; propagation can only be set via the `--mount` option.

Practice this question →
49
Multi-Selecthard

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

Select 2 answers
A.podman ps -a
B.podman images <image>
C.podman history <image>
D.podman image tree <image>
E.podman inspect <image>
AnswersD, E

Displays image layer tree with size and details.

Why this answer

Option D is correct because `podman image tree <image>` displays the image's layer hierarchy, showing parent-child relationships and layer sizes. Option E is correct because `podman inspect <image>` 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.

Exam trap

The trap here is that candidates often confuse `podman images` (which only lists basic image info) with `podman inspect` (which provides detailed configuration and layers), or they mistakenly think `podman history` shows layer details when it actually shows build command history.

Practice this question →
50
MCQhard

A container needs to share the host's network namespace for performance monitoring. Which podman run option achieves this?

A.--network slirp4netns
B.--network bridge
C.--network none
D.--network host
AnswerD

Correct. The container shares the host's network namespace.

Why this answer

Option D is correct because `--network host` makes the container use the host's network stack directly, bypassing any network namespace isolation. This allows performance monitoring tools inside the container to see the host's actual network interfaces, IP addresses, and traffic without NAT or port mapping overhead.

Exam trap

The trap here is that candidates often confuse `--network host` with `--network bridge` (the default), assuming bridge mode provides host-level visibility, but bridge mode actually creates an isolated network namespace with NAT, hiding the host's interfaces.

How to eliminate wrong answers

Option A is wrong because `--network slirp4netns` uses user-mode networking with NAT, which isolates the container's network from the host and adds performance overhead, making it unsuitable for direct host network monitoring. Option B is wrong because `--network bridge` creates a separate network namespace with a virtual bridge (default for rootless containers), isolating the container from the host's network interfaces. Option C is wrong because `--network none` disables all networking inside the container, preventing any network monitoring of the host.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Manage Containers questions.

Start 20-question session