Container Image Building practice questions

COPY app.tar.gz /opt/app/

Why it fails: COPY will simply copy the tar file as a tar file without extracting it.

EXTRACT app.tar.gz /opt/app/

Why it fails: EXTRACT is not a valid Containerfile instruction.

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

Why it fails: While this works, it adds an unnecessary extra layer and requires cleaning up the tar file.

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

Why it fails: There is no --proxy flag for podman build.

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

Why it fails: The --env flag applies to runtime, not build time.

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

Why it fails: --set-proxy is not a valid flag.

RUN

Why it fails: RUN executes at build-time, not container run-time.

EXEC

Why it fails: EXEC is not a standard standalone instruction.

ENTRYPOINT

Why it fails: ENTRYPOINT configures a container that will run as an executable, making it harder to override completely without flags.

RUN /usr/bin/redis-server

Why it fails: RUN executes the binary during the image build and records nothing in the image's runtime configuration, so the container has no entrypoint and podman run arguments are not appended to redis-server. It is tempting because RUN is the instruction for executing commands, and it would be correct for build-time steps such as compiling or installing packages.

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

Why it fails: CMD sets a default command whose arguments are replaced entirely when podman run supplies its own command, so passed arguments would not be appended to redis-server. ENTRYPOINT is required for that append behaviour. CMD is correct when the image should allow a full command override at runtime.

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

Why it fails: Using shell expansion with ENV does not lock down the entrypoint effectively.

EXEC appuser

Why it fails: EXEC is not a valid instruction.

PRIVILEGE drop appuser

Why it fails: PRIVILEGE is not a valid instruction.

SECURITY --user=appuser

Why it fails: SECURITY is not a valid Containerfile instruction.

METADATA maintainer="admin@example.com"

Why it fails: METADATA is not a valid Containerfile instruction.

ANNOTATE maintainer="admin@example.com"

Why it fails: ANNOTATE is not a valid instruction.

TAG maintainer="admin@example.com"

Why it fails: TAG is used for tagging images in a registry or build context, not labeling metadata.

RUN --strict-error command1 && command2

Why it fails: There is no --strict-error flag for RUN.

BUILD --fail-on-error

Why it fails: BUILD is not an instruction.

RUN ignore-errors=false command1 && command2

Why it fails: ignore-errors is not a valid shell directive.

By setting the ARCH environment variable in the base image.

Why it fails: Base images are specific to one architecture unless multi-arch manifests are used.

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

Why it fails: Containerfiles do not support native programmatic control-flow IF/ELSE blocks.

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

Why it fails: The correct flag for reading build-arg files is typically --build-arg-file or handling via environment, but check specific podman version flags; actually Podman supports reading build args via various options, but let's check standard OCI/Podman flags. Wait, --build-arg-file is supported in Podman.

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

Why it fails: --env-file populates runtime ENV variables in podman run, not build arguments for ARG.

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

Why it fails: WORKDIR only affects the container image internal filesystem path, not the host.

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

Why it fails: While relative paths resolve against WORKDIR, absolute paths still function normally and ignore WORKDIR.

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

Why it fails: Podman can read Containerfiles from stdin using '-'.

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

Why it fails: COPY cannot access files outside the build context.

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

Why it fails: Comments generally do not invalidate subsequent layer cache unless parsed as special directives like syntax parsers.

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

Why it fails: Content-addressable caching works independently of the host workstation as long as inputs are identical.

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

Why it fails: --rm defaults to true, but keeping intermediate containers is controlled differently; --rm=false keeps failed containers, not successful ones indefinitely.

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

Why it fails: Rootless builds cannot gain full root host privileges due to user namespace security boundaries.

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

Why it fails: If app.conf sits in the same directory as the Containerfile, it is inside the build context and should be accessible. The build context is the directory passed as the final argument to podman build, and files within it are available to COPY. So this explanation does not fit the described situation where the file is beside the Containerfile.

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

Why it fails: COPY source paths are interpreted relative to the build context, not the host filesystem, so a relative source like app.conf is normal and valid. There is no rule requiring an absolute source path when the destination is absolute. This explanation therefore does not describe the actual cause of the missing file error.

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

Why it fails: COPY creates missing parent directories in the destination automatically, so the absence of /etc/myapp would not cause a source-not-found error. The reported error concerns the source file, not the destination. This explanation confuses destination path handling with source resolution, and so it does not account for the failure.

BASE

Why it fails: BASE is not a Containerfile instruction; FROM names the base image that later build steps extend. Tempting because it literally describes a foundation, but the keyword is unrecognised, so the build errors instead of pulling any image.

