Red Hat Certified Specialist in Containers (EX188, Podman-based) (EX188) EX188 Questions 151–225 | Page 3/4

151

MCQeasy

Which user instruction changes the user name or UID and group name or GID to use when running subsequent instructions in the Containerfile?

A.LOGIN

B.IDENTITY

C.USER

D.ACCOUNT

AnswerC

USER sets the user name, UID, group name and GID applied when running subsequent RUN, CMD and ENTRYPOINT instructions, plus the container's runtime identity. It changes execution identity only, not file ownership, which requires separate handling.

Why this answer

The USER instruction sets the user name or UID to use for running the image and for any RUN, CMD and ENTRYPOINT instructions that follow it.

Full explanation →

152

MCQeasy

An administrator needs to create a persistent storage volume that Podman can manage independently of any specific container lifecycle. Which command accomplishes this?

A.podman volume init mydata

B.podman storage volume-add mydata

C.podman create volume --name mydata

D.podman volume create mydata

AnswerD

'podman volume create mydata' creates a named volume managed by Podman's volume subsystem, persisting independently of any container's lifecycle. Anonymous volumes tied to a container are removed with it; named volumes survive container deletion, satisfying the persistence constraint.

Why this answer

`podman volume create mydata` is the correct command to create a named volume that Podman manages independently of any container's lifecycle. Named volumes persist after containers are removed and can be mounted into multiple containers, making them ideal for persistent data. This is the direct Podman equivalent of `docker volume create`.

Exam trap

EX188 often tests whether candidates confuse container creation commands (`podman create`) with volume management commands (`podman volume create`), or invent nonexistent subcommands like 'volume init'.

How to eliminate wrong answers

Option A is wrong because `podman volume init` is not a valid Podman subcommand — there is no 'init' action under volume management. Option B is wrong because `podman storage volume-add` is not a valid command syntax; Podman does not have a 'storage' top-level command with a 'volume-add' subcommand. Option C is wrong because `podman create volume --name mydata` is invalid syntax — `podman create` creates containers, not volumes, and does not accept a 'volume' positional argument.

Full explanation →

153

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.

Full explanation →

154

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.

Full explanation →

155

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.

Full explanation →

156

MCQeasy

A rootless user wants to run a container and mount a host directory into it. The container process reports permission denied errors when trying to write to the mounted volume. Which SELinux-related flag is typically appended to the volume mount option to resolve container volume permission issues in rootful mode, or handled via user namespaces in rootless mode?

A.:ro

B.:shared

C.:z

D.:exec

AnswerC

The :z flag relabels the mounted host directory with a shared SELinux context (svirt_sandbox_file_t) permitting container processes to write. Without it, SELinux denies writes to the volume. In rootless mode, user namespaces handle equivalent permission mapping.

Why this answer

The `:z` volume option tells Podman to relabel the host directory with the SELinux context expected by the container process (typically `container_file_t`), allowing the confined container to read and write the mount. Without it, the directory retains its host label (e.g., `user_home_t` or `default_t`), and SELinux denies the container's writes even though Unix permissions look fine.

Exam trap

The trap is confusing mount-propagation flags (`:shared`, `:slave`) and access flags (`:ro`, `:rw`) with SELinux relabeling flags (`:z`, `:Z`); candidates who don't know SELinux pick a plausible-sounding mount option.

How to eliminate wrong answers

Option A is wrong because `:ro` makes the mount read-only, which would cause write failures rather than fix them. Option B is wrong because `:shared` controls mount propagation (whether submounts are visible across namespaces), not SELinux labeling, so it does nothing for permission denials. Option D is wrong because `:exec` toggles whether binaries on the mount can be executed (noexec/nosuid behavior); it has no effect on SELinux write access.

Full explanation →

157

MCQhard

An administrator configures rootless Podman on RHEL 9. For container user namespace mapping to function correctly for a specific user account, entries must be present in which two system files?

A./etc/passwd and /etc/group

B./etc/containers/namespace.conf and /etc/containers/users.conf

C./etc/security/limits.conf and /etc/login.defs

D./etc/subuid and /etc/subgid

AnswerD

Rootless Podman relies on user namespaces, which map container UIDs and GIDs to unprivileged ranges on the host. The /etc/subuid and /etc/subgid files define each user's subordinate ID ranges, so the specific account must have entries there for that mapping to succeed.

Why this answer

Rootless user namespaces rely on /etc/subuid and /etc/subgid.

Full explanation →

158

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.

Full explanation →

159

Multi-Selecteasy

Which THREE commands are valid Podman subcommands for managing container networks? (Choose three)

Select 3 answers

A.podman network ls

B.podman network create

C.podman network restart

D.podman network upgrade

E.podman network inspect

AnswersA, B, E

`podman network ls` lists the networks configured in Podman's CNI or Netavark backend, satisfying the stem's requirement for a valid network-management subcommand. It enumerates existing networks with their names, IDs, drivers and creation timestamps, letting you verify which networks containers can attach to before running `podman network inspect` or `podman network create`.

Why this answer

Option A, 'podman network ls', is correct because it is the standard Podman subcommand that lists all configured container networks (equivalent to 'podman network list'), showing network names, IDs, drivers, and interfaces. Option B, 'podman network create', is correct because it creates a new container network, allowing options such as --driver, --subnet, and --gateway to define CNI or Netavark network configuration. Option E, 'podman network inspect', is correct because it outputs detailed JSON metadata about one or more named networks, including subnets, gateways, and connected containers.

Options C and D are not valid Podman subcommands: 'podman network restart' does not exist (networks are not restarted like services; containers are reconnected instead), and 'podman network upgrade' is not a Podman command, as network stack upgrades are handled through package management or 'podman system migrate' rather than a network subcommand.

Exam trap

EX188 often tests whether candidates confuse Docker-style subcommands with Podman's actual command set, so options like `restart` or `upgrade` are planted because they sound plausible but do not exist under `podman network`.

Full explanation →

160

MCQmedium

You need to configure container DNS servers explicitly when running a container, overriding the host's /etc/resolv.conf settings. Which Podman flag do you use?

A.--resolv-conf custom

B.--nameserver 8.8.8.8

C.--dns-search 8.8.8.8

D.--dns 8.8.8.8

AnswerD

`--dns 8.8.8.8` injects the specified resolver directly into the container's `/etc/resolv.conf`, overriding the host's settings. Podman accepts repeatable `--dns` flags for multiple servers, satisfying the requirement to configure DNS explicitly at container runtime rather than inheriting host configuration.

Why this answer

The '--dns' flag on 'podman run' explicitly sets the DNS server(s) inside the container's /etc/resolv.conf, overriding what would otherwise be inherited from the host. Passing '--dns 8.8.8.8' makes the container use Google's public resolver for name lookups, regardless of the host's resolver configuration.

Exam trap

EX188 often tests the confusion between '--dns' (nameserver IP) and '--dns-search' (domain suffix), luring candidates to pick the search flag for setting a resolver address.

How to eliminate wrong answers

Option A is wrong because '--resolv-conf custom' is not a valid Podman flag; the actual flag is '--dns' (and there is a '--dns-search' and '--dns-option' for related settings), so this option invents a nonexistent syntax. Option B is wrong because '--nameserver' is not a Podman run flag — that is a resolv.conf directive name, not a CLI option. Option C is wrong because '--dns-search' sets the search domain suffix (e.g., example.com), not a nameserver IP; passing an IP to it is a misuse and would not configure DNS servers.

Full explanation →

161

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.

Full explanation →

162

MCQmedium

An operator wants to create a custom user-defined bridge network named 'app-net' with a specific subnet of '192.168.100.0/24' using Podman. Which command is correct?

A.podman bridge create app-net --subnet 192.168.100.0/24

B.podman network create --subnet 192.168.100.0/24 app-net

C.podman create network --ip 192.168.100.0/24 app-net

D.podman network new --subnet=192.168.100.0/24 app-net

AnswerB

The --subnet flag sets the custom CIDR, and the trailing positional argument names the network. Podman's network create syntax requires the subnet before the name, so this command produces the 'app-net' bridge with 192.168.100.0/24 as requested.

Why this answer

'podman network create --subnet 192.168.100.0/24 app-net' is the correct syntax: the '--subnet' flag specifies the CIDR, and the network name follows as the positional argument. This creates a user-defined bridge network with the specified subnet.

Exam trap

EX188 often tests command word order — candidates may pick 'podman create network' or 'podman network new' because they sound plausible, but Podman's grammar is strictly 'podman <resource> <verb>'.

How to eliminate wrong answers

