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

A bind mount maps an existing absolute host path, such as /home/user/data, straight into the container's filesystem namespace, rather than creating an isolated volume. This satisfies the stem's requirement of linking a specific host path directly into the container filesystem.

`--network host` places the container directly in the host's network namespace, so it binds host interfaces and privileged ports without NAT or `-p` forwarding. This satisfies the stem's requirement to share the host namespace and listen on privileged ports directly, unlike bridge or slirp4netns modes.

The top-level networks: block declares custom isolated networks and their drivers, letting services join named networks for inter-container communication. Without it, Compose attaches containers to a single default network, so this block is what defines the isolation the scenario requires.

SOURCE_DATE_EPOCH sets a fixed Unix timestamp that Podman's build tooling applies to file metadata, replacing build-time clocks. This yields byte-identical layers across rebuilds, satisfying the reproducibility constraint and enabling deterministic image digests for supply chain verification.

Rootless Podman reads /etc/subuid and /etc/subgid to allocate the subordinate UID and GID ranges that newuidmap and newgidmap apply, mapping container UID 0 onto the unprivileged host user. These files are the RHEL mechanism the stem requires.

Each FROM instruction begins a fresh build stage with its own base image and filesystem layer, so a single Containerfile can chain several stages. This satisfies the multi-stage requirement that stages remain isolated until explicitly copied between.

podman exec runs a new process inside an already-running container, which is exactly the requirement here. Because web_front is running and the nginx binary exists in the container's filesystem, this command starts nginx -T within the existing container namespaces and returns its output to the host terminal. No container restart or image rebuild is needed.

Name resolution by service name is provided by aardvark-dns on user-defined networks. The default bridge network does not provide automatic service-name DNS for containers, so containers placed there can communicate by IP but cannot resolve each other's names. Ensuring the services are attached to the Compose-created network restores name resolution.

The --tail 50 flag limits output to the final fifty lines, while --follow keeps the stream open and prints new entries as the container writes them. Together they satisfy both constraints: viewing recent logs and continuing to monitor the running container named log_test.

ARG declares build-time variables that are available only during the image build, not at container runtime. This satisfies the stem's requirement to define variables within a Containerfile, since ARG instructions set values consumed by subsequent build steps such as RUN, without persisting into the running container's environment.

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

FROM specifies the base image that subsequent Containerfile instructions build upon, and it must be the first non-comment instruction in a valid Containerfile. This satisfies the stem's requirement, because podman build cannot construct a layered image without an initial parent image reference.

Netavark's embedded DNS server resolves container names to IP addresses for containers attached to the same user-defined bridge network, so no manual linking or /etc/hosts editing is needed. The default bridge lacks this name resolution, making the custom network the enabling factor.

podman update modifies resource constraints on a live container without restarting it, and --cpu-shares sets relative CPU weighting. This satisfies the requirement to change cpu-shares on the running compute_job container on the fly, preserving its state.

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.

Podman's user-defined bridge networks run an embedded DNS server, so containers on the same network resolve each other by container name automatically. No manual /etc/hosts entries or links are needed, satisfying the native hostname resolution requirement.

ENV sets a persistent environment variable that remains in the image metadata, so it is available both during subsequent build steps and at container runtime. This directly satisfies the stem's requirement for a variable present across build and run, unlike ARG, which exists only at build time.

The long form of 'depends_on' supports a 'condition' key, and 'service_healthy' waits until the dependency's healthcheck reports healthy before starting the dependent service. Pairing it with a healthcheck on the database service gives the application a real readiness gate rather than starting as soon as the database container is created.

For a non-root user, Podman stores named volumes under the user's home directory because rootless containers cannot write to `/var/lib/containers`. The default rootless storage path is `~/.local/share/containers/storage`, with named volumes placed in its `volumes/` subdirectory, satisfying the non-root constraint in the stem.

`--health-cmd` overrides the image's built-in HEALTHCHECK instruction at runtime, satisfying the requirement to temporarily replace the build-time command. Podman applies this new command when starting the container, so no rebuild is needed. Other flags such as `--health-interval` or `--health-retries` tune timing only, not the command itself.

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.

A container image's layers are read-only, so any writes at runtime go to a thin writable layer created on top of the image. This copy-on-write scratchpad is unique to each container instance and persists only for that container's lifetime.

podman cp works on both running and stopped containers, copying files into or out of the container's filesystem. Since legacy_api is stopped, this command directly places the updated configuration at the target path in the container's writable layer, and the file will be present the next time the container starts.

COPY transfers files from the build context on the host into the image filesystem during a build. ADD also copies but additionally handles remote URLs and archive extraction, so COPY is the precise instruction for plain local file transfer into the container.

