How do you structure a Dockerfile to leverage layer caching for dependencies?
Tests Docker layer invalidation and cache-aware instruction ordering. Copy requirements.txt and run pip install before source code so deps cache independently. Red flag: copying everything at once or installing deps after code, busting cache every build.
What's really being asked
Whether you understand that Docker builds images in layers and that each instruction creates a cacheable layer. Interviewers want to see if you can order Dockerfile instructions by change frequency to minimize rebuild time. In ML projects, dependency installation is often the slowest step, so avoiding redundant pip installs is critical for developer productivity.
The full answer
First, copy only the dependency manifest, requirements.txt, by itself. Second, run pip install or equivalent to build a layer that contains all Python packages. Third, copy the application source code in a separate later step. Fourth, mention that because layers are cached based on the checksum of inputs, changing a Python file only invalidates layers from the final COPY onward, leaving the heavy dependency layer intact. Optionally, mention using a .dockerignore file to prevent unnecessary files from being copied and busting cache.
The mistakes people make
Copying the entire project with COPY . /app before running pip install means any code change invalidates the dependency layer. Running pip install in the same RUN command as code copying. Using ADD instead of COPY without reason. Forgetting to mention .dockerignore and letting large datasets or model artifacts trigger cache busts. Suggesting multi-stage builds without first solving the basic layer ordering problem.
What usually comes next
How would you handle both requirements.txt and a new pyproject.toml? What if you need to install system dependencies like gcc before pip install? How does BuildKit improve caching beyond classic Docker? When would you use a multi-stage build to shrink the final image size? How do you handle large ML base images like CUDA that already contain heavy libraries?
A concrete example
A Dockerfile for a FastAPI ML service might look like this: FROM python:3.11-slim; WORKDIR /app; COPY requirements.txt .; RUN pip install --no-cache-dir -r requirements.txt; COPY src/ ./src/; CMD uvicorn src.main:app --host 0.0.0.0. If you update main.py, Docker reuses the cached layer from RUN pip install and only reruns the final COPY and CMD. On a typical ML project with 2GB of dependencies, this saves 3 to 5 minutes per build.
Interview question
Which Dockerfile ordering keeps dependency installation cached when only Python source files change?
- a.Copy the application source code first, then copy requirements.txt and run pip install
- b.Use a single RUN command that copies all files and installs dependencies together
- c.Copy all project files at once, then run pip install
- d.Copy requirements.txt first, run pip install, then copy the application source codeCorrect
Why? this is the answer
Copying requirements.txt first and running pip install creates a separate layer that remains cached when source code changes later. Copying everything at once before pip install busts the dependency layer whenever any project file changes, since Docker invalidates cached layers based on input checksums.
Just read this? Test yourself on what you have been reading.
Read the original → docs.docker.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles