Docker interview questions and answers

1. Docker image versus container

What is the difference between a Docker image and a Docker container?

1. A.An image is a read-only template; a container is a running or stopped instance created from it
2. B.An image is a running process; a container is the file stored on disk
3. C.They are two names for the same thing
4. D.A container is a lightweight virtual machine with its own guest kernel; an image is the shell script that boots it

2. Container exits right after start

You run docker run -d myimage and the container shows "Exited (0)" a second later. What is the most likely reason?

1. A.The CMD or ENTRYPOINT process finished, and a container stops when its main process ends.
2. B.Detached mode (-d) stops containers after one second unless a TTY is attached with -t and -i.
3. C.The image is too large, so the Docker daemon stops it to protect host memory.
4. D.Exit code 0 means Docker could not find the image locally or in the registry.

3. ENV password in a Dockerfile

A Dockerfile contains `ENV DB_PASSWORD=Sup3r$ecret`. Why is this a problem even if the image is private?

1. A.ENV values are sent to Docker Hub analytics
2. B.Anyone who can pull the image can read it from the image config
3. C.The password is shown on the container's web page
4. D.ENV makes the image fail security signing

4. Keeping database data across restarts

You run Postgres in Docker for local development. Every time you remove and recreate the container, the data is gone. What is the standard fix?

1. A.Commit the running container to a new image each night
2. B.Add a HEALTHCHECK to the Dockerfile
3. C.Mount a named volume at the Postgres data directory
4. D.Run the container with --restart always

5. Using :latest in a Deployment

Why is `image: myapp:latest` a poor choice in a production Deployment?

1. A.You cannot tell which build runs, and nodes may run different builds
2. B.The latest tag is blocked by Kubernetes in production namespaces
3. C.Images tagged latest cannot be pulled from private registries
4. D.The latest tag disables rolling updates for the Deployment

6. Docker restart policy on a VM

You run a small service with plain Docker on a VM. You want it to start again after a crash or a VM reboot, but not if you stopped it on purpose. Which restart policy fits?

1. A.--restart unless-stopped
2. B.--restart no
3. C.--restart on-failure:0
4. D.--restart never

7. Local app with a database and cache

A developer wants to start the API, Postgres and Redis together on a laptop with one command and one file in the repo. What is the usual tool?

1. A.Docker Compose with a compose.yaml file
2. B.A Kubernetes CronJob for each service
3. C.A Dockerfile with three FROM lines
4. D.A Helm chart installed into Docker Desktop

8. Why put a model in a container

Why do teams usually package a model service in a Docker image?

1. A.Docker makes the model more accurate
2. B.The image bundles code, libraries and runtime so it runs the same way on a laptop, CI and production
3. C.Docker images cannot be deployed to the cloud otherwise
4. D.Containers remove the need for monitoring

9. Same code, different outputs after rebuild

After rebuilding the serving container, outputs changed slightly with no code change. The Dockerfile uses pip install torch transformers with no versions. What should you do?

1. A.Rebuild daily so versions stay fresh
2. B.Pin exact library versions and the image base tag
3. C.Remove the Dockerfile and install by hand
4. D.Run the model on CPU to avoid changes

10. A task that needs its own libraries

One task needs a library version that clashes with what is installed on the Airflow workers. Which operator avoids the clash by running the task in its own container image?

1. A.KubernetesPodOperator
2. B.BashOperator
3. C.PythonOperator
4. D.ShortCircuitOperator

11. Why use multi-stage builds

What is the main benefit of this multi-stage Dockerfile?

FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app ./cmd/app

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/app /app
USER nonroot
ENTRYPOINT ["/app"]

1. A.It makes the Go compiler run faster.
2. B.It lets the container run two processes at the same time.
3. C.It allows the image to be built without a Dockerfile.
4. D.The final image contains only the compiled binary, not the compiler or source, so it is much smaller and has a smaller attack surface.

12. Choosing an image tag in CI

Your pipeline pushes images for every merge to main. Which tag makes it easiest to know exactly which code is running in production?

1. A.The word stable, moved on every release
2. B.The build date, such as api:2026-10-16
3. C.The branch name, such as api:main
4. D.The Git commit SHA, such as api:3f9c2ab

13. Mounting the Docker socket

A CI build container mounts /var/run/docker.sock from the host so it can run docker build. What does this give to any code running in the job?

1. A.Read-only access to images on the host
2. B.Access only to containers the job started
3. C.Nothing, as the socket is sandboxed by default
4. D.Root-level control of the host through the Docker daemon

14. Private registry token during build

`npm ci` inside a Dockerfile needs a private registry token. Passing it with ARG leaves it in the image history. What is the safer method?

1. A.COPY the .npmrc file and delete it in the next step
2. B.Hard-code the token but use a multi-stage build
3. C.RUN --mount=type=secret with docker build --secret
4. D.Set the token with ENV and unset it at the end

15. Stale packages from layer cache

A Dockerfile has `RUN apt-get update` on one line and `RUN apt-get install -y curl` on the next. Weeks later a new package is added to the install line and the build fails with 404 errors from the mirror. Why?

1. A.The cached update layer has an old package index
2. B.apt-get cannot run twice in one Dockerfile
3. C.The install line must come before the update line
4. D.Docker deletes the package index after every RUN

16. COPY or ADD in a Dockerfile

Why do Docker best practices prefer COPY over ADD for copying local files into an image?

1. A.COPY makes smaller layers because it compresses files
2. B.ADD cannot copy directories, only single files
3. C.ADD also unpacks archives and fetches URLs, which can surprise you
4. D.COPY runs as root while ADD keeps file ownership

17. Slow Python builds on Alpine

