EX188 Registry And Security — 20 Questions

Question 1

An administrator needs to configure a custom search domain for short-name image pulls across all users on a RHEL 9 system. Which configuration file must be edited?

Accepted Answer

/etc/containers/registries.conf. On RHEL 9, the file `/etc/containers/registries.conf` controls registry configuration, including `unqualified-search-registries` (the search domains used for short-name pulls) and per-registry mirrors. To add a custom search domain for short-name image resolution across all users, you edit this file — typically under the `[registries.search]` section or the newer `unqualified-search-registries` array.

Answer

/etc/containers/storage.conf

Answer

/etc/containers/policy.json

Answer

/etc/containers/registries.d/

Question 2

When configuring a secure private registry that uses a self-signed TLS certificate, a user receives an x509 certificate signed by an unknown authority error when pulling images. Where should the CA certificate file be placed on a RHEL system for system-wide trust?

Accepted Answer

/etc/containers/certs.d/registry.example.com/ca.crt. For a private registry with a self-signed certificate, Podman looks for the CA under /etc/containers/certs.d/<registry-hostname>/ca.crt. Placing the CA there allows Podman to trust the registry's certificate for that specific host without modifying the system-wide trust store. This is the documented per-registry trust location for containers tooling.

Answer

/etc/pki/ca-trust/source/anchors/registry.crt

Answer

/usr/share/pki/trust/anchors/ca.crt

Answer

~/.config/containers/certs.d/ca.crt

Question 3

A user wants to remove all unused container images that are not currently associated with an existing container from local storage. Which command should they execute?

Accepted Answer

podman image prune -a. The command podman image prune -a removes all unused images — specifically, images not referenced by any existing container. The -a (or --all) flag extends pruning beyond dangling images to include all images without an associated container, which matches the user's requirement exactly.

Answer

podman container prune

Answer

podman rmi --all

Answer

podman system clean

Question 4

A developer needs to pull an image from a private registry that requires credentials without running an interactive shell session. Where are the authentication credentials stored after a successful 'podman login' command?

Accepted Answer

~/.config/containers/auth.json. After a successful 'podman login', credentials are stored in ~/.config/containers/auth.json (or $XDG_RUNTIME_DIR/containers/auth.json when using --authfile with a runtime path). This file uses the same format as Docker's config.json and contains base64-encoded username:password pairs keyed by registry hostname. Podman reads this file automatically on subsequent pull/push operations, enabling non-interactive authentication.

Answer

/etc/passwd

Answer

~/.ssh/authorized_keys

Answer

/etc/containers/login.conf

Question 5

An organization enforces that all container images must be signed using a local GPG key before they can be deployed in production. Which command generates a signature for an image stored in local storage using a specific signing key?

Accepted Answer

podman image sign --sign-by <key_id> registry.example.com/app:latest. The podman image sign command generates a GPG signature for an image in local storage, using --sign-by to specify the key ID. This is the correct command for signing images before pushing them to a registry, and it operates on the local image reference. The signature is stored locally and can be uploaded alongside the image.

Answer

podman push --sign-by <key_id> app:latest

Answer

podman gpg --sign app:latest

Answer

podman sign --key <key_id> app:latest

Question 6

An administrator wants to prevent users from pulling images from any registry except 'registry.access.redhat.com'. Where should this restriction be configured?

Accepted Answer

/etc/containers/registries.conf under 'unqualified-search-registries' and blocked registries lists. The correct file is /etc/containers/registries.conf, which controls registry access for container tools like Podman and Buildah. The 'unqualified-search-registries' list defines which registries are searched for unqualified image names, and the 'blocked' registries list (or 'block' in newer versions) explicitly denies pulls from specified registries. By setting 'unqualified-search-registries = ["registry.access.redhat.com"]' and adding all other registries to the blocked list, the administrator restricts pulls to only that registry. This is the standard mechanism for registry filtering in rootless and rootful container environments on RHEL and similar systems.

Answer

/etc/containers/policy.json under 'default' block rules

Answer

/etc/containers/storage.conf under 'block-pull'

Answer

