Knowledge + Practice

CCNA Registry And Security Questions

47 questions · Registry And Security · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

A system administrator logs into a RHEL 9 server as a regular non-root user and executes 'podman ps'. The command succeeds, but no containers are displayed. What architecture feature enables this user to run containers without root privileges?

A.The Docker daemon running as a system service in user space

B.The systemd-logind setuid binary wrapper

C.Linux user namespaces and subuid/subgid mapping

D.SELinux multi-category security (MCS) translation tables

AnswerC

Rootless Podman relies on Linux user namespaces to map the unprivileged user to a pseudo-root inside the container, with subuid/subgid ranges from /etc/subuid and /etc/subgid enabling that mapping. This is what lets the non-root user run containers without root privileges.

Why this answer

Rootless Podman relies on Linux user namespaces combined with subordinate UID/GID ranges defined in /etc/subuid and /etc/subgid. The user namespace maps the container's root (UID 0) to the unprivileged user's UID on the host, and additional container UIDs map into the allocated subuid/subgid ranges. This lets a non-root user run containers without any setuid daemon.

Exam trap

EX188 often tests rootless architecture, and candidates pick SELinux MCS or a setuid daemon because they assume privilege separation must come from SELinux or a privileged helper rather than user namespaces.

How to eliminate wrong answers

Option A is wrong because Podman is daemonless — there is no Docker daemon, and running a daemon in user space is not what enables rootless operation. Option B is wrong because systemd-logind is not a setuid wrapper for containers; it manages sessions and device access, not container privilege separation. Option D is wrong because SELinux MCS labels provide isolation between containers but do not grant the privilege to run containers as a non-root user — that is the job of user namespaces.

Practice this question →

2

MCQmedium

A container running in rootless mode needs to map a user account on the host to a different user inside the container namespace. Which options configure UID and GID mapping?

A.--userns-map and --groupmap

B.--uidmap and --gidmap

C.--user-namespace-file

D.--map-user and --map-group

AnswerB

The --uidmap and --gidmap flags pass explicit UID and GID translation ranges to the container runtime, mapping host accounts to different identities inside the user namespace. This satisfies the rootless mapping requirement, unlike --userns=keep-id, which preserves the invoking user's identity rather than remapping it.

Why this answer

The --uidmap and --gidmap options are used with podman run to define custom UID and GID mappings between the host and the container user namespace. These flags allow fine-grained control over how host UIDs map to container UIDs, which is essential in rootless mode where the user namespace is already in play. They accept values in the format container_uid:host_uid:count.

Exam trap

EX188 often tests the exact flag names for user namespace mapping — candidates confuse --uidmap/--gidmap with nonexistent flags like --userns-map or --map-user, and the exam includes plausible-sounding distractors.

How to eliminate wrong answers

Option A is wrong because '--userns-map' and '--groupmap' are not valid podman flags; the correct flags are --uidmap and --gidmap. Option C is wrong because '--user-namespace-file' does not exist; while there is a --userns flag (with values like host, keep-id, auto), it does not take a file for mapping. Option D is wrong because '--map-user' and '--map-group' are not podman options; they may sound plausible but are not part of the CLI.

Practice this question →

3

MCQhard

An administrator needs to configure system-wide registry search shortcuts so that developers can run 'podman pull rhel9' and Podman automatically expands it to 'registry.access.redhat.com/rhel9'. Which configuration file and parameter accomplish this?

A./etc/containers/registries.conf using the unqualified-search-registries parameter

B./etc/sysconfig/podman using the SEARCH_REGISTRIES variable

C./etc/containers/registries.d/default.yaml using the search-domains parameter

D.~/.config/containers/auth.json using the default-registry key

AnswerA

The `unqualified-search-registries` parameter in `/etc/containers/registries.conf` lists registries that Podman queries when an image name lacks a registry hostname. Adding `registry.access.redhat.com` there makes `podman pull rhel9` resolve to `registry.access.redhat.com/rhel9`, satisfying the system-wide shortcut requirement for all developers.

Why this answer

The /etc/containers/registries.conf file contains the unqualified-search-registries parameter, which lists registries to search when a user pulls an image without specifying a registry. Adding registry.access.redhat.com to this list allows podman pull rhel9 to automatically expand to registry.access.redhat.com/rhel9.

Exam trap

EX188 often tests the location and parameter name for registry search configuration, and may include plausible but incorrect files like /etc/sysconfig/podman or parameters like SEARCH_REGISTRIES to distract candidates who are not familiar with the containers-registries.conf format.

How to eliminate wrong answers

Option B is wrong because /etc/sysconfig/podman and the SEARCH_REGISTRIES variable are not part of Podman's configuration; Podman uses registries.conf. Option C is wrong because /etc/containers/registries.d/default.yaml is used for configuring signature verification and registry-specific settings, not search domains; the parameter search-domains does not exist there. Option D is wrong because ~/.config/containers/auth.json stores authentication credentials for registries, not search shortcuts; the default-registry key is not used for this purpose.

