Red Hat Certified Specialist in Containers (EX188, Podman-based) (EX188) EX188 Questions 226–264 | Page 4/4

226

MCQmedium

A developer wants to search for all available container images matching the term 'rhel9' across configured registries using Podman. Which command should they run?

A.podman find rhel9

B.podman query rhel9

C.podman search rhel9

D.podman lookup rhel9

AnswerC

podman search queries every registry configured in registries.conf and returns matching image names, satisfying the requirement to search across all configured registries. It needs no image pull or local storage, unlike podman images, which lists only locally cached images.

Why this answer

The `podman search` command queries configured container registries for images matching the given term. Running `podman search rhel9` returns a list of repositories and images whose names or descriptions contain 'rhel9'. This is the correct command for discovering available images across registries.

Exam trap

EX188 often tests command syntax recognition; candidates may invent plausible-sounding subcommands like `find` or `query` instead of remembering that `search` is the correct Podman verb for registry queries.

How to eliminate wrong answers

Option A is wrong because `podman find` is not a valid Podman subcommand. Option B is wrong because `podman query` is not a valid Podman subcommand. Option D is wrong because `podman lookup` is not a valid Podman subcommand; the correct command for searching registries is `podman search`.

Full explanation →

227

Multi-Selectmedium

Which TWO conditions are required for a non-root (rootless) user to successfully bind mount a host directory into a container? (Choose TWO)

Select 2 answers

A.Direct modification of the host kernel mount tables

B.The user must have read/write access to the host directory on the host file system

C.Disabling user namespaces across the system

D.Root privileges on the host operating system

E.Proper SELinux labeling (such as :z or :Z) if SELinux is enforcing

AnswersB, E

Rootless bind mounts are performed by the unprivileged user's own UID mapping, so the kernel enforces ordinary file permissions on the source path. Without read/write access to that host directory, the mount either fails or yields an unusable, read-only view.

Why this answer

Option B is correct because a rootless user can only bind mount a host directory into a container if that user actually has read/write permissions on the source directory in the host filesystem; without those permissions, the mount would be denied or the container process could not access the content. Option E is correct because when SELinux is enforcing, the host directory must carry a label that the container process is allowed to access, typically applied with the :z or :Z volume option so the bind mount is not blocked by SELinux policy. Option A is not required and is generally impossible for a non-root user, since directly editing kernel mount tables requires root privileges.

Option C is incorrect because disabling user namespaces would remove the very mechanism that enables rootless containers, not help bind mounting. Option D is incorrect because the whole point of a rootless container is to operate without root privileges on the host.

Exam trap

EX188 often tests the misconception that rootless containers require root privileges or kernel modifications — candidates overlook the need for host filesystem permissions and SELinux labeling.

Full explanation →

228

MCQeasy

An administrator needs to push a locally built Podman image named 'app:latest' to a remote container registry at 'registry.example.com/team'. Which command must be executed first to authenticate with the registry before pushing?

A.podman push --auth registry.example.com

B.podman auth registry.example.com

C.podman login registry.example.com

D.podman connect registry.example.com

AnswerC

Podman must authenticate against the target registry before any push succeeds. Running podman login registry.example.com stores credentials for that registry, so the subsequent push to registry.example.com/team is authorised rather than rejected with an authentication error.

Why this answer

The correct command is `podman login registry.example.com` because it authenticates the user to the specified container registry, storing credentials in the local authentication file (typically `${XDG_RUNTIME_DIR}/containers/auth.json`). This step is required before any push operation to a private registry, as it establishes the necessary session and permissions. Without a successful login, `podman push` would fail with an authentication error.

Exam trap

EX188 often tests the confusion between authentication commands and other Podman subcommands, leading candidates to select non-existent or misused options like `podman auth` or `podman push --auth` instead of the correct `podman login`.

How to eliminate wrong answers

Option A is wrong because `podman push --auth` is not a valid flag for authentication; the `--auth` flag is used to specify the path to an authentication file, not to initiate a login. Option B is wrong because `podman auth` is not a valid Podman subcommand; there is no such command for authentication. Option D is wrong because `podman connect` is not a valid Podman command; it does not exist in Podman's CLI for registry authentication.

Full explanation →

229

Multi-Selectmedium

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

Select 2 answers

A.podman container prune

B.podman rm --all --force

C.podman system prune --all

D.podman ps -a --filter status=exited --format '{{.ID}}' | xargs -r podman rm

E.podman rmi --all

AnswersA, D

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

Why this answer

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

Exam trap

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

Full explanation →

230

MCQmedium

In a Podman Compose file, how do you define a custom network and connect a service to it?

A.Use the 'links:' directive inside the service block exclusively.

B.Add a 'network_mode' string directly pointing to an external shell script.

C.Define networks at the root level and reference them under each service configuration.

D.Configure networking exclusively via command-line environment variables.

AnswerC

Compose requires networks declared under the top-level networks key, then each service references the named network in its own networks list. This two-part structure attaches containers to the custom network, satisfying the requirement to define and connect services correctly.

Why this answer

In a Podman Compose file, custom networks are declared under a top-level networks: block, and each service references the desired network(s) under its own networks: key. This two-part structure is required by the Compose specification: the root-level declaration defines the network (driver, options, external flag), and the service-level reference attaches the service to it. This is how Compose wires services into shared networks for name resolution and isolation.

Exam trap

EX188 often tests the two-level structure requirement — candidates may forget that networks must be declared at the root and referenced per service, or may confuse links with network attachment.

How to eliminate wrong answers

