Manage containers practice questions

Open port 8080 in the host firewall using firewall-cmd.

Why it fails: Running firewall-cmd --add-port=8080/tcp only adds an allow rule to the host's firewalld zone, permitting inbound connections to the host's own port 8080. It does not create any mapping between that host port and the container's network namespace; the container still listens on an isolated bridge IP (e.g., 172.17.0.2) that the host firewall cannot redirect to. Since no docker port publishing exists, traffic allowed by the firewall has no destination inside the container, so the developer's reported connectivity issue remains completely unresolved.

Disable the host firewall to allow all incoming traffic.

Why it fails: Disabling the host firewall (e.g., systemctl stop firewalld) removes all packet filtering at the host level, but the container's port remains unpublished; no DNAT rule or proxy maps host port 8080 to the container's bridge IP. Even with the firewall off, inbound packets on host port 8080 have no forwarding chain to the container's internal network address, so the custom web app stays unreachable. Furthermore, this disables protection for the entire host, leaving every open service exposed to the network — a catastrophic security choice that a Red Hat administrator should never make for any environment.

Ensure the container image includes an EXPOSE instruction for port 8080.

Why it fails: The EXPOSE instruction in a Dockerfile is purely declarative metadata; it records which ports the application intends to listen on and is used by docker run -P to publish all exposed ports to random host ports. By itself, EXPOSE does not create any port binding, iptables rule, or userland proxy, so a container started without -p or -P will not accept traffic from the host on port 8080. Adding EXPOSE to the image would only help if the container were later started with -P, which still wouldn't yield a predictable host port — and rebuilding the image changes nothing about the current runtime network configuration.

podman rmi registry.access.redhat.com/ubi8/nginx-118

Why it fails: podman rmi attempts to delete the container image, but container name ownership is tied to the container itself, not to the image from which it was created. Even if the image is forcibly removed with --force, the existing container web3 remains intact and continues to reserve the name 'web3' in Podman's container storage. Consequently, the new container cannot use that name, so rmi is ineffective for resolving the conflict.

podman kill web2

Why it fails: podman kill web2 sends SIGKILL to the primary process of container web2, stopping it immediately without a graceful shutdown. However, kill does not delete the container; web2 remains in the exited state and its name stays allocated. Moreover, the name conflict is about 'web3', so stopping web2 has no bearing on the inability to start the new container.

podman stop web1

Why it fails: podman stop web1 gracefully terminates the main process in container web1 by first sending SIGTERM, then SIGKILL after a timeout. This merely transitions the container from running to stopped; it does not remove the container metadata or release its name. Since the name 'web3' is held by a different container, stopping web1 does nothing to resolve the conflict.

Create a systemd service file using 'podman generate systemd' on a running container, then enable the service with 'systemctl enable --now container-myapp'. The container should be started with '--restart=always' and appropriate volume and port mappings.

Why it fails: This integrates with systemd for boot-start and restart, and allows non-root user via '--user' in the container.

Create a 'podman service' unit using 'podman service create' to manage the container with automatic restart and boot-start.

Why it fails: 'podman service create' is not a valid command; Podman does not have a built-in service manager.

Use 'podman create --restart=on-failure -v /var/log/app:/var/log -p 443:443 myapp' and then start it with 'podman start'.

Why it fails: This does not ensure the container starts on boot.

The SELinux context of files in /host/data remains unchanged.

Why it fails: The statement is false because the `:Z` volume flag instructs Podman to relabel the host directory to the container's SELinux file type (typically `container_file_t`) with a unique MCS category. As a result, the original SELinux context is not retained unchanged; the label is modified to permit access by the containerized process. If no `:Z`/`:z` flag is used, the context would remain unchanged, but that is not the scenario in this question.

The /host/data directory is created automatically if it does not exist.

Why it fails: Bind mounts require the host directory to already exist; Podman does not run `mkdir -p` on the source path. If `/host/data` is absent, the container creation fails with an error rather than silently producing an empty directory. This contrasts with named volumes, which Podman creates automatically with the correct ownership and SELinux label, so a bind mount is only usable when the administrator has pre-provisioned the host path.

The container cannot write to /container/data if SELinux is enforcing.

Why it fails: The claim ignores the function of the `:Z` flag, which explicitly relabels the bind-mounted host files with a container-appropriate SELinux context, allowing the container process to write. With SELinux enforcing, a bind mount without `:Z` or `:z` would indeed cause a denial, but the flag in the command resolves that denial. Therefore the container can write to `/container/data` even under enforcing policy, making the option incorrect.

podman images -q