Practice this question →

4

MCQmedium

A user is running rootless Podman and needs to verify why a container cannot bind to TCP port 80. By default, unprivileged users cannot bind to ports below 1024. Which parameter controls the minimum unprivileged port that can be bound?

A.user.max_user_namespaces

B.net.ipv4.tcp_port_range

C.fs.inotify.max_user_watches

D.net.ipv4.ip_unprivileged_port_start

AnswerD

The sysctl parameter net.ipv4.ip_unprivileged_port_start defines the lowest port number an unprivileged user may bind. Lowering it below 80 lets rootless Podman containers bind TCP port 80 without elevated privileges, directly resolving the binding failure described.

Why this answer

The sysctl parameter net.ipv4.ip_unprivileged_port_start defines the lowest port number that unprivileged (non-root) users are permitted to bind. By default it is set to 1024, which is why rootless Podman containers cannot bind to port 80. Lowering this value (e.g., to 80 or 0) allows unprivileged processes to bind to lower ports.

Exam trap

EX188 often tests the confusion between kernel parameters that control resource limits (namespaces, inotify watches) and those that govern network port privileges, so candidates must recognize that only net.ipv4.ip_unprivileged_port_start directly affects unprivileged port binding.

How to eliminate wrong answers

Option A is wrong because user.max_user_namespaces limits the number of user namespaces a user can create, not port binding privileges. Option B is wrong because net.ipv4.tcp_port_range defines the ephemeral port range for outbound connections, not the privileged port threshold. Option C is wrong because fs.inotify.max_user_watches controls the number of inotify file watches, unrelated to network port binding.

Practice this question →

5

Multi-Selecteasy

Which TWO actions can an administrator take to manage container image tags in local Podman storage? (Choose two.)

Select 2 answers

A.Use 'podman rmi' to remove a specific image tag from local storage.

B.Use 'podman push --tag' to rename images remotely.

C.Use 'podman rename' to change an image tag.

D.Use 'podman tag' to assign a new name or tag to an existing local image ID.

E.Use 'podman commit --tag' to tag running containers during creation.

AnswersA, D

'podman rmi' accepts a tag reference and deletes that specific tag from local storage, removing only the named reference while the underlying image layers remain if other tags still point to them. This satisfies the stem's requirement for managing tags in local Podman storage.

Why this answer

Option A is correct because 'podman rmi' removes images from local storage, and when given a tag reference (e.g., 'podman rmi myimage:oldtag') it deletes that specific tag; if it is the last tag on the image, the underlying image is also removed. Option D is correct because 'podman tag' creates an additional name/tag pointing to an existing local image ID (e.g., 'podman tag IMAGE_ID repo/name:newtag'), which is the standard way to assign a new tag without rebuilding or pushing. Option B is wrong because 'podman push --tag' does not exist as a rename mechanism; push transfers an image to a registry and does not manage local tags.

Option C is wrong because 'podman rename' renames containers, not images, so it cannot change an image tag. Option E is wrong because 'podman commit' creates a new image from a container's changes and does not accept a '--tag' flag for tagging during creation.

Exam trap

EX188 often tests whether candidates confuse container renaming (podman rename) with image tagging (podman tag), or assume push/commit can rename local tags.

Practice this question →

6

Multi-Selecthard

A security-conscious administrator runs a rootless Podman container that must bind-mount a directory from the host. The container process is denied access to the files even though the directory has world-readable permissions, and SELinux is enforcing. Which TWO steps will resolve the denial while keeping SELinux enforcing? (Choose two.)

Select 2 answers

A.Change the host directory's SELinux type to container_file_t with semanage fcontext and restorecon.

B.Add the :Z option to the volume mount so Podman relabels the host directory with a container-specific SELinux type.

C.Run the container with --security-opt label=disable to remove SELinux confinement from the container.

D.Set the container to run with --privileged so it bypasses SELinux checks on the mounted files.

E.Use a bind mount with the :ro option so SELinux treats the mount as read-only and permits access.

AnswersA, B

Persistently setting the directory's default context to container_file_t and applying it with restorecon makes the host path compatible with container access under SELinux enforcement. This is appropriate when the directory is dedicated to container use, and it does not require disabling SELinux or weakening the confinement of the container.

Why this answer

SELinux denials for bind mounts occur because the host directory retains a type that the container process is not allowed to access. Relabeling the path with :Z for a private container label, or persistently setting the path's type to container_file_t and applying it, aligns the SELinux context with the container's policy. Both solutions preserve enforcing mode and avoid disabling confinement.

Exam trap

The trap here is assuming that world-readable filesystem permissions are sufficient and overlooking that SELinux type enforcement blocks access independently of standard Unix permissions.

Practice this question →

7

MCQmedium

A developer needs to push a locally built image to a private registry that requires authentication. The registry uses a self-signed certificate, and the developer wants Podman to trust that certificate for this registry only. Which action should be taken?

