EX188 Multiple Select — 60 Questions

Question 1

Which TWO files or backend network management utilities are heavily relied upon by Podman for container networking stack configuration on modern Linux distributions? (Choose two.)

Accepted Answer

aardvark-dns. Option E, netavark, is correct because it is the default OCI container network backend for Podman on modern Linux distributions, responsible for setting up container network interfaces, bridges, and firewall rules. Option A, aardvark-dns, is correct because it is the authoritative DNS server that Podman relies on to provide name resolution between containers on the same network, working alongside netavark. Together, netavark and aardvark-dns replaced the older CNI-based stack as Podman's default networking solution. Option B, libnetwork, is incorrect because it is Docker's networking library, not Podman's backend. Option C, docker-proxy, is incorrect because it is a Docker component for port forwarding, not used by Podman. Option D, iptables-nft, is incorrect because although Podman may interact with nftables through netavark, iptables-nft itself is not a Podman-specific networking utility relied upon for stack configuration.

Answer

libnetwork

Answer

docker-proxy

Answer

iptables-nft

Question 2

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

Accepted Answer

Host bind mounts referencing directories on the host filesystem. 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.

Answer

Shared memory block devices via NFS exports

Answer

Direct Fibre Channel LUN mapping inside containers

Answer

Distributed HDFS cluster mounts

Question 3

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

Accepted Answer

Stop all running containers using 'podman stop $(podman ps -q)'.. 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.

Answer

Directly edit a running container's image tag using 'podman edit --tag'.

Answer

Instantly migrate a running container to a remote physical server using 'podman migrate'.

Question 4

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

Accepted Answer

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

Answer

start

Answer

build

Answer

commit

Question 5

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)

Accepted Answer

podman cp container_name:/app/file.txt host_file.txt. 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.

Answer

podman cp --target=container_name host_file.txt /app/file.txt

Answer

podman cp --direction=to-container host_file.txt container_name:/app/

Answer

podman cp --from=container_name /app/file.txt host_file.txt

Question 6

Which THREE statements correctly describe the differences between CMD and ENTRYPOINT in a Containerfile?

Accepted Answer

Combining ENTRYPOINT and CMD allows default arguments to be supplied while retaining override flexibility.. Option B is correct because when both ENTRYPOINT and CMD are used together, CMD supplies default arguments to the ENTRYPOINT executable, and those defaults can still be replaced by arguments passed at runtime to podman run. Option C is correct because ENTRYPOINT is specifically designed to set the image's main executable, making the container behave like a dedicated command such as /usr/bin/httpd or a custom application binary. Option D is correct because CMD provides defaults that are easily overridden: any arguments appended to podman run replace the CMD instruction entirely. Option A is incorrect because ENTRYPOINT can be overridden at runtime using podman run --entrypoint. Option E is incorrect because CMD and ENTRYPOINT serve different roles and have distinct syntax and behavior, especially regarding how runtime arguments interact with them.

Answer

ENTRYPOINT instructions cannot be overridden at runtime under any circumstances.

Answer

CMD and ENTRYPOINT perform identical functions with no syntactical differences.

Question 7

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

Accepted Answer

Generate a cryptographic key pair and ensure the private key is available to sign the image.. 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.

Answer

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

Answer

Store the private signing key inside the container image payload.

Answer

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

Question 8

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

Accepted Answer

-p 8080:80. 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.

Answer

-p container=80,host=8080

Answer

-p 80:8080:tcp:bind

Question 9

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

Accepted Answer

Running 'podman image inspect ' to view its configuration metadata.. Option B is correct because 'podman image inspect ' 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.

Answer

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

Answer

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

Answer

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

Question 10

Which TWO Containerfile instructions are used to bring files or data from outside the container into the build context or image? (Choose two.)

Accepted Answer

COPY. COPY is correct because it copies files or directories from the build context (or from a stage in a multi-stage build via --from) into the image filesystem, and it does not perform any remote URL fetching or automatic archive extraction. ADD is correct because it also brings files into the image, and additionally supports fetching remote URLs and auto-extracting recognized local tar archives into the destination. GET, FETCH, and IMPORT are not valid Containerfile/Dockerfile instructions, so they cannot be used to bring files or data into the build context or image.

Answer

GET

Answer

FETCH

Answer

IMPORT

Question 11

Which THREE commands are valid when inspecting or managing Podman storage volumes? (Choose THREE)

Accepted Answer

podman volume inspect. Option B, `podman volume inspect`, is correct because it is the standard subcommand for retrieving detailed JSON metadata about a named volume, including its mountpoint, driver, labels, and options. Option C, `podman volume rm`, is correct because it removes one or more volumes from Podman storage, optionally with `--force` to remove volumes in use. Option D, `podman volume create`, is correct because it is the canonical command for creating a new named volume, supporting flags such as `--driver`, `--label`, and `--opt`. Option A, `podman volume modify`, is not a valid Podman subcommand (unlike `podman volume` operations such as `ls`, `prune`, or `exists`), and Option E, `podman volume edit`, also does not exist; Podman has no built-in volume editing command, so volume attributes must be changed by recreating the volume or using supported flags at creation time.

