Courseiva

CCNA Container Operations And Lifecycle Questions

64 questions · Container Operations And Lifecycle · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

An administrator needs to copy a configuration file named /tmp/nginx.conf from the host into a running container named web_server at path /etc/nginx/nginx.conf. Which command should be used?

A.podman push --target web_server /tmp/nginx.conf
B.podman cp /tmp/nginx.conf web_server:/etc/nginx/nginx.conf
C.podman transfer /tmp/nginx.conf web_server:/etc/nginx/nginx.conf
D.podman import /tmp/nginx.conf web_server:/etc/nginx/nginx.conf
AnswerB

podman cp supports copying from host to container using host_path:container_path syntax.

Why this answer

The podman cp command copies files between the local filesystem and a container's filesystem (or between containers), using the syntax podman cp SRC DEST where a container path is prefixed with the container name and a colon. This mirrors docker cp and is the standard tool for injecting files into a running container. The command podman cp /tmp/nginx.conf web_server:/etc/nginx/nginx.conf correctly places the host file at the target path inside the container.

Exam trap

EX188 often tests confusion between image-level operations (push, import, build) and container-level file operations (cp), so candidates must recognize that only podman cp moves files into a running container.

How to eliminate wrong answers

Option A is wrong because podman push uploads an image to a registry — it has no --target flag and does not copy individual files into containers. Option C is wrong because podman transfer is not a valid Podman subcommand. Option D is wrong because podman import creates an image from a tarball of a filesystem, not a single file, and does not accept a container name as a destination.

Practice this question →
2
Multi-Selectmedium

An administrator is troubleshooting a misbehaving container and needs to examine its output logs and event history. Which TWO commands are appropriate for this task? (Choose TWO)

Select 2 answers
A.podman inspect-logs
B.podman logs
C.podman events
D.podman history
E.podman trace
AnswersB, C

podman logs retrieves a container's captured stdout and stderr, satisfying the stem's requirement to examine output logs. It reads the container's logging driver output, unlike podman events, which reports lifecycle actions rather than application output.

Why this answer

Option B, `podman logs`, is correct because it retrieves the stdout/stderr output of a container (or pod), which is exactly what the administrator needs to examine the container's output logs. Option C, `podman events`, is correct because it displays a stream of container-related events (such as create, start, stop, die, and health status changes) along with timestamps, providing the event history the administrator requires. Option A, `podman inspect-logs`, is not a valid Podman subcommand; log inspection is done with `podman logs`, while `podman inspect` returns container metadata, not logs.

Option D, `podman history`, is incorrect because it shows the image layer history (used with `podman history <image>`), not container runtime logs or events. Option E, `podman trace`, is not a real Podman command; there is no such subcommand for tracing container output or events.

Exam trap

EX188 often tests the distinction between image history (podman history) and container logs/events, and may include fabricated commands like podman inspect-logs or podman trace to distract candidates who are not familiar with the actual Podman subcommands.

Practice this question →
3
Multi-Selecthard

An administrator is troubleshooting process execution and live configuration updates on a running container. Which TWO commands allow interacting with processes or updating resource limits on the fly? (Choose TWO)

Select 2 answers
A.podman exec-top
B.podman adjust
C.podman update
D.podman modify
E.podman top
AnswersC, E

podman update modifies container resource limits like CPU shares on a running container.

Why this answer

Option C, `podman update`, is correct because it allows an administrator to change resource limits (such as CPU, memory, and pids limits) on an already-running container without restarting it, which directly satisfies the requirement for live configuration updates. Option E, `podman top`, is correct because it displays the running processes inside a container (similar to the Linux `top` command), letting the administrator inspect process execution in real time. The other options do not exist as valid Podman subcommands: `podman exec-top` (A) is not a real command, `podman adjust` (B) is not a real command, and `podman modify` (D) is not a real command, so none of them can be used for this scenario.

Exam trap

EX188 often tests the exact subcommand names for runtime mutation (`update`, not `modify`/`adjust`) and process inspection (`top`, not `exec-top`); candidates invent plausible-sounding verbs that don't exist in Podman.

Practice this question →
4
MCQmedium

An administrator wants to monitor real-time Podman system events, such as when containers are created, started, stopped, or removed, for auditing purposes. Which command should be executed?

A.podman audit
B.podman system stream
C.podman events
D.podman monitor
AnswerC

podman events streams real-time system events, including container creation, start, stop and removal, which is exactly the auditing visibility required. Other Podman commands list current state rather than a live event stream, so they cannot satisfy the monitoring requirement.

Why this answer

The podman events command streams real-time events from the Podman service, including container create, start, stop, die, and remove actions, along with image and network events. It is the direct analog to 'docker events' and is the correct tool for auditing container lifecycle activity. Options like 'podman audit' and 'podman monitor' do not exist as Podman subcommands.

Exam trap

EX188 often tests the confusion between podman events and non-existent subcommands like 'podman audit' or 'podman monitor', which sound plausible but are not part of the Podman CLI.

How to eliminate wrong answers

Option A is wrong because 'podman audit' is not a valid Podman subcommand; auditing is achieved via podman events or systemd journal integration. Option B is wrong because 'podman system stream' does not exist; the 'podman system' subcommand offers connection, df, info, prune, and reset, but not stream. Option D is wrong because 'podman monitor' is not a Podman command; monitoring is done through podman events, podman stats, or external tools.

Practice this question →
5
Multi-Selectmedium

An administrator is managing rootless Podman containers as a non-root user and wants to ensure that these containers automatically start upon system boot and persist across reboots using systemd. Which TWO steps or commands are required to accomplish this? (Choose TWO)

Select 2 answers
A.Configure the container restart policy to always using '--restart always' without systemd.
B.Run 'systemctl enable --now podman' with root privileges.
C.Modify the global '/etc/rc.local' script to execute 'podman start' on boot.
D.Run 'loginctl enable-linger <username>' to allow the user's systemd instance to run in the background when not logged in.
E.Generate a user systemd unit file using 'podman generate systemd' and place it in '~/.config/systemd/user/'.
AnswersD, E

Running `loginctl enable-linger <username>` keeps the user's systemd instance alive after logout, so user-scoped units can start at boot without an interactive session. Without lingering, rootless Podman containers defined as user services would only run while that user is logged in, breaking the persist-across-reboot requirement.

Why this answer

Option D is correct because rootless Podman containers run under the non-root user's own systemd instance, and 'loginctl enable-linger <username>' keeps that user manager (systemd --user) running after logout and across reboots, which is required for user services to start at boot without an interactive login. Option E is correct because the supported way to make a rootless container start via systemd is to generate a user unit with 'podman generate systemd' (or a Quadlet) and place it in '~/.config/systemd/user/', then enable it with 'systemctl --user enable --now <unit>'. Option A is not correct because '--restart always' is a Podman-level restart policy that only takes effect while the Podman service/container is running; it does not itself start containers at system boot without systemd integration.

Option B is not correct because enabling the system-wide 'podman' service with root privileges does not manage a non-root user's rootless containers. Option C is not correct because '/etc/rc.local' is a legacy system-wide boot script and does not properly integrate with the user's systemd instance for rootless containers.

Exam trap

EX188 often tests the misconception that '--restart always' alone is sufficient for rootless containers to start on boot; candidates must remember that lingering and systemd user units are required for persistence.

Practice this question →
6
MCQmedium

A container named db_master was previously paused using podman pause. Which command should the administrator use to resume its execution?

A.podman start db_master
B.podman resume db_master
C.podman unpause db_master
D.podman thaw db_master
AnswerC

Pausing a container with podman pause freezes its processes via the cgroup freezer without stopping them. The paired subcommand podman unpause thaws that same cgroup, resuming execution from the exact frozen state, so it is the only command that restores db_master.

Why this answer

The `podman pause` command suspends all processes in a container using the cgroup freezer. To resume execution, the correct command is `podman unpause`, which unfreezes the cgroup and allows processes to continue. Option C is the only command that reverses the paused state.

Exam trap

EX188 often tests the distinction between pausing and stopping containers, and candidates may confuse `podman unpause` with `podman start` or invent commands like `resume` or `thaw`.

How to eliminate wrong answers

Option A is wrong because `podman start` is used to start a stopped container, not to resume a paused one; a paused container is still running but frozen. Option B is wrong because `podman resume` is not a valid Podman command. Option D is wrong because `podman thaw` is not a valid Podman command; the correct term is 'unpause'.

Practice this question →
7
MCQhard

An administrator wants to view real-time container lifecycle events across the entire Podman system, such as container creation, starting, and stopping. Which command should be executed?

A.podman monitor --stream
B.podman events
C.podman logs --follow --events
D.podman system trace
AnswerB

`podman events` streams real-time lifecycle events from the Podman service, reporting actions such as create, start, stop and die for every container on the system. It satisfies the stem's requirement for system-wide, real-time monitoring, unlike `podman ps`, which only lists current container state.

Why this answer

The podman events command streams real-time container lifecycle events from the Podman system, including create, start, stop, die, and remove actions across all containers. It is the direct analog of docker events and is the correct tool for monitoring system-wide container activity.

Exam trap

EX188 often tests whether candidates confuse podman events (system-wide lifecycle stream) with podman logs (per-container stdout/stderr), and whether they invent plausible-sounding but non-existent subcommands like monitor or system trace.

How to eliminate wrong answers

Option A is wrong because podman monitor is not a valid Podman subcommand — no such command exists. Option C is wrong because podman logs --follow streams stdout/stderr from a single container and does not accept an --events flag; it cannot show system-wide lifecycle events. Option D is wrong because podman system trace is not a real subcommand — podman system has subcommands like df, info, prune, and events, but not trace.

Practice this question →
8
MCQhard

An administrator needs to view the processes running inside a specific container named worker_node, along with custom ps options like -ef to see full command arguments. Which command accomplishes this?

A.podman ps --processes worker_node
B.podman exec worker_node ps -ef
C.podman inspect --processes worker_node
D.podman top worker_node -ef
AnswerD

podman top runs ps inside a running container, and arguments after the container name pass through to ps, so -ef returns every process with full command lines. Docker-style exec would need an explicit ps invocation.

Why this answer

podman top runs a ps-like command inside the container's PID namespace and accepts custom ps arguments, so 'podman top worker_node -ef' shows all processes with full command lines. This is the purpose-built command for inspecting in-container processes with tailored output.

Exam trap

EX188 often tests whether candidates reach for 'podman exec ... ps' out of habit, ignoring that podman top is the native, dependency-free way to list in-container processes with custom ps options.