Option A is wrong because the links: directive is a legacy feature for one-way container discovery and does not define or attach services to custom networks; it is deprecated in favor of user-defined networks. Option B is wrong because network_mode is used to set modes like host, bridge, or container:<name>, not to point at an external shell script — that is not a valid value. Option D is wrong because networking is configured declaratively in the Compose file, not exclusively via command-line environment variables; env vars may override some settings but are not the definition mechanism.

Full explanation →

231

MCQmedium

You need to ensure that a file copied into your image via the COPY instruction is owned by a specific user 'developer' and group 'devgroup'. How can this be achieved efficiently?

A.COPY app.py /app/app.py && chown developer:devgroup /app/app.py

B.COPY --chown=developer:devgroup app.py /app/app.py

C.COPY --user=developer:devgroup app.py /app/app.py

D.ADD --owner=developer app.py /app/app.py

AnswerB

COPY --chown sets ownership at copy time, so the file lands in the image layer already owned by developer:devgroup. This satisfies the stem's efficiency constraint by avoiding a separate RUN chown instruction, which would create an extra layer and duplicate the file's data.

Why this answer

The COPY instruction in a Containerfile supports the --chown flag, which sets the ownership of the copied files directly during the copy operation. This is the most efficient method because it avoids creating an extra layer and does not require the user/group to exist in the image beforehand. The syntax --chown=developer:devgroup correctly specifies both user and group.

Exam trap

EX188 often tests the difference between build-time instructions and runtime commands, and candidates may confuse --chown with --user or think that chown after COPY is equivalent, not realizing the layer and dependency implications.

How to eliminate wrong answers

Option A is wrong because it uses a shell command chown after COPY, which creates an additional layer and requires the user and group to already exist in the image. Option C is wrong because --user is not a valid flag for COPY; the correct flag is --chown. Option D is wrong because ADD does not support an --owner flag; ownership must be set with --chown, and ADD is generally discouraged for simple file copies.

Full explanation →

232

MCQmedium

A security team requires that all container processes run with a specific SELinux type instead of the default container_t. How can an administrator specify a custom SELinux type when launching a container with 'podman run'?

A.--security-opt label=type:custom_t

B.--selinux-type custom_t

C.--cap-add SELINUX

D.--env SELINUX_TYPE=custom_t

AnswerA

`--security-opt label=type:custom_t` overrides the SELinux label assigned to the container process, replacing the default `container_t` with the specified type. This satisfies the stem's requirement for a custom SELinux type at launch, since Podman applies the label directly to the container process rather than relying on the default policy.

Why this answer

The `--security-opt label=type:custom_t` flag tells Podman to apply the specified SELinux type to the container's processes instead of the default container_t. This is the correct syntax for overriding SELinux labels at container launch. The label=type: prefix is part of Podman's security-opt grammar for SELinux process labeling.

Exam trap

EX188 often tests whether candidates know that SELinux type overrides must use the --security-opt label=type: syntax, and tricks them with plausible-sounding but nonexistent flags like --selinux-type or environment variables.

How to eliminate wrong answers

Option B is wrong because `--selinux-type` is not a valid Podman flag; SELinux type specification must go through --security-opt. Option C is wrong because `--cap-add SELINUX` is nonsensical — SELINUX is not a Linux capability, and capabilities control privileged operations, not SELinux labeling. Option D is wrong because setting an environment variable SELINUX_TYPE does not affect Podman's SELinux labeling; environment variables are passed to the container process, not interpreted by Podman for security configuration.

Full explanation →

233

MCQeasy

A developer needs to pass several environment variables to a container from a file named web.env. The file contains lines such as DB_HOST=localhost and DB_PORT=5432. Which Podman run flag should be used to load these variables into the container?

A.--config web.env

B.--env-file web.env

C.--environment-file web.env

D.--env web.env

AnswerB

The --env-file flag reads environment variables from a file and passes them into the container. Each line in the file must be in KEY=VALUE format, which matches the described web.env file. This is the correct way to inject multiple variables without listing them individually on the command line. It is widely used for configuration management in containerized applications.

Why this answer

The --env-file flag is designed to read environment variables from a file, with each line in KEY=VALUE format. This matches the scenario where web.env contains multiple variables. The other options either use incorrect flag names or misinterpret how environment variables are passed to containers.

Exam trap

The trap here is assuming that --env can accept a filename, when it actually sets a single variable directly.

Full explanation →

234

MCQeasy

How can an administrator remove all unused, dangling Podman volumes that are not currently attached to any container?

A.podman rm --volumes

B.podman volume rm --all

C.podman volume clean

D.podman volume prune

AnswerD

podman volume prune removes all volumes not referenced by any container, matching the dangling-volume requirement exactly. Unlike podman volume rm, it needs no explicit volume names, so it clears unused volumes in one non-interactive command.

Why this answer

'podman volume prune' removes all volumes not currently referenced by any container — exactly the definition of dangling or unused volumes. It is the dedicated cleanup command for reclaiming storage from orphaned volumes, and it prompts for confirmation unless run with --force. This is the correct tool when an administrator wants to bulk-remove unattached volumes.

Exam trap

EX188 often tests whether candidates confuse container-scoped volume removal (podman rm -v) with system-wide cleanup (podman volume prune), or invent non-existent flags like --all or subcommands like clean.

How to eliminate wrong answers

Option A is wrong because 'podman rm --volumes' (or -v) removes the anonymous volumes associated with a specific container being deleted, not all unused volumes system-wide. Option B is wrong because 'podman volume rm --all' is not a valid combination — 'volume rm' requires explicit volume names, and there is no --all flag for it. Option C is wrong because 'podman volume clean' is not a real subcommand; the correct verb is 'prune'.