A.Import the certificate with update-ca-trust and restart the podman.socket service.

B.Set tls-verify=false in the [[registry]] section for that registry in /etc/containers/registries.conf.

C.Copy the registry's CA certificate into /etc/containers/certs.d/<registry-host>:<port>/ and run podman login again.

D.Add the registry to the unqualified-search-registries list in /etc/containers/registries.conf.

AnswerC

Podman reads per-registry certificate files from /etc/containers/certs.d/<registry-host>:<port>/. Placing the CA certificate there allows Podman to trust the self-signed certificate for that specific registry during login and push operations, without modifying the system-wide trust store or disabling TLS verification.

Why this answer

Podman supports per-registry certificate directories under /etc/containers/certs.d. Placing the CA certificate in a directory named for the registry host and port allows Podman to trust the self-signed certificate for that registry alone. This avoids disabling TLS verification and avoids modifying the system-wide trust store, keeping the configuration scoped and secure.

Exam trap

The trap here is assuming that system-wide CA trust or a global tls-verify setting is required, when Podman provides a per-registry certificate directory that is more precise.

Practice this question →

8

Multi-Selecteasy

Which TWO commands allow a user to remove unwanted items from local Podman storage? (Choose two.)

Select 2 answers

A.podman container clear

B.podman rmi

C.podman prune-all

D.podman rm

E.podman image delete

AnswersB, D

Removes locally stored images from Podman's storage, freeing disk space and clearing unwanted container images. The rmi subcommand targets image removal specifically, satisfying the requirement to delete items held in local storage rather than containers or volumes.

Why this answer

Option B, `podman rmi`, is correct because it removes one or more images from local Podman storage, deleting the image layers and metadata from the local image store. Option D, `podman rm`, is correct because it removes one or more containers from local Podman storage, cleaning up stopped containers that are no longer wanted. Both commands directly target unwanted local objects (images and containers respectively) and are the standard Podman subcommands for deletion.

Option A, `podman container clear`, is not a valid Podman subcommand, so it cannot remove anything. Option C, `podman prune-all`, is not a real Podman command; pruning is done via `podman system prune` or `podman image prune`/`podman container prune`. Option E, `podman image delete`, is not a valid Podman subcommand; image deletion is performed with `podman rmi` (or `podman image rm`).

Exam trap

EX188 often tests the exact syntax of Podman commands; candidates may confuse `podman rmi` with `podman image delete` or `podman rm` with `podman container clear`.

Practice this question →

9

MCQeasy

A user wants to inspect the effective signature verification policy that Podman will apply when pulling images, without modifying any files. Which command displays the current policy configuration?

A.podman image trust show

B.skopeo inspect docker://<registry>/<image>

C.podman info --format '{{.Registries}}'

D.podman inspect --type image <image>

AnswerA

The podman image trust show command displays the active signature verification policy derived from policy.json and related configuration. It shows which registries or repositories are allowed, and what signature requirements apply. It is read-only and does not alter the policy, making it suitable for inspecting the effective settings before pulling images.

Why this answer

The signature verification policy is defined in /etc/containers/policy.json and can be viewed with podman image trust show. This command prints the effective policy, including accepted registries and signature requirements, without editing files. It is the correct way to inspect what Podman will enforce when pulling images.

Exam trap

The trap here is confusing image metadata inspection with policy inspection, leading to commands that describe an image rather than the host's signature verification rules.

Practice this question →

10

MCQeasy

A user needs to download an image from Docker Hub named 'library/alpine' using its explicit transport prefix. Which command demonstrates the correct transport syntax?

A.podman pull registry://alpine:latest

B.podman pull remote://alpine:latest

C.podman pull OCI://alpine:latest

D.podman pull docker://alpine:latest

AnswerD

The docker:// transport prefix explicitly forces Podman to treat the reference as a Docker Hub registry image, pulling library/alpine with the latest tag. This satisfies the stem's requirement for explicit transport syntax rather than relying on Podman's default registry resolution.

Why this answer

The correct transport for pulling from a Docker registry like Docker Hub is 'docker://'. The command 'podman pull docker://alpine:latest' explicitly tells Podman to use the Docker transport to fetch the 'library/alpine' image from Docker Hub. This syntax is part of Podman's support for multiple transports, where 'docker://' is the standard prefix for registry-based images.

Exam trap

EX188 often tests the distinction between different image transports in Podman, and candidates may confuse 'docker://' with other prefixes like 'oci://' or assume 'registry://' is valid, leading to incorrect answers.

How to eliminate wrong answers

Option A is wrong because 'registry://' is not a valid transport in Podman; the correct transport for Docker registries is 'docker://'. Option B is wrong because 'remote://' is not a recognized transport; Podman uses 'docker://' for remote registries. Option C is wrong because 'OCI://' is used for OCI image layouts stored locally or in a directory, not for pulling from a remote registry like Docker Hub.

Practice this question →

11

MCQeasy

A practitioner wants to view all container images currently stored in local storage, including their size, tag, and image ID. Which command should they execute?

