Interview Questions
Docker Interview Questions and Answers
Docker interviews cover both the conceptual model (images vs. containers, layer caching) and practical questions about writing a real Dockerfile efficiently.
Example: A multi-stage Dockerfile for a Java app
Dockerfile# Build stage -- has the JDK and Maven, but never ships in the final image
FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests
# Runtime stage -- only the JRE and the built jar
FROM eclipse-temurin:17-jre-jammy
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]Frequently Asked Questions
An image is a read-only template built from a Dockerfile -- your application plus its dependencies, frozen as a set of layers. A container is a running (or stopped) instance created from that image, with its own writable layer on top. You can start many containers from the same image.
Each instruction in a Dockerfile (FROM, RUN, COPY, etc.) creates a cached layer. If a layer's inputs haven't changed since the last build, Docker reuses the cached layer instead of re-running it. That's why the example Dockerfile copies pom.xml and runs a dependency-related step before copying the full source -- source code changes far more often than dependencies, so ordering things this way keeps the expensive dependency-download layer cached across most rebuilds.
It lets a Dockerfile use one image (with build tools like Maven/a JDK) to compile your app, then copy only the final build artifact into a separate, much smaller runtime image (with just a JRE) -- the build tools never end up in the image you actually deploy. This significantly reduces final image size and attack surface.
COPY does exactly what it says -- copies files/directories from the build context into the image. ADD does that too, but also has extra behavior: it can automatically extract local tar archives, and can fetch a remote URL. Most style guides recommend COPY unless you specifically need ADD's extra behavior, since ADD's implicit magic can cause surprises.
A bind mount maps a specific path on the host filesystem directly into the container (docker run -v /host/path:/container/path) -- the host path fully controls the content. A named volume is managed by Docker itself, stored in Docker's own storage area, and isn't tied to a specific host path -- generally preferred for data that should persist independent of any particular host directory structure.
By default, a process inside a container runs as root unless the image specifies otherwise. If an attacker manages to break out of the container's process isolation, running as root gives them root-equivalent access on the host in some misconfigurations. Explicitly creating and switching to a non-root user (USER directive) in the Dockerfile is a standard security hardening step.
Containers on the same user-defined Docker network can reach each other by container/service name (Docker's embedded DNS resolves it) rather than needing hardcoded IP addresses, which change across restarts. By default, containers are isolated from each other unless explicitly placed on the same network.