How to eliminate wrong answers

Option A is wrong because 'podman ps --processes' is not a valid flag — podman ps lists containers, not their internal processes. Option B is wrong because 'podman exec worker_node ps -ef' requires ps to be installed inside the container image, which minimal images (e.g., distroless, scratch-based) lack, and it spawns a new process rather than using Podman's native inspection. Option C is wrong because 'podman inspect --processes' is not a valid flag — inspect returns JSON metadata, not a process listing.

Practice this question →
9
MCQeasy

An administrator needs to start a container named webapp from the image docker.io/library/httpd in the background. Which podman command should be used?

A.podman run -d --name webapp docker.io/library/httpd
B.podman up -d --name webapp docker.io/library/httpd
C.podman container create -d --name webapp docker.io/library/httpd
D.podman start -d docker.io/library/httpd --name webapp
AnswerA

The -d flag detaches the container so it runs in the background, and --name webapp assigns the required container name. Specifying docker.io/library/httpd as the image pulls and starts it, satisfying both the naming and background constraints in one command.

Why this answer

The correct command is 'podman run -d --name webapp docker.io/library/httpd'. The 'run' subcommand creates and starts a container in one step, '-d' detaches it to run in the background, and '--name' assigns the container name. The image reference follows the options.

Exam trap

EX188 often tests confusion between 'podman run' (create+start) and 'podman create'/'podman start' (separate steps), or mistakenly using Docker Compose syntax like 'up'.

How to eliminate wrong answers

Option B is wrong because 'podman up' is not a valid Podman subcommand — 'up' belongs to Docker Compose/Podman Compose, not the podman CLI. Option C is wrong because 'podman container create' only creates the container without starting it, and the '-d' flag is not valid for create in that context; you would need a separate 'podman start'. Option D is wrong because 'podman start' starts an existing, already-created container and does not accept an image name or the '-d' flag in that form.

Practice this question →
10
MCQhard

An administrator is troubleshooting container startup failures and wants to inspect the exact entrypoint and command arguments configured for a container named app_run before it starts. Which inspect format expression retrieves this?

A.podman ps --format='{{.Command}}' app_run
B.podman inspect --format='{{.State.Command}}' app_run
C.podman inspect --format='{{.Config.Entrypoint}} {{.Config.Cmd}}' app_run
D.podman inspect --format='{{.Args}}' app_run
AnswerC

The `--format` flag with Go template syntax extracts exactly the `Config.Entrypoint` and `Config.Cmd` fields from the container's image configuration, satisfying the requirement to inspect entrypoint and command arguments without starting the container. This targets the precise metadata fields rather than the full JSON output.

Why this answer

The correct inspect format expression uses '.Config.Entrypoint' and '.Config.Cmd' to retrieve the entrypoint and command arguments configured for the container. These fields are part of the container's configuration and reflect the image's defaults or overrides specified at runtime.

Exam trap

EX188 often tests the correct JSON path for container configuration; candidates may incorrectly use .State.Command or .Args instead of .Config.Entrypoint and .Config.Cmd.

How to eliminate wrong answers

Option A is wrong because 'podman ps --format='{{.Command}}'' only shows the command of running containers and does not display the entrypoint; it also does not work for stopped containers. Option B is wrong because '.State.Command' is not a valid field; the state does not contain command information. Option D is wrong because '.Args' is not a valid field in the inspect output; the correct fields are under .Config.

Practice this question →
11
Multi-Selecthard

An administrator is configuring container health checks and wants to review health status or force immediate actions. Which TWO of the following statements or commands are accurate regarding Podman health checks? (Choose TWO)

Select 2 answers
A.podman inspect --format='{{json .State.Health.Status}}' can be used to check container health status.
B.Health checks can be configured during container creation using the --health-cmd option.
C.Container health statuses are automatically logged to /var/log/podman-health.log on the host.
D.podman stop automatically triggers a health check before shutting down.
E.podman health-check status is a valid built-in standalone top-level command.
AnswersA, B

The `podman inspect` command reads the container's persisted state, and the Go template extracts the `State.Health.Status` field, returning values such as `healthy`, `unhealthy`, or `starting`. This satisfies the requirement to review health status without executing anything inside the container, since the healthcheck results are recorded by Podman itself.

Why this answer

Option A is correct because `podman inspect --format='{{json .State.Health.Status}}'` queries the container's State.Health.Status field, which reports the current health state (healthy, unhealthy, starting) for a container that has a health check defined. Option B is correct because health checks are configured at container creation time with `podman run --health-cmd` (alongside related flags like --health-interval, --health-retries, and --health-timeout), which defines the command Podman executes to determine health. Option C is incorrect because Podman does not write health status to a host file such as /var/log/podman-health.log; health state is stored in the container's state metadata and viewed via inspect.

Option D is incorrect because `podman stop` simply sends SIGTERM (then SIGKILL after a timeout) to the container and does not trigger a health check. Option E is incorrect because there is no top-level `podman health-check status` command; health checks are managed through run/create options and inspected via `podman inspect` or `podman healthcheck run`.

Exam trap

EX188 often tests whether candidates invent plausible-sounding Podman commands — the trap is selecting fabricated options like `podman health-check status` or a nonexistent log file instead of the real `--health-cmd` flag and `inspect` query.

Practice this question →
12
MCQmedium

An administrator has a container that failed to start correctly. They want to inspect the exit code and finished timestamp. Which inspect format string provides the finished time?

A.podman inspect --format='{{.State.FinishedAt}}' failed_app
B.podman inspect --format='{{.Time.Ended}}' failed_app
C.podman inspect --format='{{.Finished}}' failed_app
D.podman ps --format='{{.FinishedAt}}' failed_app
AnswerA

The `{{.State.FinishedAt}}` field exposes the container's termination timestamp from its state object, satisfying the requirement to inspect when the failed container finished. Unlike `StartedAt` or `ExitCode`, this field specifically reports the completion time recorded by Podman, giving the exact finished timestamp the administrator needs.

Why this answer

Container lifecycle timestamps such as FinishedAt are stored under .State.

Practice this question →
13
MCQhard

An administrator is using Podman Quadlets to manage containers via systemd. Where must the Quadlet .container configuration file be placed for system-wide root containers?

A./etc/systemd/system/containers/
B./etc/containers/systemd/
C./var/lib/containers/systemd/quadlets/
D./etc/systemd/system/
AnswerB

Placing the .container file in /etc/containers/systemd/ satisfies the system-wide root requirement, since Quadlet's system generator scans this directory for root-owned units. Files here are processed by the systemd system manager, unlike user-scoped paths such as ~/.config/containers/systemd/, which only apply to rootless user services.

Why this answer

For system-wide root containers managed by Quadlets, the .container file must be placed in /etc/containers/systemd/. This directory is monitored by the podman-system-generator, which converts Quadlet files into systemd unit files at boot or on daemon-reload.

Exam trap

EX188 often tests the exact directory path for Quadlets, confusing it with standard systemd unit paths or container storage directories.

How to eliminate wrong answers

Option A is wrong because /etc/systemd/system/containers/ is not a recognized Quadlet search path; systemd does not scan subdirectories of /etc/systemd/system for unit files. Option C is wrong because /var/lib/containers/systemd/quadlets/ is not a standard Quadlet directory — /var/lib/containers is used for container storage, not unit definitions. Option D is wrong because /etc/systemd/system/ is for native systemd unit files, not Quadlet .container files; placing a .container file there will not be processed by the Quadlet generator.

Practice this question →
14
Multi-Selecthard

An administrator is working with Podman Quadlets to manage container lifecycles via systemd. Which TWO statements regarding Quadlet file naming conventions and directory locations are correct? (Choose TWO)

Select 2 answers
A.Rootless Quadlet files are placed in /var/lib/containers/systemd/ root directory.
B.Quadlet configuration files are automatically translated into native systemd unit files by Podman generators.
C.System-wide Quadlet configuration files are placed in /etc/containers/systemd/.
D.Quadlet files must be manually compiled using gcc before systemd can read them.
E.Quadlet container unit files must use the exact file extension .service.container.
AnswersB, C

Podman's systemd generators parse Quadlet files at daemon-reload and emit native unit files, so systemd manages the containers directly without a separate Podman service. This satisfies the stem's requirement that Quadlets manage container lifecycles via systemd, since the generated units are what systemd actually starts and stops.

Why this answer

Option B is correct because Podman ships systemd generators (podman-system-generator and podman-user-generator) that read .container, .volume, .network, .pod, and .kube Quadlet files and translate them into native systemd unit files at boot or daemon-reload time, so no manual compilation is needed. Option C is correct because system-wide (root) Quadlets are stored in /etc/containers/systemd/, which is the documented location the root-level generator scans for administrator-managed units. Option A is wrong because /var/lib/containers/systemd/ is not the rootless Quadlet directory; rootless units belong in ~/.config/containers/systemd/ (or /etc/containers/systemd/users/ for per-user system-wide placement).

Option D is wrong because Quadlet files are plain-text INI-style configuration consumed by Podman's generators, not C source requiring gcc. Option E is wrong because Quadlet container units use the single extension .container (e.g., foo.container), not .service.container.

Exam trap

EX188 often tests the distinction between rootless and rootful Quadlet directory paths and the file extensions, causing candidates to confuse /etc/containers/systemd/ with /var/lib/containers/systemd/ or to assume Quadlet files need compilation.

Practice this question →
15
Multi-Selectmedium

An administrator needs to export container contents or create new images from containers. Which TWO commands accomplish these actions? (Choose TWO)

Select 2 answers
A.podman extract
B.podman push-container
C.podman commit
D.podman export
E.podman save
AnswersC, D

`podman commit` creates a new image from a container's current writable layer, satisfying the requirement to create new images from containers. It captures filesystem changes made inside a running or stopped container, unlike `podman export`, which streams the filesystem as a tar archive without producing a reusable image.

Why this answer

Option C, podman commit, is correct because it creates a new image from a container's current state (including its filesystem and specified configuration), which directly satisfies the requirement to create new images from containers. Option D, podman export, is correct because it exports a container's filesystem as a tar archive, which directly satisfies the requirement to export container contents. Option A, podman extract, is not a valid Podman command for this purpose, so it does not belong.

Option B, podman push-container, is not a valid Podman command; pushing is done with podman push for images, not containers. Option E, podman save, saves an existing image to an archive rather than exporting container contents or creating a new image from a container, so it does not meet the scenario.

Exam trap