podman logs retrieves the captured standard output and standard error stream of the named container, which is exactly the log stream required. The container name auth_api is passed directly, so no exec into the container or host journal query is needed.

`podman kill dbapp` sends SIGKILL by default, terminating the container's processes immediately without the graceful stop timeout that `podman stop` honours. This satisfies the stem's requirement to forcefully terminate the unresponsive container at once, rather than waiting for a clean shutdown sequence.

The podman volume create command creates a named volume, and podman volume inspect displays detailed information about it, including the mount point on the host. This is the correct sequence to both create the volume and find its location. The inspect output includes fields such as Mountpoint, which shows where the data is stored on the host filesystem.

The --no-cache flag tells podman to bypass the layer cache entirely and execute every instruction in the Containerfile from scratch, producing fresh layers even for unchanged instructions. It does not delete the local image or the stored cache; it simply instructs this build to avoid reusing cached layers, so the newly fetched repository metadata is honored during the RUN that installs packages.

The `--format` flag applies a Go template directly to the inspect JSON, and `.NetworkSettings.IPAddress` is the exact field path holding the container's IPv4 address. This satisfies the stem's requirement to retrieve only the IP address, rather than dumping the full JSON document for web_svc.

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.

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.

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.

`podman stats` streams live CPU, memory, block I/O and network I/O counters for all running containers, refreshing continuously until interrupted. It satisfies the real-time monitoring constraint directly, unlike `podman ps` (static snapshot) or `podman inspect` (point-in-time JSON). No cgroups files need manual reading.

The depends_on key declares which services must start before a given service, so Podman Compose orders container startup accordingly. It satisfies the stem's requirement for managing service dependencies directly within the YAML service definition, rather than relying on external orchestration or manual sequencing.

podman volume inspect returns the volume's full low-level configuration, including mountpoint, driver, labels and options, in JSON form. This directly satisfies the stem's requirement for displaying detailed configuration, a capability unique to the inspect subcommand within the volume suite.

`podman volume inspect app_vol` returns the volume's full configuration as a JSON array, exposing Mountpoint, Driver, Options, Labels and Scope. This directly satisfies the stem's requirement for low-level mount point and driver detail in JSON, unlike `podman volume ls`, which lists names only.

The --env-file flag reads the named local file and injects each KEY=VALUE pair as environment variables inside the container, so app.env's multiple configuration variables become available to the application at runtime without manual --env entries.

Placing base dependencies before source code maximizes cache reuse.

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.

A user-defined network provides automatic DNS resolution between containers on that network, so 'web' can resolve 'db'. By not publishing ports for the db service, it remains accessible only to containers on the same network, satisfying the isolation requirement. This is the standard Podman Compose pattern for secure inter-service communication.

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.

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.

The COPY instruction supports the --from flag, which references a previous build stage by its name or index. Here, `builder` is the named stage, so COPY --from=builder pulls the compiled artifact from that stage's filesystem into the final image. This keeps the final image minimal because only the binary is transferred, not the entire build toolchain.

`podman system df` reports disk usage across Podman's storage, listing images, containers and volumes with total, active and reclaimable space. It directly satisfies the stem's requirement to display disk space statistics covering volumes and containers.

The `destination` key-value pair sets the container-side mount path, satisfying the requirement that `--mount` accepts explicit target parameters. Unlike `--volume`, which uses positional arguments, `--mount` requires named keys such as `destination` (or its alias `target`) to define where the volume appears inside the container.

The podman inspect command outputs detailed JSON-formatted information about a container, including its configuration, network settings, mounts, environment variables, and more. It is the standard tool for retrieving low-level container metadata and is ideal for automation because the output is structured and parseable. This command directly fulfills the requirement to inspect the container's configuration in JSON format.

The -d flag detaches the container, --name assigns web01, and -p 8080:80 maps host port 8080 to container port 80. The image reference follows, giving the correct Podman invocation for background execution with the required port mapping.

In exec form the executable becomes PID 1 directly, so signals such as SIGTERM sent by Podman reach the application itself. This enables correct signal handling and graceful termination, unlike shell form where a shell intercepts them.

The inspect subcommand reads the stored network configuration and prints JSON detailing subnet, gateway and driver settings for my-net. Unlike listing commands, which show only names, inspect exposes the full definition, satisfying the requirement to view subnet and gateway details.

The COPY --from=builder instruction pulls artefacts from the named earlier build stage rather than the build context, copying the compiled binary at /app into the final runtime image. This satisfies the multi-stage requirement to exclude build tooling from production.

