EX188 Container Image Building — Timed 10 Questions

Question 1

A container image needs to automatically extract a local tar archive file named 'app.tar.gz' into the destination directory '/opt/app' during the build process. Which instruction should be used?

Accepted Answer

ADD app.tar.gz /opt/app/. The ADD instruction automatically extracts local tar archives, whereas COPY does not.

Answer

COPY app.tar.gz /opt/app/

Answer

EXTRACT app.tar.gz /opt/app/

Answer

RUN tar -xzf app.tar.gz -C /opt/app/

Question 2

You are troubleshooting a build where a RUN instruction fails because it cannot reach a remote URL to download a file. The local network uses an HTTP proxy. How should you pass the proxy settings to the build command without hardcoding them into the image?

Accepted Answer

podman build --build-arg HTTP_PROXY=http://proxy.example.com:8080 .. `--build-arg HTTP_PROXY=...` passes the proxy value as a build-time argument that is available to RUN instructions during the build without persisting it in the final image layers. This is the standard mechanism for injecting environment-dependent values like proxy URLs into a Containerfile build.

Answer

podman build --proxy http://proxy.example.com:8080 .

Answer

podman build --env HTTP_PROXY=http://proxy.example.com:8080 .

Answer

podman build --set-proxy http://proxy.example.com:8080 .

Question 3

You are writing a Containerfile and need to ensure that the default command executed when the container starts can be easily overridden by passing arguments on the podman run command line. Which instruction should you use?

Accepted Answer

CMD. CMD sets the default command executed when the container starts, and it is specifically designed to be overridden — arguments passed after the image name on 'podman run' replace the CMD entirely. This makes CMD the correct choice when the requirement is an easily overridable default command.

Answer

RUN

Answer

EXEC

Answer

ENTRYPOINT

Question 4

You want to create a rigid container image where the container always executes a specific binary (/usr/bin/redis-server) and any arguments passed to 'podman run' are appended as arguments to that binary. Which instruction combination is best?

Accepted Answer

ENTRYPOINT ["/usr/bin/redis-server"]
CMD ["--protected-mode", "no"]. Using ENTRYPOINT in exec form pins the container's executable to /usr/bin/redis-server, and CMD supplies default arguments that are appended when no runtime arguments are given. Any arguments passed to 'podman run' replace the CMD values and are appended to the ENTRYPOINT, exactly matching the requirement for a rigid image with overridable defaults.

Answer

RUN /usr/bin/redis-server

Answer

CMD ["/usr/bin/redis-server", "--protected-mode", "no"]

Answer

ENV BIN=/usr/bin/redis-server
CMD $BIN

Question 5

An auditor notices that a container image runs its main application process as the 'root' user by default. Which Containerfile instruction can be added to ensure the container runs as a non-privileged user named 'appuser'?

Accepted Answer

RUN useradd -u 1000 appuser && chown -R appuser /app
USER appuser. The correct pattern is to create the non-privileged user during the build with `RUN useradd` (and fix ownership of the app directory), then switch to it with the `USER appuser` instruction. `USER` sets the identity for all subsequent RUN, CMD, and ENTRYPOINT instructions, so the container's main process runs as `appuser` instead of root.

Answer

EXEC appuser

Answer

PRIVILEGE drop appuser

Answer

SECURITY --user=appuser

Question 6

You need to label your container image with maintainer details and version metadata according to OCI annotation standards. Which instruction should you use?

Accepted Answer

LABEL maintainer="admin@example.com" version="1.0". The LABEL instruction in a Dockerfile adds metadata to an image as key-value pairs, and it is the correct way to embed maintainer and version information per OCI annotation standards. LABEL is the only valid Dockerfile instruction among the options for this purpose.

Answer

METADATA maintainer="admin@example.com"

Answer

ANNOTATE maintainer="admin@example.com"

Answer

TAG maintainer="admin@example.com"

Question 7

You want to ensure that if any command in a multi-command RUN instruction fails, the entire container build process fails immediately. What shell option should be set or is default in Containerfiles?

Accepted Answer

RUN set -e && command1 && command2. In a Containerfile/Dockerfile RUN instruction, the shell invoked is /bin/sh -c, and by default sh does not exit on the first failing command in a chain unless the commands are joined with && or set -e is used. Writing RUN set -e && command1 && command2 enables errexit so any failing command aborts the build immediately, which is the documented pattern for fail-fast multi-command RUN steps.

Answer

RUN --strict-error command1 && command2

Answer

BUILD --fail-on-error

Answer

RUN ignore-errors=false command1 && command2

Question 8

When creating multi-architecture container images using podman build, how can you ensure that architecture-specific binaries are correctly handled when using instructions like COPY?

Accepted Answer

By running podman build separately for each architecture and combining them with podman manifest.. When building multi-architecture images, the recommended approach is to build separately for each architecture (using --platform or on native hardware) and then combine the per-architecture images into a single manifest list using `podman manifest`. Additionally, Podman provides automatic build arguments TARGETOS and TARGETARCH that are populated during multi-platform builds, allowing Containerfiles to conditionally handle architecture-specific binaries in COPY or RUN instructions. Both C and D are correct because they describe complementary mechanisms: manifest creation for distribution and build args for conditional logic.

Answer

By setting the ARCH environment variable in the base image.

Answer

By manually editing the Containerfile to include architecture-specific IF/ELSE statements.

Question 9

Which THREE mechanisms are valid ways to pass build arguments into a Containerfile during a 'podman build' invocation? (Choose three.)

Accepted Answer

Placing default values directly in the Containerfile using 'ARG KEY=DEFAULT_VALUE'.. Option B is correct because declaring 'ARG KEY=DEFAULT_VALUE' in the Containerfile sets a default build-argument value that is used when no override is supplied at build time, making it a valid mechanism for passing arguments into the build. Option D is correct because 'podman build --build-arg KEY=VALUE' explicitly passes a build argument value on the command line, overriding any default declared with ARG. Option E is correct because 'podman build --build-arg KEY' (without '=VALUE') causes Podman to inherit the value of KEY from the host environment, which is a documented way to forward host variables as build args. Option A is not valid because Podman's build does not support a '--build-arg-file' flag for reading build arguments from a file. Option C is not valid because '--env-file' is used to set environment variables for the build process/container runtime, not to populate ARG variables during 'podman build'.

Answer

Using the '--build-arg-file' flag to read variables from a file.

Answer

Using the '--env-file' flag during 'podman build' to populate ARG variables.

Question 10

Which THREE statements are correct regarding the behavior and usage of the WORKDIR instruction? (Choose three.)

Accepted Answer

It can be used multiple times in a single Containerfile to change directories relative to previous WORKDIR paths or absolute paths.. Option B is correct because WORKDIR can appear multiple times in a Containerfile, and each occurrence changes the working directory for subsequent instructions, accepting either absolute paths or relative paths that are resolved against the previous WORKDIR value. Option C is correct because if the specified directory does not already exist in the image filesystem, WORKDIR creates it automatically, even if no later instruction references it. Option E is correct because WORKDIR sets the working directory for any RUN, CMD, ENTRYPOINT, COPY, and ADD instructions that follow it in the Containerfile. Option A is incorrect because WORKDIR affects the image's filesystem and build context, not the host machine's current working directory where 'podman build' was executed. Option D is incorrect because WORKDIR does not replace the need for absolute paths in COPY and ADD; those instructions still resolve paths according to their own source/destination semantics and the build context.

Answer

It permanently modifies the host machine's current working directory where 'podman build' was executed.

Answer

It replaces the need to specify absolute paths in COPY and ADD instructions.