A.podman list images

B.podman images

C.podman show images

D.podman ps -a

AnswerB

The podman images command lists all container images in local storage, showing repository, tag, image ID and size. That directly matches the requirement to view every locally stored image with its size, tag and ID.

Why this answer

The `podman images` command lists all container images in local storage, displaying repository, tag, image ID, creation time, and size. It is the direct equivalent of `docker images` and is the standard way to inspect the local image cache. Options A, C, and D are not valid Podman subcommands for listing images.

Exam trap

EX188 often tests the confusion between container and image management commands, specifically the difference between `podman ps` (containers) and `podman images` (images), and the invalid use of `list` or `show` as subcommands.

How to eliminate wrong answers

Option A is wrong because `podman list images` is not a valid command; Podman uses `podman images` (or `podman image list`) to list images, and `podman list` alone is not a recognized subcommand. Option C is wrong because `podman show images` does not exist; `podman show` is not a command, and image inspection is done with `podman inspect`. Option D is wrong because `podman ps -a` lists containers (including stopped ones), not images; it shows container IDs, names, status, and ports, but not image details like size or tag.

Practice this question →

12

MCQhard

A security engineer is troubleshooting why signature verification fails when pulling an image from a trusted registry. The policy file (/etc/containers/policy.json) specifies 'signedBy' using a GPG key, but the transport uses 'dir://'. Where must the public GPG key be imported for Podman to successfully verify the signature?

A.Into the local GnuPG keyring using 'gpg --import'

B.Into ~/.config/containers/policy.d/keys/

C.Into /etc/containers/certs.d/keys/

D.Into /var/lib/containers/sigstore/

AnswerA

For dir:// transports, Podman verifies signatures against keys in the local GnuPG keyring, so the public key must be imported there with gpg --import. Registry-scoped key files or policy entries alone do not satisfy verification for a directory transport.

Why this answer

For the dir:// transport, Podman verifies signatures using keys in the local GnuPG keyring, so the public key must be imported with 'gpg --import' into the user's keyring (or root's, depending on context). The signedBy field in policy.json references a key fingerprint that Podman looks up in that keyring during verification.

Exam trap

EX188 often tests the distinction between key storage locations for different transports, tempting candidates to pick sigstore or certs.d paths that sound authoritative but are used for entirely different purposes.

How to eliminate wrong answers

Option B is wrong because ~/.config/containers/policy.d/keys/ is not a directory Podman consults for GPG keys — policy.d holds policy fragments, not key material. Option C is wrong because /etc/containers/certs.d/keys/ is not a standard path; certs.d is used for registry TLS certificates, not signature keys. Option D is wrong because /var/lib/containers/sigstore/ stores signature blobs fetched from registries for the docker:// transport, not the public keys used for dir:// verification.

Practice this question →

13

MCQhard

A rootless Podman user must run a container that needs to write to a bind-mounted host directory. The container consistently fails with permission denied. The host directory is owned by the user and has mode 0775. SELinux is enforcing. Which action will allow the container to write to the directory without disabling SELinux?

A.Add the `:Z` option to the volume mount to relabel the host directory for the container.

B.Change the host directory mode to 0777 to eliminate permission issues.

C.Set the `container_manage_cgroup` boolean to allow container writes.

D.Run `podman run --privileged` to bypass all SELinux checks.

AnswerA

The :Z option tells Podman to relabel the host directory with a private SELinux label unique to the container. This allows the container process to write while keeping SELinux enforcing. It is the recommended way to handle SELinux denials for bind mounts in rootless mode, and it does not require disabling or weakening SELinux.

Why this answer

When a bind-mounted host directory is not labeled for container access, SELinux denies writes. Adding :Z to the volume mount causes Podman to relabel the directory with a container-specific private label, allowing the container to write while SELinux remains enforcing. This is the standard, secure fix for this scenario.

Exam trap

The trap here is thinking that fixing Unix permissions or disabling SELinux solves the problem, when the real issue is the SELinux label on the host directory.

Practice this question →

14

MCQmedium

An administrator wants to inspect the container storage configuration settings, such as graph root and storage driver, on a RHEL system. Which configuration file should they examine?

A./etc/containers/podman.conf

B./etc/containers/registries.conf

C./etc/containers/storage.conf

D./etc/sysconfig/docker

AnswerC

/etc/containers/storage.conf holds the container storage configuration, including graph root and storage driver settings used by Podman and related tools on RHEL. Editing this file changes where images and containers are stored and which driver handles the layers.

Why this answer

The /etc/containers/storage.conf file is the primary configuration file for container storage on RHEL systems using Podman. It defines settings such as the storage driver (e.g., overlay) and the graph root directory where container images and layers are stored. Administrators inspect this file to understand or modify how container storage is managed.

Exam trap

EX188 often tests the confusion between configuration files for different container aspects, such as storage versus registries, and the assumption that Docker-specific files apply to Podman.

How to eliminate wrong answers

