EX188 Container Image Building Practice Test 1 — 15 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.

Question 11

Which THREE statements are true concerning how Podman builds container images and utilizes the build context? (Choose three.)

Accepted Answer

A file named '.containerignore' (or '.dockerignore') can be used to exclude files from being sent to the build context.. Option A is correct because Podman honors a '.containerignore' file (and also accepts '.dockerignore') in the build context to exclude specified files and directories from being sent to the build context, reducing context size and avoiding unnecessary cache invalidation. Option D is correct because the build context is precisely the set of files in the directory, URL, or archive (e.g., a tarball) passed as the final argument to 'podman build', and COPY/ADD instructions resolve paths relative to it. Option E is correct because Podman sends the entire build context to the build engine (Buildah/the storage daemon) so that instructions like COPY and ADD can access those files, which is why trimming the context with ignore files matters. Option B is incorrect because Podman can read a Containerfile from standard input using 'podman build -f -' (or by piping), so it is not limited to on-disk files. Option C is incorrect because standard COPY instructions cannot reach files outside the build context; attempting to do so fails, and only workarounds like additional build contexts or bind-mounting during build would be needed.

Answer

Podman cannot accept a Containerfile via standard input (stdin); it must always read from a file on disk.

Answer

Files outside the build context directory can be freely copied into the image using standard COPY instructions without extra flags.

Question 12

Which THREE conditions or practices can cause layer cache invalidation during a 'podman build' operation? (Choose three.)

Accepted Answer

Modifying the content or modification timestamp (mtime) of a file referenced by a COPY instruction.. Option B is correct because Podman's layer cache keys on the checksum of files added by COPY (and ADD), so changing a file's content or its mtime invalidates the cache for that instruction and all subsequent layers. Option C is correct because the cache is keyed on the exact instruction sequence; reordering instructions changes the parent layer chain, so each affected instruction misses the cache. Option D is correct because ARG values supplied via --build-arg are part of the cache key for any instruction that references the ARG, so a different value forces a rebuild of that layer and its descendants. Option A does not invalidate the cache because comments are stripped by the parser and do not produce a layer or affect the cache key. Option E does not invalidate the cache because Podman's cache is content-based, not host-based, so identical context and Containerfile yield cache hits regardless of workstation.

Answer

Adding a comment line '#' at the very top of the Containerfile before the first FROM instruction.

Answer

Running 'podman build' on a different physical workstation while using the exact same build context and Containerfile.

Question 13

Which THREE advanced configuration steps or flags are available when performing rootless builds or utilizing buildah/podman build advanced features? (Choose three.)

Accepted Answer

Using '--tls-verify=false' to bypass TLS verification when pulling base images from insecure registries.. Option A is correct because '--tls-verify=false' is a valid buildah/podman build flag that disables TLS certificate verification when pulling base images, which is necessary when working with insecure or self-signed registries. Option B is correct because '--format oci' explicitly sets the output image manifest format to OCI rather than the default Docker v2.2 schema, a supported advanced build option. Option C is correct because '--no-cache' is a real build flag that forces every layer to be rebuilt from scratch, bypassing the local layer cache. Option D is incorrect because there is no '--rm=false' flag that keeps intermediate build containers indefinitely; buildah/podman manage intermediate containers differently and do not expose this Docker-style behavior. Option E is incorrect because '--privileged-build' is not a valid flag, and rootless builds cannot be granted full root host capabilities this way.

Answer

Using '--rm=false' to automatically keep intermediate build container containers indefinitely on disk after successful builds.

Answer

Using '--privileged-build' to grant full root host capabilities to a rootless container build.

Question 14

A Containerfile contains the line `COPY app.conf /etc/myapp/app.conf`. During the build, podman reports that the file `app.conf` is not found even though it exists on the host machine in the same directory as the Containerfile. Which explanation best describes the cause?

Accepted Answer

The file is listed in a .containerignore or .dockerignore file, so it is excluded from the build context.. COPY sources are resolved from the build context, and files matching patterns in a .containerignore or .dockerignore are omitted from that context. When the file exists on the host but podman says it is missing, an ignore rule is the likely cause. Checking the ignore file and removing the matching pattern restores the file to the build context.

Answer

The file is outside the build context, so podman cannot access it during the build.

Answer

COPY requires an absolute source path when copying into an absolute destination path.

Answer

The destination directory /etc/myapp must exist before COPY can create the file.

Question 15

When writing a Containerfile, which instruction specifies the base image to be used for the subsequent build steps?

Accepted Answer

FROM. Every Containerfile must start with a FROM instruction to define the base image.

Answer

BASE

Answer

INIT

Answer

PARENT