EX188 Practice Test 13 — 15 Questions

Question 1

Which Containerfile instruction sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions?

Accepted Answer

WORKDIR. The WORKDIR instruction sets the working directory for any instructions that follow it in the Containerfile.

Answer

PATH

Answer

ENV

Answer

RUN

Question 2

A container running in rootless mode needs to map a user account on the host to a different user inside the container namespace. Which options configure UID and GID mapping?

Accepted Answer

--uidmap and --gidmap. The --uidmap and --gidmap options are used with podman run to define custom UID and GID mappings between the host and the container user namespace. These flags allow fine-grained control over how host UIDs map to container UIDs, which is essential in rootless mode where the user namespace is already in play. They accept values in the format container_uid:host_uid:count.

Answer

--userns-map and --groupmap

Answer

--user-namespace-file

Answer

--map-user and --map-group

Question 3

Where are Podman named volumes typically stored on the host file system by default for a non-root user?

Accepted Answer

~/.local/share/containers/storage/volumes/. For a non-root user, Podman stores named volumes under the user's home directory in ~/.local/share/containers/storage/volumes/ by default. This is because rootless Podman uses a separate storage location for each user, following the XDG Base Directory specification. The root user's volumes are stored in /var/lib/containers/storage/volumes/, but non-root users do not have write access there, so Podman uses the user-specific path.

Answer

/var/lib/containers/storage/volumes/

Answer

/etc/containers/volumes/

Answer

/var/run/containers/storage/

Question 4

You need to inspect the configuration details, including subnet, gateway, and driver, of a custom Podman network named 'appnet'. Which command should you run?

Accepted Answer

podman network inspect appnet. 'podman network inspect <name>' returns detailed JSON configuration for the specified network, including subnet, gateway, driver, IPAM options, and connected containers. This is the correct command to inspect a custom Podman network's configuration details.

Answer

podman inspect --network appnet

Answer

podman network show appnet

Answer

podman network status appnet

Question 5

You need to define a persistent environment variable named 'PORT' with the value '8080' that is available during both the build process and when running containers from the resulting image. Which instruction should you use?

Accepted Answer

ENV. The ENV instruction in a Containerfile/Dockerfile sets an environment variable that persists both during subsequent build steps (RUN) and in the final image at runtime. Using ENV PORT=8080 makes PORT available to any process started from the resulting image, satisfying the requirement for build-time and runtime availability.

Answer

SET

Answer

VAR

Answer

EXPORT

Question 6

An administrator needs to commit the changes made to a running container named test_lab into a new image named my_custom_img:latest. Which command should be used?

Accepted Answer

podman commit test_lab my_custom_img:latest. The 'podman commit' command creates a new image from a container's current state, including any changes made to its filesystem. The syntax 'podman commit ' correctly captures the container 'test_lab' and produces the image 'my_custom_img:latest'.

Answer

podman create-image test_lab my_custom_img:latest

Answer

podman save test_lab my_custom_img:latest

Answer

podman build --container test_lab -t my_custom_img:latest

Question 7

Which configuration block in a Podman Compose YAML file is used to define custom isolated networks for the multi-container application?

Accepted Answer

networks:. In a Podman Compose YAML file, the top-level 'networks:' block defines custom isolated networks for the multi-container application. Services then reference these networks via their own 'networks:' key to attach to them.

Answer

interfaces:

Answer

bridges:

Answer

connections:

Question 8

You need to pass sensitive database credentials to a Podman container securely without storing them in plaintext environment variables. Which sequence of commands correctly creates and injects the secret?

Accepted Answer

podman secret create db_pass secret.txt && podman run --secret db_pass,type=mount,target=/run/secrets/pass myapp. Podman secrets are created with 'podman secret create' and injected into a container using '--secret'. Specifying type=mount and target=/run/secrets/pass mounts the secret as a file inside the container, avoiding plaintext environment variables. This is the secure, supported pattern for delivering credentials to a container.

Answer

podman volume create db_pass && podman run --volume db_pass:/run/secrets/pass myapp

Answer

podman secret create db_pass secret.txt && podman run --env-file secret.txt myapp

Answer

podman secret add db_pass secret.txt && podman run -e SECRET=db_pass myapp

Question 9

You need to inspect the network traffic of a container by capturing packets on its virtual interface. Where can you find the host-side veth interface name associated with a running container?

Accepted Answer

In the container's network inspection output under network interface details.. The host-side veth interface name is found in the container's network inspection output, typically via 'podman inspect <container>' under the 'NetworkSettings' or 'Networks' section, which lists the interface name and its peer. This allows the admin to identify the correct veth to capture packets on.