You switched a Python image from python:3.12-slim to python:3.12-alpine to save space. Now pip install takes 15 minutes and needs gcc. Why?

1. A.Alpine images block network access while pip install runs
2. B.Alpine uses musl, so glibc wheels do not fit and pip compiles
3. C.pip is not supported on Alpine, so it runs under emulation
4. D.Alpine disables the pip download cache for all packages

18. Build ARG missing at runtime

A Dockerfile has `ARG APP_VERSION` and is built with `--build-arg APP_VERSION=2.3.1`. The app reads APP_VERSION from its environment when it runs and finds it empty. Why?

1. A.ARG exists only during the build; use ENV to keep it in the image
2. B.Build args are dropped when the image is pushed to a registry
3. C.ARG values must be quoted to survive the build
4. D.The app must read build args from /proc/args instead

19. Dockerfile HEALTHCHECK on Kubernetes

An image has a HEALTHCHECK instruction that marks it unhealthy when /health fails. On Kubernetes, the container stays Running even while it is unhealthy. Why?

1. A.HEALTHCHECK runs only when the image runs as root
2. B.Kubernetes reads HEALTHCHECK but only every 10 minutes
3. C.Kubernetes ignores HEALTHCHECK; it uses Pod probes instead
4. D.The probe must use port 80 to be honoured

20. Deleted secret still in the image

A Dockerfile copies .env with a DB password in one step and deletes it in a later RUN step. The image was pushed to a public registry. Is the password exposed?

1. A.No; the later delete removes it from every layer of the image
2. B.No; Docker encrypts all files inside public images by default
3. C.Yes; earlier layers still hold the file, so rotate the password now
4. D.Only if someone runs the container with root privileges

21. Unstyled site in Docker

A Docker image built with output: 'standalone' starts, but CSS and JS return 404. What was likely missed?

1. A.Running npm install inside the final image
2. B.Setting NODE_ENV to development in Docker
3. C.Copying .next/static and public next to server.js
4. D.Adding 'use client' to the root layout file

22. Container ignores SIGTERM

Pods with this image always take the full 30-second grace period to stop and are then SIGKILLed, dropping requests. What is the most likely cause?

FROM python:3.12-slim
COPY app.py .
CMD python app.py

1. A.Shell form CMD runs /bin/sh -c as PID 1, which does not forward SIGTERM to the Python process; use exec form CMD ["python", "app.py"] and handle SIGTERM in the app.
2. B.The python:3.12-slim base image blocks all signals by default.
3. C.terminationGracePeriodSeconds must be set to 0 for signals to be delivered.
4. D.Kubernetes sends SIGINT, not SIGTERM, so Python ignores it.

23. Same commit, different build result

Rebuilding last month's commit now fails, though no code changed. The Dockerfile uses FROM node:20 and the build runs `npm install` without a lockfile. What is the root problem?

1. A.The CI runner clock is set to a different time zone
2. B.Docker images expire after 30 days in the registry
3. C.Git commits change their content after a month
4. D.Unpinned inputs: the base image and packages changed since then

24. Docker cache on fresh runners

You moved to ephemeral CI runners, and Docker builds that took 2 minutes now take 12 because every layer is rebuilt. How do you keep layer caching?

1. A.Use docker build --no-cache so builds stay consistent
2. B.Turn the ephemeral runners back into long-lived ones
3. C.Export the BuildKit cache to a registry with --cache-to and reuse it
4. D.Squash the image into one layer before pushing

25. SBOM from source vs from the image

An SBOM generated from your repo lists 120 npm packages. An SBOM generated from the final container image lists 310 components. Which one better shows what runs in production, and why?

1. A.The source SBOM, since images add only harmless files
2. B.The image SBOM, as it includes OS packages and build output
3. C.Both are equal, and the count differs only by format
4. D.Neither, because SBOMs cannot list OS packages

26. Scale-out slowed by image pulls

During a traffic spike, new nodes join quickly but new Pods take about 4 minutes to start because the 7 GB image is pulled first. The app itself starts in 20 seconds. What helps most?

1. A.Raise the readiness probe initialDelaySeconds value
2. B.Shrink the image and pre-pull it or use lazy pulling
3. C.Set imagePullPolicy: Always on the Deployment spec
4. D.Give the Pods a higher PriorityClass than others

27. Container takes 10 seconds to stop

docker stop always waits the full grace period and then kills your container. The app runs as PID 1 via a shell script and has no SIGTERM handler. Why does SIGTERM not stop it?

1. A.Containers block all signals until the grace period ends
2. B.The kernel gives PID 1 no default action for signals it has not handled
3. C.SIGTERM is only delivered to processes with a terminal
4. D.Docker sends SIGTERM to the host, not the container

28. Same tag, different image

Two pods of the same deployment behave differently. Both use image "scorer:latest", but one was pulled before a new push. What prevents this?

1. A.Restarting pods every hour
2. B.Using a larger node
3. C.Setting imagePullPolicy to Never
4. D.Deploying immutable image references by digest (or unique version tags) recorded with the model release

29. Image tag now points elsewhere

Training runs in "trainer:latest". A rerun months later gives different results, though the tag is the same. What makes the environment fixed?

1. A.Use the tag "stable" instead of "latest"
2. B.Rebuild the image before every run
3. C.Reference the image by its sha256 digest
4. D.Store the Dockerfile in a different folder

30. Old run cannot be rebuilt

You must reproduce a model trained 8 months ago. Its Dockerfile used "FROM python:3.10-slim", and that build of the base image is no longer the same. What should the team have done?

1. A.Used the "latest" tag so it was always kept current
2. B.Rebuilt the image weekly from the very same Dockerfile
3. C.Kept only the Dockerfile in Git and never the image
4. D.Pinned the base image digest and mirrored it internally