Option A is wrong because /etc/containers/podman.conf does not exist as a standard configuration file for Podman; Podman uses various files under /etc/containers/ but not this one. Option B is wrong because /etc/containers/registries.conf configures container registry access (e.g., which registries to use and their mirrors), not storage settings. Option D is wrong because /etc/sysconfig/docker is a configuration file for Docker, not Podman, and on RHEL 9 Podman is the default container engine.

Practice this question →

15

Multi-Selecthard

Which THREE methods or options can be used to authenticate or supply credentials when pulling images from a private registry that requires authentication? (Choose three.)

Select 3 answers

A.Running 'podman login' beforehand to store credentials in auth.json.

B.Setting the environment variable 'PODMAN_PASSWORD' without any login command.

C.Passing '--password-stdin' directly to 'podman pull'.

D.Using the '--authfile' flag pointing to a custom credentials file.

E.Providing username and password inline using '--creds username:password'.

AnswersA, D, E

Running podman login beforehand stores registry credentials in auth.json, which subsequent pulls read automatically. This satisfies the requirement by pre-authenticating the registry session, so no inline credentials or custom file path is needed at pull time.

Why this answer

Option A is correct because 'podman login' stores the registry credentials in the auth.json file (typically under $XDG_RUNTIME_DIR/containers/auth.json or ~/.config/containers/auth.json), and subsequent 'podman pull' operations automatically read those stored credentials. Option D is correct because the '--authfile' flag lets you point 'podman pull' at a custom credentials file in the same JSON format, which is useful for non-default credential locations or automation. Option E is correct because 'podman pull --creds username:password' supplies the credentials inline for that single command, authenticating directly against the private registry without a prior login.

Option B is not a valid mechanism: Podman does not read a 'PODMAN_PASSWORD' environment variable to authenticate pulls, so setting it alone has no effect. Option C is not valid because '--password-stdin' is an option of 'podman login' (to read the password from standard input), not of 'podman pull', so it cannot be passed directly to the pull command.

Exam trap

EX188 often tests the various authentication methods, and candidates mistakenly think environment variables like PODMAN_PASSWORD are used, or confuse '--password-stdin' as a pull flag rather than a login flag.

Practice this question →

16

MCQhard

An organization mandates that all container images produced internally must be signed using local GPG keys before being pushed to the production registry. Which tool and configuration file must be used to enforce that Podman rejects unsigned images during a pull operation?

A./etc/containers/policy.json

B./etc/containers/registries.conf

C./var/lib/shared/sigstore

D.~/.config/containers/auth.json

AnswerA

Podman consults /etc/containers/policy.json on every pull, applying its signature policy to decide whether an image is accepted. Configuring a signedBy requirement there forces rejection of unsigned images, enforcing the mandated GPG signing before production registry pulls.

Why this answer

Signature enforcement for image pulls is controlled by /etc/containers/policy.json, which defines per-transport and per-registry requirements such as 'signedBy' with a GPG keyring. To reject unsigned images, the policy must specify a signedBy requirement (or 'reject') for the relevant registry scope, causing Podman to fail the pull if the signature is missing or invalid.

Exam trap

EX188 often tests whether candidates confuse registries.conf (registry access) with policy.json (signature enforcement), or mistakenly pick auth.json for signature policy.

How to eliminate wrong answers

Option B is wrong because /etc/containers/registries.conf configures registry endpoints, mirrors, and TLS settings, but does not enforce signature verification. Option C is wrong because /var/lib/shared/sigstore is not a standard Podman configuration path for signature policy; signatures are typically stored in /var/lib/containers/sigstore or referenced via registries.d. Option D is wrong because ~/.config/containers/auth.json stores registry credentials, not signature policy.

Practice this question →

17

Multi-Selecthard

Which THREE mechanisms are part of Podman's image signature verification framework on RHEL 9? (Choose three.)

Select 3 answers

A.Signature storage backends (such as sigstore) where detached signatures are stored.

B.Automatic kernel SELinux policy compilation during image pull.

C.Built-in TLS client certificate authorities for registry TCP handshakes.

D.The policy configuration file (/etc/containers/policy.json) that defines required verification checks.

E.GnuPG public key rings or signature verification keys used to validate cryptographic signatures.

AnswersA, D, E

Detached signatures are fetched from configured storage backends such as sigstore, letting Podman retrieve the signature that corresponds to an image before validating it. This satisfies the stem's requirement for a signature verification framework mechanism.

Why this answer

Podman's image signature verification framework on RHEL 9 relies on three core components. Option A is correct because signature storage backends (for example, the sigstore backend configured in registries.d YAML files) define where detached signatures are fetched from and stored during verification. Option D is correct because /etc/containers/policy.json is the policy configuration file that specifies which repositories or transports require signature verification and what type of verification (such as signedBy) must pass.

