Courseiva

CCNA Manage Containers Questions

35 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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Running podman volume create creates a named volume that is managed by Podman and stored on the host under /var/lib/containers/storage/volumes (or a configured driver). Mounting it with -v volname:/var/lib/mysql makes MySQL data persist independently of the container's lifecycle; the volume remains after container removal and can be reused by a new container. Named volumes also allow easy backup, inspection, and sharing, and they are the recommended way to store persistent data with containers.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse `--tmpfs` with persistent storage, not realizing that tmpfs is volatile and exists only in RAM, or they mistakenly think `--rm` helps with persistence when it actually ensures automatic cleanup of the container's writable layer.

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

The podman port command prints the host port bindings for a running container, e.g., 8080/tcp -> 0.0.0.0:32768, by reading the port-mapping rules that podman created. If the container was started without -p or -P, this command produces no output, which is an immediate indicator that no host port was published and external access is impossible. It is the direct, minimal diagnostic for checking whether a container's ports are exposed to the network.

Why this answer

`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

For rootless containers, every UID and GID used inside the container must be mapped to an unprivileged range on the host, and those ranges are defined in /etc/subuid and /etc/subgid. The container engine such as Podman calls newuidmap and newgidmap to apply the subordinate ID mapping, and without at least one range assigned to the user, the kernel cannot establish the user namespace and the container fails to launch. A typical entry allocates a starting UID and a count, for example 1000:100000:65536, to give the container up to 65,536 IDs to work with.

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

`--no-cache` is the correct answer because it tells Podman to ignore every cached layer and execute each instruction from the `Containerfile` as if this were the first build. It forces all dependent stages, such as `RUN` steps, to re-run and pull any changed content from network repositories, giving a pristine result. This is useful for reproducible builds where you need to verify that a fresh base image and package set produce the image.

Why this answer

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

This is the correct approach because podman volume create dbdata allocates a dedicated, managed volume in Podman's storage area, and the -v dbdata:/var/lib/mysql flag uses the non-absolute source to identify it as a named volume rather than a host path. Podman handles all lifecycle operations, permissions are configured correctly for the container's user, and the volume persists across container restarts and even after the container is removed. You can inspect it with podman volume inspect and reuse it with other containers, making it the right choice for durable database data.

Why this answer

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 →
8
MCQhard

A system administrator wants to run a container as a systemd service that restarts automatically after a system reboot. Which approach follows Red Hat best practices?

A.Create a cron job that checks if the container is running and starts it if not.
B.Create a sysvinit script that calls podman commands.
C.Add 'podman run ...' to /etc/rc.local.
D.Use 'podman generate systemd --new --name mycontainer' and enable the generated service.
AnswerD

podman generate systemd --new --name mycontainer generates a complete systemd service unit that records the exact podman command, container ID, and environment required to create and start the container fresh on every invocation of the service. Placing this unit in /etc/systemd/system and enabling it with systemctl enable --now makes systemd the supervisor: it sets up dependencies such as After=network-online.target, can apply Restart=on-failure, and will tear down the container cleanly on service stop. This is the intended way to manage a container's lifecycle as a systemd service.

Why this answer

`podman generate systemd --new --name mycontainer` creates a systemd unit file that defines the container as a transient service with `Restart=always` and `WantedBy=multi-user.target`, ensuring the container starts automatically after a reboot. This approach aligns with Red Hat best practices for managing containers as systemd services, leveraging systemd's native dependency and restart capabilities rather than relying on legacy or non-standard methods.

Exam trap

The trap here is that candidates may think any method that runs a command at boot (like cron or rc.local) is sufficient, but Red Hat specifically tests that systemd is the standard service manager in RHEL 8/9 and that `podman generate systemd` is the recommended way to create persistent container services with proper restart and dependency handling.

How to eliminate wrong answers

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

Practice this question →
9
Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

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

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

The --storage-opt flag is a valid Podman run option that passes storage driver options to the container's writable layer. For example, size= can set a maximum size for the writable layer when using drivers that support quotas. This differs from --volume options because it configures the local mutable container layer itself rather than external storage.

Why this answer

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 →
11
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

The exhibit's PORTS column displays 0.0.0.0:8080->80/tcp, which uses Docker's host_port:container_port syntax. This means traffic sent to port 8080 on any host interface is forwarded to TCP port 80 inside the container, so container port 80 is indeed mapped to host port 8080. The wildcard 0.0.0.0 binding indicates the port is published on all of the host's network interfaces.

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 →
12
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

The -d flag detaches the container, keeping it running in the background even after your shell exits. The -p flag publishes a port mapping in the form host:container, so -p 8080:80 exposes the container's port 80 (where nginx serves HTTP) on the host's port 8080. This meets the requirement of a persistent, reachable container. Because the mapping order is correct, startup will succeed and traffic to localhost:8080 reaches nginx.

Why this answer

`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 →
13
MCQhard

A container exits immediately with status 1. The administrator runs 'podman logs container' but sees no output. What is the most likely reason for the missing logs?

A.The container binary is missing or has the wrong architecture (exec format error).
B.The container's logging driver is not configured to capture stdout.
C.The log file is rotated and cleared.
D.The container is using a non-standard log location inside the container.
AnswerA