Full explanation →

235

Multi-Selectmedium

Which TWO actions are required when configuring a secure container workflow to push a signed image to a registry using Podman? (Choose two.)

Select 2 answers

A.Disable SELinux enforcement globally on the container host before generating signatures.

B.Store the private signing key inside the container image payload.

C.Set the container storage driver to vfs in storage.conf.

D.Generate a cryptographic key pair and ensure the private key is available to sign the image.

E.Configure /etc/containers/registries.d/ to specify where signature transport and storage are located.

AnswersD, E

Signing requires an asymmetric key pair; the private key produces the signature attached to the image. Generating that pair and making the private key available to Podman is therefore a prerequisite for pushing a signed image.

Why this answer

Option D is correct because signing a container image with Podman requires a cryptographic key pair (typically created with `skopeo generate-sigstore-key` or a GPG key), and the private key must be accessible to the signing tool so it can produce the signature that is pushed alongside the image. Option E is correct because `/etc/containers/registries.d/` YAML files define the signature storage and transport configuration (for example `docker:` with `sigstore-staging:` or `lookaside-storage:`), telling Podman/Skopeo where signatures are stored and how they are associated with the registry so verification works after the push. Option A is wrong because disabling SELinux globally is neither required nor advisable for signing images; SELinux confinement is orthogonal to image signing.

Option B is wrong because embedding the private signing key in the image payload would expose the key and defeat the purpose of signing. Option C is wrong because the `vfs` storage driver is a slow, non-overlay fallback and has no bearing on the signing or push workflow.

Exam trap

EX188 often tests whether candidates confuse the signing key (private, kept local) with the verification key (public, distributed), and whether they know that registries.d — not storage.conf — controls where signatures are stored and transported.

Full explanation →

236

Multi-Selecteasy

Which TWO commands are used to manage Podman secrets? (Choose TWO)

Select 2 answers

A.podman secret create

B.podman secret compile

C.podman secret update

D.podman secret ls

E.podman secret modify

AnswersA, D

Creating a secret stores sensitive data in Podman's secret store, from which it can be injected into containers at runtime rather than baked into images or environment variables. This is the foundational write operation for the secret management workflow.

Why this answer

Option A, `podman secret create`, is correct because it is the command used to create a new secret in Podman's secret store, reading the secret value from a file or stdin and registering it under a given name for later use by containers. Option D, `podman secret ls`, is correct because it lists all secrets currently stored in the Podman secret store, allowing administrators to verify which secrets exist. The other options are not valid Podman subcommands: `podman secret compile`, `podman secret update`, and `podman secret modify` do not exist in Podman's CLI, so they cannot be used to manage secrets.

Exam trap

EX188 often tests whether candidates confuse Podman's immutable secret model with Docker/Kubernetes patterns that allow updates — candidates pick `update` or `modify` assuming secrets can be edited in place.

Full explanation →

237

Multi-Selectmedium

When publishing container ports using the Podman CLI, which THREE methods or syntaxes are valid for the -p / --publish flag? (Choose three)

Select 3 answers

A.-p 8080:80

B.-p 127.0.0.1:8080:80

C.-p container=80,host=8080

D.-p 80:8080:tcp:bind

E.-p 8080:80/udp

AnswersA, B, E

Publishing `-p 8080:80` maps host port 8080 to container port 80, satisfying the requirement for a valid `--publish` syntax. Podman accepts this `hostPort:containerPort` form directly, binding the specified host interface port to the container's exposed service port without extra flags.

Why this answer

Option A, `-p 8080:80`, is valid because the standard Podman/Docker publish syntax is `hostPort:containerPort`, mapping host port 8080 to container port 80 over the default TCP protocol. Option B, `-p 127.0.0.1:8080:80`, is valid because the full syntax `ip:hostPort:containerPort` binds the published port to a specific host interface (127.0.0.1) rather than all interfaces. Option E, `-p 8080:80/udp`, is valid because appending `/udp` (or `/tcp`) after the container port specifies the protocol for the published port.

Option C is invalid because Podman does not accept the key=value form `container=80,host=8080` for `--publish`. Option D is invalid because the protocol must be appended with a slash (e.g., `8080:80/tcp`) and cannot be followed by an extra `:bind` field in that position.

Exam trap

EX188 often tests whether candidates confuse Docker/Podman -p syntax with Kubernetes-style key=value port mappings or invent invalid protocol suffixes like ':tcp:bind'.

Full explanation →

238

Multi-Selecteasy

Which TWO commands are used to transfer container images via archive files without interacting with a network registry? (Choose two.)

Select 2 answers

A.podman save

B.podman import

C.podman export

D.podman load

E.podman transfer

AnswersA, D

podman save writes a local image's layers into a tar archive on disk. That archive can then be moved and loaded elsewhere, satisfying the requirement to transfer images via files without contacting a network registry.

Why this answer

Option A, `podman save`, is correct because it serializes one or more local container images into an archive file (e.g., a tarball) on disk, which can then be moved to another host without contacting a registry. Option D, `podman load`, is correct because it reads such an image archive produced by `podman save` and restores the image(s) into the local container storage, again with no network registry involved. Together, `podman save` and `podman load` form the standard offline image transfer pair.

Option B, `podman import`, is not correct here because it creates an image from a filesystem tarball (often produced by `podman export`), not from a saved image archive. Option C, `podman export`, is not correct because it exports a running or existing container's filesystem to a tar file, not a container image. Option E, `podman transfer`, is not a valid Podman command for this purpose.