Option E is correct because GnuPG public key rings (referenced via keyPath or keyData in policy.json) supply the cryptographic keys used to validate the detached image signatures. Option B is not part of this framework, since SELinux policy compilation is unrelated to image signature verification and is not triggered by image pulls. Option C is also incorrect because TLS client certificate authorities for registry handshakes belong to transport-level TLS authentication, not to Podman's signature verification framework.

Exam trap

The trap is that candidates conflate transport security (TLS client certs) or unrelated system hardening (SELinux policy compilation) with image signature verification, picking plausible-sounding but out-of-scope mechanisms.

Practice this question →

18

MCQhard

An administrator wants to configure Podman to pull images using a specific TLS client certificate for mutual TLS authentication against a secure private registry. Where should the client certificate and private key be placed?

A./etc/containers/certs.d/registry.example.com/ (with client.cert and client.key)

B.~/.config/containers/tls/

C./etc/pki/tls/private/

D./etc/containers/auth.d/

AnswerA

Placing client.cert and client.key under /etc/containers/certs.d/registry.example.com/ satisfies Podman's per-registry TLS lookup, where the directory name must match the registry hostname. Podman automatically presents these files during mutual TLS negotiation, so no additional configuration flags are required for the private registry connection.

Why this answer

Podman (via containers/image) looks for registry-specific TLS client certificates in /etc/containers/certs.d/<registry-hostname>/, where files named client.cert and client.key provide the mutual TLS credentials. This is the documented location for per-registry TLS configuration.

Exam trap

The trap is confusing registry authentication (auth.json for username/password) with TLS client certificate authentication (certs.d for mTLS) — they use entirely different file locations and mechanisms.

How to eliminate wrong answers

Option B is wrong because ~/.config/containers/tls/ is not a recognized path for registry client certificates — Podman's per-registry cert directory is under /etc/containers/certs.d/. Option C is wrong because /etc/pki/tls/private/ is the system-wide TLS private key directory used by OpenSSL and web servers, not by Podman for registry authentication. Option D is wrong because /etc/containers/auth.d/ is not a standard directory — authentication credentials for registries are stored in /run/containers/0/auth.json or ${XDG_RUNTIME_DIR}/containers/auth.json, and that is for username/password or token auth, not TLS client certificates.

Practice this question →

19

Multi-Selecthard

Which THREE actions occur when an administrator runs a container with an SELinux volume mount suffix ':Z'? (Choose three.)

Select 3 answers

A.The host path's SELinux context is altered to match the container's private category.

B.The SELinux enforcement mode on the host is temporarily set to permissive.

C.The mounted content is labeled with a private, unshared SELinux security context.

D.The host directory becomes completely read-only across all namespaces.

E.Only the specific container launched with the flag can access the labeled files under SELinux enforcement.

AnswersA, C, E

With :Z, the host directory's SELinux context is relabelled to carry the container's private MCS category, so the files match the container process's context. This satisfies the stem because enforcement requires the host path label to align with the container's category.

Why this answer

Option A is correct because the ':Z' suffix instructs the container runtime (e.g., podman/docker with SELinux) to relabel the host path's SELinux context, changing its type and adding a unique MCS category so it matches the container's private label. Option C is correct because ':Z' applies a private, unshared SELinux context (a unique category pair) to the mounted content, unlike ':z' which applies a shared label. Option E is correct because the private MCS category ensures that only the specific container launched with that flag can access the labeled files while SELinux is enforcing, preventing other containers from accessing them.

Option B is incorrect because ':Z' does not change the host's SELinux enforcement mode to permissive; enforcement remains as configured. Option D is incorrect because ':Z' only relabels the content and does not make the host directory read-only across all namespaces.

Exam trap

EX188 often tests the distinction between ':Z' (private) and ':z' (shared) SELinux relabeling, and candidates mistakenly think ':Z' changes enforcement mode or mount permissions.

Practice this question →

20

Multi-Selecthard

Which THREE tasks can be performed using the 'podman system' command set? (Choose three.)

Select 3 answers

A.Configuring system-wide kernel sysctl parameters for container networking.

B.Displaying storage disk space usage statistics with 'podman system df'.

C.Running an API-serving background listener with 'podman system service'.

D.Automatically updating all running systemd container services.

E.Cleaning up unused containers, images, and networks with 'podman system prune'.

AnswersB, C, E

The df subcommand reports disk space consumed by images, containers and volumes, mirroring the storage accounting administrators expect. It fulfils the question's requirement for a reporting task within the podman system command set, distinct from runtime or lifecycle operations.

Why this answer

Option B is correct because 'podman system df' reports disk space usage statistics for Podman-managed storage, showing total, active, and reclaimable space for images, containers, and volumes. Option C is correct because 'podman system service' starts a background process that exposes the Podman REST API (Docker-compatible) on a socket, enabling remote clients to manage containers. Option E is correct because 'podman system prune' removes unused containers, images, networks, and optionally volumes, reclaiming storage.

Option A is not part of the 'podman system' command set; sysctl parameters are configured via 'sysctl' or container runtime settings, not Podman. Option D is also not provided by 'podman system'; automatic updates of systemd container services are handled by tools like 'podman auto-update' or systemd timers, not the 'podman system' subcommands.