EX188 often tests whether candidates confuse `podman save` (image archiving) with `podman export` (container filesystem export), and whether they invent nonexistent subcommands like `push-container` or `extract`.

Practice this question →
16
MCQeasy

An administrator wants to immediately stop and remove a running container named temp_test in a single command. Which command should be used?

A.podman kill --remove temp_test
B.podman delete --force temp_test
C.podman stop --rm temp_test
D.podman rm -f temp_test
AnswerD

The -f flag forces removal of a running container, sending SIGKILL and deleting it without a prior stop step. This satisfies the requirement to stop and remove temp_test in a single command, unlike plain podman rm, which fails on running containers.

Why this answer

The podman rm -f command force-removes a running container by sending SIGKILL to its processes and then deleting the container in a single operation. The -f (or --force) flag is what allows removal of a running container without a prior podman stop. This is the canonical one-step command for the scenario described.

Exam trap

EX188 often tests whether candidates confuse podman kill (signal only) with podman rm -f (signal + delete), and whether they invent non-existent flags like --remove on kill or --rm on stop.

How to eliminate wrong answers

Option A is wrong because podman kill only sends a signal to the container's main process; it does not remove the container, and there is no --remove flag on podman kill. Option B is wrong because podman delete is not a valid Podman subcommand — the correct verb is rm (or remove). Option C is wrong because podman stop does not accept a --rm flag; --rm is a run-time option that auto-removes a container after it exits, not a stop-time option.

Practice this question →
17
Multi-Selectmedium

An administrator wants to modify container settings or state. Which TWO of the following commands are valid Podman subcommands for container management? (Choose TWO)

Select 2 answers
A.podman reconfigure
B.podman alter
C.podman modify
D.podman restart
E.podman rename
AnswersD, E

podman restart stops and starts an existing container, applying updated configuration such as changed resource limits or environment settings. It is a valid container-management subcommand, satisfying the administrator's need to modify container state without recreating it.

Why this answer

Option D, 'podman restart', is a valid Podman subcommand that stops and starts one or more running containers, which directly modifies container state and is used for container management. Option E, 'podman rename', is also a valid Podman subcommand that changes the name of an existing container, thereby modifying container settings/state. The other options are not Podman subcommands: 'podman reconfigure', 'podman alter', and 'podman modify' do not exist in Podman's CLI, so they cannot be used to manage containers.

Exam trap

EX188 often tests whether candidates invent plausible verbs — the trap is choosing fabricated commands like `podman modify` or `podman alter` instead of the real `restart` and `rename`.

Practice this question →
18
MCQhard

An administrator is working with a rootless Podman setup and needs to ensure that container user namespaces map UIDs correctly such that container root (UID 0) maps to the unprivileged user's UID on the host. Which file configures subordinate UID mappings for rootless users on RHEL?

A./etc/subuid and /etc/subgid
B./etc/containers/userns.conf
C./etc/security/limits.conf
D./etc/passwd and /etc/group
AnswerA

Rootless Podman reads /etc/subuid and /etc/subgid to allocate the subordinate UID and GID ranges that newuidmap and newgidmap apply, mapping container UID 0 onto the unprivileged host user. These files are the RHEL mechanism the stem requires.

Why this answer

Rootless user namespaces rely on /etc/subuid and /etc/subgid for mapping ranges.

Practice this question →
19
MCQeasy

An administrator has a running container named web_front that was started with podman run -d --name web_front nginx. The administrator needs to execute the command 'nginx -T' inside this already-running container to dump the full configuration. Which command accomplishes this?

A.podman run web_front nginx -T
B.podman attach web_front nginx -T
C.podman start web_front nginx -T
D.podman exec web_front nginx -T
AnswerD

podman exec runs a new process inside an already-running container, which is exactly the requirement here. Because web_front is running and the nginx binary exists in the container's filesystem, this command starts nginx -T within the existing container namespaces and returns its output to the host terminal. No container restart or image rebuild is needed.

Why this answer

Running a diagnostic or interactive command inside a container that is already running requires podman exec, which spawns an additional process in the container's namespaces. Commands like podman run create new containers, podman attach links to PID 1, and podman start only starts stopped containers, so none of them can execute nginx -T within the existing web_front container.

Exam trap

The trap here is confusing podman run (which creates a new container from an image) with podman exec (which runs a command inside an existing running container).

Practice this question →
20
MCQeasy

An administrator wants to view the last 50 lines of logs for a running container named log_test and keep the log stream open for new entries. Which command should be used?

A.podman tail 50 log_test
B.podman log-stream --lines=50 log_test
C.podman inspect --tail=50 log_test
D.podman logs --tail 50 --follow log_test
AnswerD

The --tail 50 flag limits output to the final fifty lines, while --follow keeps the stream open and prints new entries as the container writes them. Together they satisfy both constraints: viewing recent logs and continuing to monitor the running container named log_test.

Why this answer

`podman logs --tail 50 --follow log_test` retrieves the last 50 lines of container logs and keeps the stream open for new entries, exactly matching the requirement. The `--tail` flag limits historical output, and `--follow` (or `-f`) streams new log lines as they are written.

Exam trap

EX188 often tests whether candidates invent plausible-sounding subcommands like `podman tail` or `podman log-stream` — the trap is not remembering that log retrieval is always done via `podman logs` with flags.

How to eliminate wrong answers

Option A is wrong because `podman tail` is not a valid Podman subcommand — there is no `tail` verb in the Podman CLI. Option B is wrong because `podman log-stream` does not exist; the correct command is `podman logs` with the `--follow` flag. Option C is wrong because `podman inspect` outputs container metadata in JSON and does not read log files; it also does not support `--tail` or `--follow` flags for log streaming.

Practice this question →
21
MCQhard

An administrator needs to update the CPU shares (cpu-shares) of a running container named compute_job on the fly without stopping it. Which command should be used?

A.podman update --cpu-shares 512 compute_job
B.podman config compute_job cpu-shares=512
C.podman modify --cpu-shares 512 compute_job
D.podman set --shares=512 compute_job
AnswerA

podman update modifies resource constraints on a live container without restarting it, and --cpu-shares sets relative CPU weighting. This satisfies the requirement to change cpu-shares on the running compute_job container on the fly, preserving its state.

Why this answer

The podman update command modifies resource limits of a running container without requiring a restart, and --cpu-shares is one of the supported tunables. Running podman update --cpu-shares 512 compute_job adjusts the relative CPU weight of the container on the fly, which is exactly what the administrator needs.

Exam trap

EX188 often tests whether candidates know that podman update is the live-modification command, and whether they fall for plausible but non-existent verbs like modify, set, or config.

How to eliminate wrong answers

Option B is wrong because podman config is not a valid Podman subcommand for modifying running containers — no such command exists in the Podman CLI. Option C is wrong because podman modify is not a real Podman subcommand; the correct verb is update. Option D is wrong because podman set does not exist as a Podman command, and --shares is not the correct flag name — the flag is --cpu-shares.

Practice this question →
22
MCQhard

A container named 'worker' was configured with a health check command during build time, but an administrator needs to temporarily override or define a new health check command while running the container. Which flag should be passed to 'podman run' to achieve this?

A.--check-command
B.--healthcheck-run
C.--health-cmd
D.--health-test
AnswerC

`--health-cmd` overrides the image's built-in HEALTHCHECK instruction at runtime, satisfying the requirement to temporarily replace the build-time command. Podman applies this new command when starting the container, so no rebuild is needed. Other flags such as `--health-interval` or `--health-retries` tune timing only, not the command itself.

Why this answer

The `--health-cmd` flag in `podman run` allows overriding the health check command defined in the image. It specifies a command to run inside the container to check its health. This is the correct flag to temporarily define or override a health check at runtime.

Exam trap

EX188 often tests the exact flag names for health checks, and candidates may confuse `--health-cmd` with non-existent flags like `--health-test` or `--check-command`.

How to eliminate wrong answers

Option A is wrong because `--check-command` is not a valid Podman flag. Option B is wrong because `--healthcheck-run` is not a valid Podman flag. Option D is wrong because `--health-test` is not a valid Podman flag; the correct flag is `--health-cmd`.

Practice this question →
23
MCQmedium

An administrator has a container named legacy_api that has been stopped for several weeks. A teammate reports that the container's filesystem still contains an outdated configuration file at /etc/app/config.yml. The administrator wants to replace that file inside the stopped container's filesystem without starting it. Which command should the administrator use?

A.podman update --file ./config.yml legacy_api
B.podman cp ./config.yml legacy_api:/etc/app/config.yml
C.podman exec legacy_api sh -c 'echo > /etc/app/config.yml'
D.podman attach legacy_api sh
AnswerB

podman cp works on both running and stopped containers, copying files into or out of the container's filesystem. Since legacy_api is stopped, this command directly places the updated configuration at the target path in the container's writable layer, and the file will be present the next time the container starts.

Why this answer

podman cp transfers files between the host and a container's filesystem regardless of whether the container is running or stopped. Commands such as podman exec and podman attach require a running container, and podman update changes runtime resource settings rather than file contents, so podman cp is the only viable choice for modifying a stopped container's file.

Exam trap

The trap here is assuming file operations inside a container require the container to be running, which leads administrators to start a stopped container unnecessarily.

Practice this question →
24
MCQeasy

An operator needs to troubleshoot a failing service inside a container named 'auth_api'. Which command should the operator run to view the standard output log stream generated by this container?

A.podman output auth_api
B.podman logs auth_api
C.podman events auth_api
D.podman history auth_api
AnswerB

podman logs retrieves the captured standard output and standard error stream of the named container, which is exactly the log stream required. The container name auth_api is passed directly, so no exec into the container or host journal query is needed.

Why this answer

The `podman logs` command retrieves the standard output (stdout) and standard error (stderr) logs from a container, exactly what the operator needs to troubleshoot the failing service. It works for both running and stopped containers, and supports options like `-f` to follow the stream in real time. This is the direct Podman equivalent of `docker logs`.

Exam trap

EX188 often tests the distinction between container runtime logs (`podman logs`) and system/container lifecycle events (`podman events`), causing candidates to confuse real-time event monitoring with application log retrieval.

How to eliminate wrong answers

Option A is wrong because `podman output` is not a valid Podman subcommand; there is no such command for retrieving container output. Option C is wrong because `podman events` monitors system-level container events (create, start, stop, die, etc.) in real time, not the application's stdout/stderr log stream. Option D is wrong because `podman history` displays the image layer history (similar to `docker history`), showing how an image was built, not runtime logs from a container.

Practice this question →
25
MCQeasy

