Manage containers practice questions

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

Why wrong: 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 wrong: 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 wrong: 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 run --label selinux_context=container_t -v /host/data:/data myimage

Why wrong: 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 wrong: 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 wrong: `--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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Add the user to the 'docker' group to access the Docker socket.

Why wrong: Podman is a separate container engine that does not depend on the Docker daemon or its Unix socket. Rootless Podman communicates directly with the kernel through user namespaces and a user-space network stack like slirp4netns, or via the podman.socket systemd unit for API access. Adding the user to the 'docker' group would grant access to a rootful socket, presenting a security risk while being completely unnecessary for Podman.

Grant the user sudo privileges to run podman commands.

Why wrong: Rootless Podman is intentionally designed to operate without sudo by leveraging user namespaces and the caller's unprivileged UID. Running `podman` with sudo would execute the container as root on the host, removing the security boundaries that rootless operation provides. Sudo is not required; instead, the necessary capabilities come from subgid/subuid mappings and systemd user session management. Granting sudo is both unnecessary and a potential privilege-escalation risk.

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

Why wrong: 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 wrong: 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 wrong: 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.

podman run -d -p 80:8080 nginx

Why wrong: This option reverses the required host:container port syntax. With -p 80:8080, the host port 80 is forwarded to container port 8080, which is not the port where nginx listens. Nginx's default listening port is 80 inside the container, so the forwarded traffic goes to a closed container port. The intention was to expose the service on host port 8080, but this mapping sends it to the wrong destination.

podman run -d --expose 80 nginx

Why wrong: The --expose 80 flag merely declares that the container's port 80 is intended for use; it does not publish that port to the host. Without -p or -P, no port is mapped, making the service unreachable from outside the container's own network namespace. The container may run fine, but a user on the host cannot access nginx via any published port. Therefore, it fails the requirement to expose the container on a specific host port.

podman run -d -P 8080:80 nginx

Why wrong: The -P flag (--publish-all) automatically publishes every exposed container port to a random high-numbered host port, and it takes no arguments. The subsequent '8080:80' is not a valid parameter for -P; it would be interpreted as a separate argument, likely causing an error. Even if the command were accepted, the resulting host port would be random, not guaranteed to be 8080. To force a fixed host port, you must use the lowercase -p with an explicit mapping.

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

Why wrong: 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 wrong: 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 wrong: 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.

Step 1: Edit /etc/exports to add the export entry. Step 2: Create the /nfsshare directory. Step 3: Start and enable the NFS server service. Step 4: Run exportfs -a.

Why wrong: Editing /etc/exports before the /nfsshare directory exists is risky because exportfs -a parses the exports file and expects each pathname to be a real directory; a missing directory can cause exportfs to fail with a "No such file or directory" error or register an invalid export. Additionally, placing exportfs -a after starting the NFS service means the daemon is already running with a stale or empty export table, so the newly edited share won't be available until you explicitly reload exports or restart the service. The correct order is to create the directory first, then edit the exports file, then run exportfs -a, and finally start/enable the service.

Step 1: Start and enable the NFS server service. Step 2: Create the /nfsshare directory. Step 3: Edit /etc/exports to add the export entry. Step 4: Run exportfs -a.

Why wrong: Starting and enabling the NFS server service before anything else is premature: the service will launch, but /etc/exports still has no entry for /nfsshare, so the daemon's export table is empty and no clients can mount the share. When the exports file is later edited, running exportfs -a at the end does apply the share, but the service has already been started unnecessarily early, and if it loaded a cached or empty export table, you may need to restart the service again to serve the new export. A proper configuration ensures the export is defined before the service starts, so the initial export table is correct from the moment the daemon comes up.

Step 1: Create the /nfsshare directory. Step 2: Run exportfs -a. Step 3: Edit /etc/exports to add the export entry. Step 4: Start and enable the NFS server service.

Why wrong: Running exportfs -a immediately after creating the directory is ineffective because exportfs only reads the current contents of /etc/exports, which does not yet list /nfsshare; it cannot infer which directories to export. After the exports file is finally edited, the sequence does not run exportfs -a again, so the new share is never registered with the kernel's NFS daemon before the service is started. The share must first be declared in /etc/exports, and exportfs -a must be rerun after that edit to apply the export; otherwise the NFS server has no record of the directory to serve.

/var/log/messages: Authentication and security-related messages

Why wrong: The claim that /var/log/messages holds authentication and security-related messages is incorrect because Red Hat's rsyslog configuration separates the authpriv facility and directs it to /var/log/secure. While a subset of kernel-level security events may appear in messages, login attempts, sudo commands, and PAM results are almost exclusively written to secure. Treating /var/log/messages as the auth log could lead to missing critical evidence during a security investigation.

/var/log/secure: Mail server logs

Why wrong: The claim that /var/log/secure contains mail server logs is a mix-up of Red Hat's log routing; mail events are handled by the mail facility and written to /var/log/maillog, not to secure. The /var/log/secure file is reserved for authentication and privilege authorization records, including SSH and sudo. Examining secure for mail queues or delivery errors would yield nothing relevant, whereas maillog contains the full mail transaction trail.

podman images -q

Why wrong: 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 wrong: 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.

podman logs <container>

Why wrong: podman logs <container> retrieves only the container's stdout/stderr history, which is generated by the application running inside the container. Although the application might print an error like 'address already in use', that message is not a definitive indicator of the host's port state. It also does not query the host kernel's socket table, so it cannot reveal which process is actually listening on the conflicting port.

podman port -l

Why wrong: podman port -l shows the port forwarding mappings defined for the most recently created container, such as 8080->80, but it does not inspect the host's current network state. It only reports what ports the container is configured to map, not whether any other process is already listening on the host side. Therefore it cannot reveal that the target port is occupied by an unrelated process.

firewall-cmd --list-ports

Why wrong: firewall-cmd --list-ports lists the TCP and UDP ports explicitly allowed through the firewalld zone, which is a packet filtering policy, not a list of active listeners. A port can be open in the firewall yet completely unused, or it can be in use even when blocked by the firewall. To find a port conflict, you need to inspect running sockets, not firewall rules.

--env

Why wrong: 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 wrong: 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 wrong: 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.

--volume

Why wrong: --volume is the long form of -v and, like its shorthand, accepts key=value pairs such as volume=/host/logs:/var/log/nginx, but it does not support explicit mount propagation or fine-grained control over mount type and read-only settings. When using --volume, Podman infers the mount type based on whether the source exists or contains a slash, which can lead to unexpected behavior if the host path doesn't exist. For a straightforward bind mount it works, but it lacks the explicitness and advanced capabilities of --mount, making it a less reliable option for production persistence.

--bind

Why wrong: There is no --bind option in the podman run command; it is a catch-all flag that does not exist in the Podman or Docker CLI reference. To create a bind mount, you must use --mount type=bind,source=/host/logs,destination=/var/log/nginx or the -v/--volume shorthand. Selecting --bind would immediately result in an error (e.g., unknown flag), so it is not a viable way to persist logs outside the container.

-v

Why wrong: The -v option (shorthand for --volume) is commonly used for volume mounts, but it has significant limitations for advanced persistence scenarios. It automatically creates a directory on the host if the source path does not exist, and it does not allow you to specify mount propagation or explicit bind-mount type. While -v works for simple cases, its implicit behavior and lack of support for propagation options make it unsuitable when you need deterministic, production-grade log persistence; --mount is the safer alternative.

podman logs -f <container>

Why wrong: The `-f` (or `--follow`) flag attaches to the container's log stream and keeps the output open, displaying new lines in real time as they are written. In a crash-looping container this is not the same as viewing a fixed tail; it will wait for future output and may never terminate, so it does not give the administrator a clean snapshot of the last 10 lines that led to the crash. A follow is useful for debugging a running container, not for retrieving a bounded history from a crashed one.

podman logs --since 10m <container>

Why wrong: The `--since 10m` option filters logs to only those entries generated in the last 10 minutes, rather than the last 10 lines. This is a time-based filter, not a count-based one, so it can return hundreds of lines or none at all depending on how long ago the container crashed and how verbose the logs are. For a crash loop, you need the final lines from the most recent exit, not all log output within a time window.

podman inspect <container>

Why wrong: The `podman inspect` command retrieves low-level metadata about the container—such as its configuration, mount points, network settings, and state—as a large JSON object. It does not read the container's stdout/stderr logs, so it provides no visibility into the application error that caused the crash. Inspect is useful for checking the container's exit code or environment, but it cannot replace `podman logs` for diagnosing the actual runtime failure.

--layers=false

Why wrong: The `--layers=false` argument is not a recognized `podman build` option; the utility rejects it as invalid before any build or caching logic runs. Consequently, it cannot selectively disable cached layers. To bypass the layer cache in Podman, the correct flag is `--no-cache`, which is an entirely separate command-line switch rather than a boolean assignment on a `--layers` toggle.

--squash

Why wrong: `--squash` is valid but it only flattens all generated layers into a single layer after the build completes; it does not inspect or purge the builder's layer cache. Cached layers from earlier instructions will still be reused during the build, so in the short term you gain a smaller image while losing the ability to see layer history. To prevent cached layers from being consulted, you need `--no-cache`, not a compression or flattening operation.

--force-rm

Why wrong: `--force-rm` controls intermediate container cleanup, not the build cache: it guarantees that any temporary containers created during the build are removed on success and failure. The layer cache remains fully active, so unchanged instructions resolve to already-built layers and never rerun. This option addresses disk hygiene and stale container leftovers, but it is irrelevant when the goal is a cache-disabled build.

--network slirp4netns

Why wrong: --network slirp4netns is a user-space networking backend, commonly used with rootless Docker or Podman, that provides a network namespace with a virtual network through a SLIRP-based user-mode stack. It does not place the container in the host's network namespace; rather, it emulates a private network and translates traffic through the userland, which is slower but avoids needing root privileges. This is distinctly different from --network host, which uses the host's actual interfaces without any translation.

--network bridge

Why wrong: --network bridge is the default Docker networking mode, where the container gets its own network namespace with a unique IP address on a virtual bridge network (usually docker0). Traffic from the container is forwarded to the host via Network Address Translation (NAT) and veth pairs, so the container does not share the host's network namespace. This mode provides isolation but adds a small layer of abstraction and requires explicit port publishing for external access.

--network none

Why wrong: --network none disables all external networking for the container. The container is created with only a loopback interface and no routes to the outside world, meaning it cannot access the host network, other containers, or the internet. This isolation is useful for batch jobs or security-sensitive processes that require no network connectivity, but it does not share the host's network namespace.

--read-only

Why wrong: --read-only makes the container's root filesystem immutable, preventing any writes to the overlay or writable layer. It is a safety/security measure to stop containers from modifying their own image filesystem during runtime, not a mechanism to preserve or store data. Any data written would be rejected unless another writable mount is provided, so it does not and cannot persist data on its own.

--tmpfs

Why wrong: --tmpfs mounts an in-memory temporary filesystem, typically ram-backed, at a specified mount point in the container. The contents exist only for the life of the container process and are wiped completely when the container stops or is removed. It is useful for temporary, non-critical data that must be fast and non-persistent, but it does not provide any durable storage.

--squash

Why wrong: --squash is not a recognized option for podman run; it is a build-time flag used with podman build to flatten image layers. At runtime, podman run cannot squash layers or influence storage persistence, so the option is invalid for this command. Attempting to use --squash with podman run will produce an error, making it definitively wrong.

--expose

Why wrong: The --expose option is incorrect because it does not map any port to the host. It only tells Podman that the container listens on a particular port, and that port is communicated to other containers on the same network or via a pod. No host-side port binding is created, so the exposed port is not reachable from the host or from the outside world unless you separately publish a port with -p or -P.

--port

Why wrong: The --port option is not a valid Podman run option. Podman's CLI for publishing ports is -p or --publish, while -P publishes every exposed port; there is no single --port flag. Attempting to use it results in an 'unknown flag: --port' error from Podman. Therefore, it cannot be used to publish container ports and is the wrong choice for this question.