When a container exits immediately with status 1 and no output, the kernel often returns ENOEXEC ('exec format error') because the configured entrypoint or command is not a valid executable for the host architecture. This occurs when the image was built for a different CPU architecture (e.g., ARM on x86_64) or when a script's shebang points to a missing interpreter. The container's main process never actually runs, so no stdout/stderr is generated, making logs appear empty. Therefore, the correct action is to verify the image architecture and the executable's format using 'file' and 'podman inspect'.

Why this answer

When a container exits immediately with status 1 and `podman logs` shows no output, the most common cause is that the container binary is missing or has the wrong architecture (e.g., an x86 binary on an ARM system). This results in an 'exec format error' that prevents the container's entrypoint from executing, so no stdout/stderr is ever written to the logging driver. The container exits before any process runs, leaving the log buffer empty.

Exam trap

Red Hat often tests the misconception that missing logs are always due to a logging configuration issue, but the trap here is that an immediate exit with status 1 and no output points to a failure before any process runs, such as an exec format error.

How to eliminate wrong answers

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

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

ss -tlnp is correct because it directly interrogates the kernel's socket table for listening TCP endpoints. The -t option limits output to TCP, -l shows only listening sockets, -n displays numeric addresses and ports without DNS lookups, and -p appends the process ID and name that holds each socket. This lets you see exactly which host process has bound the port that the container needs, confirming the conflict at the OS level.

Why this answer

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

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

A.podman run --name web1 -it registry.access.redhat.com/ubi8/httpd-24
B.podman start web1
C.podman restart web1 && podman attach web1
D.podman start web1 && podman attach web1
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
16
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. Correct matches: /var/log/messages for general messages, /var/log/secure for authentication, /var/log/maillog for mail, /var/log/cron for cron jobs. Common confusions involve swapping secure and maillog.

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

Rootless Podman relies on a per-user systemd instance to manage the lifecycle of container processes and services. `loginctl enable-linger` ensures that this user instance starts automatically at boot and persists after the user logs out, which is essential for containers running in the background. Without linger, containers may be terminated when the user session ends.

Why this answer

`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 →
18
MCQhard

A company runs a critical web application in a container on a Red Hat Enterprise Linux 9 server. The container is started via a systemd service called 'webapp.service'. The service unit file was generated using 'podman generate systemd --new --name webapp'. Recently, after a kernel update and reboot, the service fails to start the container. The administrator runs 'systemctl status webapp.service' and sees 'Active: failed (Result: exit-code)' and 'Process: 1234 ExecStart=/usr/bin/podman run ... (code=exited, status=125)'. The administrator also checks 'journalctl -u webapp.service' and sees: 'Error: unable to start container: container create failed: OCI runtime error: container_linux.go:380: starting container process caused: exec: "/usr/bin/app.sh": stat /usr/bin/app.sh: no such file or directory'. The container image was built locally using a Containerfile that includes 'COPY app.sh /usr/bin/app.sh'. The administrator verifies the image is present locally. What should the administrator do to resolve this issue?

A.Disable SELinux with setenforce 0 and restart the service.
B.Remove the systemd service and regenerate it with 'podman generate systemd --new --name webapp'.
C.Manually create the /usr/bin/app.sh file inside the container using podman exec.
D.Rebuild the container image using 'podman build -t webapp .' to ensure the app.sh file is included, then restart the service.
AnswerD

Rebuilding with podman build -t webapp . rereads the Dockerfile/Containerfile in the current directory and recreates the image; if that file contains a COPY app.sh /usr/bin/app.sh step, the new image will contain the missing script. Because the systemd unit references the webapp image tag, when the service restarts it will pull the updated local image with the same tag and use it to run a fresh container. This addresses the root cause, and restarting the service verifies the container starts cleanly.

Why this answer

The error indicates that the container image is missing the `/usr/bin/app.sh` file, even though the `COPY` instruction was in the Containerfile. The most likely cause is that the image was built before the `app.sh` script was added to the build context, or the build was incomplete. Rebuilding the image with `podman build -t webapp .` ensures the file is properly included in the image layers, resolving the OCI runtime error.

Exam trap

The trap here is that candidates may confuse a missing file inside the container image with a host-level issue (SELinux, service unit, or runtime environment) and overlook the need to rebuild the image with the correct build context.

How to eliminate wrong answers

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

Practice this question →
19
MCQeasy

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

A.Add the --restart=always flag to the podman run command
B.Use podman run --detach to run the container in the background
C.Use podman run -d to run the container in detached mode
D.Create a systemd user service by running 'podman generate systemd --new --name mywebcontainer' and then enable and start the service with 'systemctl --user enable --now container-mywebcontainer.service'
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

--mount is a structured key=value flag, e.g., --mount type=bind,source=/data,target=/var/lib/data or type=volume,source=myvol,target=/var/lib/data. Unlike -v, it explicitly exposes the mount type and cleanly separates source and destination syntax. Because the mount points to a named volume or a host directory outside the container's writable layer, data is written to external storage and survives container deletion or re-creation.

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 →
21
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

A container is the runtime instance produced when an image is instantiated, and it always has its own thin writable layer placed on top of the read-only image layers. This layer captures all file system changes made by the container, regardless of whether the container is currently executing or has been stopped. The writable layer remains associated with the container object until the container itself is deleted, so both running and stopped containers are considered instances with that writable layer.

Why this answer

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 →
22
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

The `--tail` option explicitly instructs `podman logs` to output only the last 50 lines of the container's log stream. This is the exact functionality needed to satisfy the admin's requirement. The syntax `podman logs --tail 50 app1` is correct and will work as expected. Specifying a numeric value after `--tail` is the standard way to limit log output to the most recent entries.

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

The command podman unshare chown 1001:1001 /host/dir changes ownership of the host directory from inside the same user namespace that the rootless container will use. Because podman unshare maps the container's UID/GID to the correct underlying host UIDs, the directory becomes owned by UID 1001 and GID 1001 as seen by the container, and the container user 1001 can write to it. This is the recommended approach for fixing rootless bind-mount permission issues, as it avoids requiring host-level root and precisely matches the container's identity.

Why this answer

`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 →
24
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