Exam trap

The trap is confusing image-level operations (`save`/`load`) with container-filesystem operations (`export`/`import`); candidates who don't distinguish the two pick `export` or `import` and lose image metadata.

Full explanation →

239

MCQmedium

A system administrator needs to load a container image from a previously generated tar archive named 'app.tar' into local Podman storage. Which command should be executed?

A.podman import app.tar

B.podman restore -i app.tar

C.podman load -i app.tar

D.podman read app.tar

AnswerC

podman load reads a tar archive and imports the contained image and its layers into local container storage; the -i flag specifies the input file. This satisfies the requirement to restore 'app.tar' into local Podman storage, unlike podman import, which accepts a filesystem tarball rather than an image archive.

Why this answer

The podman load command reads a container image from a tar archive and imports it into local container storage. The -i flag specifies the input file, so podman load -i app.tar loads the image from app.tar. This is the standard way to restore an image previously saved with podman save.

Exam trap

EX188 often tests the confusion between podman load (restore a saved image archive) and podman import (create an image from a filesystem tarball), which are used in different scenarios.

How to eliminate wrong answers

Option A is wrong because podman import is used to create a container image from a tarball of a filesystem, not to load a saved image archive. Option B is wrong because podman restore is not a valid Podman command for loading images; it does not exist in this context. Option D is wrong because podman read is not a valid Podman command for image loading.

Full explanation →

240

MCQeasy

A user needs to remove a local container image that is no longer needed. Which command should be used?

A.podman image delete image_name

B.podman rm image_name

C.podman delete image_name

D.podman rmi image_name

AnswerD

The rmi subcommand removes images from local storage, matching the requirement to delete an unneeded local image. Unlike rm, which targets containers, rmi operates on image references, so podman rmi image_name deletes the specified image and its untagged layers.

Why this answer

`podman rmi` is the dedicated image-removal subcommand; it accepts an image name or ID and deletes the local image from container storage. It is the Podman equivalent of `docker rmi` and is the canonical command documented for removing images.

Exam trap

The trap is the near-identical verbs `rm` (containers) versus `rmi` (images); candidates who don't distinguish the two pick `podman rm` and remove the wrong object type.

How to eliminate wrong answers

Option A is wrong because `podman image delete` is not a valid subcommand; the `podman image` command group supports `rm`/`remove` (aliases for rmi) but not `delete`. Option B is wrong because `podman rm` removes containers, not images — a common confusion since both operate on 'things that exist locally'. Option C is wrong because `podman delete` is not a Podman subcommand at all; there is no top-level delete verb.

Full explanation →

241

MCQeasy

A team wants to document ownership and contact information directly in the image so that `podman inspect` shows who maintains it. Which Containerfile instruction should they add to set this metadata?

A.COMMENT maintainer="team@example.com"

B.ENV maintainer="team@example.com"

C.ARG maintainer="team@example.com"

D.LABEL maintainer="team@example.com"

AnswerD

LABEL adds arbitrary key-value metadata to the image, and maintainer is a commonly recognized key for contact information. The data becomes part of the image configuration and is visible through podman inspect, which is exactly the documentation goal described. Multiple LABEL instructions or a single instruction with several key=value pairs can be used.

Why this answer

Image metadata such as maintainer contact information is set with the LABEL instruction. Labels are stored in the image configuration and can be read with podman inspect, making them the correct mechanism for documenting ownership without affecting runtime behavior or build-time variables.

Exam trap

The trap here is assuming that any instruction which can hold a string value, such as ENV or ARG, is suitable for storing image metadata.

Full explanation →

242

MCQhard

An administrator configures a mirror for a primary registry in /etc/containers/registries.conf. What is the correct TOML syntax format to define a registry block with a mirror?

A.registry: name: registry.example.com mirror: internal-mirror.example.com

B.[[registry]] prefix = "registry.example.com" location = "internal-mirror.example.com"

C.SERVER=registry.example.com MIRROR=internal-mirror.example.com

D.[registry "registry.example.com"] mirror = "internal-mirror.example.com"

AnswerB

The [[registry]] array of tables format with location and mirrors is correct for registries.conf.

Why this answer

Podman's `/etc/containers/registries.conf` uses TOML, and a registry block is defined with `[[registry]]` (an array of tables). The `prefix` field specifies the registry hostname to match, and `location` specifies the mirror to use instead, so `[[registry]]` with `prefix` and `location` is the correct syntax.

Exam trap

The trap is that candidates recognize the concept of a mirror but pick a syntax from a different config format (YAML, INI, or shell), not realizing registries.conf is strict TOML with `[[registry]]` array-of-tables.

How to eliminate wrong answers

Option A is wrong because it uses YAML-style `key: value` syntax, which is not valid TOML and would cause the config parser to fail. Option C is wrong because it uses shell-style `SERVER=`/`MIRROR=` environment variable syntax, which is not TOML at all. Option D is wrong because `[registry "registry.example.com"]` is not the TOML table syntax Podman expects; Podman uses `[[registry]]` array-of-tables with `prefix` and `location` fields, not a quoted subtable with a `mirror` key.

Full explanation →

243

MCQmedium

A developer has written a Containerfile with multiple COPY instructions for static configuration files that change frequently, placed near the top of the Containerfile before the application code installation. Why is this considered a bad practice for build caching?

A.It invalidates the build cache for all subsequent instructions whenever those configuration files change, slowing down builds.

B.It violates OCI container image specification limits on COPY counts.

