EX188 Registry And Security Practice Test 1 — 15 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