EX188 Container Image Building Practice Test 2 — 15 Questions

Question 1

Which instruction documents the network ports on which a container listens at runtime?

Accepted Answer

EXPOSE. The EXPOSE instruction in a Containerfile documents the network port(s) the containerized application listens on at runtime. It is metadata only — it does not actually publish the port to the host; that requires -p or -P at podman run time. EXPOSE is the standard OCI/Dockerfile directive for this purpose and is what tools like podman inspect read to report exposed ports.

Answer

LISTEN

Answer

PORT

Answer

OPEN

Question 2

A developer wants to build a container image using podman build, but the Containerfile is named 'Customfile' and located in a subdirectory named 'dockerfiles'. Which command accomplishes this?

Accepted Answer

podman build -f dockerfiles/Customfile .. The `podman build` command uses the `-f` or `--file` flag to specify an alternative Containerfile. The correct syntax is `podman build -f dockerfiles/Customfile .`, where the path to the Containerfile is given relative to the current directory, and the build context is the current directory (`.`).

Answer

podman build --file-path dockerfiles/Customfile .

Answer

podman build -p dockerfiles/Customfile .

Answer

podman build --config dockerfiles/Customfile .

Question 3

You need to set a persistent environment variable named 'APP_PORT' with the value '8080' inside a container image via the Containerfile. Which instruction should you use?

Accepted Answer

ENV APP_PORT=8080. The ENV instruction in a Containerfile sets a persistent environment variable that is available both during the build and at container runtime. This is the standard Dockerfile/Containerfile directive for environment variables, and it persists in the image metadata. Options like EXPORT, VAR, or SET are not valid Containerfile instructions.

Answer

EXPORT APP_PORT=8080

Answer

VAR APP_PORT=8080

Answer

SET APP_PORT=8080

Question 4

Which instruction should be used in a Containerfile to copy local files from the host machine into the container filesystem?

Accepted Answer

COPY. The `COPY` instruction in a Containerfile is used to copy files from the build context (host machine) into the container filesystem. It is the standard and recommended instruction for this purpose.

Answer

TRANSFER

Answer

ADD

Answer

MOVE

Question 5

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 6

Which user instruction changes the user name or UID and group name or GID to use when running subsequent instructions in the Containerfile?

Accepted Answer

USER. The USER instruction sets the user name or UID to use for running the image and for any RUN, CMD and ENTRYPOINT instructions that follow it.

Answer

LOGIN

Answer

IDENTITY

Answer

ACCOUNT

Question 7

You want to build an image that has a build-time argument named 'VERSION'. How do you declare this variable inside the Containerfile so it can be used during the build steps?

Accepted Answer

ARG VERSION. ARG is the Containerfile instruction that declares a build-time variable, which can be populated with --build-arg at build time and referenced in subsequent RUN, COPY, or other instructions. It exists only during the build and is not persisted in the final image's runtime environment, which is exactly the semantics required for a build-time VERSION variable.

Answer

DEFINE VERSION

Answer

ENV VERSION=1.0

Answer

VAR VERSION

Question 8

An administrator needs to execute multiple commands in a single RUN instruction to minimize image layers. Which syntax is standard in a Containerfile?

Accepted Answer

RUN dnf update -y && dnf install -y httpd. Combining commands using shell operators like && within a single RUN instruction reduces the total number of layers.

Answer

RUN ["dnf update -y", "dnf install -y httpd"]

Answer

RUN { dnf update -y; dnf install -y httpd; }

Answer

RUN dnf update -y 
 dnf install -y httpd

Question 9

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 10

A developer needs to optimize image size by removing build caches and temporary package manager cache files within the same RUN instruction. Why must this be done in a single RUN instruction?

Accepted Answer

Because file deletions in separate layers do not reduce the final image size due to the layered filesystem.. Container images are built as a stack of immutable layers, and each RUN instruction creates a new layer. If files are created in one RUN and deleted in a later RUN, the deletion only adds a whiteout marker in the new layer; the original files remain in the earlier layer and still contribute to the final image size. Performing installation and cleanup in a single RUN ensures the temporary files never persist in any committed layer.

Answer

Because package managers lock the database across different layers.

Answer

Because the container build engine will fail if cache cleanup happens in a separate layer.

Answer

To ensure environment variables persist between installation and cleanup.

Question 11

What is the primary benefit of utilizing multi-stage builds in Containerfiles?

Accepted Answer

It allows you to produce a final production image containing only the application binary and runtime dependencies, significantly reducing image size and attack surface.. Multi-stage builds allow developers to use multiple FROM statements, leaving behind build tools and heavy SDKs in earlier stages and keeping production images small and secure.

Answer

It automatically encrypts environment variables stored in the image layers.

Answer

It bypasses the need for a container registry when sharing images.

Answer

It speeds up local DNS resolution during container execution.

Question 12

When writing a Containerfile, what is the difference between shell form and exec form for the CMD instruction?

Accepted Answer

Exec form runs the executable directly without invoking a shell, making it receive Unix signals (like SIGTERM) properly as PID 1.. Exec form (JSON array syntax, e.g., CMD ["executable","arg1"]) runs the executable directly without a shell, so the process becomes PID 1 and receives Unix signals such as SIGTERM directly, enabling graceful shutdown. Shell form (CMD command arg1) wraps the command in /bin/sh -c, so the shell becomes PID 1 and may not forward signals to the child process. This distinction is critical for container lifecycle management.

Answer

There is no functional difference; they are syntactic aliases.

Answer

Shell form is required for multi-stage builds, while exec form is for single-stage builds.

Answer

Shell form runs the command as PID 1, while exec form spawns a bash shell wrapper.

Question 13

You need to ensure that a file copied into your image via the COPY instruction is owned by a specific user 'developer' and group 'devgroup'. How can this be achieved efficiently?

Accepted Answer

COPY --chown=developer:devgroup app.py /app/app.py. The COPY instruction in a Containerfile supports the --chown flag, which sets the ownership of the copied files directly during the copy operation. This is the most efficient method because it avoids creating an extra layer and does not require the user/group to exist in the image beforehand. The syntax --chown=developer:devgroup correctly specifies both user and group.

Answer

COPY app.py /app/app.py && chown developer:devgroup /app/app.py

Answer

COPY --user=developer:devgroup app.py /app/app.py

Answer

ADD --owner=developer app.py /app/app.py

Question 14

A developer has written a Containerfile with multiple COPY instructions for static configuration files that change frequently, placed near the top of the Containerfile before the application code installation. Why is this considered a bad practice for build caching?

Accepted Answer

It invalidates the build cache for all subsequent instructions whenever those configuration files change, slowing down builds.. Changing a file earlier in the Containerfile invalidates the cache for all subsequent instructions, forcing unnecessary rebuilds of heavy steps.

Answer

It violates OCI container image specification limits on COPY counts.

Answer

It causes the ENTRYPOINT instruction to fail at runtime.

Answer

It causes Podman to store duplicate layers in local storage, exhausting disk space.

Question 15

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