A running Podman container named 'dbapp' is unresponsive, and a technician needs to immediately and forcefully terminate it without waiting for a graceful shutdown timeout. Which Podman command should be executed?

A.podman stop --force dbapp
B.podman kill dbapp
C.podman terminate dbapp
D.podman rm -f dbapp
AnswerB

`podman kill dbapp` sends SIGKILL by default, terminating the container's processes immediately without the graceful stop timeout that `podman stop` honours. This satisfies the stem's requirement to forcefully terminate the unresponsive container at once, rather than waiting for a clean shutdown sequence.

Why this answer

The `podman kill` command sends a SIGKILL signal to the main process of the container by default, which immediately and forcefully terminates it without any graceful shutdown period. This matches the requirement to 'immediately and forcefully terminate' the unresponsive container. Unlike `podman stop`, which sends SIGTERM and waits for a timeout, `podman kill` does not wait and is the correct tool for this scenario.

Exam trap

EX188 often tests the difference between `podman stop` and `podman kill`, and candidates may incorrectly assume that `podman stop --force` exists or that `podman rm -f` is equivalent to killing a container.

How to eliminate wrong answers

Option A is wrong because `podman stop --force` does not exist; `podman stop` accepts a `--time` flag to set the timeout, but there is no `--force` option, and even if it did, it would still attempt a graceful stop first. Option C is wrong because `podman terminate` is not a valid Podman command; the correct command is `podman kill` or `podman stop`. Option D is wrong because `podman rm -f` forcefully removes a container, but it also deletes the container and its associated resources, which is not the same as simply terminating a running container; the question asks to terminate, not remove.

Practice this question →
26
MCQhard

An administrator wants to retrieve only the IP address of a running container named web_svc by querying podman inspect with a specific format template. Which command is correct?

A.podman ps --format='{{ .IP }}' web_svc
B.podman inspect --ip web_svc
C.podman inspect --format='{{ .NetworkSettings.IPAddress }}' web_svc
D.podman inspect --query=ip web_svc
AnswerC

The `--format` flag applies a Go template directly to the inspect JSON, and `.NetworkSettings.IPAddress` is the exact field path holding the container's IPv4 address. This satisfies the stem's requirement to retrieve only the IP address, rather than dumping the full JSON document for web_svc.

Why this answer

podman inspect supports Go-template formatting via --format, and the container's IP address lives at .NetworkSettings.IPAddress in the inspect JSON. The command podman inspect --format='{{ .NetworkSettings.IPAddress }}' web_svc extracts exactly that field for the named container.

Exam trap

EX188 often tests whether candidates know that podman inspect uses Go-template --format syntax and the exact JSON path .NetworkSettings.IPAddress, rather than inventing flags like --ip or --query.

How to eliminate wrong answers

Option A is wrong because podman ps does not expose an .IP field in its format template — ps shows status, ports, names, and IDs, not IP addresses. Option B is wrong because podman inspect has no --ip flag; it only accepts --format, --type, and --size. Option D is wrong because podman inspect has no --query flag — that is a fabricated option; filtering is done exclusively through --format templates.

Practice this question →
27
MCQmedium

An administrator wants to monitor resource usage (CPU, memory, block I/O, network I/O) of all running containers in real-time. Which command provides this functionality?

A.podman stats
B.podman monitor resources
C.podman top
D.podman system df
AnswerA

`podman stats` streams live CPU, memory, block I/O and network I/O counters for all running containers, refreshing continuously until interrupted. It satisfies the real-time monitoring constraint directly, unlike `podman ps` (static snapshot) or `podman inspect` (point-in-time JSON). No cgroups files need manual reading.

Why this answer

podman stats displays real-time resource usage statistics (CPU, memory, block I/O, network I/O, and PIDs) for running containers, similar to docker stats. It continuously refreshes and can be filtered to specific containers. This is the direct command for live resource monitoring.

Exam trap

EX188 often tests confusion between podman top (processes) and podman stats (resource metrics), or invents plausible-sounding subcommands like 'podman monitor resources' that do not exist.

How to eliminate wrong answers

Option B is wrong because 'podman monitor resources' is not a valid Podman subcommand; Podman has no such command. Option C is wrong because podman top shows the running processes inside a container (like ps), not resource usage metrics such as CPU and memory percentages. Option D is wrong because podman system df reports disk usage of images, containers, and volumes, not live CPU/memory/network statistics.

Practice this question →
28
MCQeasy

An administrator needs to inspect the low-level configuration of a running container named net_tool, including its network settings, mounted volumes, and environment variables, in a JSON format for automation. Which command should the administrator use?

A.podman top net_tool
B.podman inspect net_tool
C.podman ps --format json net_tool
D.podman logs net_tool
AnswerB

The podman inspect command outputs detailed JSON-formatted information about a container, including its configuration, network settings, mounts, environment variables, and more. It is the standard tool for retrieving low-level container metadata and is ideal for automation because the output is structured and parseable. This command directly fulfills the requirement to inspect the container's configuration in JSON format.

Why this answer

The podman inspect command provides comprehensive JSON output about a container's configuration, including network settings, volumes, environment variables, and other metadata. It is the correct tool for obtaining low-level details in a machine-readable format. Other commands like podman ps, podman logs, and podman top offer limited or unrelated information and do not fulfill the requirement for detailed configuration inspection.

Exam trap

The trap here is confusing podman ps --format json with podman inspect; the former only lists summary information and does not provide full configuration details.

Practice this question →
29
MCQmedium

An administrator needs to run a container named 'web01' using Podman in the background using the image registry.access.redhat.com/ubi8/httpd-24:latest. Which command correctly starts this container in detached mode and maps port 8080 on the host to port 80 in the container?

A.podman start -d --name web01 -p 8080:80 registry.access.redhat.com/ubi8/httpd-24:latest
B.podman container create -d --name web01 -p 8080:80 registry.access.redhat.com/ubi8/httpd-24:latest
C.podman run -d --name web01 -p 8080:80 registry.access.redhat.com/ubi8/httpd-24:latest
D.podman run -b --name web01 -p 80:8080 registry.access.redhat.com/ubi8/httpd-24:latest
AnswerC

The -d flag detaches the container, --name assigns web01, and -p 8080:80 maps host port 8080 to container port 80. The image reference follows, giving the correct Podman invocation for background execution with the required port mapping.

Why this answer

'podman run' is the command that creates and starts a container in one step, and -d puts it in detached (background) mode. The -p 8080:80 flag maps host port 8080 to container port 80 in the correct host:container order, and --name web01 assigns the required container name. This is the canonical Podman invocation for starting a named, detached, port-mapped container.

Exam trap

EX188 often tests the host:container order of the -p flag and the distinction between 'podman run' (create+start) versus 'podman create'/'podman start' (separate steps), catching candidates who reverse the port mapping or use the wrong lifecycle command.

How to eliminate wrong answers

Option A is wrong because 'podman start' only starts an existing, already-created container — it does not accept an image reference or create a new container, so passing the image name and -p flags will fail. Option B is wrong because 'podman container create' only creates the container without starting it, and -d is not meaningful for create; the container would exist but not run. Option D is wrong because -b is not a valid Podman flag (it is not the detach flag), and the port mapping is reversed — 80:8080 would map host port 80 to container port 8080, which is backwards from the requirement.

Practice this question →
30
Multi-Selecteasy

An administrator wants to check container port mappings and process listings inside containers. Which TWO commands provide these insights? (Choose TWO)

Select 2 answers
A.podman port
B.podman ps-ports
C.podman processes
D.podman top
E.podman netstat
AnswersA, D

The podman port command queries a running container's network namespace and prints its published and exposed port mappings, directly satisfying the requirement to inspect container port mappings without entering the container or inspecting the host firewall.

Why this answer

Option A, `podman port`, is correct because it displays the port mappings for a container, showing which container ports are forwarded to which host ports, exactly the insight the administrator needs for port mappings. Option D, `podman top`, is correct because it runs a process listing inside a running container (similar to `ps`), letting the administrator inspect the processes running within that container. Option B, `podman ps-ports`, is not a valid podman subcommand, so it cannot provide port mapping information.

Option C, `podman processes`, is not a valid podman subcommand for listing processes. Option E, `podman netstat`, is not a valid podman subcommand; network inspection is done via other tools or commands, not `podman netstat`.

Exam trap

EX188 often tests the exact syntax of Podman commands, and candidates may confuse podman port with podman ps-ports or assume that podman processes is a valid command.

Practice this question →
31
MCQeasy

An administrator needs to view all network ports exposed or mapped by a container named web_prod using a simplified summary command. Which command can be used?

A.podman port web_prod
B.podman show-ports web_prod
C.podman network list-ports web_prod
D.podman inspect --ports web_prod
AnswerA

podman port lists the port mappings for a named container, showing each exposed container port and its host binding in a concise summary. It satisfies the requirement to view all ports exposed or mapped by web_prod without inspecting full container configuration.

Why this answer

podman port is the dedicated subcommand that prints the port mappings (published and exposed) for a container in a compact, human-readable summary format. It mirrors docker port and is the intended tool when you want a quick listing rather than the full JSON dump from podman inspect.

Exam trap

EX188 often tests whether candidates know the exact subcommand name — podman port (singular, no flags) versus invented variants like show-ports or inspect --ports.

How to eliminate wrong answers

Option B is wrong because podman has no show-ports subcommand — it is a fabricated command. Option C is wrong because podman network list-ports does not exist; podman network only supports subcommands like create, ls, inspect, connect, and disconnect. Option D is wrong because podman inspect does not accept a --ports flag; port information is only available via the full JSON output or by filtering with --format.

Practice this question →
32
MCQeasy

An administrator needs to pause all processes inside a running container named db_master without stopping it. Which command accomplishes this?

A.podman suspend db_master
B.podman freeze db_master
C.podman hold db_master
D.podman pause db_master
AnswerD

`podman pause db_master` sends SIGSTOP to every process in the container's cgroup, freezing execution while leaving the container running and its state intact. This satisfies the requirement to suspend all processes without stopping the container, unlike `podman stop`, which terminates it.

Why this answer

The `podman pause` command sends the SIGSTOP signal to all processes inside the specified container, freezing their execution without terminating the container or its processes. This allows the container to be resumed later with `podman unpause`, which sends SIGCONT. Unlike stopping, the container's state and memory are preserved.

Exam trap

EX188 often tests the distinction between pause/unpause and stop/start, tricking candidates who assume 'suspend' or 'freeze' are valid Podman verbs when only pause/unpause exist in the Podman CLI.