C.It causes the ENTRYPOINT instruction to fail at runtime.

D.It causes Podman to store duplicate layers in local storage, exhausting disk space.

AnswerA

Container image layers cache by instruction order, so a COPY of frequently changing configuration files near the top invalidates every subsequent layer, forcing application installation to rebuild each time. Moving volatile files later preserves caching for the expensive, stable application code layers.

Why this answer

Changing a file earlier in the Containerfile invalidates the cache for all subsequent instructions, forcing unnecessary rebuilds of heavy steps.

Full explanation →

244

MCQhard

An administrator runs a container with a SELinux-relabeled host directory mount using the Z option, but multiple containers need to share write access to this exact same volume. Which option should be used instead?

A.podman run -v /host/data:/data:O

B.podman run -v /host/data:/data:Z

C.podman run -v /host/data:/data:z

D.podman run -v /host/data:/data:shared

AnswerC

Lowercase z relabels content so multiple containers can share the volume.

Why this answer

The `:z` option applies a shared SELinux label to the volume, allowing multiple containers to access the same content. When multiple containers need write access to the same host directory, `:z` is the correct choice because it relabels the content with a shared MCS category rather than a private one.

Exam trap

EX188 often tests the `:z` vs `:Z` distinction; candidates may pick `:Z` for shared access because they think uppercase means 'more permissive', when actually `:Z` is private and `:z` is shared.

How to eliminate wrong answers

Option A is wrong because `:O` is not a valid SELinux mount option in Podman; it may be confused with other flags. Option B is wrong because `:Z` applies a private label, which would prevent other containers from accessing the volume. Option D is wrong because `:shared` is not a valid SELinux suffix; it is a mount propagation option, not an SELinux label.

Full explanation →

245

MCQhard

You have a Kubernetes YAML manifest file named 'app.yaml' that defines a Pod with network settings. You want to deploy this directly as a Podman container/pod on your local system. Which command should you use?

A.podman-compose up --file app.yaml

B.podman run --kube app.yaml

C.podman apply -f app.yaml

D.podman play kube app.yaml

AnswerD

`podman play kube` reads a Kubernetes YAML manifest and creates the corresponding Podman pod and containers, translating Kubernetes constructs such as pod-level network namespaces into native Podman equivalents. This directly satisfies the stem's requirement to deploy an existing Kubernetes manifest locally without conversion or a cluster.

Why this answer

'podman play kube' reads a Kubernetes YAML manifest and creates the corresponding Podman pods and containers locally. It supports Pod, Deployment, and ConfigMap kinds, translating Kubernetes constructs into Podman equivalents. This is the correct command to deploy a Kubernetes manifest directly with Podman.

Exam trap

EX188 often tests the confusion between 'podman play kube' (Kubernetes YAML) and 'podman-compose' (Compose YAML), and candidates pick invalid flags like --kube on run.

How to eliminate wrong answers

Option A is wrong because 'podman-compose' consumes docker-compose YAML, not Kubernetes manifests, and 'up --file' is not the correct syntax for Kubernetes YAML. Option B is wrong because 'podman run --kube' is not a valid flag combination — run does not accept Kubernetes manifests. Option C is wrong because 'podman apply' is not a Podman subcommand; apply is a Kubernetes/OpenShift concept.

Full explanation →

246

Multi-Selectmedium

Which THREE configuration keys are valid within a service definition block in a Podman Compose file for managing container networking and ports? (Choose three.)

Select 3 answers

A.ports

B.interfaces

C.expose

D.firewall

E.networks

AnswersA, C, E

The ports key maps container ports to host ports within a service definition, directly satisfying the question's requirement for managing port publishing. It accepts a list of mappings or short syntax, and Podman Compose translates these into the corresponding port bindings when the container starts.

Why this answer

In a Podman Compose service definition, the ports key is valid because it publishes container ports to the host using the standard HOST:CONTAINER syntax, which is essential for managing port mappings. The expose key is also valid because it documents and exposes container ports to linked services on the internal network without publishing them to the host. The networks key is valid because it attaches a service to one or more named networks defined in the top-level networks section, enabling container-to-container networking.

The interfaces key is not a Compose service configuration key, as interface naming is handled by the container runtime rather than the Compose file. The firewall key is not part of the Compose specification; firewall rules are managed by the host's firewall tooling, not by service definitions.

Exam trap

EX188 often tests the distinction between ports (host publishing) and expose (internal only), and candidates may incorrectly select non-existent keys like interfaces or firewall.

Full explanation →

247

MCQeasy

Which Podman network mode completely isolates a container from any network communication, removing all interfaces except the loopback?

A.--network none

B.--network isolated

C.--network closed

D.--network disabled

AnswerA

`--network none` creates a network namespace containing only the loopback interface, so the container has no route to other containers, the host, or external networks. This directly satisfies the stem's requirement for complete isolation with all interfaces removed except loopback.

Why this answer

The `--network none` option in Podman creates a container with a completely isolated network namespace that contains only the loopback interface (lo). No veth pair, no bridge attachment, and no external connectivity is configured, so the container cannot send or receive any network traffic beyond itself. This is the canonical way to run a container with zero network exposure for security-sensitive workloads.

Exam trap

EX188 often tests whether candidates confuse the valid Podman network mode 'none' with plausible-sounding but nonexistent modes like 'isolated', 'closed', or 'disabled'.

How to eliminate wrong answers

