Reducing final image size by 80 percent in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use multi-stage builds in Docker?

What is the main reason to use multi-stage builds when aiming to reduce Docker image size by 80%?

A To automatically compress the image after building

B To run multiple containers simultaneously for faster builds

C To cache all layers and speed up network downloads

D To separate build dependencies from runtime dependencies, keeping only necessary files in the final image

💡 Hint

Think about how build tools and runtime environments differ in what files they need.

Multi-stage builds let you compile or build your app in one stage with all tools, then copy only the final app files to a smaller base image. This removes unnecessary build files and reduces image size.

💻 Command Output

intermediate

Output of docker image size after optimization

Given a Dockerfile that uses alpine as the base image and copies only the compiled binary, what is the expected approximate size of the final image?

A About 500 MB

B About 5 MB

C About 50 MB

D About 1 GB

💡 Hint

Alpine Linux base images are known for being very small.

Alpine base images are minimal, around 5 MB. Copying only the compiled binary keeps the image size very small, typically near 5 MB.

❓ Configuration

advanced

Identify the correct Dockerfile snippet to reduce image size

Which Dockerfile snippet correctly uses multi-stage build to reduce final image size by copying only the compiled binary?

Docker

FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

FROM alpine:latest
COPY --from=builder /app/myapp /usr/local/bin/myapp
ENTRYPOINT ["/usr/local/bin/myapp"]

A

FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

FROM alpine:latest
COPY --from=builder /app/myapp /usr/local/bin/myapp
ENTRYPOINT ["/usr/local/bin/myapp"]

B

FROM alpine:latest
COPY myapp /usr/local/bin/myapp
ENTRYPOINT ["/usr/local/bin/myapp"]

C

FROM golang:1.20
WORKDIR /app
COPY . .
RUN go build -o myapp
ENTRYPOINT ["./myapp"]

D

FROM alpine:latest
RUN apk add go
WORKDIR /app
COPY . .
RUN go build -o myapp
ENTRYPOINT ["/usr/local/bin/myapp"]

💡 Hint

Look for the snippet that builds in one stage and copies only the binary to a smaller image.

Option A uses a multi-stage build: first stage builds the app with Go, second stage uses Alpine and copies only the binary. This reduces image size significantly.

❓ Troubleshoot

advanced

Why does the final image remain large despite multi-stage build?

You used a multi-stage Dockerfile to reduce image size, but the final image is still over 500 MB. What is the most likely cause?

A You used a multi-stage build with separate stages

B You used Alpine as the base image in the final stage

C You copied the entire build context instead of only the binary in the final stage

D You did not run <code>docker system prune</code> after building

💡 Hint

Check what files are copied into the final image.

If you copy the whole build directory instead of just the compiled binary, all source files and dependencies remain, making the image large.

✅ Best Practice

expert

Best practice to reduce Docker image size by 80% in CI/CD pipelines

In a CI/CD pipeline, what is the best practice to ensure Docker images are consistently reduced by 80% in size?

A Use multi-stage builds, clean up unnecessary files, and use minimal base images like Alpine or scratch

B Build images on developer machines and push them to the registry

C Use large base images to avoid compatibility issues

D Avoid using multi-stage builds to speed up build time

💡 Hint

Think about combining multiple strategies for image size reduction.

Combining multi-stage builds, cleaning files, and using minimal base images ensures small, efficient images in automated pipelines.