INIT

Why it fails: INIT is not a Containerfile instruction; FROM specifies the base image for subsequent build steps. Tempting because it suggests initialisation or a starting point, yet the builder recognises no INIT keyword, so the Containerfile is rejected before any layer is created.

PARENT

Why it fails: PARENT is not a Containerfile instruction; the base image is declared with FROM, which must precede build steps. Tempting because it evokes inheritance, but no such keyword exists, so the build fails immediately rather than resolving any parent layer.

LISTEN

Why it fails: LISTEN is not a Dockerfile instruction; it belongs to PostgreSQL configuration syntax, so the builder rejects it. It is tempting because the word describes a socket awaiting connections, and would be relevant when configuring a database server's listening addresses, not when documenting a container image's exposed ports.

PORT

Why it fails: PORT is not a Dockerfile instruction; it appears in Docker Compose or Kubernetes manifests, so the build fails. It is tempting because it names the concept directly, and would be correct in a compose file mapping host and container ports, but image metadata requires EXPOSE instead.

OPEN

Why it fails: OPEN is a Dockerfile instruction declaring which ports the image exposes as metadata; it does not document runtime listening ports, which are determined by the process and visible via docker ps or inspect. It is tempting because EXPOSE is commonly mistaken for port publishing, and would be relevant when authoring an image to signal intended ports.

podman build --file-path dockerfiles/Customfile .

Why it fails: `--file-path` is not a recognised podman build flag, so the command errors out before reading the Containerfile. The tempting part is that it looks like a natural way to point at a non-default filename in a subdirectory — a real need, since podman defaults to `Containerfile` or `Dockerfile` in the build context root. The correct flag for that purpose is `--file` (or `-f`).

podman build -p dockerfiles/Customfile .

Why it fails: -p is not a podman build option; it maps ports in podman run. The flag looks like a path selector, which is why it tempts, but podman build accepts an alternate Containerfile solely via --file (or -f).

podman build --config dockerfiles/Customfile .

Why it fails: --config is not a podman build flag; it belongs to podman run and podman create for specifying container configuration files. The tempting pull is that it sounds like a file-selection switch, but podman build selects a Containerfile only through --file.

EXPORT APP_PORT=8080

Why it fails: EXPORT is a shell builtin, not a Containerfile instruction, so the build fails; ENV is what persists a variable into the image. It tempts anyone used to interactive shells, where export APP_PORT=8080 sets a variable for the current session, but that scope is transient and never captured in an image layer.

VAR APP_PORT=8080

Why it fails: VAR is not a valid Containerfile instruction.

SET APP_PORT=8080

Why it fails: SET is a Windows CMD construct, not a Containerfile instruction, so the build errors before any layer runs. It tempts administrators with a Windows background, since SET APP_PORT=8080 does define environment variables in cmd.exe, but Linux container builds require ENV to persist the variable into the image.

TRANSFER

Why it fails: TRANSFER is not a Containerfile instruction at all, so the build would fail to parse rather than copy anything. It is tempting because the word describes moving files, but no such directive exists in the Containerfile specification; COPY is the instruction that copies local build-context files into the image.

ADD

Why it fails: ADD does copy local files, but it also auto-extracts recognised archives and fetches remote URLs, behaviour the scenario does not request. COPY performs the plain local copy required. ADD is tempting because it handles local sources, yet its extra extraction and remote-fetch semantics make it the wrong instruction here.

MOVE

Why it fails: MOVE is not a valid Containerfile instruction, so the build errors instead of copying host files into the image. The name suggests relocating files, which is why it tempts, but Containerfile syntax defines no MOVE directive; COPY is what transfers build-context content into the container filesystem.

PATH

Why it fails: PATH is not a Containerfile instruction at all; it is a shell environment variable. The stem requires WORKDIR, which persists a directory change into subsequent RUN, CMD, ENTRYPOINT, COPY and ADD layers. PATH is tempting because it governs command lookup during builds, but it cannot set a build-time working directory.

ENV

Why it fails: ENV sets persistent environment variables, not the working directory, so subsequent RUN, CMD, ENTRYPOINT, COPY and ADD still execute relative to the previous directory. It is tempting because ENV values do persist across later instructions, but that persistence applies to variables, whereas WORKDIR changes the directory context itself.

RUN

Why it fails: RUN executes a command during the image build and creates a layer; it does not set a persistent working directory for later instructions. It is tempting because RUN commands often reference paths, but RUN is the correct instruction when you need to execute build steps such as installing packages.