Image size and minimal base images in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why choose minimal base images in Docker?

Which of the following is the main advantage of using minimal base images like alpine in Docker containers?

A They include all development tools by default for easier debugging.

B They automatically update to the latest OS version on container start.

C They guarantee compatibility with all Linux distributions.

D They reduce the final image size, improving download and startup speed.

💡 Hint

Think about what affects container download and deployment speed.

Minimal base images like Alpine are very small, which reduces the image size. Smaller images download faster and start quicker, which is a key benefit in container environments.

💻 Command Output

intermediate

Output of Docker image size command

What is the output of the following command if you have a Docker image named myapp built from alpine base?

docker images myapp --format "{{.Repository}}: {{.Size}}"

A myapp: 500MB

B myapp: 50MB

C myapp: 5MB

D myapp: 1GB

💡 Hint

Alpine base images are known for being very small, around 5MB.

Alpine base images are typically around 5MB, so images built on top of Alpine tend to be small unless large layers are added.

❓ Configuration

advanced

Reducing Docker image size with multi-stage builds

Which Dockerfile snippet correctly uses multi-stage builds to reduce the final image size by excluding build tools?

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 ["myapp"]

A The snippet uses multi-stage build to copy only the binary, reducing image size.

B The snippet copies the entire builder image, increasing image size.

C The snippet installs build tools in the final image, increasing size.

D The snippet uses the same base image for both stages, no size reduction.

💡 Hint

Look for copying only the necessary files from the builder stage.

Multi-stage builds allow compiling in one stage and copying only the final binary to a minimal base image, reducing the final image size.

❓ Troubleshoot

advanced

Troubleshooting large Docker image size

You notice your Docker image size is unexpectedly large. Which of the following is the most likely cause?

A Using multi-stage builds to separate build and runtime stages.

B Including unnecessary packages and files in the image layers.

C Using a minimal base image like Alpine.

D Removing cache after package installation.

💡 Hint

Think about what adds extra weight to an image.

Including unnecessary packages and files increases image size. Minimal base images and multi-stage builds help reduce size, and removing cache also helps.

✅ Best Practice

expert

Best practice for minimal Docker images with Python apps

Which Dockerfile approach best minimizes image size for a Python application?

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

A Use <code>python:3.12-slim</code> with <code>pip install --no-cache-dir</code> to avoid cache files.

B Use <code>python:3.12</code> full image for maximum compatibility.

C Install packages with cache to speed up builds.

D Use <code>python:3.12-alpine</code> without adjusting pip install options.

💡 Hint

Consider both base image size and package installation options.

Using the slim base image reduces base size, and --no-cache-dir prevents pip from storing cache files, minimizing final image size.

Practice

1. Which base image is known for being very small and commonly used to create minimal Docker images?

easy

A. Ubuntu

B. Alpine

C. Debian

D. CentOS

Solution

1. Step 1: Understand common base images

   Ubuntu, Debian, and CentOS are full Linux distributions and tend to be larger in size.

2. Step 2: Identify minimal base images

   Alpine is a lightweight Linux distribution designed for minimal size, often under 10 MB.

3. Final Answer:

   Alpine -> Option B

4. Quick Check:

   Minimal base image = Alpine [OK]

Hint: Alpine is the go-to small base image for minimal Docker images [OK]

Common Mistakes:

• Choosing Ubuntu or Debian as minimal base images
• Confusing full distributions with minimal ones
• Not knowing Alpine is designed for small size

2. Which of the following Dockerfile base image declarations is syntactically correct for using Alpine Linux?

easy

A. FROM alpine:latest

B. BASE alpine

C. USE alpine

D. IMAGE alpine

Solution

1. Step 1: Recall Dockerfile syntax for base images

   The correct keyword to specify a base image is FROM followed by the image name and optional tag.

2. Step 2: Check each option

   Only 'FROM alpine:latest' uses the correct syntax. Others are invalid Dockerfile commands.

3. Final Answer:

   FROM alpine:latest -> Option A

4. Quick Check:

   Base image syntax = FROM [OK]

Hint: Base images start with FROM in Dockerfiles [OK]

Common Mistakes:

• Using incorrect keywords like BASE or USE
• Omitting the FROM keyword
• Not specifying image tag correctly

3. Given this Dockerfile snippet:

FROM alpine:3.18
RUN apk add --no-cache curl

What is the main reason this image remains small compared to using Ubuntu as base?

medium

A. Alpine automatically removes all packages after installation

B. Alpine installs curl faster than Ubuntu

C. Ubuntu images do not support curl installation

D. Alpine uses apk with --no-cache to avoid cache files, reducing size

Solution

1. Step 1: Understand Alpine's package manager behavior

   Alpine uses apk, and the --no-cache option prevents storing temporary cache files, keeping the image small.

2. Step 2: Compare with Ubuntu

   Ubuntu uses apt which caches package files unless explicitly cleaned, increasing image size.

3. Final Answer:

   Alpine uses apk with --no-cache to avoid cache files, reducing size -> Option D

4. Quick Check:

   apk --no-cache reduces image size [OK]

Hint: Use apk add --no-cache on Alpine to keep images small [OK]

Common Mistakes:

• Thinking Alpine installs packages faster
• Believing Ubuntu can't install curl
• Assuming Alpine removes all packages automatically

4. You wrote this Dockerfile:

FROM alpine
RUN apk add curl

But your final image is much larger than expected. What is the likely cause?

medium

A. You forgot to use --no-cache with apk add, so cache files remain

B. Alpine base image is always large regardless of commands

C. You should use Ubuntu base image for smaller size

D. The RUN command syntax is incorrect

Solution

1. Step 1: Analyze apk add command

   Without --no-cache, apk stores cache files in the image, increasing size.

2. Step 2: Understand base image size and syntax

   Alpine is small by default, RUN syntax is correct, and Ubuntu is larger, so those are not causes.

3. Final Answer:

   You forgot to use --no-cache with apk add, so cache files remain -> Option A

4. Quick Check:

   Missing --no-cache causes larger images [OK]

Hint: Always add --no-cache with apk to keep Alpine images small [OK]

Common Mistakes:

• Assuming Alpine is large by default
• Using wrong RUN syntax
• Switching to Ubuntu thinking it is smaller

5. You want to create the smallest possible Docker image for a Go application. Which base image and approach is best to minimize image size?

hard

A. Use FROM ubuntu and install Go runtime

B. Use FROM alpine and install full Go toolchain

C. Use FROM scratch and copy only the compiled Go binary

D. Use FROM debian and add all dependencies

Solution

1. Step 1: Understand the scratch base image

   Scratch is an empty image with zero size, ideal for copying only necessary files like a compiled binary.

2. Step 2: Compare other options

   Ubuntu, Alpine, and Debian add extra layers and packages, increasing image size unnecessarily.

3. Final Answer:

   Use FROM scratch and copy only the compiled Go binary -> Option C

4. Quick Check:

   Scratch + compiled binary = smallest image [OK]

Hint: Use scratch base and copy binary for tiniest Go images [OK]

Common Mistakes:

• Installing full runtimes increasing image size
• Using larger base images unnecessarily
• Not using multi-stage builds to compile separately