Option B is wrong because `--network isolated` is not a valid Podman network mode — Podman supports none, host, bridge, slirp4netns, pasta, macvlan, ipvlan, and container:<id>, but not 'isolated'. Option C is wrong because `--network closed` is not a recognized Podman network mode and would produce an error. Option D is wrong because `--network disabled` is not a valid Podman network mode; the correct keyword for full network isolation is 'none'.

Full explanation →

248

MCQmedium

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

A.podman export --path /app/logs prod_app /var/backups/

B.podman pull prod_app:/app/logs /var/backups/

C.podman download prod_app:/app/logs /var/backups/

D.podman cp prod_app:/app/logs /var/backups/

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

249

MCQmedium

A user running rootless Podman wants to pull an image from an insecure registry running over HTTP on port 5000. When running 'podman pull', the command fails with a connection error. Where must the administrator define this registry as insecure for the user?

A.~/.local/share/containers/storage.conf

B./etc/sysconfig/podman

C./etc/containers/registries.conf

D.~/.config/containers/registries.conf

AnswerD

Rootless Podman looks for user-specific registry configurations in ~/.config/containers/registries.conf.

Why this answer

For rootless Podman, user-specific configuration files take precedence over system-wide ones. The correct location to define an insecure registry for a single user is ~/.config/containers/registries.conf, which is the per-user override for /etc/containers/registries.conf. Podman reads this file when running as a non-root user, allowing the user to specify registries as insecure without requiring root privileges.

This is part of the containers/image configuration stack, and the user-level file is the proper place for such customizations.

Exam trap

EX188 often tests the distinction between system-wide and user-specific configuration files for rootless Podman, trapping candidates who assume system-wide files apply universally or confuse storage configuration with registry configuration.

How to eliminate wrong answers

Option A is wrong because ~/.local/share/containers/storage.conf is used for storage configuration (e.g., driver, graphroot) in rootless mode, not for registry security settings. Option B is wrong because /etc/sysconfig/podman is not a standard configuration file for Podman; it may exist for service environment variables but does not control registry insecurity. Option C is wrong because /etc/containers/registries.conf is the system-wide configuration and would require root privileges to edit; while it can define insecure registries, it is not the user-specific location and may be overridden by the user file.

Full explanation →

250

Multi-Selectmedium

Which TWO statements are true regarding user-defined bridge networks in Podman? (Choose two)

Select 2 answers

A.They require the host firewall to be completely disabled to function.

B.Containers attached to different user-defined networks can communicate without explicit routing.

C.They prevent containers from communicating with the outside internet entirely.

D.They allow administrators to specify custom subnets and gateways during creation.

E.They provide automatic internal DNS resolution so containers can reach each other by name.

AnswersD, E

Podman accepts --subnet and --gateway flags at network creation, letting administrators define the address range and default gateway instead of accepting an auto-assigned range. This satisfies the stem's requirement by giving explicit control over the bridge network's IP addressing scheme.

Why this answer

Option D is correct because when creating a user-defined bridge network with `podman network create`, administrators can pass flags such as `--subnet` and `--gateway` to define custom CIDR ranges and gateway addresses instead of relying on Podman's default allocations. Option E is correct because Podman runs an internal DNS server (aardvark-dns) on user-defined networks, allowing containers to resolve each other by container name or network alias rather than by IP address. Option A is wrong because user-defined bridge networks rely on normal netfilter/NAT rules and do not require disabling the host firewall.

Option B is wrong because containers on separate user-defined bridge networks are isolated by default and cannot communicate without explicit routing or connecting a container to both networks. Option C is wrong because user-defined bridge networks still provide outbound connectivity to the internet via NAT/masquerading on the host.

Exam trap

EX188 often tests the difference between the default bridge network and user-defined networks, specifically that automatic DNS resolution and custom subnet configuration are exclusive to user-defined networks, while many candidates incorrectly assume these features are available on the default bridge.

Full explanation →

251

MCQhard

You need to copy local application source code from your build context into the /app directory inside the container image, automatically unpacking it if it is a local tar archive. Which instruction should you select?

A.FETCH

B.TRANSFER

C.COPY

D.ADD

AnswerD

ADD handles both local paths and remote URLs, and automatically extracts a local tar archive into the destination. COPY only copies files and never unpacks archives, so it cannot satisfy the automatic-unpacking constraint for the /app directory.

Why this answer

The ADD instruction in a Containerfile (Dockerfile) copies files from the build context into the image, and it has the additional feature of automatically unpacking local tar archives and fetching remote URLs. The COPY instruction only copies files and directories without unpacking or fetching. Therefore, ADD is the correct choice when you need to unpack a local tar archive into the image.

Exam trap

The trap is thinking that COPY can unpack archives, but it cannot; only ADD has that capability. Candidates might also confuse ADD with other instructions like FETCH or TRANSFER, which do not exist.

How to eliminate wrong answers

Option A is wrong because FETCH is not a valid Containerfile instruction. Option B is wrong because TRANSFER is not a valid Containerfile instruction. Option C is wrong because COPY does not unpack tar archives; it only copies files and directories as-is.

Full explanation →

252

MCQeasy

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

A.podman ps -a

B.podman status --all

C.podman list --all

D.podman containers show

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

253

MCQeasy

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

A.podman inspect --logs db_cache

B.podman logs db_cache

C.podman output db_cache

D.podman history db_cache

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

254

Multi-Selecthard

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

Select 2 answers

A.Running systemctl daemon-reload is unnecessary after generating a unit file because Podman reloads systemd automatically.

B.Generated systemd files for rootless users must always be placed in /etc/systemd/system/.

C.The --new flag ensures that the generated service creates a new container instance upon starting rather than requiring a pre-existing static container.