Why it fails: The `-q` (or `--quiet`) flag only alters the output format by printing numeric image IDs instead of the default table, but it does not change which images are selected. Without `--all`, Podman's default view includes only top-level, tagged or container-referenced images, so intermediate layers and dangling images remain hidden. Therefore, `podman images -q` alone cannot list all stored container images; it merely provides a compact ID-only listing of the same incomplete set.

podman images --no-trunc

Why it fails: The `--no-trunc` option affects only the display formatting, preventing Podman from shortening long image IDs and repository names in the output columns. It has no effect whatsoever on the set of images that are listed, so intermediate layers and dangling images remain hidden unless `--all` is also passed. An administrator seeking to list all images needs to expand the query with `--all`, not merely adjust truncation, so this command fails to meet the requirement.

--env

Why it fails: passes variables directly on the command line as KEY=value pairs. Because process arguments are visible to any user with access to the system via ps, this exposes sensitive values in the process table and shell history; it also doesn't read from a file, so it's unsuitable when the requirement is to load variables from a file.

--secret

Why it fails: a dedicated secret-management mechanism (e.g., Podman's --secret or Docker BuildKit's --secret) that mounts sensitive data into the container, usually as files under /run/secrets, rather than setting general environment variables. Unlike --env-file, it is not designed for reading arbitrary .env files and injects values through a separate secret API or a temporary filesystem, so it does not satisfy the requirement to pass environment variables from a file.

-e

Why it fails: abbreviated alias for --env, so it also takes KEY=value arguments directly in the shell command. Even though it is a common convenience for interactive runs, every local user can read the value from the process list, and the variable must be manually pasted or typed rather than loaded from a file — an unacceptable fit for a task that explicitly requires reading from a file.

The container registry is unreachable due to a firewall blocking port 443.

Why it fails: A firewall blocking port 443 would only affect the HTTPS connection to the registry IP after the hostname is resolved; the error `dial tcp: lookup ... timeout` shows a DNS query on UDP/TCP port 53 timed out before any TCP connection was attempted. The phrase `lookup ... on ...:53` explicitly identifies DNS as the failing layer, not TLS/SSL on 443. Therefore this cause does not match the exhibited error.

The image name is invalid.

Why it fails: An invalid image name normally produces registry API errors such as `repository not found` or `manifest unknown`, which require the registry hostname to be successfully resolved first. Here the error occurs during the `lookup` phase, meaning Docker never even reached the registry to validate the name. Since the hostname cannot be resolved, the failure is necessarily before name validation, so an invalid name cannot be the proximate cause.

The container registry is unreachable due to a network outage.

Why it fails: While a total network outage could prevent DNS and all traffic, the error is specifically diagnostic: `dial tcp: lookup <registry> on <server>:53: read udp ...: timeout` points to a DNS query timeout, not a general `connect: network is unreachable` or `connection timed out` to the registry. Also, the registry may still be reachable over the network if DNS is broken; the outage is isolated to DNS resolution. A generic network outage would produce a different Go error string, so this option is too broad and less precise.

SELinux is preventing the container from binding to the port; set enforce to permissive.

Why it fails: SELinux enforces policy via AVC denials and EACCES/EPERM errors, never EADDRINUSE. If the container's httpd process lacked permission to bind to the target port, the kernel would log something like 'avc: denied { name_bind }' and the application would receive 'Permission denied'—not 'address already in use'. Moreover, setting enforce to permissive is overly broad and would not release an occupied port; the underlying socket is held by a different process regardless of SELinux mode.

The container does not have network access; add --network host.

Why it fails: Adding --network host does not help because it gives the container the host's network namespace, so the container's server would attempt to bind directly to host port 80—exactly the port that is already occupied. The reported error is about binding a listening socket on the host, not about the container lacking outbound connectivity or a bridge network. In fact, running with --network host would make the conflict more direct, not resolve it.

The firewall is blocking outbound connections; disable firewalld.

Why it fails: firewalld inspects and filters network packets traversing interfaces; it does not control whether a local process can bind a listening socket on a port. An outbound connection would generate firewall/egress rules, whereas the web server needs to create an inbound listening socket, and a collision there produces EADDRINUSE. Disabling firewalld would not terminate or free the process currently occupying port 80, so the exact same bind error would appear.

Use 'podman network create' and connect both containers to that network.

Why it fails: Running `podman network create` and attaching both containers to that user-defined network would technically allow communication, but it is unnecessary and adds configuration overhead. Since the two containers are already in the same pod, they share the same network namespace and can communicate via localhost or container-name DNS without any extra network setup. Moreover, this approach would bypass the pod's automatic name resolution and instead rely on the separate network's DNS, which is redundant for pods.