The `podman exec` command takes a container name or ID followed by a command, then runs that command as a new process inside the already running container's namespaces and root filesystem. Here, `ls /` is executed directly by the container's runtime, not through a shell unless explicitly wrapped, so the output is the contents of the container's root directory. This is the core purpose of `exec`: to run a one-off command in an existing, running container without creating a new container.

Why this answer

`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 →
25
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` directly instructs the container runtime to apply the SELinux type `container_t` to the container's processes and files, which is the proper way to set a SELinux context in Podman. This option is processed by the OCI runtime and translates into the appropriate SELinux labeling call, ensuring the container is confined by the targeted policy. It is the correct method because it leverages the intended `security-opt` mechanism for SELinux type selection.

Why this answer

`--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 →
26
MCQeasy

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

A.The container is using host networking mode.
B.The container cannot be reached from other containers.
C.The container's port 3306 is bound to all host interfaces.
D.The container is using bridge networking with a static IP.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Running 'podman login registry.example.com:5000' first authenticates you to the private registry, using the username and password you supply to create an entry in your local credentials store (typically $XDG_RUNTIME_DIR/containers/auth.json). This grants your user session permission to read image metadata and layers from that registry's namespace. Only after a successful login will a subsequent 'podman pull' be able to authenticate and retrieve the image. Therefore, this is the correct prerequisite step to enable the pull.

Why this answer

`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 →
28
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

The lowercase -p option is the short form of --publish and is the primary way to map a container port to a host port. It accepts the syntax -p hostPort:containerPort/protocol, such as -p 8080:80/tcp, and can be repeated to publish multiple ports. By default, it binds to all host interfaces (0.0.0.0) unless you prefix an IP address, making the container's service reachable from the host or external network.

Why this answer

(-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 →
29
MCQhard

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

A.Add --force to the podman run command
B.Check which process is using port 80 and either stop that process or use a different host port
C.Add --replace to the podman run command
D.Use --net=host to bypass the port mapping
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Using lowercase -v with the absolute source and destination paths is the correct bind-mount syntax: podman -v /data:/var/lib/data mounts the host directory /data at the container path /var/lib/data. Because /data is an absolute path, Podman treats it as a bind mount rather than creating a named volume. The container's writes to /var/lib/data will be immediately reflected in host's /data, which is exactly the desired behavior.

Why this answer

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 →
31
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

The `--tail 10` flag limits the output to the last 10 lines of the container's log stream, which is exactly what an administrator needs when a database crashes repeatedly. Because the crash reason almost always appears in the final log entries before the process exits, viewing the tail provides the most recent error without wading through the full history. This is the standard, non-interactive way to capture the fatal diagnostics for a container that has already stopped.

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

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

A.--restart=on-failure
B.--restart=always
C.--restart=unless-stopped
D.--restart=no
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Dockerfile (or Containerfile) is the conventional build file that podman build reads by default to assemble an image, containing instructions such as FROM, RUN, and COPY. Podman automatically looks for Dockerfile and, if not found, falls back to Containerfile, which uses the same syntax and is tool-agnostic. A directory with one of these files is the minimal requirement to start a build.

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 →
34
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

The --mount option is the correct choice because it provides an explicit, structured way to define a bind mount with comma-separated key=value syntax, such as type=bind,source=/host/logs,destination=/var/log/nginx. It allows specifying advanced parameters like bind-propagation (e.g., rshared, rslave) and read-only enforcement, which are essential for reliably persisting container logs outside the container. Unlike -v or --volume, --mount does not guess whether the source is a file, directory, or named volume, making it the most deterministic and production-safe approach for this task.

Why this answer

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 →
35
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

--network host connects the container directly to the host's network namespace, so the container sees the same IP address, routing table, and network interfaces as the host. Any service listening in the container binds directly to the host's ports without requiring -p or --publish mappings. This eliminates the NAT and veth-pair overhead of bridge networking, but it also means the container has no network isolation from the host, which can be a security risk if untrusted workloads are run.

Why this answer

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