Exam trap

EX188 often tests whether candidates assume 'podman system' covers sysctl tuning or auto-updates, when those belong to sysctl and 'podman auto-update' respectively.

Practice this question →

21

Multi-Selectmedium

Which TWO configuration files or directories are routinely modified when establishing secure private container registry trust and signature policies on RHEL 9? (Choose two.)

Select 2 answers

A./etc/fstab

B./etc/containers/registries.conf

C./etc/hosts

D./etc/passwd

E./etc/containers/policy.json

AnswersB, E

registries.conf defines which registries Podman and CRI-O may contact, including unqualified-search registries and per-registry mirrors or blocks. Editing it establishes the trusted private registry endpoints required before signature verification can be enforced, satisfying the stem's secure registry trust requirement.

Why this answer

Option B, /etc/containers/registries.conf, is correct because it is the primary configuration file used by container tools such as Podman and Skopeo to define registry trust settings, including which registries are allowed, blocked, or treated as insecure, and it can reference registry-specific configuration directories. Option E, /etc/containers/policy.json, is correct because it defines the signature verification policy that container engines apply when pulling images, specifying which keys or signed identities are trusted for particular registries or repositories. Together, these files establish both registry access trust and image signature enforcement on RHEL 9.

Option A, /etc/fstab, is incorrect because it defines filesystem mount points and has nothing to do with container registry trust. Option C, /etc/hosts, is incorrect because it only provides static hostname-to-IP mappings. Option D, /etc/passwd, is incorrect because it stores local user account information, not container registry or signature policy settings.

Exam trap

EX188 often tests whether candidates confuse registry configuration (registries.conf) with signature enforcement (policy.json), leading them to pick only one file when both are required.

Practice this question →

22

MCQmedium

A system administrator is auditing containers and notices one running with the option '--security-opt label=disable'. What does this flag do?

A.It turns off SELinux separation and labeling for the container.

B.It disables seccomp system call filtering.

C.It disables user namespace mapping.

D.It disables AppArmor enforcement.

AnswerA

Disabling SELinux labelling removes the mandatory access control confinement Podman applies to the container, satisfying the stem's audit concern about reduced isolation. Processes then run under the container runtime's default type without per-container category labels, so they are no longer separated from other containers on the host.

Why this answer

The '--security-opt label=disable' flag in Podman disables SELinux labeling for the container. This means that the container processes are not confined by SELinux policies, and the container can access files without SELinux context restrictions. This is often used when SELinux is causing permission issues, but it reduces security.

The flag specifically turns off SELinux separation, not seccomp, user namespaces, or AppArmor.

Exam trap

The trap is confusing SELinux labeling with other security mechanisms like seccomp, AppArmor, or user namespaces. Candidates might think 'label=disable' disables all security features, but it specifically targets SELinux.

How to eliminate wrong answers

Option B is wrong because seccomp filtering is disabled using '--security-opt seccomp=unconfined', not 'label=disable'. Option C is wrong because user namespace mapping is controlled by '--userns' options, not by 'label=disable'. Option D is wrong because AppArmor enforcement is disabled using '--security-opt apparmor=unconfined', not 'label=disable'.

Practice this question →

23

MCQhard

An auditor notices that a container running with SELinux enforcement needs to access a specific host directory with a private read-write security context. Which SELinux suffix should be applied to the volume mount if the content is exclusive to that single container and should not be shared?

A.:z

B.:Z

C.:private

D.:seclabel

AnswerB

The :Z suffix relabels the host directory with a private, unshared SELinux context tied to that container, permitting read-write access under enforcement. The shared :z variant would allow multiple containers, so :Z satisfies the exclusivity constraint.

Why this answer

The `:Z` suffix applies a private, unshared SELinux label to the volume mount, meaning the content is exclusively accessible by that single container. This is appropriate when the host directory should not be shared with other containers, as it relabels the content with a unique MCS category.

Exam trap

EX188 often tests the distinction between `:z` (shared) and `:Z` (private); candidates confuse the two and pick `:z` when exclusive access is required, or invent non-existent options like `:private`.

How to eliminate wrong answers

Option A is wrong because `:z` applies a shared label, allowing multiple containers to access the same content, which contradicts the requirement for exclusive access. Option C is wrong because `:private` is not a valid SELinux mount suffix in Podman; the valid suffixes are `z` and `Z`. Option D is wrong because `:seclabel` is not a valid Podman volume option; it is a mount option in some contexts but not used for this purpose.

Practice this question →

24

MCQmedium

A developer wants to push a locally built container image named webapp:v1 to a private container registry located at registry.local:5000/myteam/. Which sequence of commands correctly tags and pushes the image?

A.podman push webapp:v1 --registry registry.local:5000/myteam/

B.podman tag localhost/webapp:v1 registry.local:5000/myteam/webapp:v1 followed by podman push registry.local:5000/myteam/webapp:v1

