EX188 Practice Test 10 — 10 Questions

Question 1

Which TWO methods can be used to supply environment variables to a Podman container? (Choose TWO)

Accepted Answer

Using the -e or --env flag. Option C is correct because Podman supports the -e or --env flag to pass individual environment variables directly on the command line, e.g. podman run -e MYVAR=value image, which sets the variable inside the container. Option E is correct because the --env-file flag lets you supply a file containing KEY=value lines that Podman reads and injects as environment variables into the container. The other options are not valid Podman flags: --environment-map (A), --var-file (B), and --inject-env (D) do not exist in Podman's CLI, so they cannot be used to supply environment variables.

Answer

Using the --environment-map flag

Answer

Using the --var-file flag

Answer

Using the --inject-env flag

Question 2

Which TWO options can be specified when mounting a Podman secret into a container? (Choose TWO)

Accepted Answer

type=env. Option A (type=env) is correct because Podman secrets support being exposed to a container as environment variables, which is selected with the type=env mount option (e.g., podman run --secret mysecret,type=env). Option D (type=mount) is correct because the default and explicitly supported way to inject a secret is as a file mounted into the container's filesystem, specified with type=mount (e.g., --secret mysecret,type=mount). The remaining options do not belong: type=volume, type=tmpfs, and type=bind are not valid secret type values for Podman secrets — tmpfs and bind are storage/mount concepts used elsewhere (e.g., --mount type=tmpfs or type=bind), and volume is a storage driver concept, none of which are accepted as the secret type parameter.

Answer

type=volume

Answer

type=tmpfs

Answer

type=bind

Question 3

When configuring container networking in Podman, which TWO built-in network modes are available by default without creating custom networks? (Choose two)

Accepted Answer

bridge. Option A (bridge) is correct because Podman ships with a default bridge network (named 'podman') that containers attach to by default, providing NAT-based connectivity and inter-container communication on the host. Option B (host) is correct because Podman supports the host network mode out of the box, where the container shares the host's network namespace and uses the host's IP stack directly. Options C (macvlan), D (routed), and E (overlay) are not default built-in modes: macvlan and overlay typically require creating a custom network with specific drivers, and routed is not a standard Podman network mode available without additional configuration.

Answer

macvlan

Answer

routed

Answer

overlay

Question 4

Which TWO statements are true regarding the EXPOSE instruction in a Containerfile? (Choose two.)

Accepted Answer

It informs Podman that the container listens on the specified network ports at runtime.. Option A is correct because EXPOSE in a Containerfile declares the network ports the containerized application listens on at runtime, and Podman records this metadata so tools like podman inspect and podman run -P can use it. Option D is correct because EXPOSE serves primarily as documentation between the image creator and the container operator, indicating intended listening ports without actually opening or publishing them. Option B is wrong because EXPOSE has no relationship to environment variables; port configuration via env vars is a separate application-level concern. Option C is wrong because EXPOSE does not create or enforce firewall rules in the container network namespace and does not block unexposed ports. Option E is wrong because EXPOSE alone does not publish ports to the host; publishing requires -p for explicit mapping or -P to publish all exposed ports to random host ports.

Answer

It replaces the need to define environment variables for port configuration.

Answer

It enforces strict firewall rules inside the container network namespace, blocking unexposed ports.

Answer

It automatically publishes all exposed ports to random host ports without needing the -p or -P flag.

Question 5

Which THREE directives or practices are associated with implementing secure container builds and adhering to least-privilege principles? (Choose three.)

Accepted Answer

Using minimal, trusted base images to reduce the total software footprint and vulnerability surface.. Option B is correct because starting from minimal, trusted base images (e.g., distroless, alpine, or scratch) shrinks the installed package set and attack surface, reducing the number of exploitable CVEs in the final image. Option C is correct because a USER instruction that switches to a non-root UID/username before CMD or ENTRYPOINT enforces least privilege at runtime, preventing container processes from having root capabilities if the container is compromised. Option E is correct because BuildKit's --secret mounts (e.g., RUN --mount=type=secret) inject credentials only during the build step without persisting them in any image layer, unlike ENV or COPY which bake secrets permanently into the image history. Option A is wrong because hardcoding database passwords in ENV instructions stores credentials in plaintext in image metadata and layers, violating least privilege and secret-management best practices. Option D is wrong because running RUN instructions with --privileged grants the build container full host capabilities, which is the opposite of least privilege and dramatically increases the risk of container escape during builds.

Answer

Hardcoding database passwords directly into ENV instructions so the application can read them easily.

Answer

Running all RUN instructions with '--privileged' inside the Containerfile.

Question 6

How does Podman's rootless build architecture handle volume mounts or privileged operations specified within a RUN instruction in a Containerfile?

Accepted Answer

Rootless builds execute within user namespaces, mapping root inside the container to an unprivileged user on the host, restricting certain host-level operations.. Podman rootless builds run inside a user namespace where the container's UID 0 is mapped to the invoking unprivileged user's UID on the host (via /etc/subuid and /etc/subgid ranges). This means RUN instructions that appear to run as root inside the build actually execute as an unprivileged user on the host, so operations requiring real host privileges — mounting block devices, changing host ownership outside the mapped range, or binding to privileged ports — are restricted or fail.

Answer

Rootless builds cannot execute RUN instructions that install RPM packages using dnf.

Answer

Rootless builds automatically elevate privileges via sudo when a RUN instruction requires root access.

Answer

Rootless builds require the buildah daemon to be running as root in systemd.

Question 7

When deploying containers using Podman Compose, what is the default network driver assigned to user-defined networks created by compose if no driver is specified?

Accepted Answer

bridge. When Podman Compose creates a user-defined network without an explicit driver, it defaults to the bridge driver, matching Docker Compose behavior. The bridge driver creates a local software bridge on the host, giving containers on that network isolated L2 connectivity and automatic DNS-based name resolution among them.

Answer

host

Answer

macvlan

Answer

overlay

Question 8

Which Podman network mode completely isolates a container from any network communication, removing all interfaces except the loopback?

Accepted Answer

--network none. The `--network none` option in Podman creates a container with a completely isolated network namespace that contains only the loopback interface (lo). No veth pair, no bridge attachment, and no external connectivity is configured, so the container cannot send or receive any network traffic beyond itself. This is the canonical way to run a container with zero network exposure for security-sensitive workloads.

Answer

--network isolated

Answer

--network closed

Answer

--network disabled

Question 9

How can an administrator remove all unused, dangling Podman volumes that are not currently attached to any container?

Accepted Answer

podman volume prune. 'podman volume prune' removes all volumes not currently referenced by any container — exactly the definition of dangling or unused volumes. It is the dedicated cleanup command for reclaiming storage from orphaned volumes, and it prompts for confirmation unless run with --force. This is the correct tool when an administrator wants to bulk-remove unattached volumes.

Answer

podman rm --volumes

Answer

podman volume rm --all

Answer

podman volume clean

Question 10

A container named db_cache has stopped unexpectedly. An administrator wants to see the standard output logs generated by this container prior to its exit. Which command should be used?

Accepted Answer

podman logs db_cache. The `podman logs` command retrieves the standard output (stdout) and standard error (stderr) logs from a container, whether it is running or has stopped. Since the container `db_cache` has exited, `podman logs db_cache` will display the logs generated prior to its exit. This is the standard and correct way to access container logs in Podman.

Answer

podman inspect --logs db_cache

Answer

podman output db_cache

Answer

podman history db_cache