EX188 Practice Test 17 — 15 Questions

Question 1

An administrator needs to run a PostgreSQL container that stores its database files in a Podman named volume called pgdata, which was created earlier. The container must also have the volume mounted at /var/lib/postgresql/data inside the container. Which command should the administrator use?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

podman run -d --name pg -v pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=secret postgres:15. The correct command uses the -v flag to mount the named volume pgdata at the container path /var/lib/postgresql/data. Named volumes are referenced by name, and the short syntax source:destination is the standard way to attach them. The other options either reverse the order, use the wrong mount type, or add a read-only restriction that breaks database functionality.

Answer

podman run -d --name pg -v /var/lib/postgresql/data:pgdata -e POSTGRES_PASSWORD=secret postgres:15

Answer

podman run -d --name pg --volume pgdata:/var/lib/postgresql/data:ro -e POSTGRES_PASSWORD=secret postgres:15

Answer

podman run -d --name pg --mount type=bind,source=pgdata,destination=/var/lib/postgresql/data -e POSTGRES_PASSWORD=secret postgres:15

Question 2

You are troubleshooting a Podman Compose deployment where containers on a user-defined network cannot resolve each other by service name, although they can reach each other by IP address. Which TWO conditions would explain the name resolution failure? (Choose two.)

Accepted Answer

The containers were attached to the default bridge network instead of the Compose-created user-defined network.. Service-name resolution on a user-defined Podman network depends on two things: the containers must be attached to that network, and aardvark-dns must be running to answer queries. If containers sit on the default bridge or the DNS service is down, IP connectivity still works through the bridge while name lookups fail. Fixing the network attachment or the DNS service restores resolution.

Answer

Each service publishes its port to the host with 'ports:', which replaces the internal DNS records.

Answer

The Compose file sets 'dns:' on each service to an external resolver that has no record of the service names.

Answer

The containers are running with '--network none' but have static /etc/hosts entries for each other.

Question 3

A team wants to document ownership and contact information directly in the image so that `podman inspect` shows who maintains it. Which Containerfile instruction should they add to set this metadata?

Accepted Answer

LABEL maintainer="team@example.com". Image metadata such as maintainer contact information is set with the LABEL instruction. Labels are stored in the image configuration and can be read with podman inspect, making them the correct mechanism for documenting ownership without affecting runtime behavior or build-time variables.

Answer

COMMENT maintainer="team@example.com"

Answer

ENV maintainer="team@example.com"

Answer

ARG maintainer="team@example.com"

Question 4

An administrator wants to create a named volume called appdata and inspect its mount point on the host. Which sequence of commands should the administrator use?

Accepted Answer

podman volume create appdata then podman volume inspect appdata. To create a named volume and inspect its host mount point, the administrator should use podman volume create followed by podman volume inspect. These are the correct subcommands for volume management in Podman. The other options use invalid command syntax that would not work.

Answer

podman volume add appdata then podman volume show appdata

Answer

podman volume new appdata then podman volume details appdata

Answer

podman create volume appdata then podman inspect volume appdata

Question 5

You are writing a Containerfile for a Python web service. You want the image build to install dependencies and then run the service with predictable behavior across environments. Which TWO practices correctly apply build-time and runtime configuration in the Containerfile? (Choose two.)

Accepted Answer

Use ARG to declare a build-time variable such as APP_VERSION, then reference it in a RUN instruction to fetch the matching artifact.. Build-time parameters that affect what is installed belong in ARG, while runtime configuration that the service reads on startup belongs in ENV. ARG keeps values out of the final runtime environment, and ENV makes defaults available to the process while still allowing overrides at podman run time. Using each instruction for its intended purpose yields predictable builds and predictable runtime behavior.

Answer

Use ENV to set APP_VERSION and reference it in a RUN instruction to fetch the matching artifact.

Answer

Use ARG to set APP_PORT so the service can read it at runtime.

Answer

Use LABEL to set APP_PORT so the service can read it at runtime.

Question 6

An application container requires multiple configuration variables defined in a local file named 'app.env'. Which flag loads these variables into the container environment?

Accepted Answer

podman run --env-file app.env myapp. The --env-file flag is used with podman run to load environment variables from a file. The file should contain lines in the format VAR=value. This allows multiple variables to be set in the container environment without specifying each with -e.

Answer

podman run --config-file app.env myapp

Answer

podman run -e @app.env myapp

Answer

podman run --load-env app.env myapp

Question 7

An administrator needs to copy a configuration file named /tmp/nginx.conf from the host into a running container named web_server at path /etc/nginx/nginx.conf. Which command should be used?

Accepted Answer

podman cp /tmp/nginx.conf web_server:/etc/nginx/nginx.conf. The podman cp command copies files between the local filesystem and a container's filesystem (or between containers), using the syntax podman cp SRC DEST where a container path is prefixed with the container name and a colon. This mirrors docker cp and is the standard tool for injecting files into a running container. The command podman cp /tmp/nginx.conf web_server:/etc/nginx/nginx.conf correctly places the host file at the target path inside the container.

Answer

podman push --target web_server /tmp/nginx.conf

Answer

podman transfer /tmp/nginx.conf web_server:/etc/nginx/nginx.conf

Answer

podman import /tmp/nginx.conf web_server:/etc/nginx/nginx.conf

Question 8

How do you disconnect a running container from a custom network named 'mynet'?

Accepted Answer

podman network disconnect mynet mycontainer. The `podman network disconnect` command removes a container from a specified network, taking the network name and container name as arguments. This is the exact syntax for detaching a running container from a custom network like 'mynet' without stopping it. It is the counterpart to `podman network connect`.