C.podman commit webapp:v1 registry.local:5000/myteam/webapp:v1

D.podman export webapp:v1 > registry.local:5000/myteam/webapp:v1.tar

AnswerB

The tag command creates a new reference pointing the local image at the registry's fully qualified repository path, which podman push then requires. Pushing that tagged reference uploads the image to registry.local:5000/myteam/, satisfying the private registry target.

Why this answer

The correct workflow requires first creating a new tag that includes the full registry path (registry.local:5000/myteam/webapp:v1) pointing to the existing local image, then pushing that fully-qualified reference. The 'podman tag' command creates an additional name for the same image without copying layers, and 'podman push' uses the registry-qualified name to determine the destination. This two-step approach is required because podman push does not accept a separate --registry flag to redirect an existing local name.

Exam trap

EX188 often tests whether candidates confuse the tagging step with the push step — many assume podman push accepts a destination registry argument, but the registry must be part of the image name created by podman tag.

How to eliminate wrong answers

Option A is wrong because 'podman push' has no '--registry' flag; the destination registry must be encoded in the image reference itself. Option C is wrong because 'podman commit' creates a new image from a running container's filesystem changes and does not tag or push to a registry. Option D is wrong because 'podman export' writes a container's filesystem as a tar archive to stdout; it does not push images to a registry and the redirection syntax is invalid for registry operations.

Practice this question →

25

MCQeasy

A user running a rootless container needs to inspect which subordinate UID and GID ranges have been allocated to their user account on the RHEL 9 host. Which files define these mappings?

A./etc/subuid and /etc/subgid

B./etc/passwd and /etc/group

C./etc/security/limits.conf

D.~/.config/containers/storage.conf

AnswerA

Rootless containers rely on user namespaces, so the kernel must map the unprivileged account's UID/GID to a wider range. /etc/subuid and /etc/subgid hold those per-user subordinate allocations, letting the user inspect exactly which ranges are assigned on the RHEL 9 host.

Why this answer

The /etc/subuid and /etc/subgid files define the subordinate UID and GID ranges allocated to each user for rootless container mapping. Each line is user:start:count, and Podman reads these to build the user namespace mappings. Inspecting them shows exactly which host UIDs/GIDs the user's containers can use.

Exam trap

EX188 often tests where subordinate ID mappings live, and candidates confuse /etc/passwd (primary IDs) with /etc/subuid and /etc/subgid (subordinate ranges).

How to eliminate wrong answers

Option B is wrong because /etc/passwd and /etc/group define the user's primary UID/GID and group memberships, not the subordinate ranges used for container mapping. Option C is wrong because /etc/security/limits.conf sets resource limits (nofile, nproc), not UID/GID mappings. Option D is wrong because ~/.config/containers/storage.conf configures storage driver and graph root, not subordinate ID allocation.

Practice this question →

26

MCQmedium

After pushing an image to a registry, a developer wants to tag the local image 'myapp:v1' as 'registry.example.com/myteam/myapp:latest'. Which command accomplishes this?

A.podman rename myapp:v1 registry.example.com/myteam/myapp:latest

B.podman commit myapp:v1 registry.example.com/myteam/myapp:latest

C.podman push myapp:v1 --target registry.example.com/myteam/myapp:latest

D.podman tag myapp:v1 registry.example.com/myteam/myapp:latest

AnswerD

The tag subcommand creates a new reference pointing at the existing local image without copying layers or contacting the registry. The source stays myapp:v1 and the fully qualified target name is added, ready for a later push.

Why this answer

The podman tag command creates a new tag that points to the same image ID as an existing local image. Running podman tag myapp:v1 registry.example.com/myteam/myapp:latest adds the fully qualified registry tag to the local image, preparing it for a push to that registry.

Exam trap

EX188 often tests the misconception that podman push can retag an image on the fly, when in fact you must tag the image locally with the full registry path before pushing.

How to eliminate wrong answers

Option A is wrong because podman rename is not a valid Podman command for tagging images; there is no rename subcommand for images. Option B is wrong because podman commit creates a new image from a container's changes, not a tag on an existing image. Option C is wrong because podman push does not have a --target flag for retagging; it pushes an already-tagged image to a registry.

Practice this question →

27

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.

Practice this question →

28

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.

Practice this question →

29

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.

Practice this question →

30

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.

Practice this question →

31

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.

Practice this question →

32

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.

Practice this question →

33

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.

Practice this question →

34

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.

Practice this question →

35

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.

Practice this question →

36

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

Practice this question →

37

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.

Practice this question →

38

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.

Practice this question →

39

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.

Practice this question →

40

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.

Practice this question →

41

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.

Practice this question →

42

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.

Practice this question →

43

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.

Practice this question →

44

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.

Practice this question →

45

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.

Practice this question →

46

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.

Practice this question →

47

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

Practice this question →

Ready to test yourself?

Try a timed practice session using only Registry And Security questions.

Start 20-question session