Application Design and Build →mediumMultiple Choice

CKAD Application Design and Build Practice Question

You are tasked with containerizing a Go application. The application compiles into a binary. Which Dockerfile best implements a multi-stage build to produce a minimal image?

⚠ Common exam trap

The CKAD exam often tests the requirement to explicitly name the builder stage (e.g., `AS builder`) and use the correct `COPY --from=builder` syntax, and the trap here is that candidates may pick Option A thinking it is valid multi-stage, overlooking the missing base image in the first `FROM`.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

FROM golang:1.21 AS builder\nWORKDIR /app\nCOPY . .\nRUN go build -o myapp\nFROM scratch\nCOPY --from=builder /app/myapp /myapp\nCMD ["/myapp"]

It uses a multi-stage build: the first stage uses the official `golang:1.21` image to compile the Go binary, and the second stage copies only the compiled binary into a `scratch` (empty) image. This produces a minimal image containing only the binary and no build tools, reducing attack surface and image size.

Answer analysis

Option-by-option breakdown

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

✗
FROM AS builder\nWORKDIR /app\nCOPY . .\nRUN go build -o myapp\nFROM scratch\nCOPY --from=builder /app/myapp /myapp\nCMD ["/myapp"]
Why it's wrong here
This Dockerfile is syntactically invalid because the FROM instruction must reference an existing base image; writing 'FROM AS builder' provides no image name, so the builder stage has nothing to start from and the build fails immediately. Even if a previous stage were intended, the correct syntax would be 'FROM <image> AS builder', and omitting the image means Docker cannot resolve the stage.
✗
FROM ubuntu:latest\nRUN apt-get update && apt-get install -y golang\nCOPY . /app\nWORKDIR /app\nRUN go build -o myapp\nCMD ["./myapp"]
Why it's wrong here
Using ubuntu:latest and installing golang via apt-get creates a single-stage build that retains the entire operating system, package manager, and Go toolchain, resulting in an image that is hundreds of megabytes larger than necessary. This approach also ties your build to the Ubuntu repository's Go version, potentially excluding newer features or security fixes, and unnecessarily widens the container's attack surface by including extra binaries and libraries.
✓
FROM golang:1.21 AS builder\nWORKDIR /app\nCOPY . .\nRUN go build -o myapp\nFROM scratch\nCOPY --from=builder /app/myapp /myapp\nCMD ["/myapp"]
Why this is correct
This multi-stage build is the optimal solution: the first stage uses golang:1.21 to compile the application in a controlled environment, then the second stage copies only the compiled binary into a scratch (empty) image. The final image contains just the executable, which is possible because Go can statically link most programs without a runtime or system libraries, yielding a minimal, secure container with fast startup and a tiny attack surface.
✗
FROM golang:1.21\nWORKDIR /app\nCOPY . .\nRUN go build -o myapp\nCMD ["./myapp"]
Why it's wrong here
While this single-stage Dockerfile will successfully compile the Go app, it retains the full golang:1.21 toolchain, source code, and build artifacts in the final image, making it unnecessarily large and bloated. Additionally, using CMD ["./myapp"] assumes the working directory remains /app, but if a user changes the WORKDIR later or runs the container with a different context, the relative path may break; an absolute path like /myapp is more robust.

Go deeper

CKAD Application Design and Build Practice Question

Why each option matters

Option-by-option breakdown

Related to this question