Set environment variable LOGGER_HOST in nginx container.

Why it fails: Setting an environment variable like LOGGER_HOST in the nginx container is a manual, brittle approach that requires knowing the exact container name or IP address ahead of time. It also fails to leverage the pod's built-in DNS service, which dynamically resolves container names to their current IPs. If the container is recreated, the environment variable would become stale, whereas the pod-managed DNS entry updates automatically.

Create a network with --internal and --ip-range.

Why it fails: Creating a network with `--internal` and `--ip-range` is completely over-engineered and actually counterproductive for this scenario. An internal network prohibits external connectivity, and setting an ip-range restricts the IP allocation pool, both of which are irrelevant to pod-internal communication. Since containers inside the same pod already share a network namespace and can reach each other via container names, no additional network configuration—let alone a restricted one—is required.

podman ps -a

Why it fails: `podman ps -a` lists all containers on the system, both running and stopped, along with their container IDs, names, status, and ports. It does not provide any information about container images themselves, such as their layers, configuration, or metadata, so it is irrelevant to the task of inspecting image details.

podman images <image>

Why it fails: `podman images <image>` displays a table of local images that match the given name, showing only the repository, tag, image ID, and size. This is a high-level summary; it lacks the detailed JSON configuration, layer information, and metadata that the question asks for.

podman history <image>

Why it fails: `podman history <image>` outputs the layer history of the image, listing each layer's creation time, size, and command that generated it. While useful for understanding how an image was built, it does not expose the full container configuration, environment variables, entrypoint, or other detailed metadata that `podman inspect` provides.

Use a bind mount (e.g., --volume /host/data:/container/data)

Why it fails: A bind mount maps a host directory directly into the container, so the data's lifecycle is tied to the host filesystem rather than to Podman. You must manually create and manage the host path, handle host-specific permissions and SELinux labels, and back it up outside Podman's tooling. Because bind mounts are inherently host-dependent, they sacrifice portability and are more error-prone in production than managed volumes.

Use the --rm flag when running the container

Why it fails: Using --rm tells Podman to remove the container immediately after it exits, and with it the container's writable storage layer where unpersisted changes are written. Any data not stored in an external volume is deleted along with the container, making --rm the antithesis of a persistence strategy. It is useful for clean ephemeral tasks, but relying on it for persistent data directly conflicts with the requirement to keep information across runs.

Use a tmpfs mount (e.g., --tmpfs /container/data)

Why it fails: A tmpfs mount is an in-memory RAM-based filesystem mounted at /container/data, so writes are stored in kernel memory rather than on disk. The instant the container stops, the entire tmpfs mount is discarded, and there is no way to recover the data after the process exits. It is useful for temporary data like /tmp inside a container, but it fails completely as a persistence mechanism because nothing survives the container's lifetime.

Change the FROM line to use ubi9/ubi (Red Hat Universal Base Image 9)

Why it fails: The error stems from the base image reference being unpinned, not from the major version. Switching to ubi9/ubi would change the entire user-space baseline from RHEL 8 to RHEL 9, potentially introducing incompatibilities with application dependencies and system libraries. The correct fix is to specify an exact tag on the existing ubi8/ubi image, ensuring a reproducible build without altering the intended OS version.

Add an EXPOSE 80 instruction before the CMD

Why it fails: EXPOSE is a purely informational instruction that records the intended listening port in the image metadata; it neither installs nor configures anything during the build. Omitting it cannot cause a build failure because the build tool does not require a port declaration. Port publishing is done at container runtime with `podman run -p`, so adding EXPOSE would be irrelevant to the actual error.

Add a second COPY instruction to copy the container configuration files

Why it fails: The failure is not related to COPY; the instruction as written correctly places index.html into the image. Adding a second COPY would only be necessary if the build requires additional files, but it does not address the root cause and could itself fail if the specified source path is not present in the build context. The error output would clearly indicate a missing file or unauthenticated repository, not a missing COPY instruction.

Assign each container a unique hostname using the --hostname flag

Why it fails: Setting `--hostname` changes the container's own hostname but does not publish a DNS record or /etc/hosts entry for other containers.

Recreate both containers with --net=host to share the host's network stack

Why it fails: `--net=host` removes the containers from the pod's shared namespace and uses the host network stack, which is unnecessary and can cause port conflicts; it does not resolve container names.

Use 'podman pod inspect webpod' to verify both containers are part of the pod; if not, remove and recreate the containers using '--pod webpod' correctly

Why it fails: This is unlikely because the commands already include `--pod webpod`; more importantly, being in the same pod does not automatically make container names resolvable via DNS.