Answer

podman volume modify

Answer

podman volume edit

Question 12

Which TWO actions can be performed using the podman volume management command suite? (Choose two.)

Accepted Answer

Display detailed low-level configuration of a volume using podman volume inspect. Option B is correct because `podman volume inspect` is a real subcommand of the `podman volume` suite that outputs detailed low-level JSON configuration for a named volume, including its mountpoint, driver, labels, and options. Option E is correct because `podman volume prune` is a valid subcommand that removes all volumes not currently referenced by any container, freeing unused storage. Option A is incorrect because there is no `podman volume resize` subcommand; volume size limits are not managed that way in Podman. Option C is incorrect because `podman volume encrypt` does not exist; Podman does not provide a volume-encryption subcommand in its volume suite. Option D is incorrect because `podman volume convert` is not a real subcommand and bind mounts cannot be converted into named volumes via the volume management suite.

Answer

Modify the size limit of an existing volume using podman volume resize

Answer

Encrypt a managed volume at rest using podman volume encrypt

Answer

Convert a bind mount to a named volume using podman volume convert

Question 13

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

Accepted Answer

podman unpause. Option B, podman pause, is correct because it suspends all processes in a running container by sending SIGSTOP via the freezer cgroup, leaving the container intact so it can be resumed later. Option A, podman unpause, is correct because it reverses that state by sending SIGCONT through the freezer cgroup, allowing the previously paused processes to continue running. Together these two commands implement the temporary pause-and-resume workflow the administrator needs. Option C, podman freeze, is not a valid Podman command for this purpose, and option D, podman resume, is likewise not a real Podman subcommand. Option E, podman stop, is incorrect because it terminates the container's processes rather than temporarily suspending them, so the container could not simply be resumed.

Answer

podman freeze

Answer

podman resume

Answer

podman stop

Question 14

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

Accepted Answer

podman secret create. 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.

Answer

podman secret compile

Answer

podman secret update

Answer

podman secret modify

Question 15

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)

Accepted Answer

podman inspect --format='{{.State.StartedAt}}' container_name. 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.

Answer

podman inspect --format='{{.Metadata.ExitCode}}' container_name

Answer

podman inspect --format='{{.Status.Running}}' container_name

Answer

podman inspect --format='{{.Exit}}' container_name

Question 16

Which THREE of the following are valid options or flags when working with Podman secrets? (Choose THREE)

Accepted Answer

podman secret rm. Option B, `podman secret rm`, is a valid Podman subcommand used to remove one or more existing secrets from Podman's secret store, so it correctly belongs to the `podman secret` command family. Option C, `podman secret ls`, is also valid because it lists all secrets currently managed by Podman, optionally with formatting or filtering flags. Option E, `podman secret create`, is valid as the primary command for creating a new secret from a file or standard input, which is the core operation for Podman secrets. The unmarked options do not belong: `podman secret extract` (A) is not a Podman secret subcommand, and `podman secret compile` (D) is likewise not a recognized Podman secret operation.

Answer

podman secret extract

Answer

podman secret compile

Question 17

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

Accepted Answer

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

Answer

Networks

Answer

Secrets

Question 18

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

Accepted Answer

The user must have read/write access to the host directory on the host file system. 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.

Answer

Direct modification of the host kernel mount tables

Answer

Disabling user namespaces across the system

Answer

Root privileges on the host operating system

Question 19

Which TWO methods can be used to supply environment variables to a Podman container? (Choose TWO)

Accepted Answer

Using the -e or --env flag. Option C is correct because Podman supports the -e or --env flag to pass individual environment variables directly on the command line, e.g. podman run -e MYVAR=value image, which sets the variable inside the container. Option E is correct because the --env-file flag lets you supply a file containing KEY=value lines that Podman reads and injects as environment variables into the container. The other options are not valid Podman flags: --environment-map (A), --var-file (B), and --inject-env (D) do not exist in Podman's CLI, so they cannot be used to supply environment variables.

Answer

Using the --environment-map flag

Answer

Using the --var-file flag

Answer

Using the --inject-env flag

Question 20

Which TWO options can be specified when mounting a Podman secret into a container? (Choose TWO)

Accepted Answer

type=env. Option A (type=env) is correct because Podman secrets support being exposed to a container as environment variables, which is selected with the type=env mount option (e.g., podman run --secret mysecret,type=env). Option D (type=mount) is correct because the default and explicitly supported way to inject a secret is as a file mounted into the container's filesystem, specified with type=mount (e.g., --secret mysecret,type=mount). The remaining options do not belong: type=volume, type=tmpfs, and type=bind are not valid secret type values for Podman secrets — tmpfs and bind are storage/mount concepts used elsewhere (e.g., --mount type=tmpfs or type=bind), and volume is a storage driver concept, none of which are accepted as the secret type parameter.

Answer

type=volume

Answer

type=tmpfs

Answer

type=bind