quizzMonkey
Start free

Docker Interview Mock sample questions with answers

10 questions from the Docker Interview Mock practice bank, spread across its domains. Pick your answer, then open the explanation to see why each option is right or wrong.

  1. Question 1Running Containers

    You run docker exec -it app apk add curl, then docker restart app. A week later you deploy with docker rm -f app && docker run -d --name app myimage. Is curl available, and when?

    • A

      Available after the restart and after the redeploy

    • B

      Available after the restart, gone after the redeploy

    • C

      Gone after the restart, because restarts reset the container filesystem

    • D

      Gone immediately, because docker exec changes are never saved

    Show the answer and explanation

    Answer: B

    Changes made by any process, including docker exec, land in the container's writable layer. That layer survives stop, start and restart of the same container, but docker rm deletes it, and a new container gets a fresh one from the image. That's why runtime installs "work until the next deploy". Put dependencies in the Dockerfile.

    Why the other options are wrong

    • A. A new container starts from the image, without the old writable layer.

    • C. Restarting the same container keeps its writable layer.

    • D. exec changes the container's writable layer like any other process.

  2. Question 2Building Images

    Given this Dockerfile, which two statements are true? (Choose two.)

    FROM node:22-slim
RUN useradd -m app
USER app
WORKDIR /home/app
COPY package.json .
RUN npm install
CMD ["node", "index.js"]

    Choose 2.

    • A

      package.json is owned by root, because COPY ignores USER unless --chown is used

    • B

      npm install and the final node index.js both run as the app user

    • C

      useradd fails because USER is set before it runs

    • D

      COPY creates package.json owned by app because USER was set first

    • E

      USER only affects the container at runtime; build steps always run as root

    Show the answer and explanation

    Answer: A and B

    USER sets the user for the rest of the stage: later RUN steps and the runtime CMD/ENTRYPOINT. COPY and ADD do not follow it. Without --chown, copied files belong to UID and GID 0, so use COPY --chown=app:app package.json . if the app user must write to them.

    Why the other options are wrong

    • C. useradd runs before the USER line, still as root.

    • D. COPY needs --chown=app:app to change ownership.

    • E. USER also sets the user for subsequent RUN instructions.

  3. Question 3Production and Ecosystem

    A Node.js Dockerfile installs dependencies for a production image. Why is npm ci usually preferred over npm install here?

    • A

      npm ci installs packages in parallel, so it is always faster than npm install

    • B

      npm ci skips lifecycle scripts, which makes the image safer to build

    • C

      It installs exactly what the lockfile specifies and fails if package.json disagrees

    • D

      It downloads packages from Docker Hub instead of the npm registry

    Show the answer and explanation

    Answer: C

    npm ci requires a lockfile, deletes any existing node_modules, installs the exact versions in the lockfile, and errors if package.json and the lockfile are out of sync. That determinism is what you want in an image build; npm install may update the lockfile and resolve different versions.

    Why the other options are wrong

    • A. Speed isn't the main reason, and it can be slower because it removes node_modules first.

    • B. npm ci still runs install scripts unless you pass --ignore-scripts.

    • D. npm ci still uses the npm registry configured for the project.

  4. Question 4Container Fundamentals

    A teammate fixed a bug inside a running container and then ran docker commit to publish the result as app:hotfix. Why is this a poor way to ship images?

    • A

      Committed images can only run on the host that created them, so they can't ship

    • B

      There's no Dockerfile to rebuild or review it, and it may hold leftover secrets

    • C

      Committed images don't get a digest, so they can't be pinned

    • D

      docker commit deletes the container's writable layer

    Show the answer and explanation

    Answer: B

    A committed image freezes the container's current state: shell history, caches, temporary credentials and whatever else was changed by hand. Without a Dockerfile and CI build it can't be reproduced, reviewed or patched systematically. Put the fix in the Dockerfile and rebuild.

    Why the other options are wrong

    • A. Committed images can be pushed and run anywhere, which is part of the risk.

    • C. A committed image has a config and manifest digest like any other.

    • D. Commit copies the writable layer into a new image; the container is untouched.

  5. Question 5Running Containers

    A container keeps dying with exit code 137. Which command tells you directly whether the kernel's out-of-memory killer was responsible?

    • A

      docker inspect -f '{{.State.OOMKilled}}' app

    • B

      docker logs --tail 1 app, to read the app's last message before it died

    • C

      docker stats --no-stream app

    • D

      docker ps -a --filter status=dead

    Show the answer and explanation

    Answer: A

    137 only says the process got SIGKILL. docker inspect exposes State.OOMKilled, which is true when the kernel OOM killer ended the process for exceeding its memory limit. If it's false, look at other causes, such as docker kill, a stop timeout, or an orchestrator.

    Why the other options are wrong

    • B. The OOM killer sends SIGKILL; the app gets no chance to log anything.

    • C. It shows current usage, not why the last run ended.

    • D. dead is a different state, for containers Docker failed to remove.

  6. Question 6Building Images

    A Dockerfile runs COPY . . and then RUN npm ci && npm run build. The team says builds are slow even for one-line code changes. What is the root cause?

    • A

      npm ci always ignores existing packages and reinstalls from scratch

    • B

      Any source edit changes the COPY . . checksum, so the install below it reruns too

    • C

      Combining two commands in one RUN disables layer caching for that step

    • D

      The build script edits package.json, so the next build starts with a changed manifest

    Show the answer and explanation

    Answer: B

    Once COPY . . misses the cache, every later instruction runs again. Putting dependency installation after a copy of the whole source ties it to every code change. Copy the manifests, install, then copy the source, or use a cache mount so reinstalls are fast.

    Why the other options are wrong

    • A. That is true of npm ci, but a cache hit would skip the step completely.

    • C. A combined RUN is cached like any other; the problem is its position.

    • D. A build script changing package.json is unusual and is not the issue described.

  7. Question 7Production and Ecosystem

    You run docker compose -f deploy/compose.yaml -f overrides/dev.yaml up from the repository root. overrides/dev.yaml contains build: ./api. Which folder does Compose use as the build context?

    • A

      overrides/api, relative to the file that declares it

    • B

      deploy/api, relative to the first Compose file's directory

    • C

      ./api at the repository root, relative to where you ran the command

    • D

      Compose refuses relative paths in override files

    Show the answer and explanation

    Answer: B

    When you merge several files with -f, Compose resolves every relative path against the project directory. That is the directory of the first file, unless you set --project-directory. Override files can be fragments, so tracking a separate base per fragment would be confusing. Write all paths relative to the base file, and check the result with docker compose config.

    Why the other options are wrong

    • A. Merged files don't resolve paths relative to themselves; they all use one base.

    • C. The current directory only applies when no project directory is derived from a file.

    • D. Relative paths are allowed; they just resolve against the base file's directory.

  8. Question 8Container Fundamentals

    On Docker Desktop for Mac, npm install in a container is several times slower when /app is a bind mount of the macOS project folder than when node_modules is in a named volume. Why?

    • A

      Bind mounts disable the overlay2 page cache inside every container

    • B

      Bind mounts cross the VM boundary; volumes live on the VM's disk

    • C

      macOS encrypts every file that a Linux container writes to a bind mount

    • D

      Named volumes are held in RAM, while bind mounts must write to the SSD

    Show the answer and explanation

    Answer: B

    Docker Desktop runs containers in a Linux VM. A bind mount of a macOS folder is served into that VM through a file-sharing layer (virtiofs on recent versions), so metadata-heavy workloads with thousands of small files pay a cross-VM cost per operation. A named volume lives on the VM's own disk and runs at native Linux speed. That's why a common pattern keeps the source bind-mounted and node_modules in a volume.

    Why the other options are wrong

    • A. Bind mounts don't use overlay2 at all; the slowdown comes from file sharing.

    • C. Docker adds no encryption layer to bind-mounted writes.

    • D. Named volumes live on the VM's virtual disk, not in memory.

  9. Question 9Running Containers

    docker cp can copy files out of a container that has already stopped.

    • A

      True

    • B

      False

    Show the answer and explanation

    Answer: A

    docker cp works with running and stopped containers alike, because the writable layer and the mounted volumes persist until the container is removed.

    Why the other options are wrong

    • B. It works on stopped containers, which is handy for grabbing logs or crash dumps after a failure.

  10. Question 10Building Images

    The package name below is misspelled, so apt-get install fails. What happens to the build?

    # syntax=docker/dockerfile:1
FROM debian
RUN <<EOF
apt-get update
apt-get install -y curlx
echo "done"
EOF
    • A

      It fails, because each heredoc line runs as a separate RUN step

    • B

      It succeeds: the script runs in the default shell without set -e, and echo exits 0

    • C

      It fails, because BuildKit always runs heredoc scripts with set -euo pipefail added

    • D

      It succeeds, but only because the legacy builder skips heredoc steps

    Show the answer and explanation

    Answer: B

    A heredoc that is the whole command is run as one script in the default shell. A plain shell script continues after a failing command, and its exit status is that of the last command (echo), so the step passes. Start the script with set -e, as in the docs example, or chain commands with &&.

    Why the other options are wrong

    • A. The heredoc is one script run by one RUN step.

    • C. No error options are added automatically.

    • D. Heredocs are a BuildKit feature and do run.

Practise all 450 DOCKER questions

Start with the free 15-question diagnostic. It shows where to focus, and your results carry over if you sign up.

Go to DOCKER