Configure podman auto-update to automatically start the container on boot

Why it fails: Podman auto-update is a mechanism that periodically checks for newer versions of container images and applies updates to running containers by redeploying them via the existing systemd unit; it has no role in launching or creating a container at boot. Auto-update requires the container to already exist and be managed by a systemd unit, so relying on it to start the container is conceptually wrong. A separate systemd unit with a proper ExecStart command (or one generated by 'podman generate systemd --new') is mandatory for boot-time startup.

Add --restart=always to the ExecStart line in the existing unit file

Why it fails: The unit file already contains Restart=always, so adding the container's own --restart=always flag to the ExecStart line is redundant and does not alter how systemd supervises the service. Furthermore, --restart=always is a podman container restart policy that only applies once the container has been created and started; it cannot resurrect a nonexistent container during boot. A service that executes 'podman start payments' will fail if the container does not yet exist in the container store, regardless of any restart policy attached to the command line.

Set RestartSec=0 in the [Service] section to eliminate any delay

Why it fails: RestartSec is the delay systemd waits before retrying a service after a failed restart attempt, but if the underlying 'podman start payments' command fails because the container is missing, setting RestartSec=0 simply causes immediate, repeated retries that still hit the same missing-container error. It only changes the timing of the failure loop, not the root cause. The correct solution is to ensure the unit first creates the container—as 'podman generate systemd --new' does—so that the start command has a valid container to launch.

SELinux is blocking the port.

Why it fails: SELinux enforcement of port binding does not manifest as a 'cannot listen on port 80' error; it results in a 'Permission denied' or AVC denial logged in the audit subsystem when the bind() syscall is blocked. A port conflict, by contrast, occurs at the network stack level and produces a distinct error indicating that the address is already in use. Therefore, while SELinux could influence which ports a container process may bind, the specific error described is diagnostic of resource contention, not policy denial.

The container image is corrupt.

Why it fails: A corrupt container image would cause errors during image pull, verification, or container creation, such as checksum mismatches, invalid layer digests, or failure to unpack the root filesystem. These problems prevent the container from starting its main process altogether, so the runtime would never reach the point of attempting to bind ports. The error 'cannot listen on port 80' indicates that the container's application has already started successfully and is trying to open a network socket, which means image corruption is not the underlying cause.

The container is out of memory.

Why it fails: An out-of-memory condition does not produce a port-binding error; it manifests as the container's main process being killed by the OOM killer, typically resulting in an exit signal 9 (SIGKILL) or an exit status of 137. The bind() system call for port 80 does not require a significant memory allocation and the error occurs before the application attempts to allocate heap or stack memory. Since the error specifically states the port cannot be listened on, it points to a network address conflict rather than insufficient memory for the container process.

podman pod stop apppod, podman pod rm apppod, podman pod create --name apppod ... , podman run --pod apppod ...

Why it fails: Removing the pod with `podman pod rm apppod` destroys the pod's infrastructure container and its network namespace, including the assigned IP address. Recreating the pod will produce a new pod with a new IP, violating the requirement. This approach also loses any pod-level configuration. It is the wrong method when the IP and shared namespace must be preserved.

podman pod stop apppod, podman rm web, podman run --pod apppod ... , podman pod start apppod

Why it fails: Stopping and restarting the pod does not preserve the pod's network namespace across a full stop/start cycle in the way required, and removing the container while the pod is stopped means the pod itself is inactive. More importantly, `podman rm web` removes only the container, but running a new container into a stopped pod is not supported; the pod must be running to join it. This sequence will fail and does not meet the requirement of keeping the pod's IP intact.

podman container update web --add-port 8080:80

Why it fails: There is no `podman container update` subcommand that adds port mappings to a running container. Port mappings are set at container creation time via `podman run -p` or at pod creation time via `podman pod create -p`. This command does not exist and would fail, so it cannot satisfy the requirement. The administrator must recreate the container to change port mappings.

podman run --label selinux_context=container_t -v /host/data:/data myimage

Why it fails: The `--label` flag is intended for attaching key-value metadata to the container, such as version or description, which is stored in the container's configuration and exposed via `podman inspect`. It does not interact with SELinux labeling at all; `selinux_context` is not a recognized label key for security purposes. SELinux contexts are controlled through the `--security-opt label=` options, not via metadata labels.

podman run --privileged -v /host/data:/data myimage

Why it fails: The `--privileged` flag disables SELinux separation entirely for the container, turning off the `container_t` type enforcement and other isolation mechanisms, which is a significant security risk. It also grants all capabilities and access to host devices, effectively bypassing the very SELinux controls you might want to enforce. For a task where the goal is to ensure the container runs with a specific SELinux context, this option is the opposite of a targeted security setting.

