Docker layer caching in CI - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use Docker layer caching in CI pipelines?

Imagine you run a CI pipeline that builds a Docker image every time you push code. Why is using Docker layer caching helpful in this scenario?

A It automatically pushes the image to the registry without building.

B It deletes all previous images to free up disk space before building.

C It speeds up builds by reusing unchanged layers, reducing build time and resource use.

D It forces the build to always start from scratch to avoid stale layers.

💡 Hint

Think about what happens if you rebuild the same parts of the image repeatedly.

Docker layer caching saves time by reusing layers that did not change, so the build only processes new or changed parts.

💻 Command Output

intermediate

Output of Docker build with cache hit

What will be the output status of the following Docker build step if the layer is cached?

Docker

Step 3/5 : RUN apt-get update && apt-get install -y curl
---> Using cache

A The step runs again and downloads packages.

B The step is skipped and the cached layer is reused.

C The build fails due to cache conflict.

D The step is ignored and not included in the image.

💡 Hint

Look at the phrase '---> Using cache' in the output.

'---> Using cache' means Docker found a matching layer and reused it without rerunning the command.

❓ Configuration

advanced

Configuring Docker layer caching in GitHub Actions

Which GitHub Actions step correctly enables Docker layer caching using the official cache action?

Docker

name: Build and cache Docker image
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Cache Docker layers
        uses: actions/cache@v3
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-
      - name: Build image
        run: |
          docker build --cache-from=type=local,src=/tmp/.buildx-cache \
                       --cache-to=type=local,dest=/tmp/.buildx-cache-new .
      - name: Move cache
        run: |
          rm -rf /tmp/.buildx-cache
          mv /tmp/.buildx-cache-new /tmp/.buildx-cache

A The given configuration correctly caches Docker layers between builds.

B The cache action is missing the 'restore-keys' field, so caching won't work.

C The docker build command lacks '--cache-from' option, so no cache is used.

D The cache path is incorrect; it should be '/var/lib/docker' to cache layers.

💡 Hint

Check if the cache action and docker build commands use matching cache paths.

This setup uses a local directory to store cache and passes it to docker build with proper options, enabling layer caching.

❓ Troubleshoot

advanced

Why is Docker layer caching not working in CI?

You notice your CI builds always take a long time and never reuse cached Docker layers. Which reason below explains this behavior?

A The Dockerfile has a 'COPY .' command before installing dependencies, invalidating cache early.

B The CI runner has enough disk space and memory for caching.

C The Docker build uses '--cache-from' with a valid cache source.

D The base image is pulled from a public registry without changes.

💡 Hint

Think about how Docker cache invalidation works with file changes.

Placing 'COPY .' before installing dependencies causes cache invalidation if any source file changes, forcing rebuild of all later steps.

🔀 Workflow

expert

Optimizing Docker layer caching in multi-stage CI builds

You have a multi-stage Dockerfile used in CI. Which practice best improves layer caching efficiency across stages?

A Use 'COPY .' as the first command in every stage to include all files early.

B Combine all commands into a single stage to avoid cache misses between stages.

C Always run 'apt-get update' in every stage to ensure fresh packages.

D Separate frequently changing files into later stages and keep stable dependencies in earlier stages.

💡 Hint

Think about which parts of the build change often and which stay stable.

Keeping stable dependencies in early stages allows Docker to cache them once, while changing files copied later avoid invalidating earlier cached layers.