The podman port command queries a running container's network namespace and prints its published and exposed port mappings, directly satisfying the requirement to inspect container port mappings without entering the container or inspecting the host firewall.

podman port lists the port mappings for a named container, showing each exposed container port and its host binding in a concise summary. It satisfies the requirement to view all ports exposed or mapped by web_prod without inspecting full container configuration.

The logs subcommand aggregates stdout and stderr from every container defined in the Compose file, streaming them with service-name prefixes. Running it against the compose file satisfies the requirement to inspect all managed services at once, whereas podman logs only targets a single named container.

This approach separates dependency installation from application code copying. Podman caches each instruction layer. Since dependencies change infrequently, their layer remains cached when only code changes, avoiding reinstallation. The COPY of code invalidates subsequent layers, but dependencies are already cached. This optimizes rebuild time and is a best practice for leveraging build caching effectively.

The podman secret rm subcommand deletes the named secret from Podman's secret store, removing it so containers can no longer reference it. The syntax matches the resource type followed by the verb and the secret's name.

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.

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.

Podman's published ports become containerPort entries inside the containers spec array, since Kubernetes Services, not the Pod manifest, handle host-level exposure. This satisfies the stem's requirement that published ports map into the generated manifest as container port definitions.

`podman pause db_master` sends SIGSTOP to every process in the container's cgroup, freezing execution while leaving the container running and its state intact. This satisfies the requirement to suspend all processes without stopping the container, unlike `podman stop`, which terminates it.

The `--subnet` and `--gateway` flags on `podman network create` define the CNI bridge network's address range and default router directly, satisfying the stem's requirement for a specific subnet and gateway. Both parameters are applied at creation time, so the resulting `customnet` network uses 192.168.200.0/24 with 192.168.200.1 as its gateway.

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.

Podman stores each network's IP under NetworkSettings.Networks, so the Go template must range over that map to reach IPAddress; a bare .NetworkSettings.IPAddress returns nothing. The --format flag applies this template to the inspect JSON, printing only the address.

Omitting a host IP in the -p flag causes Podman to bind the published port on all host interfaces, including the host's 192.168.1.x address. Other machines on the subnet can therefore reach the service at the host IP on port 8080. This is the correct and simplest syntax for the scenario, and it works in rootless mode because the port is above 1024.

COPY transfers files from the build context or a stage into the image filesystem, satisfying the requirement to bring external data in. ADD performs the same transfer with extra archive and URL handling. Both are distinct from RUN, which executes commands inside the build.

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.

podman system df reports disk usage for images, containers, and volumes managed by Podman, mirroring docker system df. It directly answers the administrator's need to check space consumption across all three resource types in one command.

ENTRYPOINT fixes the executable, while CMD supplies default arguments that a user can replace by appending values to `podman run`. This satisfies the stem's requirement for overridable defaults, since arguments passed on the command line replace CMD entirely but leave ENTRYPOINT intact.

Running podman network inspect or the equivalent container network inspection command lists the container's network interface details, including the host-side veth pair name. That name is then used with tcpdump on the host to capture the container's traffic.

`podman secret ls` queries the local Podman secret store and returns every created secret, satisfying the requirement to list all secrets on the system. Unlike `podman secret inspect`, which requires a named secret, `ls` enumerates them without arguments, matching the administrator's need for a complete inventory.

WORKDIR sets the working directory used by subsequent RUN, CMD, ENTRYPOINT, COPY and ADD instructions in the Containerfile, persisting across later layers. This directly satisfies the stem's requirement for the instruction that establishes that directory context.

Podman refuses to remove a network while containers remain attached, returning an error rather than silently detaching them. You must stop and disconnect every container from 'testnet' first, satisfying the stem's active-container constraint. This prevents orphaned containers losing network connectivity mid-operation.

The -e flag passes a single environment variable into the container at runtime, setting DB_HOST to localhost for the myapp process. This satisfies the requirement to inject one variable directly on the command line rather than through an env file.

`podman secret rm` deletes a stored secret from Podman's secret store, satisfying the requirement to identify valid secret-management subcommands. It mirrors the removal operation available for other Podman objects, letting you clean up secrets no longer needed by containers. This is a genuine subcommand, unlike fabricated flags.

Aardvark-dns is the authoritative DNS server paired with netavark, resolving container names to IP addresses on Podman-defined networks. It supplies the name resolution layer the networking stack needs, satisfying the stem's requirement for a backend utility Podman relies upon on modern Linux distributions.

Podman unpause resumes the cgroup freezer state previously set on the container, allowing its processes to continue from exactly where they halted. It is the second of the two commands required, completing the pause-then-resume workflow the administrator needs to restore the running container.