How to eliminate wrong answers

Option A is wrong because `podman suspend` is not a valid Podman subcommand — there is no suspend verb in the Podman CLI. Option B is wrong because `podman freeze` is not a Podman command; freeze is a concept used in CRI-O (crictl) but not exposed as a Podman subcommand. Option C is wrong because `podman hold` does not exist in Podman; hold is not a recognized Podman operation.

Practice this question →
33
MCQeasy

An administrator needs to check the disk space consumption of all containers, images, and volumes managed by Podman. Which command should be run?

A.podman storage show
B.podman system df
C.podman disk usage
D.podman inspect --disk
AnswerB

podman system df reports disk usage for images, containers, and volumes managed by Podman, mirroring docker system df. It directly answers the administrator's need to check space consumption across all three resource types in one command.

Why this answer

`podman system df` is the correct command because it reports disk usage for Podman-managed objects — images, containers, volumes, and the build cache — in a single summary table, mirroring `docker system df`. It shows total size, reclaimable space, and active counts, making it the canonical way to audit storage consumption. The other options are not valid Podman subcommands.

Exam trap

EX188 often tests whether candidates confuse Docker-style verbs with Podman equivalents — the trap is picking a plausible-sounding but nonexistent command like `podman disk usage` instead of the real `podman system df`.

How to eliminate wrong answers

Option A is wrong because `podman storage show` is not a valid Podman subcommand; storage configuration is inspected via `podman info` or the `storage.conf` file, not a `storage show` verb. Option C is wrong because `podman disk usage` does not exist — the correct verb is `system df` (df = disk free/usage), and Podman does not expose a top-level `disk` command. Option D is wrong because `podman inspect` operates on a specific container or image object and has no `--disk` flag; it returns JSON metadata, not aggregate storage statistics.

Practice this question →
34
Multi-Selectmedium

An administrator wants to temporarily pause a running container's processes and later resume them. Which TWO commands should be used? (Choose TWO)

Select 2 answers
A.podman unpause
B.podman pause
C.podman freeze
D.podman resume
E.podman stop
AnswersA, B

Podman unpause resumes the cgroup freezer state previously set on the container, allowing its processes to continue from exactly where they halted. It is the second of the two commands required, completing the pause-then-resume workflow the administrator needs to restore the running container.

Why this answer

Option B, podman pause, is correct because it suspends all processes in a running container by sending SIGSTOP via the freezer cgroup, leaving the container intact so it can be resumed later. Option A, podman unpause, is correct because it reverses that state by sending SIGCONT through the freezer cgroup, allowing the previously paused processes to continue running. Together these two commands implement the temporary pause-and-resume workflow the administrator needs.

Option C, podman freeze, is not a valid Podman command for this purpose, and option D, podman resume, is likewise not a real Podman subcommand. Option E, podman stop, is incorrect because it terminates the container's processes rather than temporarily suspending them, so the container could not simply be resumed.

Exam trap

The trap is assuming symmetric command names — candidates pick 'freeze/resume' by analogy, but Podman's actual pair is 'pause/unpause'.

Practice this question →
35
MCQmedium

An administrator wants to rename an existing stopped container from old_name to new_name. Which command should be used?

A.podman update --name new_name old_name
B.podman mv old_name new_name
C.podman modify --name new_name old_name
D.podman rename old_name new_name
AnswerD

`podman rename` changes a stopped container's name in place, satisfying the requirement to rename rather than recreate. Unlike `podman commit` or export/import workflows, it preserves the container's ID, configuration and filesystem layers, so no data or settings are lost. The container must be stopped, which the stem specifies.

Why this answer

'podman rename old_name new_name' is the dedicated command for renaming a container, and it works on stopped containers. It updates the container's name in Podman's storage without altering its ID, configuration, or state. This is the direct, purpose-built solution for the task.

Exam trap

EX188 often tests whether candidates know the exact Podman subcommand names — distractors like 'podman mv' and 'podman modify' sound plausible but do not exist.

How to eliminate wrong answers

Option A is wrong because 'podman update' modifies resource limits and runtime settings (like CPU/memory), not the container name, and it does not accept a --name flag for renaming. Option B is wrong because 'podman mv' is not a valid Podman subcommand — there is no move command for containers. Option C is wrong because 'podman modify' is not a valid Podman subcommand; container configuration changes are made via 'podman update' or by recreating the container.

Practice this question →
36
MCQmedium

An administrator wants to export the filesystem of a container named golden_image into a tar archive file named container_fs.tar. Which command should be used?

A.podman save -o container_fs.tar golden_image
B.podman backup golden_image --file container_fs.tar
C.podman archive golden_image container_fs.tar
D.podman export -o container_fs.tar golden_image
AnswerD

podman export writes a container's filesystem as a tar archive, and the -o flag specifies the output file, so -o container_fs.tar golden_image produces the required container_fs.tar. Unlike podman save, which archives images, export targets the running or stopped container's filesystem.

Why this answer

podman export exports a container's filesystem as a tar archive.

Practice this question →
37
Multi-Selecteasy

An administrator needs to inspect running containers and their resource consumption. Which TWO commands provide information about running container state or resource usage? (Choose TWO)

Select 2 answers
A.podman storage
B.podman stats
C.podman ps
D.podman images
E.podman network ls
AnswersB, C

podman stats streams live CPU, memory, network and block I/O consumption per running container, directly satisfying the resource-usage half of the requirement. It refreshes continuously, unlike static listings, so the administrator can observe consumption trends as they develop.

Why this answer

Option B, `podman stats`, is correct because it displays live resource-usage statistics for running containers, including CPU percentage, memory usage/limit, network I/O, block I/O, and PIDs, which directly addresses the requirement to inspect resource consumption. Option C, `podman ps`, is correct because it lists containers and their current state (e.g., Up, Exited), so it provides the running-container state information the administrator needs. Option A, `podman storage`, is not correct because it reports storage-driver and layer/space information rather than per-container runtime state or resource usage.

Option D, `podman images`, is not correct because it lists local image metadata (repository, tag, image ID, size), not running containers. Option E, `podman network ls`, is not correct because it lists configured container networks, not container state or resource consumption.

Exam trap

EX188 often tests whether candidates confuse image-related commands (`podman images`) or network commands (`podman network ls`) with container-state commands — the trap is picking commands that operate on the wrong object type.

Practice this question →
38
MCQeasy

An administrator needs to remove all stopped containers from the system to free up disk space in a single command. Which command should be used?

A.podman rm stopped
B.podman container prune
C.podman system clean
D.podman rm --all
AnswerB

`podman container prune` removes every stopped container in one operation, directly satisfying the single-command requirement to reclaim disk space. Unlike `podman rm`, which needs explicit container IDs or the `-a` flag plus command substitution, prune targets only stopped containers by default, leaving running ones untouched.

Why this answer

The podman container prune command removes all stopped containers in a single operation, freeing disk space and cleaning up the container runtime state. It is the purpose-built subcommand for this task and prompts for confirmation before deletion (unless --force is used). This is the correct and idiomatic Podman command for bulk removal of stopped containers.

Exam trap

EX188 often tests the distinction between podman container prune (stopped containers only), podman system prune (containers, networks, images, build cache), and invalid syntax like podman rm --all or podman system clean that candidates assume exist.

How to eliminate wrong answers

Option A is wrong because podman rm stopped is not valid syntax; podman rm requires container IDs or names, not the literal word 'stopped'. Option C is wrong because podman system clean is not a valid Podman subcommand; the correct command for system-wide cleanup is podman system prune. Option D is wrong because podman rm --all attempts to remove all containers including running ones, which will fail for running containers and is not scoped to stopped containers only.

Practice this question →
39
MCQmedium

An administrator needs to inspect low-level configuration, network settings, and state details of a running container named redis_cache in JSON format. Which command provides this?

A.podman show redis_cache
B.podman details redis_cache
C.podman inspect redis_cache
D.podman query --json redis_cache
AnswerC

Podman stores container configuration as OCI metadata, and inspect renders it as JSON, exposing low-level settings, network configuration and runtime state. Unlike logs or ps, which show only summary or output data, inspect returns the full structured document the administrator requires.

Why this answer

`podman inspect` is the canonical command for retrieving low-level metadata about a container, image, volume, or network. It outputs a comprehensive JSON document containing configuration, state, network settings, mounts, environment variables, and more. Since the question explicitly asks for JSON-format low-level details, `podman inspect redis_cache` is the correct choice.

Exam trap

EX188 often tests whether candidates confuse Docker-style verbs with Podman's actual CLI surface — the trap is picking a plausible-sounding but nonexistent subcommand like `show`, `details`, or `query` instead of the real `inspect`.

How to eliminate wrong answers

Option A is wrong because `podman show` is not a valid Podman subcommand — there is no such verb in the Podman CLI. Option B is wrong because `podman details` does not exist; the correct verb is `inspect`, not `details`. Option D is wrong because `podman query` is not a Podman subcommand, and the `--json` flag is not needed since `inspect` already outputs JSON by default.

Practice this question →
40
MCQmedium

A container named app_server is running and consuming excessive CPU. An administrator needs to gracefully stop this container with a 30-second timeout before forcing termination. Which command accomplishes this?

A.podman kill --signal SIGTERM --timeout 30 app_server
B.podman halt -s 30 app_server
C.podman stop --time 30 app_server
D.podman terminate --grace-period=30 app_server
AnswerC

The --time flag sets the grace period before SIGKILL, so podman stop --time 30 app_server sends SIGTERM, waits 30 seconds for graceful shutdown, then forces termination. This precisely matches the stem's requirement for a graceful stop with a 30-second timeout.

Why this answer

`podman stop --time 30 app_server` is correct because `--time` (or `-t`) sets the number of seconds Podman waits after sending SIGTERM before escalating to SIGKILL. This is exactly the graceful-stop-with-30-second-timeout behavior required. The container's main process gets SIGTERM, and only if it does not exit within 30 seconds does Podman force-kill it.

Exam trap

EX188 often tests the difference between `stop` (graceful, SIGTERM then SIGKILL after timeout) and `kill` (immediate signal) — the trap is picking `podman kill` with a fabricated `--timeout` flag instead of `podman stop --time`.

How to eliminate wrong answers

Option A is wrong because `podman kill` sends a signal immediately and has no `--timeout` flag — it does not implement a graceful wait-then-force sequence; `--signal SIGTERM` just changes which signal is sent, and the container is killed without a grace period. Option B is wrong because `podman halt` is not a Podman subcommand, and `-s 30` is not a valid flag. Option D is wrong because `podman terminate` does not exist in Podman, and `--grace-period` is a Kubernetes/Docker-adjacent concept, not a Podman flag.