~/.config/containers/access.conf

Question 7

An administrator needs to configure a local container registry mirror that redirects all requests for 'registry.redhat.io' to an internal caching proxy 'mirror.corp.local'. Which section of /etc/containers/registries.conf must be modified?

Accepted Answer

[[registry]] with prefix and location/mirrors parameters. The `[[registry]]` block in `/etc/containers/registries.conf` is the correct section for defining a registry mirror. You specify `prefix = "registry.redhat.io"` and either `location = "mirror.corp.local"` or a `[[registry.mirror]]` sub-block with `location = "mirror.corp.local"` to redirect all pulls for that registry to the internal proxy.

Answer

[registries.search]
mirrors = [...]

Answer

[mirror "registry.redhat.io"]

Answer

[cache.registry]
proxy = [...]

Question 8

A security officer wants to disable all signature checking for a specific insecure test registry in /etc/containers/policy.json. What transport matching rule should be configured under 'transports'?

Accepted Answer

Set the transport rule for that registry prefix to 'accept'. Policy matching is configured under the 'transports' key in policy.json, often using 'reject', 'accept', or 'signedBy'.

Answer

Set the rule to 'bypass-security'

Answer

Remove the registry entry entirely from policy.json

Answer

Set the rule to 'ignore-signatures'

Question 9

An administrator needs to set up a local directory to act as an OCI-compliant layout image store, and then push an image into it using Podman. Which transport prefix is used for local OCI layout directories?

Accepted Answer

oci:directory_path:tag. The oci: transport prefix tells Podman to use a local directory as an OCI-compliant image layout store. The syntax is oci:directory_path:tag, where the directory contains the OCI layout (index.json, blobs, etc.). This allows pushing and pulling images to/from a local directory without a registry.

Answer

tar:directory_path:tag

Answer

dir:directory_path:tag

Answer

local:directory_path:tag

Question 10

Which TWO commands display information about container images present in local Podman storage? (Choose two.)

Accepted Answer

podman image inspect. Option E, `podman images`, is correct because it lists all container images stored in local Podman storage, showing repository, tag, image ID, creation time, and size. Option D, `podman image inspect`, is correct because it retrieves detailed low-level metadata (JSON) about one or more local images, such as configuration, layers, and labels, which is information about images present in local storage. Option A, `podman container list`, is incorrect because it lists containers, not images, even though containers may be based on images. Option B, `podman ps`, is incorrect because it shows running (or with -a, all) containers rather than images. Option C, `podman volume ls`, is incorrect because it lists Podman volumes, which are persistent storage resources unrelated to image inventory.

Answer

podman container list

Answer

podman ps

Answer

podman volume ls

Question 11

Which TWO settings or files are critical when configuring rootless Podman environments on RHEL 9? (Choose two.)

Accepted Answer

/etc/subuid and /etc/subgid for user namespace allocations.. Option C is correct because rootless Podman relies on user namespaces, and the /etc/subuid and /etc/subgid files define the ranges of subordinate UIDs and GIDs that an unprivileged user can map inside containers; without these entries, rootless containers cannot start. Option E is correct because in rootless mode Podman reads user-specific configuration from ~/.config/containers/registries.conf, which lets a non-root user define registry mirrors, unqualified-search registries, and insecure registries without needing root access to /etc/containers/registries.conf. Option A is not required for rootless Podman configuration, since SELinux mode is a system-wide setting managed separately and rootless Podman works with SELinux enforcing by default. Option B is irrelevant because rootless Podman is specifically designed to run without root privileges, so /etc/sudoers is not part of its configuration. Option D is also irrelevant, as /etc/shadow stores root password hashes and has no role in allocating user namespaces or configuring rootless container registries.

Answer

/etc/selinux/config for enforcing SELinux mode.

Answer

/etc/sudoers for root privileges.

Answer

/etc/shadow for root password hashes.

Question 12

Which TWO parameters or directives can be configured inside '/etc/containers/registries.conf' to control how Podman interacts with container registries? (Choose two.)

Accepted Answer