podman run --selinux-context container_t -v /host/data:/data myimage

Why it fails: `--selinux-context` is not a valid `podman run` command-line option, so the command would immediately fail with an unknown flag error. Even if the flag were accepted, specifying a bare type like `container_t` without the `label=` prefix structure would not be how SELinux policy is applied. The correct syntax requires the `--security-opt` option with `label=type:` as a prefix to the SELinux type.

The container must be run with the '--privileged' flag.

Why it fails: Running a container with --privileged grants all Linux capabilities and bypasses the security isolation layers, but a rootless container is started by an unprivileged user who cannot obtain those capabilities from the host kernel. The flag is incompatible with rootless operation because the user namespace mapping, not privilege escalation, is what allows the container to function as root inside the namespace. Thus --privileged cannot work around the missing /etc/subuid and /etc/subgid entries.

The system must have cgroups v2 enabled.

Why it fails: cgroups v2 offers a unified hierarchy and supports delegation of controller subtrees to unprivileged users, so rootless containers can use it to enforce memory and CPU limits when the system is configured appropriately. However, the absence of cgroups v2 does not prevent a rootless container from being created and run; it simply means that resource constraints cannot be applied, and many container engines will fall back to running without a cgroup context. Since the core requirement for rootless operation is a working user namespace mapping, cgroups v2 is an improvement, not a prerequisite.

The user must have root privileges to run the container.

Why it fails: Rootless containers are explicitly designed to allow an unprivileged user to run containers without requiring sudo or root access on the host. The user appears as root only inside the container through a user namespace mapping, but the host sees that user's ordinary UID, and any operations requiring host privileges are denied. Demanding root privileges to launch the container would eliminate the security and flexibility benefits that rootless mode exists to provide, so this statement is false.

podman run -v /var/lib/mysql:/var/lib/mysql mydb

Why it fails: This command uses -v with an absolute host path as the source, which tells Podman to create a bind mount directly to /var/lib/mysql on the host instead of a managed named volume. While the data may persist on the host, this approach bypasses Podman's volume management, often leading to permission mismatches (especially in rootless mode), unexpected host-directory creation, and no easy way to inspect or back up the mount with podman volume commands. It is therefore incorrect because a bind mount is not a named volume.

podman run --mount type=bind,src=dbdata,dst=/var/lib/mysql mydb

Why it fails: The --mount flag with type=bind explicitly instructs Podman to treat src as a host filesystem path, not a named volume. Here, 'dbdata' is interpreted as a relative path, so Podman will look for (or create) a directory named 'dbdata' in the current working directory on the host, completely ignoring the dbdata volume created by podman volume create. This means the container will not use the managed volume, and database files will be written to an unintended location, potentially causing data loss or confusion. To use a named volume with --mount, you must specify type=volume instead.

podman run --mount type=tmpfs,dst=/var/lib/mysql mydb

Why it fails: This command mounts a tmpfs filesystem at /var/lib/mysql, which is backed by RAM or swap and is inherently ephemeral. Any data written to this mount is lost the moment the container stops, is restarted, or the host is rebooted, providing zero durability for a database. Additionally, tmpfs is constrained by memory limits and is not intended for persistent storage or sharing data across container restarts. Therefore, this option fails the core requirement of persisting database data.

A container can only be created from an image that is stored locally.

Why it fails: While container engines typically use locally cached images, they are not restricted to them. When a container is run from a named image not present locally, the engine automatically pulls it from a configured registry such as Docker Hub. This pull-on-demand behavior means the image does not need to exist on disk beforehand. Additionally, tools like Podman can run images directly from a remote reference without a pre-existing local copy.

When a container is stopped, its writable layer is automatically removed.

Why it fails: Stopping a container only sends a signal to terminate its primary process and halts CPU scheduling; it does not alter the container's storage. The writable layer, which contains all file changes made during the container's lifetime, is preserved on disk so the container can be restarted with its state intact. That layer is removed only when the container is explicitly deleted using a command like `podman rm` or `docker rm`, not when it transitions to stopped. Thus the statement conflates stopping with removal.

A container image must be built using a Dockerfile.

Why it fails: A Dockerfile is one common way to define a new image, but it is not mandatory. Images frequently originate by pulling an existing pre-built image from a registry, which requires no Dockerfile at all. They can also be created interactively by committing a modified container with `docker commit`, or by importing a filesystem archive. Consequently, building with a Dockerfile is optional and not a requirement for every container image.