Answer

It is always named 'eth0' on the host system.

Answer

In the /etc/resolv.conf file inside the container.

Answer

In the systemd journal logs exclusively.

Question 10

Which TWO of the following instructions in a Containerfile can be written using either the shell form or the exec form?

Accepted Answer

RUN. Option B (RUN) is correct because the RUN instruction supports both the shell form (e.g., RUN apt-get update) and the exec form (e.g., RUN ["apt-get", "update"]), allowing either a shell command string or a JSON array of executable and arguments. Option D (CMD) is correct because CMD likewise accepts both forms: the shell form (CMD echo hello) and the exec form (CMD ["echo", "hello"]), with the exec form being the preferred default-command syntax. Option A (WORKDIR) is not correct because it takes only a plain path argument (WORKDIR /app) and has no exec/shell form distinction. Option C (FROM) is not correct because it specifies an image reference and optional stage name (FROM alpine:3.19 AS build) with no shell or exec form. Option E (ENV) is not correct because it sets variables using key=value syntax (ENV KEY=value) and does not offer an exec-form JSON array variant.

Answer

WORKDIR

Answer

FROM

Answer

ENV

Question 11

You want to set the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions that follow it in the Containerfile. Which instruction achieves this?

Accepted Answer

WORKDIR. The WORKDIR instruction sets the working directory for subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions in a Containerfile. If the directory does not exist, WORKDIR creates it automatically, and it can be used multiple times to change context throughout the build.

Answer

DIR

Answer

CD

Answer

PATH

Question 12

You are using a multi-stage build in your Containerfile. How do you copy a compiled binary named 'app' from a build stage named 'builder' into your final production runtime stage?

Accepted Answer

COPY --from=builder /app /app. The COPY instruction in a Containerfile supports the --from=<stage> flag, which references a previously named build stage (e.g., 'builder') and copies artifacts from that stage's filesystem into the current stage. This is the canonical multi-stage build pattern for producing slim runtime images that exclude compilers, SDKs, and build dependencies. The syntax COPY --from=builder /app /app copies the compiled binary from the builder stage's /app path into the final stage's /app path.

Answer

COPY --stage=builder /app /app

Answer

ADD --stage-name=builder /app /app

Answer

IMPORT --from=builder /app /app

Question 13

When interacting with container registries using Podman, which THREE commands or tasks are valid operations supported natively by the Podman CLI? (Choose three.)

Accepted Answer

podman pull registry.example.com/image:tag. Option C (podman pull registry.example.com/image:tag) is correct because podman pull is the native Podman CLI command that downloads an image from a registry such as registry.example.com, resolving the image by name and tag. Option D (podman push registry.example.com/image:tag) is correct because podman push is the native command that uploads a local image to a remote registry, using the fully qualified image reference including the registry host and tag. Option E (podman login registry.example.com) is correct because podman login authenticates the CLI session against the specified registry, storing credentials (typically in ${XDG_RUNTIME_DIR}/containers/auth.json or ~/.docker/config.json) so that pull and push operations can access private repositories. Options A and B are not valid Podman subcommands: there is no podman mount-registry command (mounting is done with podman mount on local containers/images) and no podman compile-image command, so neither performs any registry operation.

Answer

podman mount-registry --remote

Answer

podman compile-image --from-registry

Question 14

An administrator is working with a rootless Podman setup and needs to ensure that container user namespaces map UIDs correctly such that container root (UID 0) maps to the unprivileged user's UID on the host. Which file configures subordinate UID mappings for rootless users on RHEL?

Accepted Answer

/etc/subuid and /etc/subgid. Rootless user namespaces rely on /etc/subuid and /etc/subgid for mapping ranges.

Answer

/etc/containers/userns.conf

Answer

/etc/security/limits.conf

Answer

/etc/passwd and /etc/group

Question 15

An engineer needs to mount a host directory using the advanced '--mount' syntax instead of '-v'. Which syntax correctly specifies a bind mount?

Accepted Answer

podman run --mount type=bind,source=/host/path,destination=/container/path myapp. The advanced --mount syntax uses comma-separated key=value pairs, and for a bind mount you must specify type=bind, source=, destination=. Option D is the only one that follows this exact syntax.

Answer

podman run --mount /host/path:/container/path:bind myapp

Answer

podman run --mount source=/host/path,target=/container/path myapp

Answer

podman run --mount bind:/host/path:/container/path myapp