Practice this question →
41
MCQmedium

An administrator needs to restart a running container named app_v1 so that configuration changes take effect. Which command performs a container restart?

A.podman reload app_v1
B.podman restart app_v1
C.podman cycle app_v1
D.podman refresh app_v1
AnswerB

`podman restart app_v1` stops and starts the named container in a single operation, so the process re-reads its configuration on startup. It targets the container by name, satisfying the requirement to restart the running `app_v1` container without recreating it or altering its image.

Why this answer

The 'podman restart' command stops and then starts the specified container in a single operation, which re-reads the container's configuration and applies any changes that require a fresh process. It is the direct equivalent of 'docker restart' and is the correct verb for restarting a running container by name.

Exam trap

EX188 often tests whether candidates confuse container lifecycle verbs (restart, stop, start, kill) with non-existent or systemd-style verbs like reload or refresh.

How to eliminate wrong answers

Option A is wrong because 'podman reload' is not a valid Podman subcommand for containers; reload semantics exist for systemd units, not Podman containers. Option C is wrong because 'podman cycle' does not exist in the Podman CLI. Option D is wrong because 'podman refresh' is not a Podman command; there is no refresh verb for containers.

Practice this question →
42
MCQhard

An administrator is troubleshooting container exit codes. A container exited with code 137. What does this specific exit code typically signify in container engines?

A.The container was terminated forcefully by SIGKILL (often due to Out-Of-Memory).
B.The container executed an invalid system call blocked by seccomp.
C.The container encountered an application-level syntax error.
D.The container startup script had a permission denied error.
AnswerA

Exit code 137 equals 128 plus signal 9, meaning the container received SIGKILL. The kernel's OOM killer commonly sends SIGKILL when a container exceeds its memory cgroup limit, so the process is terminated forcefully without cleanup.

Why this answer

Exit code 137 is calculated as 128 + 9, where 9 is the signal number for SIGKILL. This means the container's main process was forcibly terminated with SIGKILL, most commonly because the kernel OOM killer invoked it when the container exceeded its memory cgroup limit, or because an administrator ran `podman kill`.

Exam trap

EX188 often tests whether candidates know the 128+signal convention — the trap is assuming 137 is an application error code rather than recognizing it as SIGKILL (9) and associating it with OOM termination.

How to eliminate wrong answers

Option B is wrong because a seccomp-blocked system call typically results in the process receiving SIGSYS (signal 31), producing exit code 159, not 137. Option C is wrong because an application-level syntax error would cause the application to exit with its own error code (often 1 or 2), not a signal-based code. Option D is wrong because a permission denied error on a startup script would result in exit code 126 (command found but not executable) or 127 (command not found), not 137.

Practice this question →
43
Multi-Selecthard

An administrator is troubleshooting container exit codes and low-level state details. Which TWO of the following inspect format expressions correctly extract container state attributes? (Choose TWO)

Select 2 answers
A.podman inspect --format='{{.Metadata.ExitCode}}' container_name
B.podman inspect --format='{{.State.StartedAt}}' container_name
C.podman inspect --format='{{.Status.Running}}' container_name
D.podman inspect --format='{{.Exit}}' container_name
E.podman inspect --format='{{.State.ExitCode}}' container_name
AnswersB, E

The template {{.State.StartedAt}} extracts the timestamp recording when the container last started, a low-level state attribute held in the inspect JSON's State object. This satisfies the requirement to pull container state details via a format expression.

Why this answer

Option B is correct because podman inspect exposes the container's low-level state under the .State object, and .State.StartedAt is the valid field holding the container start timestamp. Option E is correct because the container exit code is stored at .State.ExitCode in the inspect JSON, so this Go-template expression properly extracts the exit status the administrator is troubleshooting. Option A is wrong because .Metadata.ExitCode does not exist in podman inspect output; exit codes live under .State, not .Metadata.

Option C is wrong because .Status.Running is not a valid path — running state is reported via .State.Running. Option D is wrong because there is no top-level .Exit field; the exit code must be referenced as .State.ExitCode.

Exam trap

EX188 often tests whether candidates know that all runtime state fields live under `.State` (not `.Status`, `.Metadata`, or top-level keys), catching those who guess plausible-sounding but invalid template paths.

Practice this question →
44
MCQmedium

An administrator wants to run a one-off command (/bin/sh) interactively inside an existing running container named legacy_app. Which command should be used?

A.podman run -it legacy_app /bin/sh
B.podman enter legacy_app /bin/sh
C.podman attach legacy_app --shell=/bin/sh
D.podman exec -it legacy_app /bin/sh
AnswerD

podman exec runs a command in an already-running container, and the -it flags allocate an interactive TTY with stdin attached, giving an interactive shell. Naming legacy_app targets the existing container, satisfying the one-off interactive /bin/sh requirement without creating a new container.

Why this answer

podman exec -it legacy_app /bin/sh runs a new process inside the already-running container with an interactive TTY, which is exactly what is needed for a one-off interactive shell. The -i keeps stdin open and -t allocates a pseudo-TTY.

Exam trap

The trap is confusing run (new container) with exec (process in existing container), and attach (main process stdio) with exec (new process).

How to eliminate wrong answers

Option A is wrong because podman run creates and starts a new container from an image; it does not enter the existing legacy_app container. Option B is wrong because podman enter is not a valid Podman subcommand. Option C is wrong because podman attach connects to the container's main process stdio and has no --shell option; attaching to a running service would not give a shell and could disrupt the main process.

Practice this question →
45
MCQeasy

An administrator needs to commit the changes made to a running container named test_lab into a new image named my_custom_img:latest. Which command should be used?

A.podman commit test_lab my_custom_img:latest
B.podman create-image test_lab my_custom_img:latest
C.podman save test_lab my_custom_img:latest
D.podman build --container test_lab -t my_custom_img:latest
AnswerA

podman commit creates a new image from a container's current state, capturing filesystem changes made since it started. The syntax takes the container name then the new image reference, so 'podman commit test_lab my_custom_img:latest' correctly produces the tagged image. Export, save and build do not commit container changes.

Why this answer

The 'podman commit' command creates a new image from a container's current state, including any changes made to its filesystem. The syntax 'podman commit <container> <image>' correctly captures the container 'test_lab' and produces the image 'my_custom_img:latest'.

Exam trap

EX188 often tests the distinction between 'commit' (create image from container) and 'save' (export image to tar) or 'build' (create image from Containerfile); candidates may confuse these commands.

How to eliminate wrong answers

Option B is wrong because 'podman create-image' is not a valid Podman command; the correct command to create an image from a container is 'commit'. Option C is wrong because 'podman save' is used to save an image to a tar archive, not to create an image from a container. Option D is wrong because 'podman build --container' is not a valid option; 'podman build' builds an image from a Containerfile or Dockerfile, not from a running container.

Practice this question →
46
MCQmedium

An administrator has created a systemd service file named container-web.service using podman generate systemd. Where should this file be placed for a rootless user to manage it as a user-level service?

A.~/.local/share/podman/systemd/
B./etc/systemd/system/
C.~/.config/systemd/user/
D./var/lib/containers/systemd/
AnswerC

Rootless Podman services run under the user's own systemd instance, which reads units from ~/.config/systemd/user/. Placing the generated file there lets the unprivileged user enable and manage it with systemctl --user, without root-owned system paths.

Why this answer

For rootless Podman containers, systemd user services must reside in the user's systemd configuration directory, which is ~/.config/systemd/user/. This allows the user to manage the service with systemctl --user commands without requiring root privileges. Placing the unit file here ensures it is loaded when the user's systemd instance starts, typically at login.

Exam trap

EX188 often tests the confusion between system-level and user-level systemd directories, leading candidates to choose /etc/systemd/system/ for rootless services.

How to eliminate wrong answers

Option A is wrong because ~/.local/share/podman/systemd/ is not a standard systemd unit directory; systemd does not search there for user units. Option B is wrong because /etc/systemd/system/ is for system-level services managed by root, not for rootless user services. Option D is wrong because /var/lib/containers/systemd/ is used by Podman's Quadlet feature for system-level container units, not for user-level generated services.

Practice this question →
47
Multi-Selecteasy

An administrator needs to clean up stopped containers and unused data to reclaim disk space. Which TWO commands can be used to remove containers? (Choose TWO)

Select 2 answers
A.podman image prune
B.podman rmi
C.podman rm
D.podman system clean
E.podman container prune
AnswersC, E

`podman rm` deletes stopped containers by name or ID, directly reclaiming the writable layer each container holds on disk. This satisfies the stem's requirement to remove containers, as distinct from `podman rmi`, which targets images, or `podman system prune`, which clears broader unused data.

Why this answer

Option C, 'podman rm', is correct because it removes one or more specified containers by name or ID, which is the standard way to delete stopped containers and free their writable layer space. Option E, 'podman container prune', is correct because it bulk-removes all stopped containers in a single operation, directly reclaiming disk space from containers that are no longer running. Option A, 'podman image prune', is wrong because it removes unused images, not containers.

Option B, 'podman rmi', is wrong because it removes images rather than containers. Option D, 'podman system clean', is wrong because there is no such Podman subcommand; the actual command for reclaiming multiple resource types is 'podman system prune'.

Exam trap

EX188 often tests the container-versus-image distinction — the trap is selecting `podman rmi` or `podman image prune` for container cleanup, or inventing `podman system clean` instead of the real `podman system prune`.

Practice this question →
48
MCQeasy

An administrator needs to attach to the terminal of a currently running container named backend_app to view its active console output interactively. Which command should be used?

A.podman console backend_app
B.podman connect backend_app
C.podman attach backend_app
D.podman join backend_app
AnswerC

podman attach connects the administrator's terminal to the running container's main process, streaming its active console output interactively. Unlike podman exec, which spawns a new process, attach joins the existing terminal, matching the requirement to view live output from backend_app.

Why this answer

`podman attach` connects the current terminal's STDIN/STDOUT/STDERR to a running container's main process (PID 1), letting the administrator view live console output and interact with it. This is the direct equivalent of `docker attach` and is the correct tool for viewing an active console interactively.

Exam trap