[[registry]] for defining prefix matching, mirrors, and insecure registries.. Option D is correct because /etc/containers/registries.conf supports [[registry]] TOML tables that let you define a registry's location, prefix matching, mirrors, and set insecure = true for registries that lack valid TLS certificates. Option E is correct because unqualified-search-registries is a top-level directive listing the registries Podman searches (in order) when an image name has no registry qualifier, e.g. unqualified-search-registries = ["docker.io", "quay.io"]. Option A is wrong because default_transport is a containers-transports.conf setting (e.g. docker://) that specifies the transport used for unqualified image names, not a registries.conf directive. Option B is wrong because storage_driver is configured in /etc/containers/storage.conf (e.g. overlay) and controls the container storage backend, not registry interaction. Option C is wrong because signature_policy_file is set in /etc/containers/policy.json or via the --signature-policy flag, not as a registries.conf parameter.

Answer

default_transport

Answer

storage_driver

Answer

signature_policy_file

Question 13

Which TWO scenarios correctly describe when an administrator should use the ':z' SELinux mount option instead of ':Z'? (Choose two.)

Accepted Answer

When content generated on the host needs to be safely read and written by multiple container instances using a shared label.. Option B is correct because ':z' applies the same shared SELinux label (for example, container_file_t with an MCS category shared across the containers) to the volume contents, allowing host-generated content to be read and written by multiple container instances without relabeling conflicts. Option C is correct because ':z' is specifically designed for shared volumes where multiple containers need concurrent read-write access, since it assigns a common label rather than a private per-container label. In contrast, ':Z' assigns a private, unshared label tied to a single container, which would break multi-container sharing. Option A is wrong because neither ':z' nor ':Z' disables SELinux checks; disabling enforcement would require setting SELinux to permissive or disabled, not a mount option. Option D is wrong because ':z' explicitly shares the label, so it does not provide absolute isolation; ':Z' is the more restrictive private-label option. Option E is wrong because read-only mounting is controlled by the ':ro' mount flag, not by ':z' or ':Z'.

Answer

When disabling SELinux checks entirely for the volume.

Answer

When absolute isolation is required so that no other container can ever read the volume.

Answer

When mounting a host directory as strictly read-only.

Question 14

Which THREE configuration directives or files are associated with customizing container storage backends and root directory locations in Podman? (Choose three.)

Accepted Answer

The environment variables 'CONTAINERS_STORAGE_DRIVER' or 'STORAGE_DRIVER'.. Storage options are configured in /etc/containers/storage.conf, via environment variables like STORAGE_DRIVER, or via user home directory overrides.

Answer

The signature verification policy file '/etc/containers/policy.json'.

Answer

The registry authentication file '~/.config/containers/auth.json'.

Question 15

A container administrator needs to download an image named rhel9/httpd-24 from the Red Hat Ecosystem Catalog using Podman, but requires local authorization without interactive password prompts. Which file should the administrator configure to store these registry credentials in base64-encoded format?

Accepted Answer

~/.config/containers/auth.json. Podman uses the containers/auth.json file to store registry credentials in base64-encoded format. The default location for a rootless user is ~/.config/containers/auth.json, while for root it is /run/containers/0/auth.json or /etc/containers/auth.json depending on configuration. The file follows the Docker config.json format and allows non-interactive authentication to registries like the Red Hat Ecosystem Catalog.

Answer

~/.local/share/containers/storage/mounts

Answer

/etc/containers/registries.conf

Answer

/etc/sysconfig/podman

Question 16

An administrator is configuring Podman on a RHEL 9 host to pull images from an internal, insecure container registry at registry.example.com:5000 using HTTP instead of TLS. Where should this registry address be added to allow unencrypted communication?

Accepted Answer

~/.config/containers/policy.json. The /etc/containers/registries.conf file contains the [registries.insecure] table (or unqualified-search-registries and registries.block configurations) where insecure registries lacking TLS certificates can be explicitly declared.

Answer

/etc/hosts

Answer

/etc/containers/registries.d/default.yaml

Question 17