Option A is wrong because 'podman bridge create' is not a valid command — bridge networks are created via 'podman network create' with the default bridge driver, not a separate 'bridge' subcommand. Option C is wrong because 'podman create network' reverses the command structure; 'create' is a container subcommand, and 'network' must come first. Option D is wrong because 'podman network new' is not a valid subcommand — Podman uses 'create', not 'new'.

Full explanation →

163

MCQmedium

By default, podman build executes build instructions using the root user. You want to switch the execution context to a non-privileged user named 'appuser' for all subsequent RUN, CMD, and ENTRYPOINT instructions. Which instruction should you use?

A.USER

B.LOGIN

C.SU

D.ACCOUNT

AnswerA

The USER instruction sets the execution identity for subsequent RUN, CMD and ENTRYPOINT instructions within the image, satisfying the stem's requirement to switch from root to the non-privileged 'appuser' account. Unlike WORKDIR or ENV, USER changes the UID/GID context, so later build steps and container runtime processes run unprivileged.

Why this answer

The USER instruction in a Containerfile sets the UID (and optionally GID) that subsequent RUN, CMD, and ENTRYPOINT instructions execute as, and it also sets the default user for the running container. Placing USER appuser before the relevant instructions switches the execution context to that non-privileged account.

Exam trap

EX188 often tests whether candidates confuse Linux commands (su, login) with Containerfile instructions — only USER is a valid build directive for changing execution context.

How to eliminate wrong answers

Option B is wrong because LOGIN is not a valid Containerfile instruction — there is no such directive in the OCI/Dockerfile specification. Option C is wrong because SU is a Linux command, not a Containerfile instruction; you cannot use it as a build directive. Option D is wrong because ACCOUNT is not a Containerfile instruction — it is a fabricated keyword with no meaning to podman build.

Full explanation →

164

MCQeasy

How do you list all available Podman networks on your system?

A.podman network ls

B.podman network list

C.podman network status

D.podman network show

AnswerA

`podman network ls` queries Podman's local network backend and prints every configured network, including the default podman network, satisfying the requirement to list all available networks. It reads the same CNI or Netavark configuration used at container start, so the output reflects exactly what `podman run --network` accepts.

Why this answer

'podman network ls' is the correct command to list all Podman networks. The 'ls' subcommand is the standard Podman verb for listing resources, consistent with 'podman volume ls', 'podman image ls', and 'podman container ls'.

Exam trap

The trap is assuming 'list' is a valid long form — Podman consistently uses 'ls' across all resource types, and candidates who guess 'list' or 'show' fall for the distractor.

How to eliminate wrong answers

Option B is wrong because 'podman network list' is not a valid subcommand — Podman uses the abbreviated 'ls' form, not the full word 'list'. Option C is wrong because 'podman network status' does not exist; there is no 'status' verb under 'podman network'. Option D is wrong because 'podman network show' is not a valid subcommand — network details are retrieved with 'podman network inspect', not 'show'.

Full explanation →

165

MCQhard

When configuring an environment file for use with '--env-file', how are comment lines designated?

A.Using '//' at the beginning of the line

B.Using '#' at the beginning of the line

C.Using ';' at the beginning of the line

D.Using '/* ... */' block syntax

AnswerB

In an environment file, any line beginning with '#' is treated as a comment and ignored when parsed by '--env-file', so it never becomes a key-value variable. This lets teams annotate configuration without affecting the container's runtime environment.

Why this answer

In an environment file used with --env-file, comment lines are designated with a '#' at the beginning of the line. Podman (and Docker) parse these files line by line, treating lines starting with # as comments and ignoring them. This matches common shell-style and .env file conventions.

Exam trap

EX188 often tests the comment character for env files, and candidates confuse it with ';' from INI files or '//' from programming languages.

How to eliminate wrong answers

Option A is wrong because '//' is a comment syntax used in languages like C++ and JavaScript, not in env files. Option C is wrong because ';' is used in INI files and some configuration formats, but not in podman env files. Option D is wrong because '/* ... */' is C-style block comment syntax and is not supported in env files, which are line-oriented.

Full explanation →

166

Multi-Selectmedium

Which THREE features or characteristics distinguish the ADD instruction from the COPY instruction in a Containerfile? (Choose three.)

Select 3 answers

A.ADD can automatically extract local compressed tar archive files into the destination directory.

B.ADD requires the source file to be located within a git repository, unlike COPY.

C.COPY supports remote URLs natively just like ADD.

D.ADD supports fetching files directly from remote URLs.

E.COPY is generally recommended over ADD for simple file copying due to its predictable, transparent behavior.

AnswersA, D, E

ADD unpacks a recognised local compressed tar archive (gzip, bzip2 or xz) directly into the destination path, satisfying the stem's requirement for a distinguishing characteristic. COPY merely transfers files verbatim, performing no extraction, so archive handling is an axis unique to ADD.

Why this answer

Option A is correct because ADD automatically unpacks recognized local compressed tar archives (e.g., .tar, .tar.gz, .tgz, .tar.bz2, .tar.xz) into the destination directory, whereas COPY just places the file as-is. Option D is correct because ADD can fetch files directly from remote HTTP/HTTPS URLs, a capability COPY does not have. Option E is correct because COPY is preferred for straightforward file copying since its behavior is explicit and predictable, avoiding ADD's implicit extraction and remote-fetch side effects.

Option B is wrong because neither ADD nor COPY requires the source to be in a git repository. Option C is wrong because COPY does not support remote URLs natively; only ADD does.

Exam trap

EX188 often tests the misconception that COPY supports remote URLs like ADD, or that ADD requires git; the real distinctions are tar auto-extraction, URL fetch, and COPY's predictability.

Full explanation →

167

MCQeasy

A user wants to save a locally stored container image to a tar archive file to transfer it across systems without a registry. Which command should they use?

A.podman export -o image.tar container_name

B.podman backup image_name

C.podman dump image_name

D.podman save -o image.tar image_name

AnswerD

`podman save -o image.tar image_name` writes the local image directly to a tar archive, satisfying the requirement to transfer without a registry. Unlike `podman export`, which flattens a container's filesystem, `save` preserves image layers and metadata, so the archive can be reloaded intact via `podman load` on the target system.

Why this answer

'podman save -o image.tar image_name' exports a locally stored image to a tar archive, preserving all layers and metadata. This is the correct command for transferring images between systems without a registry.

Exam trap

EX188 often tests the confusion between 'podman save' (image to tar) and 'podman export' (container filesystem to tar) — candidates pick 'export' because it also produces a tar, but it operates on containers, not images.

How to eliminate wrong answers

Option A is wrong because 'podman export' exports a container's filesystem (a flat tar of the container's rootfs), not an image — it loses layer history and metadata, and it requires a container name, not an image. Option B is wrong because 'podman backup' is not a valid Podman command. Option C is wrong because 'podman dump' is not a valid Podman command — there is no 'dump' subcommand for images.

Full explanation →

168

MCQhard

A security administrator is implementing image signature verification on RHEL 9. Where is the default system-wide signature policy file located?

A./etc/containers/signatures.yaml

B.~/.config/containers/policy.json

C./etc/containers/policy.json

D./etc/containers/registries.conf

AnswerC

/etc/containers/policy.json is the system-wide policy file that container tooling such as Podman and Skopeo consult by default when deciding whether to accept an image. It defines which registries and signatures are trusted, satisfying RHEL 9's requirement for image signature verification without per-user configuration.

Why this answer

The default system-wide signature policy file for container image verification on RHEL 9 is located at /etc/containers/policy.json. This file defines the policy for validating image signatures using tools like podman and skopeo.

Exam trap

EX188 often tests the location of configuration files, and candidates confuse policy.json with registries.conf or user-specific configs.

How to eliminate wrong answers

Option A is wrong because /etc/containers/signatures.yaml is not the default policy file; it might be confused with a signature store configuration. Option B is wrong because ~/.config/containers/policy.json is a user-specific policy file, not system-wide. Option D is wrong because /etc/containers/registries.conf is used to configure registry access, not signature policies.

Full explanation →

169

MCQhard

You need to configure a container port mapping in Podman Compose so that host port 80 forwards to container port 8080. Which YAML syntax is correct under the service definition?

A.publish: - 80->8080

B.ports: - "80:8080"

C.expose: - "80:8080"

D.ports: container: 8080 host: 80

AnswerB

The `ports` list maps host to container as `"host:container"`, so `"80:8080"` forwards host port 80 to container port 8080, satisfying the stem's requirement. Quoting the value prevents YAML parsing it as a sexagesimal integer, which would corrupt the mapping. Podman Compose accepts this short syntax directly under the service definition.

Why this answer

In Podman Compose (and Docker Compose), the ports key under a service takes a list of strings in the form "HOST:CONTAINER" to publish a container port on the host. So "80:8080" maps host port 80 to container port 8080. The quotes are recommended because YAML can misinterpret bare numbers containing colons.