The trap here is confusing `attach` (bind to PID 1's stdio) with `exec` (spawn a new process) — candidates often pick a fabricated verb like `console` or `connect` when they forget the exact subcommand name.

How to eliminate wrong answers

Option A is wrong because `podman console` is not a valid Podman subcommand — there is no such verb. Option B is wrong because `podman connect` does not exist; `podman network connect` exists but attaches a container to a network, not a terminal. Option D is wrong because `podman join` is not a Podman subcommand (it resembles Kubernetes `kubectl exec` or `nsenter` semantics but is not implemented in Podman).

Practice this question →
49
MCQhard

An administrator is troubleshooting a rootless Podman container named payment_svc that fails to start with a permission-related error. The administrator wants to inspect the container's low-level configuration, including its mount points, namespace settings, and the exact command that was configured, without starting the container. Which command provides this information?

A.podman logs payment_svc
B.podman top payment_svc
C.podman inspect payment_svc
D.podman stats payment_svc
AnswerC

podman inspect returns a detailed JSON document describing the container's configuration, including its mounts, namespaces, environment, entrypoint and command, network settings, and the stored state. It works on stopped containers, making it the correct tool to examine why a container fails before it ever starts.

Why this answer

podman inspect exposes the full stored configuration of a container as JSON, including mounts, namespace modes, environment, and the configured entrypoint and command, and it works whether the container is running or stopped. The other commands report runtime output, running processes, or live resource usage, all of which are unavailable or irrelevant for a container that never starts.

Exam trap

The trap here is reaching for podman logs to diagnose a startup failure, when logs only contain output from a process that actually ran.

Practice this question →
50
MCQhard

An administrator is configuring a systemd service using podman generate systemd and wants the generated service to stop and remove the container automatically when the service stops, and create a fresh container when it starts. Which flag should be added?

A.--ephemeral
B.--new
C.--recreate
D.--auto-remove
AnswerB

The --new flag makes the generated systemd unit create a fresh container on each service start and remove it on stop, rather than reusing the existing container, matching the requirement for automatic teardown and recreation.

Why this answer

The --new flag in podman generate systemd creates a systemd unit that removes the existing container when the service stops and creates a fresh container when it starts. This ensures a clean state on each service start, which is useful for stateless or ephemeral workloads.

Exam trap

EX188 often tests the specific flags of podman generate systemd; candidates may confuse --new with Docker's --rm or assume --recreate exists, but the correct flag for recreate-on-start is --new.

How to eliminate wrong answers

Option A is wrong because --ephemeral is not a valid flag for podman generate systemd; it is not a recognized option for this command. Option C is wrong because --recreate is not a podman generate systemd flag; it may be confused with Docker Compose or other tooling. Option D is wrong because --auto-remove is not a flag for podman generate systemd; while podman run has --rm for auto-removal, the systemd generator uses --new to achieve the recreate-on-start behavior.

Practice this question →
51
MCQeasy

An administrator wants to view a list of all running containers in a clean, tabular format without stopping containers or showing extra metadata. Which command should be used?

A.podman ps
B.podman show running
C.podman list
D.podman containers
AnswerA

podman ps lists only running containers in a compact tabular layout, showing container ID, image, command, creation time, status, ports and names. It neither stops containers nor adds the extra metadata that flags such as -a or --size would introduce, matching the clean-list requirement.

Why this answer

podman ps lists running containers by default.

Practice this question →
52
MCQhard

An administrator is managing rootless containers and wants to enable systemd linger for their user account so that user-level container services continue running after the user logs out. Which command should be run?

A.systemctl enable --user --linger
B.podman system linger enable
C.usermod --linger=true $USER
D.loginctl enable-linger
AnswerD

`loginctl enable-linger` instructs systemd-logind to keep the user's systemd instance running after logout, satisfying the requirement that user-level container services persist without an active session. It targets the specific user manager rather than the system manager, which is precisely what rootless Podman's `--user` services depend on.

Why this answer

The loginctl enable-linger command (optionally with a username) enables systemd linger for a user, which keeps that user's systemd instance and its user services running after the user logs out. This is essential for rootless Podman containers managed as systemd user services (via podman generate systemd or Quadlet) to survive logout and start at boot. Running loginctl enable-linger $USER is the canonical way to enable this.

Exam trap

EX188 often tests the misconception that systemctl or podman can enable linger, when the correct tool is loginctl — candidates must remember linger is a logind/session concept, not a systemctl or Podman feature.

How to eliminate wrong answers

Option A is wrong because systemctl enable --user --linger is not valid syntax — --linger is not a systemctl option; linger is controlled by loginctl. Option B is wrong because podman system linger enable is not a real Podman subcommand; podman system has subcommands like df, info, and migrate, but not linger. Option C is wrong because usermod has no --linger option; linger is a systemd-logind concept managed via loginctl, not a user account attribute in /etc/passwd.

Practice this question →
53
MCQmedium

An administrator wants to create a new container named app_test from the image registry.example.com/apps/web:v2, but the container should not start immediately so that environment variables can be adjusted first. Which command creates the container without starting it?

A.podman run --name app_test registry.example.com/apps/web:v2
B.podman start --name app_test registry.example.com/apps/web:v2
C.podman pull --name app_test registry.example.com/apps/web:v2
D.podman create --name app_test registry.example.com/apps/web:v2
AnswerD

podman create builds the container's writable layer and configuration from the image but leaves it in the Created state without starting it. This lets the administrator inspect or modify settings, and then start it later with podman start app_test. It is the correct way to stage a container before first launch.

Why this answer

To prepare a container without launching it, use podman create, which instantiates the container from the image and leaves it stopped. podman run starts immediately, podman pull only fetches the image, and podman start requires an existing container. Creating first and starting later allows configuration changes before the application initializes.

Exam trap

The trap here is assuming that podman run is the only way to instantiate a container, when podman create is specifically designed to create without starting.

Practice this question →
54
Multi-Selecteasy

An administrator needs to manage multiple containers simultaneously using Podman. Which THREE actions can be performed directly using Podman commands? (Choose THREE)

Select 3 answers
A.Stop all running containers using 'podman stop $(podman ps -q)'.
B.Directly edit a running container's image tag using 'podman edit --tag'.
C.Instantly migrate a running container to a remote physical server using 'podman migrate'.
D.Remove all stopped containers using 'podman container prune'.
E.Restart a specific container using 'podman restart <container_name>'.
AnswersA, D, E

Command substitution feeds every container ID returned by 'podman ps -q' into 'podman stop', halting all running containers in one command. Podman natively supports this shell-driven bulk operation, satisfying the stem's requirement for managing multiple containers directly.

Why this answer

Option A is correct because 'podman stop $(podman ps -q)' uses command substitution: 'podman ps -q' returns the IDs of all running containers, and 'podman stop' then stops each of them in one command, enabling bulk management. Option D is correct because 'podman container prune' is a built-in Podman command that removes all stopped containers, which is a standard bulk cleanup action. Option E is correct because 'podman restart <container_name>' is a valid Podman command that restarts the specified container by name or ID.

Option B is not valid because Podman has no 'podman edit --tag' command to directly edit a running container's image tag; image tags are managed with commands like 'podman tag' or 'podman build', not by editing a running container. Option C is not valid because Podman has no 'podman migrate' command to instantly move a running container to a remote physical server; container migration/checkpointing is handled by tools such as CRIU with 'podman container checkpoint' and 'podman container restore', not a simple 'migrate' subcommand.

Exam trap

EX188 often tests whether candidates invent plausible-sounding Podman subcommands like `migrate` or `edit --tag`, when in reality Podman's command set mirrors Docker's and lacks those operations.

Practice this question →
55
Multi-Selectmedium

An administrator needs to copy files between the host system and a running container. Which TWO syntax forms or commands are correct when using podman cp? (Choose TWO)

Select 2 answers
A.podman cp --target=container_name host_file.txt /app/file.txt
B.podman cp --direction=to-container host_file.txt container_name:/app/
C.podman cp container_name:/app/file.txt host_file.txt
D.podman cp host_file.txt container_name:/app/file.txt
E.podman cp --from=container_name /app/file.txt host_file.txt
AnswersC, D

The container-to-host direction puts the container_name:/path source first and the local destination second. Podman reads the file from the running container's filesystem and writes it to the host, satisfying the requirement to copy out of a container.

Why this answer

Option D is correct because podman cp follows the same source-then-destination syntax as docker cp, so copying a host file into a running container is expressed as `podman cp host_file.txt container_name:/app/file.txt`, where the container path is prefixed with the container name and a colon. Option C is correct because the reverse direction uses the same syntax with the container path as the source: `podman cp container_name:/app/file.txt host_file.txt` copies the file out of the container onto the host. The remaining options are invalid because podman cp does not support a `--target` flag (A), a `--direction` flag (B), or a `--from` flag (E); direction is determined solely by which operand contains the `container:` prefix.

Exam trap

EX188 often tests whether candidates invent flags like '--from' or '--target' instead of recognizing that 'podman cp' encodes direction purely through the 'container:path' positional syntax.

Practice this question →
56
MCQmedium

An administrator needs to inspect container health check logs to determine why recent health checks failed for a container named app_prod. Which command displays the container's health check log history?

A.podman logs --health app_prod
B.podman health-log app_prod
C.podman events --health app_prod
D.podman inspect --format='{{json .State.Health.Log}}' app_prod
AnswerD

The --format flag with the Go template extracts .State.Health.Log from the container's JSON state, returning the recorded health check attempts and their exit codes. This directly satisfies the need to inspect historical health check results for app_prod.

Why this answer

inspecting State.Health.Log within podman inspect shows recent health check execution details and error outputs.

Practice this question →
57
MCQmedium

A container named 'metrics' has been running for several hours, and an engineer needs to inspect its current resource consumption (CPU, memory, and network I/O usage). Which Podman command provides a live-updating stream of resource usage statistics for running containers?

A.podman inspect metrics
B.podman top metrics
C.podman system df metrics
D.podman stats metrics
AnswerD

podman stats streams live CPU, memory, and network I/O statistics for running containers, refreshing continuously. Naming the metrics container scopes output to it, satisfying the live-updating inspection requirement, whereas podman top shows processes rather than resource consumption.

Why this answer

`podman stats` is the Podman equivalent of `docker stats` and provides a live, continuously updating stream of CPU, memory, network I/O, and block I/O statistics for one or more running containers. When a container name is passed (e.g., `podman stats metrics`), it filters the output to just that container and refreshes on an interval until interrupted.

Exam trap

EX188 often tests the distinction between static inspection commands (`inspect`, `top`, `system df`) and the live streaming metrics command (`stats`); candidates confuse `top` (processes) with `stats` (resource usage).

How to eliminate wrong answers

Option A is wrong because `podman inspect` returns a one-shot JSON dump of static container metadata and configuration (image, mounts, env, state) — it does not report live CPU/memory/network usage. Option B is wrong because `podman top` shows the running processes inside a container (like `ps`), not resource consumption metrics. Option C is wrong because `podman system df` reports disk usage of images, containers, and volumes on the host, not per-container CPU/memory/network I/O.

Practice this question →
58
Multi-Selectmedium

An administrator needs to clean up a host running rootless Podman. Several containers have exited and are consuming disk space, and the administrator wants to remove only the stopped containers while preserving running containers and all images. Which TWO commands accomplish this? (Choose two.)

Select 2 answers
A.podman container prune
B.podman rm --all --force
C.podman system prune --all
D.podman ps -a --filter status=exited --format '{{.ID}}' | xargs -r podman rm
E.podman rmi --all
AnswersA, D

podman container prune removes all stopped containers in one operation while leaving running containers untouched. It prompts for confirmation unless the force flag is supplied. This matches the requirement to reclaim space from exited containers without affecting running workloads or deleting any images from local storage.

Why this answer

Removing only stopped containers while preserving running containers and images can be done with podman container prune, which targets exited containers, or by filtering podman ps for exited containers and piping their IDs to podman rm. The all-container removal, system-wide prune with images, and image removal commands either affect running workloads or delete images that must be retained.

Exam trap

The trap here is conflating container cleanup with image cleanup, so commands like podman system prune --all get chosen even though they also delete images.

Practice this question →
59
MCQmedium

An administrator needs to copy a directory named /app/logs from a running container named prod_app to the local host directory /var/backups/. Which command accomplishes this?

A.podman export --path /app/logs prod_app /var/backups/
B.podman pull prod_app:/app/logs /var/backups/
C.podman download prod_app:/app/logs /var/backups/
D.podman cp prod_app:/app/logs /var/backups/
AnswerD

podman cp copies files between a container and the host using the container:path syntax, so prod_app:/app/logs names the source directory and /var/backups/ the destination. This satisfies the requirement to copy from the running container to the local host.

Why this answer

'podman cp' copies files or directories between a container and the host, using the 'container:path' syntax to disambiguate the container side. 'podman cp prod_app:/app/logs /var/backups/' copies the directory from the running container to the host. It works on running containers and preserves the source path semantics.

Exam trap

EX188 often tests whether candidates confuse 'podman cp' with 'podman export' or invent non-existent subcommands like 'download', so knowing the exact CLI surface is essential.

How to eliminate wrong answers

Option A is wrong because 'podman export' exports a container's filesystem as a tar archive to a file or stdout — it has no '--path' flag and cannot copy a single directory to a host path. Option B is wrong because 'podman pull' downloads images from a registry; it does not accept a container:path source. Option C is wrong because 'podman download' is not a Podman subcommand at all.

Practice this question →
60
MCQeasy

An administrator needs to list all containers, including both running and stopped ones, on the system. Which command should be used?

A.podman ps -a
B.podman status --all
C.podman list --all
D.podman containers show
AnswerA

`podman ps -a` lists every container regardless of state, satisfying the requirement to include stopped ones. Without `-a`, the command shows only running containers, so stopped instances stay hidden. The `-a` flag maps directly to the stem's "both running and stopped" constraint.

Why this answer

The podman ps command lists containers, and the -a (or --all) flag includes both running and stopped containers. Without -a, podman ps shows only running containers. This mirrors the Docker CLI behavior and is the standard way to view all container states.

Exam trap

EX188 often tests the difference between podman ps (running only) and podman ps -a (all containers), and may include plausible but non-existent subcommands like podman list or podman status to distract candidates.

How to eliminate wrong answers

Option B is wrong because podman status is not a valid subcommand; there is no podman status command in the Podman CLI. Option C is wrong because podman list is not a valid subcommand; the correct command is podman ps or podman container ls. Option D is wrong because podman containers show is not a valid command; podman inspect is used for detailed container information, but it does not list containers.

Practice this question →
61
MCQeasy

A container named db_cache has stopped unexpectedly. An administrator wants to see the standard output logs generated by this container prior to its exit. Which command should be used?

A.podman inspect --logs db_cache
B.podman logs db_cache
C.podman output db_cache
D.podman history db_cache
AnswerB

`podman logs db_cache` retrieves the captured stdout/stderr of the container, including output written before it exited, satisfying the requirement to inspect pre-exit standard output. Because Podman persists container logs after termination, this works even though `db_cache` has stopped, unlike `podman attach`, which requires a running container.

Why this answer

The `podman logs` command retrieves the standard output (stdout) and standard error (stderr) logs from a container, whether it is running or has stopped. Since the container `db_cache` has exited, `podman logs db_cache` will display the logs generated prior to its exit. This is the standard and correct way to access container logs in Podman.

Exam trap

EX188 often tests the distinction between commands that inspect container metadata (like `podman inspect`) and those that retrieve runtime output (like `podman logs`), so candidates must remember that `inspect` does not provide logs despite its comprehensive output.

How to eliminate wrong answers

Option A is wrong because `podman inspect` does not have a `--logs` flag; it is used to display low-level configuration and state information about a container, not its output logs. Option C is wrong because `podman output` is not a valid Podman command; there is no such subcommand for retrieving logs. Option D is wrong because `podman history` is used to show the history of an image (its layers and creation commands), not the logs of a container.

Practice this question →
62
Multi-Selecthard

An administrator is integrating Podman containers with systemd using generated unit files. Which TWO statements are correct regarding podman generate systemd and its usage? (Choose TWO)

Select 2 answers
A.Running systemctl daemon-reload is unnecessary after generating a unit file because Podman reloads systemd automatically.
B.Generated systemd files for rootless users must always be placed in /etc/systemd/system/.
C.The --new flag ensures that the generated service creates a new container instance upon starting rather than requiring a pre-existing static container.
D.podman generate systemd can output unit files for both individual containers and pods.
E.Generated systemd unit files are executed exclusively by Docker daemon integration.
AnswersC, D

The --new flag makes the generated unit create a fresh container on each service start instead of starting a pre-existing one, so the container need not exist beforehand. This suits stateless or ephemeral workloads managed declaratively by systemd.

Why this answer

Option C is correct because the --new flag in podman generate systemd produces a unit file that creates a fresh container instance each time the service starts (via podman run) instead of managing a pre-existing container, which is essential for ephemeral or recreated workloads. Option D is correct because podman generate systemd accepts either a container name/ID or a pod name/ID and emits a corresponding .service unit file, so it supports both individual containers and pods. Option A is wrong because after placing or modifying a unit file you must run systemctl daemon-reload so systemd rereads unit definitions; Podman does not reload systemd automatically.

Option B is wrong because rootless users typically place units in ~/.config/systemd/user/ (and use systemctl --user), not /etc/systemd/system/, which is for system-wide units. Option E is wrong because these units invoke Podman directly and have no dependency on the Docker daemon.

Exam trap

EX188 often tests the misconception that rootless systemd units belong in /etc/systemd/system/ and that daemon-reload is automatic, when in fact rootless units live under ~/.config/systemd/user/ and daemon-reload is always manual.

Practice this question →
63
MCQhard

An administrator is troubleshooting a container that fails its health check repeatedly. The container definition needs a health check that runs curl -f http://localhost/ || exit 1 every 30s, with a 5s timeout and 3 retries, starting after a 10s grace period. Which flag combination implements this correctly in podman run?

A.podman run --healthcheck="curl -f http://localhost/" --interval=30 --timeout=5 --retries=3 webapp
B.podman run --health-probe="curl -f http://localhost/" --health-delay=10s webapp
C.podman run --health-cmd="curl -f http://localhost/ || exit 1" --health-interval=30s --health-timeout=5s --health-retries=3 --health-start-period=10s webapp
D.podman run --check-command="curl -f http://localhost/" --check-period=30s webapp
AnswerC

The `--health-start-period=10s` flag supplies the grace period before failures count, while `--health-interval=30s`, `--health-timeout=5s` and `--health-retries=3` map exactly to the stem's cadence, timeout and retry constraints. `--health-cmd` carries the curl command verbatim, so podman's health check matches the specified definition precisely.

Why this answer

The correct flag combination uses Podman's health check flags: --health-cmd for the command, --health-interval for the period, --health-timeout for the timeout, --health-retries for retry count, and --health-start-period for the initial grace period. Option C matches all required parameters exactly, including the '|| exit 1' failure semantics. Podman's health check system mirrors Docker's HEALTHCHECK instruction and uses these specific flag names.

Exam trap

EX188 often tests flag naming precision — candidates confuse Docker Compose or Kubernetes probe terminology (e.g., --healthcheck, --health-probe) with Podman's actual --health-* flags, or forget the --health-start-period for grace periods.

How to eliminate wrong answers

Option A is wrong because it uses non-existent flags (--healthcheck, --interval, --timeout, --retries) that Podman does not recognize — Podman requires the --health-* prefix. Option B is wrong because --health-probe and --health-delay are not valid Podman flags; the correct flags are --health-cmd and --health-start-period. Option D is wrong because --check-command and --check-period are not Podman flags at all; they appear to be invented or confused with other tooling.

Practice this question →
64
Multi-Selecteasy

An administrator needs to view logs or attach to a running container to troubleshoot an issue. Which TWO commands can be used to interact with container output streams? (Choose TWO)

Select 2 answers
A.podman stream
B.podman view-logs
C.podman attach
D.podman output
E.podman logs
AnswersC, E

podman attach connects the terminal directly to a running container's standard input, output and error streams, letting the administrator watch live output and interact with the process. This satisfies the requirement to interact with container output streams for troubleshooting.

Why this answer

Option C, `podman attach`, is correct because it connects the terminal's standard input, output, and error streams directly to a running container's main process (PID 1), allowing the administrator to view live output and interact with the container's streams in real time. Option E, `podman logs`, is correct because it retrieves the captured stdout/stderr history of a container (or pod), which is exactly what is needed to view log output for troubleshooting. The unmarked options do not belong: `podman stream` (A) is not a valid podman subcommand, `podman view-logs` (B) does not exist, and `podman output` (D) is not a real podman command for reading container streams.

Exam trap

EX188 often tests whether candidates confuse `attach` (bind to PID 1's streams) with `exec` (spawn a new process) — the trap is picking fabricated commands like `podman stream` or `podman view-logs` instead of the real `logs` and `attach`.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Container Operations And Lifecycle questions.

Start 20-question session