Answer

podman container disconnect mynet mycontainer

Answer

podman network remove mynet mycontainer

Answer

podman network detach mynet mycontainer

Question 9

You are building an image behind a corporate firewall that requires a custom Certificate Authority (CA) certificate to trust internal registries and repositories. How can you add this CA certificate to the build container?

Accepted Answer

COPY corporate-ca.crt /etc/pki/ca-trust/source/anchors/
RUN update-ca-trust. Placing the CA certificate in the appropriate system directory (e.g., /etc/pki/ca-trust/source/anchors/ on RHEL/Fedora-based images) and running update-ca-trust is standard.

Answer

TRUST corporate-ca.crt

Answer

EXPOSE CERT corporate-ca.crt

Answer

ENV CA_CERT=corporate-ca.crt

Question 10

You are building a minimal container image from scratch using 'FROM scratch'. Your statically compiled Go binary fails to execute when the container starts, with a 'file not found' error, even though it was successfully copied into the image. What is the most likely cause?

Accepted Answer

The binary was dynamically linked against glibc or requires system files (like /etc/passwd or /lib64/ld-linux-x86-64.so.2) that are absent in the scratch image.. 'FROM scratch' is an empty image. If the binary depends on shared libraries (e.g., glibc) or dynamic linkers that exist in the host/build environment but not in scratch, it will fail.

Answer

The binary was copied with incorrect permissions; it needs to be made executable with chmod +x during build.

Answer

The EXPOSE instruction was missing, preventing the binary from binding to network interfaces.

Answer

The WORKDIR instruction was omitted, preventing Podman from locating the binary.

Question 11

You are configuring a container to consume a Podman secret named db_password. By default, where within the container's file system will this secret be mounted if no destination path is specified?

Accepted Answer

/run/secrets/db_password. When a Podman secret is consumed without an explicit destination, Podman mounts it at /run/secrets/<secret-name> inside the container. This mirrors the Docker Swarm convention and uses /run because it is a tmpfs-backed runtime directory, keeping the secret out of the image layers and off persistent storage. Thus db_password appears at /run/secrets/db_password.

Answer

/secrets/db_password

Answer

/etc/secrets/db_password

Answer

/var/run/secrets/db_password

Question 12

An application requires a secret to be exposed as an environment variable inside the container instead of a file mount. Which option achieves this with '--secret'?

Accepted Answer

podman run --secret db_pwd,type=env myapp. Podman's --secret flag supports a type= option, and type=env exposes the secret as an environment variable inside the container rather than mounting it as a file under /run/secrets. The syntax --secret db_pwd,type=env is the documented form for this behavior. This is useful for applications that read credentials from environment variables (e.g., 12-factor apps) instead of files.

Answer

podman run --secret db_pwd,destination=env myapp

Answer

podman run --secret db_pwd,target=variable myapp

Answer

podman run --secret db_pwd,mode=environment myapp

Question 13

An administrator is managing rootless Podman containers as a non-root user and wants to ensure that these containers automatically start upon system boot and persist across reboots using systemd. Which TWO steps or commands are required to accomplish this? (Choose TWO)

Accepted Answer

Run 'loginctl enable-linger ' to allow the user's systemd instance to run in the background when not logged in.. Option D is correct because rootless Podman containers run under the non-root user's own systemd instance, and 'loginctl enable-linger ' keeps that user manager (systemd --user) running after logout and across reboots, which is required for user services to start at boot without an interactive login. Option E is correct because the supported way to make a rootless container start via systemd is to generate a user unit with 'podman generate systemd' (or a Quadlet) and place it in '~/.config/systemd/user/', then enable it with 'systemctl --user enable --now '. Option A is not correct because '--restart always' is a Podman-level restart policy that only takes effect while the Podman service/container is running; it does not itself start containers at system boot without systemd integration. Option B is not correct because enabling the system-wide 'podman' service with root privileges does not manage a non-root user's rootless containers. Option C is not correct because '/etc/rc.local' is a legacy system-wide boot script and does not properly integrate with the user's systemd instance for rootless containers.

Answer

Configure the container restart policy to always using '--restart always' without systemd.

Answer

Run 'systemctl enable --now podman' with root privileges.

Answer

Modify the global '/etc/rc.local' script to execute 'podman start' on boot.

Question 14

Which TWO instructions can be used to copy files or directories from a build context into a container image?

Accepted Answer

COPY. The COPY instruction is correct because it copies files or directories from the build context (or a stage in a multi-stage build) into the image filesystem, with the syntax COPY ... , and it performs no automatic extraction or remote URL fetching. The ADD instruction is also correct because it likewise copies files or directories from the build context into the image, and additionally supports remote URLs and auto-extraction of local tar archives, though for plain copying COPY is preferred. PULL is not a Dockerfile instruction for transferring build-context files into an image; it describes fetching an image from a registry (docker pull). INSTALL is not a Dockerfile instruction; package installation is done via RUN with a package manager such as apt-get or yum. GET is not a Dockerfile instruction for copying build-context content into an image.

Answer

PULL

Answer

INSTALL

Answer

GET

Question 15

A container named db_master was previously paused using podman pause. Which command should the administrator use to resume its execution?

Accepted Answer

podman unpause db_master. The `podman pause` command suspends all processes in a container using the cgroup freezer. To resume execution, the correct command is `podman unpause`, which unfreezes the cgroup and allows processes to continue. Option C is the only command that reverses the paused state.

Answer

podman start db_master

Answer

podman resume db_master

Answer

podman thaw db_master