Exam trap

EX188 often tests the confusion between ports: (publishes to host) and expose: (internal only), and candidates who remember Docker's arrow notation or invent a mapping-style syntax pick the wrong option.

How to eliminate wrong answers

Option A is wrong because publish: is not a valid Compose service key, and the 80->8080 arrow syntax is not used by Compose (it resembles Podman's -p 80:8080 but with the wrong separator). Option C is wrong because expose: only documents ports that the container listens on for inter-container communication; it does not publish them to the host and does not accept host:container syntax. Option D is wrong because ports: must be a list of strings, not a mapping with container: and host: keys — that structure is not part of the Compose specification.

Full explanation →

170

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.

Full explanation →

171

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.

Full explanation →

172

Multi-Selectmedium

Which TWO conditions are typically required for rootless container users to successfully map UIDs and GIDs from host accounts to container accounts? (Choose two.)

Select 2 answers

A.The user account must have assigned ranges in /etc/subuid and /etc/subgid.

B.The user must have root privileges via sudo on the host system.

C.The kernel must support user namespaces (which is enabled by default in RHEL 9).

D.The storage driver must be set to vfs exclusively.

E.SELinux must be set to disabled mode globally.

AnswersA, C

Rootless mapping requires each user to own subordinate ID ranges defined in /etc/subuid and /etc/subgid. Without these entries, newuidmap and newgidmap cannot translate container IDs to host IDs, so the mapping the scenario requires fails.

Why this answer

Option A is correct because rootless containers rely on subordinate UID/GID mappings, which are defined per-user in /etc/subuid and /etc/subgid; without an assigned range, the user namespace cannot map container IDs to unprivileged host IDs. Option C is correct because user namespaces are the kernel feature that makes rootless UID/GID mapping possible, and on RHEL 9 this support is enabled by default. Option B is incorrect because rootless containers are specifically designed to run without root or sudo privileges on the host.

Option D is incorrect because the vfs storage driver is not required for UID/GID mapping and is generally used only as a fallback due to poor performance. Option E is incorrect because disabling SELinux globally is not a prerequisite for rootless containers and would weaken host security.

Exam trap

EX188 often tests the prerequisites for rootless containers; candidates incorrectly assume root privileges or sudo are needed, or that SELinux must be disabled, when the real requirements are subuid/subgid ranges and kernel user namespace support.

Full explanation →

173

MCQmedium

You are deploying a container and want to bind its published port exclusively to the loopback interface (127.0.0.1) on the host to prevent external network access. Which syntax is correct?

A.-p 127.0.0.1:8080:80

B.-p 8080:80@127.0.0.1

C.-p 80:80 --host-ip 127.0.0.1

D.--bind-ip 127.0.0.1 -p 8080:80

AnswerA

Binding to 127.0.0.1 restricts the published port to the host's loopback interface, so only local processes can reach container port 80 via host port 8080. This satisfies the stem's requirement to prevent external network access, unlike `-p 8080:80`, which binds all interfaces.

Why this answer

The -p flag accepts an optional host IP prefix in the form [hostIP:]hostPort:containerPort. Specifying 127.0.0.1:8080:80 binds the published port only to the loopback interface, so only processes on the host itself can reach the container's port 80 via host port 8080. This is the standard Docker/Podman port-publishing syntax and is the only option that places the IP in the correct position.

Exam trap

The trap here is that candidates invent plausible-sounding flags like --host-ip or --bind-ip, or misplace the IP after the port mapping; EX188 often tests whether you know the exact [hostIP:]hostPort:containerPort ordering of the -p argument.

How to eliminate wrong answers

Option B is wrong because '@127.0.0.1' is not valid syntax — the '@' character has no meaning in the -p/--publish argument and would cause Podman to reject the value. Option C is wrong because --host-ip is not a real Podman flag; binding is controlled entirely through the -p argument's host-IP prefix. Option D is wrong because --bind-ip is not a Podman option — the correct mechanism is embedding the IP inside the -p value, not a separate flag.

Full explanation →

174

MCQmedium

An administrator wants to bind mount a host file directly into a container as a configuration file. Is this supported in Podman?

A.Yes, Podman supports bind mounting individual files from the host.

B.No, bind mounts are restricted to named volumes only.

C.No, Podman only supports bind mounting entire directories.

D.Yes, but only if the file is located inside /var/lib/containers.

AnswerA

Podman's bind mount mechanism operates at the file level, not just directories, so a single host file can be mapped to a container path. This suits injecting a configuration file without mounting an entire directory, and the mount is read-write by default unless :ro is appended.

Why this answer

Podman supports bind mounting individual files from the host into a container using the -v or --mount flag, e.g., `podman run -v /host/config.conf:/etc/config.conf:Z`. This is a standard OCI runtime feature and is fully supported.

Exam trap

The trap is assuming that bind mounts only work for directories, or that Podman restricts file mounts to specific paths; candidates may overthink SELinux or storage graph locations.

How to eliminate wrong answers

Option B is wrong because bind mounts are not restricted to named volumes; Podman supports both bind mounts and named volumes. Option C is wrong because Podman supports bind mounting both directories and individual files. Option D is wrong because there is no requirement for the file to be under /var/lib/containers; that directory is for Podman's internal storage, not a restriction for bind mounts.

Full explanation →

175

MCQmedium

You are deploying a three-tier application with Podman Compose. The web service must resolve the database service by the name 'db' on the Compose-created network, and you want the web service to keep that name after container restarts. Which action ensures the 'db' alias is resolvable by the web container on the Compose network?

A.Set 'network_mode: host' on the web service so it uses the host resolver for the 'db' name.

B.Publish the database port with 'ports:' and have the web service connect to 'host.containers.internal'.

C.Create a user-defined network in the Compose file and attach both services to it; Compose registers each service name as a DNS alias on that network.

D.Add a 'links:' entry under the web service that lists 'db' with its container name.

AnswerC

When services are attached to the same user-defined network created by Podman Compose, Podman's embedded DNS (dnsname plugin) registers each service name and its aliases as resolvable names inside that network. The web container can then resolve 'db' by the service name defined in the Compose file, and this resolution persists across container restarts as long as the network remains.

Why this answer

Attaching both services to the same user-defined Compose network is what makes service names resolvable. Podman's embedded DNS registers each service name and any declared aliases on that network, so the web container can reach the database as 'db' without static host entries or host port publishing. This also keeps the traffic on the isolated bridge and survives container recreation.

Exam trap

The trap here is assuming that declaring 'links' or publishing ports is what makes a service name resolvable, when in Podman Compose the service-name DNS comes from attaching containers to the same user-defined network.

Full explanation →

176

MCQeasy

You have a file named config.env containing multiple KEY=VALUE pairs. Which flag allows you to load these configurations into a container as environment variables?

A.--config-file config.env

B.--volume config.env:/etc/env

C.--secret file=config.env

D.--env-file config.env

AnswerD

The --env-file flag reads a file of KEY=VALUE pairs and injects each as an environment variable inside the container, satisfying the requirement to load config.env without passing individual -e flags. Docker parses the file line by line at container start.

Why this answer

The --env-file flag allows you to specify a file containing KEY=VALUE pairs that will be loaded as environment variables in the container. This is the standard way to pass multiple environment variables from a file. The file format is simple: each line is a KEY=VALUE pair, and comments are supported with #.

Exam trap

EX188 often tests the confusion between --env-file (for environment variables) and --secret or --volume (for files), leading candidates to choose a file-mounting option.

How to eliminate wrong answers

Option A is wrong because --config-file is not a valid Podman flag for environment variables; it might be confused with Docker Compose or other tools. Option B is wrong because --volume mounts the file into the container as a file, not as environment variables; the application would need to read the file itself. Option C is wrong because --secret is used to mount secrets as files, not to load environment variables from a file.

Full explanation →

177

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.

Full explanation →

178

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.

Full explanation →

179

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.

Full explanation →

180

MCQhard

You need to completely remove a custom user-defined bridge network named 'test-net' that has no active containers attached to it. Which command performs this action?

A.podman network prune --force

B.podman network rm test-net

C.podman rm network test-net

D.podman network delete test-net

AnswerB

The podman network rm command deletes a named user-defined bridge network, and it succeeds here because no containers remain attached. Removing the network directly is the correct action rather than pruning or disconnecting containers first.

Why this answer

'podman network rm test-net' removes the specified user-defined network. Since the network has no active containers attached, the removal succeeds immediately; if containers were attached, Podman would refuse unless forced. This is the direct, correct command for deleting a named network.

Exam trap

EX188 often tests the confusion between 'podman rm' (removes containers) and 'podman network rm' (removes networks), plus the invented 'delete' verb, to catch candidates who guess at syntax.

How to eliminate wrong answers

Option A is wrong because 'podman network prune' removes all unused networks at once, not a specific named one — it is a bulk cleanup, not targeted removal, and '--force' is not the correct way to name a network. Option C is wrong because 'podman rm network test-net' uses the container-removal command 'podman rm' with an invalid argument; 'podman rm' removes containers, not networks, so this syntax fails. Option D is wrong because 'podman network delete' is not a valid subcommand — the correct verb is 'rm' (remove), not 'delete'.

Full explanation →

181

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.

Full explanation →

182

MCQeasy

Which command removes all unused Podman networks that are not currently connected to any containers?

A.podman network prune

B.podman network clean

C.podman network rm --unused

D.podman prune networks

AnswerA

podman network prune removes all networks not connected to any container, exactly matching the requirement. Other network subcommands list, inspect or create networks but do not delete unused ones, so they fail the stated condition.

Why this answer

'podman network prune' deletes unused networks.

Full explanation →

183

Multi-Selecteasy

When configuring container networking in Podman, which TWO built-in network modes are available by default without creating custom networks? (Choose two)

Select 2 answers

A.bridge

B.host

C.macvlan

D.routed

E.overlay

AnswersA, B

Bridge mode is a default Podman network mode, providing NAT-based connectivity between containers and the host on an isolated virtual network. It satisfies the requirement for a built-in mode available without creating custom networks, alongside slirp4netns/pasta.

Why this answer

Option A (bridge) is correct because Podman ships with a default bridge network (named 'podman') that containers attach to by default, providing NAT-based connectivity and inter-container communication on the host. Option B (host) is correct because Podman supports the host network mode out of the box, where the container shares the host's network namespace and uses the host's IP stack directly. Options C (macvlan), D (routed), and E (overlay) are not default built-in modes: macvlan and overlay typically require creating a custom network with specific drivers, and routed is not a standard Podman network mode available without additional configuration.

Exam trap

EX188 often tests whether candidates confuse default built-in network modes (bridge, host) with driver types that require explicit creation (macvlan, overlay, routed).

Full explanation →

184

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.

Full explanation →

185

Multi-Selecteasy

Which TWO statements are true regarding the EXPOSE instruction in a Containerfile? (Choose two.)

Select 2 answers

A.It informs Podman that the container listens on the specified network ports at runtime.

B.It replaces the need to define environment variables for port configuration.

C.It enforces strict firewall rules inside the container network namespace, blocking unexposed ports.

D.It acts as a type of documentation between the image creator and container operator.

E.It automatically publishes all exposed ports to random host ports without needing the -p or -P flag.

AnswersA, D

EXPOSE documents the ports the containerised process listens on, letting Podman and other tooling know which network ports are intended for publication. It satisfies the stem's requirement by declaring runtime listening intent as image metadata, though it does not itself publish the port or alter firewall rules.

Why this answer

Option A is correct because EXPOSE in a Containerfile declares the network ports the containerized application listens on at runtime, and Podman records this metadata so tools like podman inspect and podman run -P can use it. Option D is correct because EXPOSE serves primarily as documentation between the image creator and the container operator, indicating intended listening ports without actually opening or publishing them. Option B is wrong because EXPOSE has no relationship to environment variables; port configuration via env vars is a separate application-level concern.

Option C is wrong because EXPOSE does not create or enforce firewall rules in the container network namespace and does not block unexposed ports. Option E is wrong because EXPOSE alone does not publish ports to the host; publishing requires -p for explicit mapping or -P to publish all exposed ports to random host ports.

Exam trap

EX188 often tests the misconception that EXPOSE actually publishes or enforces ports; candidates confuse declarative metadata with runtime port publishing (-p/-P) and firewall enforcement.

Full explanation →

186

MCQmedium

An administrator needs to run a container that requires access to the host's network stack directly, bypassing network isolation. Which flag should be passed to 'podman run'?

A.--share network

B.--network host

C.--privileged

D.--net bridge

AnswerB

The --network host flag attaches the container directly to the host's network namespace, removing the default bridge isolation and giving it the host's interfaces and IP addresses. That satisfies the requirement to bypass network isolation.

Why this answer

The `--network host` flag makes the container share the host's network namespace, so it uses the host's IP address, routing table, and ports directly without network isolation. This is the correct way to bypass network isolation and give the container direct access to the host network stack.

Exam trap

EX188 often tests whether candidates confuse --privileged with --network host, assuming that privileged mode automatically grants host network access when it does not.

How to eliminate wrong answers

Option A is wrong because `--share network` is not a valid Podman flag for network sharing; --share is used for sharing namespaces like IPC, UTS, or PID, but network sharing is controlled via --network. Option C is wrong because `--privileged` grants extensive capabilities and device access but does not by itself put the container on the host network; a privileged container still uses its own network namespace unless --network host is also specified. Option D is wrong because `--net bridge` (or --network bridge) attaches the container to the default bridge network, which is an isolated network, not the host stack.

Full explanation →

187

Multi-Selectmedium

An administrator is preparing a Podman container that requires persistent storage for a web application. The storage must survive container restarts and be easily backed up. Which two types of storage mechanisms should the administrator consider? (Choose two.)

Select 2 answers

A.Anonymous volumes

B.Bind mounts from the host filesystem

C.tmpfs mounts

D.Named volumes managed by Podman

E.The container's writable layer

AnswersB, D

Bind mounts map a host directory or file directly into the container. The data resides on the host filesystem, so it persists beyond container lifecycles and can be backed up using standard host tools. They are suitable for persistent storage, especially when the data needs to be accessed or managed directly on the host. However, they require careful permission and SELinux configuration.

Why this answer

Named volumes and bind mounts are the two primary mechanisms for persistent storage in Podman. Named volumes are managed by Podman and persist independently, while bind mounts use host directories that persist on the host. The other options are either ephemeral or not designed for long-term persistence.

Exam trap

The trap here is thinking that anonymous volumes are a reliable persistent storage option, but they are difficult to manage and often removed with the container.

Full explanation →

188

Multi-Selecthard

You are writing a Containerfile for a Python web service. You want the image build to install dependencies and then run the service with predictable behavior across environments. Which TWO practices correctly apply build-time and runtime configuration in the Containerfile? (Choose two.)

Select 2 answers

A.Use ARG to declare a build-time variable such as APP_VERSION, then reference it in a RUN instruction to fetch the matching artifact.

B.Use ENV to set APP_VERSION and reference it in a RUN instruction to fetch the matching artifact.

C.Use ARG to set APP_PORT so the service can read it at runtime.

D.Use LABEL to set APP_PORT so the service can read it at runtime.

E.Use ENV to set a runtime variable such as APP_PORT so the service reads it when the container starts.

AnswersA, E

ARG declares variables that are available only during the build and can be referenced in instructions like RUN to influence what gets installed. This is appropriate for values such as a version or a package channel that affect the build result. The value is not persisted as a runtime environment variable, so it does not leak into the running container unless explicitly re-declared.

Why this answer

Build-time parameters that affect what is installed belong in ARG, while runtime configuration that the service reads on startup belongs in ENV. ARG keeps values out of the final runtime environment, and ENV makes defaults available to the process while still allowing overrides at podman run time. Using each instruction for its intended purpose yields predictable builds and predictable runtime behavior.

Exam trap

The trap here is treating ARG and ENV as interchangeable, when ARG is build-only and ENV persists into the running container.

Full explanation →

189

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

Full explanation →

190

MCQhard

How does Podman's rootless build architecture handle volume mounts or privileged operations specified within a RUN instruction in a Containerfile?

A.Rootless builds cannot execute RUN instructions that install RPM packages using dnf.

B.Rootless builds execute within user namespaces, mapping root inside the container to an unprivileged user on the host, restricting certain host-level operations.

C.Rootless builds automatically elevate privileges via sudo when a RUN instruction requires root access.

D.Rootless builds require the buildah daemon to be running as root in systemd.

AnswerB

Rootless builds run inside user namespaces, so root within the container maps to an unprivileged host UID. Privileged operations and host volume mounts are therefore constrained, since the build process lacks real host root privileges.

Why this answer

Podman rootless builds run inside a user namespace where the container's UID 0 is mapped to the invoking unprivileged user's UID on the host (via /etc/subuid and /etc/subgid ranges). This means RUN instructions that appear to run as root inside the build actually execute as an unprivileged user on the host, so operations requiring real host privileges — mounting block devices, changing host ownership outside the mapped range, or binding to privileged ports — are restricted or fail.

Exam trap

EX188 often tests the misconception that rootless builds cannot install packages or run privileged-looking commands at all, when in fact only host-level privileged operations are blocked — package installation inside the container filesystem works normally.

How to eliminate wrong answers

Option A is wrong because rootless builds can absolutely run dnf install inside a RUN instruction — package installation writes only to the container's own filesystem layer, which is permitted within the user namespace; the restriction is on host-level operations, not on package managers. Option C is wrong because Podman rootless builds never silently escalate via sudo; doing so would defeat the security model, and any elevation must be explicitly configured by the user outside the build. Option D is wrong because Podman is daemonless by design — there is no buildah daemon, and rootless builds do not require a root-owned systemd service; buildah runs as the invoking user.

Full explanation →

191

MCQmedium

An administrator needs to create a temporary filesystem mount stored purely in host memory for high-performance temporary data inside a container. Which mount type should be used?

A.podman run --ramdisk /app/cache myapp

B.podman run --mount type=memory,destination=/app/cache myapp

C.podman run --memory-mount /app/cache myapp

D.podman run --tmpfs /app/cache myapp

AnswerD

The --tmpfs flag mounts a memory-backed filesystem inside the container, storing data in host RAM rather than on disk. This delivers the high-performance temporary storage the scenario requires, and contents vanish when the container stops.

Why this answer

The --tmpfs flag in podman run mounts a tmpfs filesystem at the specified container path, backed entirely by host memory (and swap if enabled). This is the standard, documented way to provide high-performance ephemeral storage inside a container. tmpfs contents are lost when the container stops, which matches the 'temporary' requirement.

Exam trap

EX188 often tests whether candidates invent plausible-sounding but nonexistent flags like --ramdisk or --memory-mount, or confuse memory cgroup limits (--memory) with memory-backed mounts (--tmpfs).

How to eliminate wrong answers

Option A is wrong because --ramdisk is not a valid podman run flag — no such option exists in Podman's CLI. Option B is wrong because --mount type=memory is not a supported mount type; valid types are bind, volume, tmpfs, image, devpts, and glob. Option C is wrong because --memory-mount is not a Podman flag; memory-related flags are --memory and --memory-swap, which control cgroup limits, not mounts.

Full explanation →

192

MCQeasy

Which flag can be passed to 'podman run' to automatically remove the container and its anonymous volumes upon exit?

A.podman run --delete-on-exit

B.podman run --clean

C.podman run --rm

D.podman run --purge

AnswerC

The --rm flag deletes the container automatically once it exits, and it also removes any anonymous volumes created with -v that were not given a name. This satisfies the requirement to clean up both the container and its anonymous volumes without manual pruning.

Why this answer

The --rm flag in podman run tells Podman to automatically remove the container and its anonymous volumes when the container exits. This is equivalent to the --rm flag in Docker and is commonly used for ephemeral containers. It helps keep the system clean by removing stopped containers and their associated anonymous volumes.

Exam trap

EX188 often tests the confusion between --rm and other cleanup flags like --delete or --purge, which do not exist in Podman.

How to eliminate wrong answers

Option A is wrong because --delete-on-exit is not a valid Podman flag; the correct flag is --rm. Option B is wrong because --clean is not a valid Podman run flag; it might be confused with podman system prune or similar cleanup commands. Option D is wrong because --purge is not a valid Podman flag; it is not used for container removal on exit.

Full explanation →

193

MCQeasy

You are troubleshooting a container that should have no network access whatsoever for security isolation. Which networking option should you apply?

A.--network isolated

B.--network bridge

C.--network host

D.--network none

AnswerD

The --network none option attaches the container to no network namespace at all, leaving only a loopback interface. This enforces complete isolation, satisfying the requirement for zero network access, unlike bridge or host modes which still permit connectivity.

Why this answer

`--network none` is the Podman option that places the container in an isolated network namespace containing only the loopback interface, providing complete network isolation. This is exactly what is required when a container must have no network access whatsoever for security reasons. It removes all external interfaces and prevents any inbound or outbound traffic beyond the container itself.

Exam trap

EX188 often tests whether candidates pick a plausible-sounding but nonexistent mode like 'isolated' instead of the actual Podman keyword 'none' for full network isolation.

How to eliminate wrong answers

Option A is wrong because `--network isolated` is not a valid Podman network mode — no such keyword exists in the Podman CLI. Option B is wrong because `--network bridge` attaches the container to the default podman0 bridge with NAT, giving it outbound network access, which violates the isolation requirement. Option C is wrong because `--network host` shares the host's network namespace, giving the container full access to host interfaces — the opposite of isolation.

Full explanation →

194

Multi-Selecteasy

Which TWO instructions in a Containerfile can be used to set metadata or default execution parameters that influence how a container runs? (Choose two.)

Select 2 answers

A.RUN

B.CMD

C.ENTRYPOINT

D.COPY

E.FROM

AnswersB, C

CMD supplies the default command executed when a container starts, and it is overridden by arguments passed at runtime. This satisfies the stem's requirement for a default execution parameter, complementing ENTRYPOINT, which defines the fixed executable that CMD arguments feed into.

Why this answer

CMD [CORRECT] is right because it sets the default command (and/or default arguments) that the container executes when it starts if no command is supplied at runtime, directly influencing how the container runs. ENTRYPOINT [CORRECT] is also right because it configures the executable that the container always runs, defining the container's primary process and default execution behavior. Both are runtime metadata instructions stored in the image config, unlike build-time instructions.

RUN (A) executes commands during image build to create layers and does not set runtime defaults. COPY (D) only copies files from the build context into the image filesystem. FROM (E) merely specifies the base image for the build stage and has no role in runtime execution parameters.

Exam trap

EX188 often tests the build-time versus runtime distinction, tricking candidates into selecting RUN because it appears to 'do something' with commands, when only CMD and ENTRYPOINT affect how the container runs.

Full explanation →

195

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

Full explanation →

196

Multi-Selecteasy

Which TWO types of storage mechanisms are natively supported by Podman for container data persistence? (Choose two.)

Select 2 answers

A.Shared memory block devices via NFS exports

B.Host bind mounts referencing directories on the host filesystem

C.Direct Fibre Channel LUN mapping inside containers

D.Managed volumes stored in Podman's storage graph

E.Distributed HDFS cluster mounts

AnswersB, D

Host bind mounts map an existing host directory straight into the container, so data written by the process lands on the host filesystem and survives container removal. This satisfies the persistence requirement natively, without extra drivers or plugins, because the mount is handled directly by the kernel.

Why this answer

Option B is correct because Podman natively supports host bind mounts, where a directory or file on the host filesystem is mapped directly into the container using the -v or --mount flag (e.g., -v /host/path:/container/path), making it a first-class persistence mechanism. Option D is correct because Podman also natively supports managed named volumes, which are created and tracked in Podman's own storage graph (typically under /var/lib/containers/storage/volumes for root or ~/.local/share/containers/storage/volumes for rootless users) and persist independently of container lifecycle. Option A is not a native Podman storage mechanism; NFS exports would have to be mounted on the host first and then exposed via a bind mount, and shared memory block devices are not a Podman persistence type.

Option C is incorrect because direct Fibre Channel LUN mapping is a host-level storage concern handled by the OS, not something Podman natively provides to containers. Option E is incorrect because HDFS is a distributed filesystem service external to Podman and is not a natively supported container storage driver.

Exam trap

The trap is selecting exotic storage types like NFS or Fibre Channel because they sound enterprise-ready; candidates may forget that Podman's native persistence is limited to bind mounts and managed volumes.

Full explanation →

197

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.

Full explanation →

198

Multi-Selecthard

Which THREE inspection or cleanup actions can be performed on Podman secrets? (Choose THREE)

Select 3 answers

A.List existing secrets with 'podman secret ls'

B.Inspect secret metadata with 'podman secret inspect'

C.Compile secrets into binary format with 'podman secret compile'

D.Edit secret values in-place with 'podman secret edit'

E.Remove secrets with 'podman secret rm'

AnswersA, B, E

`podman secret ls` enumerates every secret stored in the Podman secret store, satisfying the inspection requirement. It queries the local secret database directly, returning names, IDs, and drivers without exposing secret values. This read-only listing is one of the three permitted inspection or cleanup actions, alongside `podman secret inspect` and `podman secret rm`.

Why this answer

Option A is correct because 'podman secret ls' is the standard subcommand that enumerates all secrets currently stored in Podman's secret store, showing IDs and names. Option B is correct because 'podman secret inspect' retrieves metadata about a secret (such as ID, name, driver, and timestamps) without exposing the secret payload. Option E is correct because 'podman secret rm' deletes one or more secrets from the store, which is the supported cleanup action.

Option C is not a real Podman subcommand; secrets are created via 'podman secret create' and are not compiled into a binary format. Option D is also invalid because Podman does not support editing secret values in place; secrets are immutable and must be removed and recreated to change their contents.

Exam trap

EX188 often tests the misconception that secrets can be edited in-place or compiled, when in fact they are immutable and only support list, inspect, create, and remove operations.

Full explanation →

199

MCQeasy

When writing a Containerfile, which instruction specifies the base image to be used for the subsequent build steps?

A.BASE

B.INIT

C.FROM

D.PARENT

AnswerC

FROM declares the base image from which subsequent build steps run, and it must be the first instruction in a stage. It satisfies the stem because every later instruction, such as RUN or COPY, executes against the filesystem and metadata established by that base image.

Why this answer

Every Containerfile must start with a FROM instruction to define the base image.

Full explanation →

200

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.

Full explanation →

201

MCQeasy

A developer wants to build a container image using podman build, but the Containerfile is named 'Customfile' and located in a subdirectory named 'dockerfiles'. Which command accomplishes this?

A.podman build -f dockerfiles/Customfile .

B.podman build --file-path dockerfiles/Customfile .

C.podman build -p dockerfiles/Customfile .

D.podman build --config dockerfiles/Customfile .

AnswerA

The -f flag overrides podman build's default Containerfile lookup, pointing it at dockerfiles/Customfile. The trailing dot supplies the build context, so podman reads instructions from that named file while resolving COPY and ADD paths relative to the current directory, satisfying both the non-standard filename and subdirectory location.

Why this answer

The `podman build` command uses the `-f` or `--file` flag to specify an alternative Containerfile. The correct syntax is `podman build -f dockerfiles/Customfile .`, where the path to the Containerfile is given relative to the current directory, and the build context is the current directory (`.`).

Exam trap

EX188 often tests the correct flag for specifying a Containerfile, and candidates may confuse `-f` with other flags like `--file-path` or `--config`.

How to eliminate wrong answers

Option B is wrong because `--file-path` is not a valid flag for `podman build`; the correct flag is `-f` or `--file`. Option C is wrong because `-p` is not a valid flag for specifying a Containerfile; it might be confused with `--pull` or other flags. Option D is wrong because `--config` is not a valid flag for specifying a Containerfile.

Full explanation →

202

MCQhard

You are optimizing image build times and notice that a specific RUN instruction fetching dependencies is re-running on every build, even though the requirements.txt file has not changed. What is causing this behavior?

A.The COPY requirements.txt instruction was placed after an instruction that introduces non-deterministic data or the build context files have modified timestamps.

B.The Containerfile lacks an explicit CACHE instruction at the top.

C.Podman disables caching by default for all RUN instructions containing package managers.

D.The USER instruction was set to root, which disables layer caching.

AnswerA

Docker caches each layer keyed on the instruction and its inputs. If COPY requirements.txt sits after a layer whose content or timestamps change, that layer's cache invalidates, forcing the subsequent RUN to re-execute even though requirements.txt itself is unchanged.

Why this answer

Docker/Podman layer caching invalidates a RUN layer when any preceding instruction's layer changes. If COPY requirements.txt comes after an instruction that produces non-deterministic output (e.g., a RUN that fetches latest packages or writes timestamps) or if build-context files have changed mtimes, the cache key for the COPY layer changes, invalidating all subsequent RUN layers including the dependency install.

Exam trap

EX188 often tests the misconception that a special CACHE instruction or a flag controls caching, when the real cause is instruction ordering and build-context file changes invalidating the cache key.

How to eliminate wrong answers

Option B is wrong because there is no 'CACHE' instruction in Containerfile syntax — caching is automatic and controlled by instruction ordering and content hashes, not an explicit directive. Option C is wrong because Podman does not disable caching for package-manager RUN instructions; caching applies uniformly unless '--no-cache' is passed. Option D is wrong because the USER instruction has no effect on layer caching — cache keys are based on instruction content and parent layer digests, not the runtime user.

Full explanation →

203

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.

Full explanation →

204

Multi-Selecteasy

Which TWO commands or flags are valid for managing Podman named volumes? (Choose TWO)

Select 2 answers

A.podman volume make

B.podman volume compile

C.podman volume build

D.podman volume create

E.podman volume ls

AnswersD, E

`podman volume create` provisions a named volume in Podman's local storage, satisfying the stem's requirement for a valid named-volume management command. It accepts flags such as `--driver` and `--label`, and the resulting volume persists independently of any container, unlike anonymous volumes created implicitly at runtime.

Why this answer

Option D, 'podman volume create', is correct because it is the actual Podman subcommand used to create a named volume, which can then be referenced by containers via the -v or --mount flag. Option E, 'podman volume ls', is correct because it lists all existing named volumes along with their driver and mountpoint, making it a valid management command. The other options do not belong: 'podman volume make' (A), 'podman volume compile' (B), and 'podman volume build' (C) are not real Podman subcommands and would return an unknown command error, since Podman's volume management verbs are create, ls, inspect, rm, and prune.

Exam trap

EX188 often tests basic Podman commands, and candidates may confuse volume subcommands with image or container subcommands, leading to invalid options like make or build.

Full explanation →

205

MCQmedium

An administrator needs to execute a package update and install dependencies during the podman build process, ensuring these commands are committed as a new layer in the final image. Which instruction accomplishes this?

A.EXEC

B.START

C.CMD

D.RUN

AnswerD

The RUN instruction executes shell commands during a build stage and commits the resulting filesystem changes as a new image layer. Package updates and dependency installs therefore persist in the final image, unlike CMD or ENTRYPOINT, which only define runtime behaviour.

Why this answer

`RUN` executes a command during the image build and commits the resulting filesystem changes as a new layer in the image. Using `RUN dnf update -y && dnf install -y <deps>` performs the package update and dependency install at build time, baking the results into the final image.

Exam trap

EX188 often tests build-time vs runtime instruction confusion — candidates pick `CMD` thinking it runs commands during build, when in fact only `RUN` executes at build time and commits a layer.

How to eliminate wrong answers

Option A is wrong because `EXEC` is not a Containerfile instruction — it resembles Kubernetes `exec` or a shell builtin but is not part of the Dockerfile/Containerfile grammar. Option B is wrong because `START` is not a valid Containerfile instruction; starting a process is a runtime concern handled by `CMD`/`ENTRYPOINT`, not a build directive. Option C is wrong because `CMD` sets the default command executed when a container starts from the image — it does not run at build time and does not create a layer.

Full explanation →

206

MCQmedium

You want to build an image that has a build-time argument named 'VERSION'. How do you declare this variable inside the Containerfile so it can be used during the build steps?

A.DEFINE VERSION

B.ARG VERSION

C.ENV VERSION=1.0

D.VAR VERSION

AnswerB

ARG declares a build-time variable that exists only during image construction, so the VERSION value can be referenced by RUN instructions in the Containerfile. Unlike ENV, it is not persisted into the running container, satisfying the build-time-only constraint in the stem.

Why this answer

ARG is the Containerfile instruction that declares a build-time variable, which can be populated with --build-arg at build time and referenced in subsequent RUN, COPY, or other instructions. It exists only during the build and is not persisted in the final image's runtime environment, which is exactly the semantics required for a build-time VERSION variable.

Exam trap

EX188 often tests the distinction between ARG (build-time, not persisted) and ENV (runtime, persisted in the image), catching candidates who pick ENV because it 'also works' during the build.

How to eliminate wrong answers

Option A is wrong because DEFINE is not a valid Containerfile instruction — it is a C preprocessor directive and has no meaning in image builds. Option C is wrong because ENV sets a persistent environment variable that is baked into the image and visible at runtime; while it can be used during the build, it is not the correct choice for a build-time-only argument and cannot be overridden with --build-arg. Option D is wrong because VAR is not a Containerfile instruction in any OCI/Dockerfile specification.

Full explanation →

207

MCQhard

You have created a Podman pod and want to launch two containers inside this pod so they share the same network namespace. How do you specify this during container creation?

A.podman run --pod mypod -d myimage

B.podman run --share-namespace mypod -d myimage

C.podman pod connect mypod myimage

D.podman run --network pod:mypod -d myimage

AnswerA

The --pod flag attaches the new container to an existing pod, so it joins that pod's shared network namespace and can reach sibling containers over localhost. This directly satisfies the requirement that both containers share one network namespace.

Why this answer

The --pod flag on podman run attaches a new container to an existing pod, and all containers in the same pod share the pod's network namespace (and by default its IPC and UTS namespaces). So podman run --pod mypod -d myimage launches the container inside the pod with shared networking. This is the standard way to add containers to a pod after the pod is created.

Exam trap

EX188 often tests the difference between attaching a container to a pod (--pod) and attaching it to a network (--network), and candidates who invent flags like --share-namespace or --network pod: fall for the distractor.

How to eliminate wrong answers

Option B is wrong because --share-namespace is not a valid podman run flag; namespace sharing is controlled by --pod or by explicit --net/--ipc/--uts flags. Option C is wrong because podman pod connect does not exist — the pod subcommands are create, start, stop, rm, ps, inspect, top, pause, unpause, and exists; there is no connect verb for attaching images. Option D is wrong because --network pod:mypod is not the documented syntax; the correct flag is --pod mypod (or --pod=name), and --network is used for CNI/netavark networks, not pods.

Full explanation →

208

MCQmedium

When writing a Containerfile, what is the difference between shell form and exec form for the CMD instruction?

A.There is no functional difference; they are syntactic aliases.

B.Exec form runs the executable directly without invoking a shell, making it receive Unix signals (like SIGTERM) properly as PID 1.

C.Shell form is required for multi-stage builds, while exec form is for single-stage builds.

D.Shell form runs the command as PID 1, while exec form spawns a bash shell wrapper.

AnswerB

Exec form passes the command as a JSON array, so the process runs directly as PID 1 without a shell wrapper. It therefore receives Unix signals such as SIGTERM itself, enabling graceful shutdown, whereas shell form spawns a shell that intercepts signals.

Why this answer

Exec form (JSON array syntax, e.g., CMD ["executable","arg1"]) runs the executable directly without a shell, so the process becomes PID 1 and receives Unix signals such as SIGTERM directly, enabling graceful shutdown. Shell form (CMD command arg1) wraps the command in /bin/sh -c, so the shell becomes PID 1 and may not forward signals to the child process. This distinction is critical for container lifecycle management.

Exam trap

EX188 often tests the misconception that shell form is 'more powerful' or that both forms behave identically, when the real differentiator is PID 1 signal handling and shell wrapping.

How to eliminate wrong answers

Option A is wrong because the two forms are not syntactic aliases; they differ in process invocation, signal handling, and variable expansion behavior. Option C is wrong because multi-stage builds are unrelated to CMD form; both forms work in any build stage, and multi-stage builds concern COPY --from and build stages, not CMD syntax. Option D is wrong because it reverses the behavior: shell form spawns a shell wrapper as PID 1, while exec form runs the executable directly as PID 1.

Full explanation →

209

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.

Full explanation →

210

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.

Full explanation →

211

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.

Full explanation →

212

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.

Full explanation →

213

MCQmedium

A developer needs to optimize image size by removing build caches and temporary package manager cache files within the same RUN instruction. Why must this be done in a single RUN instruction?

A.Because file deletions in separate layers do not reduce the final image size due to the layered filesystem.

B.Because package managers lock the database across different layers.

C.Because the container build engine will fail if cache cleanup happens in a separate layer.

D.To ensure environment variables persist between installation and cleanup.

AnswerA

Each RUN instruction creates an immutable layer; deleting files in a later layer only adds a whiteout marker, leaving the original bytes in the earlier layer and thus in the final image. Combining download, install, cache removal and cleanup in one RUN prevents those bytes from ever being committed.

Why this answer

Container images are built as a stack of immutable layers, and each RUN instruction creates a new layer. If files are created in one RUN and deleted in a later RUN, the deletion only adds a whiteout marker in the new layer; the original files remain in the earlier layer and still contribute to the final image size. Performing installation and cleanup in a single RUN ensures the temporary files never persist in any committed layer.

Exam trap

EX188 often tests the misconception that deleting files in a later layer reduces image size, when in fact the layered filesystem preserves the original data unless creation and deletion occur in the same RUN instruction.

How to eliminate wrong answers

Option B is wrong because package managers do not lock their database across separate RUN layers in a way that prevents cleanup; the issue is purely layer immutability, not database locking. Option C is wrong because the build engine does not fail when cleanup is in a separate layer; it simply produces a larger image. Option D is wrong because environment variables set with ENV persist across layers regardless of RUN grouping, and persistence is not the reason for combining commands.

Full explanation →

214

Multi-Selecteasy

Which TWO actions can be performed using the 'podman network' subcommand? (Choose two.)

Select 2 answers

A.start

B.build

C.ls

D.commit

E.rm

AnswersC, E

The podman network ls command lists all configured container networks, showing names, IDs, drivers and scope. This read-only action lets administrators inspect available networks before attaching containers, directly satisfying the subcommand's enumeration capability required by the question.

Why this answer

Option C (ls) is correct because 'podman network ls' lists all the container networks configured on the system, which is a core function of the 'podman network' subcommand. Option E (rm) is correct because 'podman network rm' removes one or more specified networks, another valid operation under the 'podman network' subcommand. The unmarked options do not belong: 'start' (A) is used with containers (e.g., 'podman start'), not networks; 'build' (B) is used to build images (e.g., 'podman build'), not networks; and 'commit' (D) creates an image from a container's changes (e.g., 'podman commit'), which is unrelated to network management.

Exam trap

EX188 often tests the distinction between subcommands for different Podman objects (containers, images, networks, volumes), so candidates must know which actions apply to which object type; confusing 'podman network' with 'podman container' or 'podman image' leads to selecting invalid options like 'start' or 'commit'.

Full explanation →

215

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.

Full explanation →

216

MCQeasy

A user needs to log out from a private container registry to remove stored credentials from their local machine. Which command accomplishes this?

A.podman logout registry.example.com

B.podman rm auth registry.example.com

C.podman clear-credentials registry.example.com

D.podman disconnect registry.example.com

AnswerA

`podman logout registry.example.com` clears the stored credentials for that specific registry from the local authentication file, satisfying the requirement to remove cached login details from the machine. Unlike `podman login`, which writes credentials, logout deletes the entry, so subsequent pulls prompt for authentication again.

Why this answer

'podman logout' removes stored credentials for a registry.

Full explanation →

217

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.

Full explanation →

218

MCQhard

You need to troubleshoot name resolution between containers on a custom network. Which backend service does Podman utilize by default for container DNS resolution in modern rootless setups?

A.nscd

B.aardvark-dns

C.dnsmasq

D.bind9

AnswerB

Aardvark-dns is Podman's default authoritative DNS server for custom container networks, resolving container names to their IP addresses. It runs per-network alongside Netavark, Podman's default network backend, and supports rootless operation without requiring root privileges. This satisfies the stem's requirement for the default DNS backend in modern rootless setups.

Why this answer

In modern rootless Podman setups, container name resolution on user-defined networks is handled by aardvark-dns, a lightweight authoritative DNS server that Podman launches per network. It reads container name/IP mappings from the network's configuration and answers A/AAAA queries from containers, enabling name-based communication without editing /etc/hosts.

Exam trap

EX188 often tests the assumption that Podman uses dnsmasq (as Docker historically did) for container DNS, when the modern rootless default is actually aardvark-dns.

How to eliminate wrong answers

Option A is wrong because nscd is a legacy glibc name-service cache daemon for the host, not a per-network container DNS resolver, and it is not used by Podman for container-to-container resolution. Option C is wrong because dnsmasq is a general-purpose DNS/DHCP forwarder commonly used by Docker-style setups or libvirt, but Podman's default modern backend is aardvark-dns, not dnsmasq. Option D is wrong because bind9 is a full external DNS server product; Podman does not embed or default to BIND for container name resolution.

Full explanation →

219

Multi-Selecteasy

When interacting with container registries using Podman, which THREE commands or tasks are valid operations supported natively by the Podman CLI? (Choose three.)

Select 3 answers

A.podman mount-registry --remote

B.podman compile-image --from-registry

C.podman pull registry.example.com/image:tag

D.podman push registry.example.com/image:tag

E.podman login registry.example.com

AnswersC, D, E

`podman pull` natively retrieves an image from any OCI-compliant registry, including private ones such as registry.example.com, authenticating via credentials stored in `${XDG_RUNTIME_DIR}/containers/auth.json`. This satisfies the stem's requirement for a registry interaction supported directly by the Podman CLI without additional tooling.

Why this answer

Option C (podman pull registry.example.com/image:tag) is correct because podman pull is the native Podman CLI command that downloads an image from a registry such as registry.example.com, resolving the image by name and tag. Option D (podman push registry.example.com/image:tag) is correct because podman push is the native command that uploads a local image to a remote registry, using the fully qualified image reference including the registry host and tag. Option E (podman login registry.example.com) is correct because podman login authenticates the CLI session against the specified registry, storing credentials (typically in ${XDG_RUNTIME_DIR}/containers/auth.json or ~/.docker/config.json) so that pull and push operations can access private repositories.

Options A and B are not valid Podman subcommands: there is no podman mount-registry command (mounting is done with podman mount on local containers/images) and no podman compile-image command, so neither performs any registry operation.

Exam trap

EX188 often tests command validity, and candidates pick fabricated verbs like mount-registry or compile-image because they sound like plausible Podman extensions.

Full explanation →

220

Multi-Selecteasy

Which THREE storage-related items can be inspected using 'podman system df'? (Choose THREE)

Select 3 answers

A.Networks

B.Images

C.Containers

D.Volumes

E.Secrets

AnswersB, C, D

'podman system df' reports disk usage across containers, images and volumes. Images are listed because their read-only layers consume the bulk of local storage, and the command shows total image size, shared layers and reclaimable space, making images one of the three items the question requires.

Why this answer

The 'podman system df' command reports disk usage for the storage-related resources that Podman manages, and its output lists Images (B), Containers (C), and Volumes (D) with their total, active, and reclaimable sizes. Images (B) are included because Podman tracks the space consumed by locally stored image layers and their shared parents. Containers (C) are included because each container's writable layer occupies storage on disk.

Volumes (D) are included because named volumes persist data outside the container layer and their disk consumption is reported. Networks (A) and Secrets (E) are not storage-usage items reported by 'podman system df'; networks are runtime/network configuration and secrets are managed credential objects, neither of which appears in this command's output.

Exam trap

EX188 often tests whether candidates assume `podman system df` mirrors `docker system df` exactly — Docker includes build cache and networks in some views, so candidates wrongly select Networks.

Full explanation →

221

Multi-Selecthard

Which THREE practices are recommended when optimizing cache utilization during image builds with podman build?

Select 3 answers

A.Use the --no-cache flag on every routine build to ensure absolute freshness.

B.Always place COPY . . at the very top of the Containerfile before installing software dependencies.

C.Place instructions that change frequently, such as COPYing source code, near the end of the Containerfile.

D.Combine related package installation and cleanup steps into a single RUN instruction.

E.Order Containerfile instructions from least frequently changed to most frequently changed.

AnswersC, D, E

Frequently changing instructions such as COPY of source code invalidate the cache for that layer and every layer after it. Putting them last confines cache invalidation to the final steps, so earlier dependency layers remain reusable across rebuilds.

Why this answer

Option C is correct because placing frequently changing instructions such as COPYing source code near the end of the Containerfile preserves the cache for earlier, stable layers; when source changes, only the final layers are rebuilt. Option D is correct because combining related package installation and cleanup into a single RUN instruction creates one cacheable layer and avoids leaving package-manager metadata or temporary files in intermediate layers, which also reduces image size. Option E is correct because ordering instructions from least frequently changed to most frequently changed maximizes cache hits: stable base and dependency layers stay cached while only the volatile trailing layers are invalidated.

Option A is not recommended because --no-cache disables layer caching entirely, forcing full rebuilds and defeating cache optimization for routine builds. Option B is wrong because putting COPY . . at the top invalidates the cache for every subsequent instruction whenever any source file changes, so dependency installation and other expensive steps rerun unnecessarily.

Exam trap

EX188 often tests the misconception that --no-cache is a best practice for 'freshness' — in reality it destroys the layer cache and is only for troubleshooting or forced rebuilds.

Full explanation →

222

MCQeasy

A user running rootless Podman wants to check the disk space consumed by images and containers in local storage. Which command provides this storage usage summary?

A.podman system df

B.df -h podman

C.podman storage status

D.podman disk usage

AnswerA

podman system df reports total, active and reclaimable disk usage for images, containers and volumes in local storage. It queries the rootless user's own storage graph, so it works without root privileges, directly satisfying the requirement to summarise consumed space.

Why this answer

podman system df reports disk usage for images, containers, volumes, and the build cache, similar to docker system df. It shows total, active, and reclaimable space, making it the correct command for a storage usage summary in rootless Podman. The output helps identify what can be pruned with podman system prune.

Exam trap

EX188 often tests the exact subcommand syntax for storage inspection, and candidates who guess podman storage status or podman disk usage instead of the correct podman system df pick a distractor.

How to eliminate wrong answers

Option B is wrong because df -h podman treats 'podman' as a filesystem path, not a Podman command — df is a Linux filesystem utility and has no knowledge of Podman storage. Option C is wrong because podman storage status is not a valid subcommand; the storage-related subcommands are podman system df, podman system prune, and podman system reset. Option D is wrong because podman disk usage is not a valid subcommand — the correct form is podman system df.

Full explanation →

223

MCQmedium

An administrator needs to create a Podman secret from a file on disk named 'secret.txt'. Which command correctly performs this action?

A.podman secret import db_secret secret.txt

B.podman create secret db_secret secret.txt

C.podman secret add db_secret --file secret.txt

D.podman secret create db_secret secret.txt

AnswerD

'podman secret create' takes the secret name followed by the source file path, so db_secret is created from secret.txt. This satisfies the requirement to build a Podman secret directly from an on-disk file rather than from stdin or an environment variable.

Why this answer

The correct syntax for creating a Podman secret from a file is `podman secret create <name> <file>`. Podman's secret subcommand mirrors Docker's `docker secret create` syntax, where the secret name comes first and the source file (or `-` for stdin) comes second. This command reads the file contents and stores them in Podman's secret store, making them available to containers via `--secret`.

Exam trap

EX188 often tests the exact subcommand hierarchy and argument order for Podman commands, so candidates who confuse `podman secret create` with Docker-style `import` or who place the file before the name will pick a wrong answer.

How to eliminate wrong answers

Option A is wrong because `podman secret import` is not a valid subcommand — Podman's secret subcommands are create, inspect, ls, rm, and exists, not import. Option B is wrong because `podman create secret` inverts the command hierarchy; `create` is a container subcommand, not a secret subcommand, and there is no `podman create secret` form. Option C is wrong because `podman secret add` is not a valid subcommand, and the `--file` flag does not exist for secret creation — the file is passed positionally.

Full explanation →

224

MCQhard

An administrator wants to ensure that a bind-mounted directory allows propagation of mounts from the host into the container. Which mount option configures mount propagation mode?

A.podman run -v /host/dir:/container/dir:mtype=shared myapp

B.podman run -v /host/dir:/container/dir:shared myapp

C.podman run -v /host/dir:/container/dir:sync myapp

D.podman run -v /host/dir:/container/dir:propagate myapp

AnswerB

The shared propagation mode lets mounts performed on the host propagate into the container and vice versa, which is exactly the bind-mount behaviour requested. Without it, the default private mode isolates the mount namespace and host mounts never appear inside.

Why this answer

The :shared mount option on a bind mount configures mount propagation mode to shared, allowing mounts performed on the host to propagate into the container (and vice versa). The syntax is -v /host/dir:/container/dir:shared, where shared is the propagation mode keyword.

Exam trap

EX188 often tests mount propagation syntax, and candidates pick plausible-sounding keywords like propagate or mtype=shared instead of the actual kernel mode name shared.

How to eliminate wrong answers

Option A is wrong because mtype=shared is not valid Podman syntax — the propagation mode is specified directly as shared, not as a key=value pair. Option C is wrong because sync is not a mount propagation mode; the valid modes are shared, slave, private, and unbindable (plus rshared, rslave, rprivate, runbindable for recursive). Option D is wrong because propagate is not a valid keyword — the correct term is shared, and propagate is a related but distinct concept (mount --make-shared).

Full explanation →

225

MCQeasy

An administrator needs to create a persistent storage area managed completely by Podman that does not rely on a specific host directory path. Which command should be used?

A.podman volume bind my_data

B.podman run -v /my_data

C.podman volume create my_data

D.podman create volume my_data

AnswerC

Podman volumes are stored in a Podman-managed location on the host, so no explicit host directory path is required. Creating the named volume with podman volume create my_data satisfies the persistence and host-path-independence constraints before it is mounted into a container.

Why this answer

podman volume create my_data creates a named volume managed by Podman's volume driver, which stores data in a Podman-controlled location (e.g., ~/.local/share/containers/storage/volumes for rootless) rather than a user-specified host path. This is exactly what the question asks for: persistent storage managed by Podman without relying on a specific host directory.

Exam trap

EX188 often tests the exact subcommand ordering — 'podman volume create NAME' versus the reversed 'podman create volume NAME' — and whether candidates confuse named volumes with bind mounts.

How to eliminate wrong answers

Option A is wrong because 'podman volume bind' is not a valid subcommand — bind mounts are configured at run time via -v /host/path:/container/path, not by a volume subcommand. Option B is wrong because 'podman run -v /my_data' is malformed — a single path with no container target is not a valid volume specification, and it does not create a managed volume. Option D is wrong because 'podman create volume my_data' has the verb and noun reversed; the correct syntax is 'podman volume create my_data'.

Full explanation →

Red Hat Certified Specialist in Containers (EX188, Podman-based) (EX188) (EX188) — Questions 151–225