D.podman generate systemd can output unit files for both individual containers and pods.

E.Generated systemd unit files are executed exclusively by Docker daemon integration.

AnswersC, D

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

Why this answer

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

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

Exam trap

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

Full explanation →

255

MCQeasy

A developer needs to pull a private image from quay.io. The registry requires authentication. Which command should the developer use to store credentials for quay.io so that subsequent `podman pull` operations succeed without prompting?

A.podman pull --authfile ~/.docker/config.json quay.io/image

B.podman login quay.io

C.podman logout quay.io

D.podman run --login quay.io

AnswerB

This command prompts for username and password and stores the credentials in the configured authentication file, typically ${XDG_RUNTIME_DIR}/containers/auth.json for rootless users. Once logged in, Podman can pull private images from quay.io without further prompts, making it the correct way to handle registry authentication.

Why this answer

The podman login command authenticates to a registry and stores the credentials in the appropriate auth file. After a successful login, Podman uses those stored credentials for subsequent operations such as podman pull. This is the standard method for accessing private images without embedding credentials in each command.

Exam trap

The trap here is confusing login with logout, or assuming that a pull command can create credentials on its own.

Full explanation →

256

Multi-Selecteasy

Which TWO methods can a user employ to verify that an image has been successfully downloaded to their local machine? (Choose two.)

Select 2 answers

A.Running 'podman network ls' to verify image network attachment.

B.Running 'podman image inspect <image_name>' to view its configuration metadata.

C.Running 'podman ps -a' to see the downloaded image layers.

D.Running 'podman volume inspect' to check image storage paths.

E.Running 'podman images' to check if the image name and tag appear in the list.

AnswersB, E

podman image inspect reads the locally stored image's configuration metadata, including its ID, layers, and creation details. A successful result proves the image exists in local storage, satisfying the requirement to verify the download completed.

Why this answer

Option B is correct because 'podman image inspect <image_name>' returns the image's configuration metadata (such as its ID, layers, and creation details) from the local image store, which only succeeds if the image was actually downloaded and is present locally. Option E is correct because 'podman images' lists all images in local storage with their repository, tag, image ID, and size, so seeing the expected name and tag confirms the download completed. Option A is wrong because 'podman network ls' lists configured networks, not images, and has nothing to do with verifying a downloaded image.

Option C is wrong because 'podman ps -a' lists containers (running and stopped), not image layers, so it cannot confirm an image download. Option D is wrong because 'podman volume inspect' reports on volumes, not image storage paths or downloaded images.

Exam trap

EX188 often tests the confusion between container-listing commands ('podman ps') and image-listing commands ('podman images'), tricking candidates into picking 'ps -a' as an image verification method.

Full explanation →

257

Multi-Selecteasy

Which TWO options are valid flags for the 'podman build' command to specify build arguments and tags? (Choose two.)

Select 2 answers

A.--volume

B.--publish

C.--build-arg

D.-t / --tag

E.--env-file

AnswersC, D

--build-arg passes a named variable into the build at run time, letting a Containerfile consume values such as versions or credentials without hard-coding them. It satisfies the stem's requirement for specifying build arguments, distinct from --tag, which names the resulting image.

Why this answer

Option C (--build-arg) is correct because 'podman build --build-arg KEY=VALUE' passes a build-time variable into the Containerfile/Dockerfile, matching the ARG instruction during the image build. Option D (-t / --tag) is correct because 'podman build -t name:tag' (or --tag) assigns a repository name and tag to the resulting image, which is exactly how you name built images. Option A (--volume) is not a build flag for specifying build arguments or tags; it is used with run/create to mount host paths into containers.

Option B (--publish) is also a run/create flag for mapping container ports to host ports, not a build argument or tag mechanism. Option E (--env-file) supplies environment variables at runtime for run/create, not build-time arguments or image tags, so it does not fit the scenario.

Exam trap

EX188 often tests confusion between 'podman build' flags and 'podman run' flags — options like --volume, --publish, and --env-file belong to run, not build.

Full explanation →

258

MCQmedium

An auditor reviewing your Containerfile notices an EXPOSE instruction for port 80. What is the primary function of the EXPOSE instruction?

A.It documents which ports the container listens on at runtime.

B.It opens firewall ports on the underlying RHEL host system permanently.

C.It encrypts network traffic entering the specified container port.

D.It automatically publishes all exposed ports to random host ports without flags.

AnswerA

EXPOSE is metadata only; it records the port the image intends to listen on, informing users and tooling. It does not publish the port or alter runtime networking, which requires -p or -P at container start.

Why this answer

The EXPOSE instruction in a Containerfile is purely metadata — it documents the port the containerized application listens on, so tools like podman and image consumers know which port to publish. It does not actually open, publish, or firewall the port; the operator must still use -p or -P at runtime to map it to a host port.

Exam trap

EX188 often tests the misconception that EXPOSE actively opens or publishes a port, when it is only declarative metadata.

How to eliminate wrong answers

Option B is wrong because EXPOSE never touches the RHEL host firewall (firewalld/nftables); port publishing is handled by podman's port mapping at runtime, not by the image build. Option C is wrong because EXPOSE has nothing to do with encryption — TLS/SSL is configured in the application or a reverse proxy, not via EXPOSE. Option D is wrong because EXPOSE does not auto-publish ports; publishing requires the -P (capital) flag or explicit -p mappings, and even then it maps to random host ports only when -P is used.

Full explanation →

259

MCQhard

When deploying containers using Podman Compose, what is the default network driver assigned to user-defined networks created by compose if no driver is specified?

