CKAD Application Design and Build Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Combine all RUN commands into a single layer

  Why it's wrong here

  Combining all RUN commands into a single layer reduces the number of intermediate layers but does nothing to remove the Go toolchain, compilers, or system packages that were installed during the build. In fact, using a single RUN instruction can make caching worse because any change invalidates the entire layer, and the accumulated build dependencies remain permanently in that layer. This approach only optimizes layer metadata, not the actual disk footprint of the final image.

• ✗

  Add a .dockerignore file to exclude unnecessary files

  Why it's wrong here

  Adding a .dockerignore file trims the build context sent to the Docker daemon, which speeds up the COPY of source code, but it has no effect on the size of the base image or the dependencies pulled in during the build. The dominant contributor to image size is usually the base image (like golang:latest) and the build tools, not the source files. The .dockerignore only prevents unwanted files from being copied; it cannot strip out the compiler, linker, or installed libraries that are already baked into the image layers.

• ✗

  Use a smaller base image like alpine:3.19

  Why it's wrong here

  Switching to a smaller base image like alpine:3.19 reduces the OS layer, but you will still have to install the Go toolchain and any build dependencies on top of that base image, which adds significant size. More importantly, if you use alpine as the final image and keep all the build tools, the image remains bloated and retains a shell and package manager. The real win comes from using an alpine-based build stage and then copying the static binary to a scratch final stage, which is a multi-stage approach, not just a base image swap.

• ✓

  Use multi-stage builds with a scratch final stage

  Why this is correct

  Multi-stage builds are the correct approach because they allow the Dockerfile to use a full Go toolchain in a builder stage, produce the compiled binary, and then copy that artifact into a fresh scratch final stage. Scratch is an empty image with no OS, no shell, and no libraries, so all build-time dependencies, compilers, and unnecessary files are discarded, leaving only the static executable. This drastically reduces image size and attack surface, and since Go can produce statically linked binaries with CGO_ENABLED=0, the binary runs perfectly on scratch without any runtime dependencies.

Go deeper

Related to this question