A rootless user runs a container that needs to write data to a host directory using podman run -v /home/user/data:/data:Z. When the container starts, permission denied errors occur when writing to /data. What is the cause of this SELinux issue in rootless mode?

Accepted Answer

Rootless containers cannot use the :Z or :z SELinux volume options because rootless Podman runs inside a user namespace where process MCS labeling is restricted.. In rootless Podman, the container process runs inside a user namespace, and the MCS (Multi-Category Security) categories used by SELinux to label container processes are drawn from the user's own MCS range, which is typically limited to a single category pair (e.g., c0,c1). The :Z option requires relabeling the host directory with a category that matches the container's process label, but rootless users cannot assign arbitrary MCS categories to files they don't own at the system level, and the relabel operation is restricted. As a result, the volume mount cannot be properly relabeled and the container process is denied write access.

Answer

Rootless containers automatically disable SELinux enforcement for all mounted volumes, bypassing container isolation.

Answer

The SELinux policy enforcement level must be set to permissive globally across the entire RHEL host.

Answer

The host directory must be owned by the root user before mounting into a rootless container.

Question 18

An administrator is troubleshooting an issue where a rootless container cannot access a host file because of SELinux denials. Which THREE statements accurately describe how SELinux interacts with rootless Podman containers on RHEL 9? (Choose three.)

Accepted Answer

Rootless containers run under the user's unprivileged process context and are still constrained by SELinux policy rules.. Option A is correct because rootless Podman containers still execute as the invoking unprivileged user (e.g., user_u:user_r:user_t or unconfined_u:unconfined_r:unconfined_t) and remain subject to the loaded SELinux policy, so denials such as AVC messages can occur even without root. Option D is correct because SELinux MCS uses category sets (e.g., c1,c2) assigned to each container's processes and files, and these categories keep containers from different users (or different containers) from accessing each other's resources, effectively preventing escape into other users' namespaces. Option E is correct because a rootless user lacks the CAP_MAC_ADMIN capability and the SELinux policy does not permit unprivileged domains to relabel arbitrary host files, so commands like chcon or setfiles on host paths fail unless the user is granted elevated privileges or the file is relabeled by an administrator. Option B is incorrect because SELinux enforcement is never automatically disabled for rootless containers; the policy remains active regardless of rootless mode. Option C is incorrect because rootless Podman works fine with SELinux enforcing, and booting with selinux=0 is not a requirement — it would actually remove the protection rather than enable the container to run.

Answer

Rootless containers completely disable SELinux enforcement automatically upon startup.

Answer

Rootless containers require the container host to be booted with selinux=0 kernel parameter to function.

Question 19

A container image stored in an OCI registry is signed with a GPG key. A rootless Podman user on a RHEL 9 system needs to validate that signature automatically during `podman pull`. Which file should the user edit to define the trust policy that Podman applies to the registry?

Accepted Answer

/etc/containers/policy.json. Podman evaluates image signatures during pull using the trust policy defined in /etc/containers/policy.json. That file maps registries and repositories to requirements such as signedBy with specific GPG keys. Configuring it correctly causes Podman to reject unsigned or improperly signed images, satisfying the need to validate the GPG signature automatically during pull.

Answer

/etc/containers/registries.d/default.yaml

Answer

/etc/containers/registries.conf.d/99-signature.conf

Answer

~/.config/containers/registries.conf

Question 20

An administrator wants to prevent all users on a RHEL 9 system from pulling images from any registry except registry.access.redhat.com. Which configuration change achieves this?

Accepted Answer

Set `blocked_registries = ["*", "!registry.access.redhat.com"]` in /etc/containers/registries.conf.. The blocked_registries option in registries.conf can enforce an allowlist by blocking all registries with a wildcard and then negating the allowed one. This ensures that only registry.access.redhat.com is permitted, while any other registry is denied for image pulls across the system.

Answer

Set `unqualified-search-registries = ["registry.access.redhat.com"]` in /etc/containers/registries.conf.

Answer

Add `registry.access.redhat.com` to the `blocked_registries` list in /etc/containers/registries.conf.

Answer

Remove all other registry entries from /etc/containers/registries.conf.