A.host

B.macvlan

C.overlay

D.bridge

AnswerD

Podman Compose creates user-defined networks using the bridge driver by default, giving containers on the same network layer-2 connectivity and name resolution. This matches the stem's unspecified-driver scenario, where no explicit driver means bridge is applied.

Why this answer

When Podman Compose creates a user-defined network without an explicit driver, it defaults to the bridge driver, matching Docker Compose behavior. The bridge driver creates a local software bridge on the host, giving containers on that network isolated L2 connectivity and automatic DNS-based name resolution among them.

Exam trap

EX188 often tests the assumption that Compose defaults to the host or overlay driver, when the correct default for user-defined networks is bridge.

How to eliminate wrong answers

Option A is wrong because the host driver removes network isolation entirely, sharing the host's network namespace — it is never the default for user-defined compose networks. Option B is wrong because macvlan assigns containers MAC addresses on the physical LAN, requiring a parent interface and often promiscuous mode; it is an explicit opt-in driver, not a default. Option C is wrong because overlay networks span multiple hosts (Swarm/Kubernetes style) and require a key-value store or orchestrator; Podman Compose on a single host does not default to overlay.

Full explanation →

260

MCQeasy

A user wants to inspect the metadata and layers of an image stored locally without running it. Which Podman command should be used?

A.podman inspect image_name

B.podman view image_name

C.podman info

D.podman show image_name

AnswerA

podman inspect reads the local image's configuration metadata and layer information from container storage without creating or starting a container. Commands such as podman run or podman history execute or rebuild context, so they fail the stem's constraint of inspecting without running.

Why this answer

'podman inspect image_name' returns detailed JSON metadata about the image, including its layers, configuration, environment variables, and creation history, without running it. This is the standard command for examining local image details.

Exam trap

The trap is confusing 'podman info' (host-level) with 'podman inspect <image>' (resource-level) — candidates often pick 'info' thinking it provides image details, but it only shows system-wide configuration.

How to eliminate wrong answers

Option B is wrong because 'podman view' is not a valid Podman command — there is no 'view' subcommand. Option C is wrong because 'podman info' displays host-level Podman configuration (storage driver, cgroup version, registries), not details about a specific image. Option D is wrong because 'podman show' is not a valid command — image details are retrieved with 'inspect', not 'show'.

Full explanation →

261

MCQhard

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

A.podman run --healthcheck="curl -f http://localhost/" --interval=30 --timeout=5 --retries=3 webapp

B.podman run --health-probe="curl -f http://localhost/" --health-delay=10s webapp

C.podman run --health-cmd="curl -f http://localhost/ || exit 1" --health-interval=30s --health-timeout=5s --health-retries=3 --health-start-period=10s webapp

D.podman run --check-command="curl -f http://localhost/" --check-period=30s webapp

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

262

MCQhard

A developer wants to pass a secret API key during the container build process without leaving the secret exposed in image layers or history. Which Podman feature should be used?

A.ARG API_KEY=secret_value

B.ENV API_KEY=secret_value

C.podman build --secret id=mysecret,src=/path/to/key.txt . with RUN --mount=type=secret,id=mysecret ...

D.ADD /path/to/key.txt /app/key.txt followed by RUN rm /app/key.txt

AnswerC

Build secrets mount the key only during the RUN instruction via a temporary filesystem, so it never persists in image layers or history. This satisfies the requirement to pass the API key without exposing it in the resulting image.

Why this answer

Podman supports build-time secrets using the --secret flag and the --mount=type=secret directive in the Containerfile.

Full explanation →

263

Multi-Selecteasy

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

Select 2 answers

A.podman stream

B.podman view-logs

C.podman attach

D.podman output

E.podman logs

AnswersC, E

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

Why this answer

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

Exam trap

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

Full explanation →

264

MCQmedium

You need to configure a container so that its port 8080 maps to port 80 on the host's loopback interface only (127.0.0.1). Which syntax is correct?

A.podman run --net 127.0.0.1:80:8080 myapp

B.podman run -p 80:8080/127.0.0.1 myapp

C.podman run --publish 8080:80/lo myapp

D.podman run -p 127.0.0.1:80:8080 myapp

AnswerD

Binding the host address explicitly as 127.0.0.1:80:8080 restricts the published port to the loopback interface, satisfying the stem's requirement that only the host itself reach container port 8080 via host port 80. Omitting the address would publish on all interfaces, exposing the service externally.

Why this answer

The correct syntax for binding a published container port to a specific host IP is `-p HOST_IP:HOST_PORT:CONTAINER_PORT`. Option D, `-p 127.0.0.1:80:8080`, maps container port 8080 to host port 80, but only on the loopback interface 127.0.0.1, which is exactly what the question requires. This restricts external access so only processes on the host itself can reach the service.

Exam trap

EX188 often tests the exact ordering of the `-p` argument — candidates frequently swap host and container ports or misplace the IP, so memorise the format `IP:hostPort:containerPort/protocol`.

How to eliminate wrong answers

Option A is wrong because `--net` is used to specify a network mode (bridge, host, none, or a CNI network name), not to publish ports, and the value `127.0.0.1:80:8080` is not a valid network name. Option B is wrong because the syntax `80:8080/127.0.0.1` places the IP after a slash, which Podman interprets as a protocol suffix (tcp/udp), not a host IP binding. Option C is wrong because `8080:80/lo` reverses the port order and uses `lo` as a protocol, which is invalid; the correct order is host:container and the protocol must be tcp or udp.

Full explanation →

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