Why build optimization matters in Docker - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the Dockerfile command to set the base image.

Docker

FROM [1]

Drag options to blanks, or click blank then click option'

Aubuntu:20.04

BCOPY . /app

CRUN apt-get update

DEXPOSE 80

Attempts:

3 left

💡 Hint

Common Mistakes

Using commands like COPY or RUN instead of a base image after FROM.

The FROM command sets the base image for the Docker build. Here, ubuntu:20.04 is a valid base image.

2fill in blank

medium

Complete the Dockerfile command to copy files into the image.

Docker

COPY [1] /app

Drag options to blanks, or click blank then click option'

ARUN apt-get install -y curl

B.

C/app

DEXPOSE 8080

Attempts:

3 left

💡 Hint

Common Mistakes

Using commands like RUN or EXPOSE instead of a path.

The COPY command copies files from the current directory (represented by .) into the image's /app directory.

3fill in blank

hard

Fix the error in the Dockerfile command to run a package update.

Docker

RUN apt-get [1] update

Drag options to blanks, or click blank then click option'

Ainstall

Bupgrade

Cremove

Dupdate

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'install' or 'upgrade' instead of 'update' in this context.

The correct command to update package lists is apt-get update. Using install or upgrade here is incorrect.

4fill in blank

hard

Fill both blanks to optimize the Dockerfile by combining commands.

Docker

RUN apt-get [1] && apt-get [2] -y curl

Drag options to blanks, or click blank then click option'

Aupdate

Binstall

Cremove

Dupgrade

Attempts:

3 left

💡 Hint

Common Mistakes

Reversing the order or using 'remove' or 'upgrade' incorrectly.

Combining apt-get update and apt-get install -y curl in one RUN command reduces image layers and speeds up builds.

5fill in blank

hard

Fill all three blanks to create a dictionary comprehension that filters packages to install.

Docker

packages = {pkg: version for pkg, version in all_packages.items() if pkg [1] ['curl', [2], [3]]}

Drag options to blanks, or click blank then click option'

Ain

B'wget'

C'git'

Dnot in

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'not in' or forgetting quotes around package names.

This comprehension keeps only packages named 'curl', 'wget', or 'git' by checking if pkg is in the list.

Practice

1. Why is it important to optimize Docker builds?

easy

A. To increase the number of layers in the image

B. To make images smaller and build faster

C. To use more disk space on the host

D. To avoid using Docker cache completely

Solution

1. Step 1: Understand build optimization goals

   Build optimization aims to reduce image size and speed up build time.

2. Step 2: Identify correct benefit

   Smaller images use less space and faster builds save time.

3. Final Answer:

   To make images smaller and build faster -> Option B

4. Quick Check:

   Build optimization = smaller, faster builds [OK]

Hint: Think about saving time and space with builds [OK]

Common Mistakes:

• Confusing more layers with optimization
• Assuming optimization uses more disk space
• Ignoring Docker cache benefits

2. Which Dockerfile command order helps leverage cache best?

easy

A. Put rarely changing commands first

B. Put frequently changing commands first

C. Put all commands in random order

D. Put RUN commands after COPY commands

Solution

1. Step 1: Recall Docker cache behavior

   Docker caches layers and reuses them if commands and files don't change.

2. Step 2: Order commands for cache reuse

   Put rarely changing commands first to maximize cache hits.

3. Final Answer:

   Put rarely changing commands first -> Option A

4. Quick Check:

   Rare commands first = better cache use [OK]

Hint: Order commands by how often they change [OK]

Common Mistakes:

• Putting frequently changing commands first
• Ignoring command order impact on cache
• Assuming random order is fine

3. Given this Dockerfile snippet, what is the main benefit of using multi-stage builds?

FROM node:18 AS build
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/build /usr/share/nginx/html

medium

A. It makes the image incompatible with nginx

B. It increases build time by adding extra steps

C. It copies unnecessary files to the final image

D. It reduces final image size by excluding build tools

Solution

1. Step 1: Understand multi-stage build purpose

   Multi-stage builds separate build environment from runtime to keep final image small.

2. Step 2: Analyze given Dockerfile

   Build stage installs node and builds app; final stage uses nginx and copies only build output.

3. Final Answer:

   It reduces final image size by excluding build tools -> Option D

4. Quick Check:

   Multi-stage = smaller final image [OK]

Hint: Multi-stage builds keep only needed files in final image [OK]

Common Mistakes:

• Thinking multi-stage always slows build
• Assuming all files are copied to final image
• Believing multi-stage breaks compatibility

4. You have this Dockerfile snippet:

FROM python:3.12
COPY . /app
RUN pip install -r /app/requirements.txt

Why might this cause slow rebuilds when you change source code files?

medium

A. Because COPY . /app invalidates cache for pip install

B. Because python:3.12 image is too large

C. Because pip install runs every build even if requirements.txt is unchanged

D. Because requirements.txt is copied after pip install

Solution

1. Step 1: Understand Docker cache invalidation

   Each command creates a layer; if a previous layer changes, later layers rebuild.

2. Step 2: Analyze COPY order impact

   COPY . /app copies all source files, changing often, invalidating cache for pip install layer.

3. Final Answer:

   Because COPY . /app invalidates cache for pip install -> Option A

4. Quick Check:

   Changing source files breaks cache after pip install [OK]

Hint: Copy dependencies before source code to keep cache [OK]

Common Mistakes:

• Thinking pip install always runs
• Ignoring COPY order effect on cache
• Blaming base image size for rebuild speed

5. You want to optimize a Dockerfile for a Go app. Which approach best reduces final image size and speeds up build?

Option A:
FROM golang:1.20
WORKDIR /app
COPY . .
RUN go build -o app

Option B:
FROM golang:1.20 AS build
WORKDIR /app
COPY . .
RUN go build -o app
FROM alpine:latest
COPY --from=build /app/app /app/app
CMD ["/app/app"]

hard

A. Use single stage build with golang image only

B. Use alpine image only without building

C. Use multi-stage build with golang and alpine images

D. Use golang image and copy source code at runtime

Solution

1. Step 1: Compare single vs multi-stage builds

   Single stage keeps build tools in final image; multi-stage separates build and runtime.

2. Step 2: Analyze options

   Use multi-stage build with golang and alpine images uses golang to build, then copies only binary to small alpine image, reducing size and speeding runtime.

3. Final Answer:

   Use multi-stage build with golang and alpine images -> Option C

4. Quick Check:

   Multi-stage builds = smaller, faster images [OK]

Hint: Build in one stage, run in smaller base image [OK]

Common Mistakes:

• Using large build image as final runtime image
• Skipping build step in alpine image
• Copying source code instead of binary