DevOpsNovember 4, 202624 min read

Top Docker Interview Questions & Answers (2026)

17 questions DevOps Engineer (Docker-focused) interviewers actually ask, with the strong answer, the weak one, and the follow-up that comes next.

  • DevOps EngineerRole
  • $100K-$140KTypical US pay
  • 3-5 roundsInterview loop
  • Nice to haveCert in hiring
  • OftenHands-on test
Docker interview questions and answers - interviewer and candidate speech bubbles

Table of Contents

Docker questions come up in interviews for DevOps, platform, build and release, and backend roles at almost any company that ships software in containers. Even teams that run Kubernetes in production still build and test with Docker images, so interviewers expect you to understand images, layers, networking, storage and container security at a practical level, not just to have typed docker run.

In 2026 most Docker-focused interviews mix concept questions with a hands-on piece: fix a slow or bloated Dockerfile, debug a Compose stack that will not start, or explain how you would harden an image for production. The Docker Certified Associate is run by Mirantis, which took over Docker Enterprise in 2019, and its blueprint still leans on Swarm and Mirantis enterprise products. It shows you studied the platform properly, but hiring decisions turn on what you can build and debug.

What the DevOps Engineer (Docker-focused) interview loop looks like

Most DevOps Engineer (Docker-focused) hiring runs 4 rounds. Each one is testing something different, so prepare for each separately.

1
Recruiter screenRecruiter or HR · 20-30 minPay range, notice period, the tools in your CV and whether you have run containers in productionTip: Be clear about where containers ran: local dev only, CI, Swarm, or Kubernetes. That one detail sets the level of the rest of the loop.
2
Technical screenDevOps or platform engineer · 45-60 minImages, layers, caching, volumes, networking, Compose and container security fundamentalsTip: Tie every concept to a real problem you hit, such as a slow build or a container that could not reach its database. Stories prove depth.
3
Hands-on exerciseTwo engineers from the team · 60-90 minLive or take-home: writing or fixing a Dockerfile and Compose file, debugging a failing containerTip: Keep it simple and reproducible. Comment why each Dockerfile line is there, and show the image size and build time before and after.
4
Hiring manager and teamEngineering manager plus a developer · 45 minCollaboration with developers, incident handling, ownership of pipelines and how you drive adoptionTip: Show you can make containers easier for developers, not just correct. Templates, docs and fast feedback loops are good examples.

The 17 questions, with answers

Each card shows the question as it is usually asked, what the interviewer is really checking, a strong answer, the weak answer they hear most often, and the follow-up that comes next. Say the strong answers in your own words — a memorised script sounds memorised.

  • Basic · 4
  • Core · 5
  • Advanced · 3
  • Scenario · 3
  • Behavioural · 2
Basic · 4Warm-up questions. Fluff these and the rest of the interview is uphill.
Q01BasicImage Creation, Management, and Registry
Interviewer

In your own words, what is the difference between an image and a container?

What they are testing: A precise mental model of layers, the writable layer and isolation, not a one-liner

Strong answer

An image is a read-only template: a stack of filesystem layers plus metadata like the default command, environment variables and exposed ports. It is built once and identified by a digest, so it is the thing I version and push to a registry. A container is a running instance of that image. The runtime adds a thin writable layer on top and starts the process inside Linux namespaces and cgroups, so it has its own view of processes, network and filesystem, with resource limits. Anything written into that writable layer disappears when the container is removed, which is why data belongs in volumes. Many containers can share the same image layers on disk.

Weak answerSays a container is a lightweight VM, which hides the fact that containers share the host kernel and leads to wrong security assumptions.
Next they will askIf containers share the host kernel, what does that mean for running a container built for a different CPU architecture or OS?
Q02BasicImage Creation, Management, and Registry
Interviewer

How do image layers and the build cache work, and how do you order a Dockerfile to keep builds fast?

What they are testing: Whether you understand cache invalidation and can apply it to real Dockerfiles

Strong answer

Each instruction that changes the filesystem, mainly RUN, COPY and ADD, produces a layer. When building, Docker reuses a cached layer if the instruction and its inputs are unchanged; for COPY that means the content of the copied files. Once one layer is invalidated, every layer after it is rebuilt. So I put things that change rarely first and things that change often last. In a Node or Python app I copy only the dependency manifest and lock file, install dependencies, then copy the source code. A code change then skips the slow install step. I also use a .dockerignore so node_modules, .git and local env files never enter the build context and do not bust the cache.

Weak answerCopies the whole project first and installs dependencies after, so every one-line code change reinstalls everything, and they cannot explain why.
Next they will askYour CI runners are ephemeral, so the local cache is always empty. How do you still get cache hits?
Q03BasicStorage and Volumes
Interviewer

When would you use a named volume, a bind mount or a tmpfs mount?

What they are testing: Whether you choose storage by lifecycle, portability and security, not habit

Strong answer

A named volume is managed by Docker, lives outside the container's writable layer and survives container removal, so it is my default for persistent data like a database directory. It also works the same on every host because Docker owns the path. A bind mount maps a specific host path into the container. I use it in local development to mount source code for live reload, or to give a container a specific host config file, but it ties the container to that host's layout and permissions. A tmpfs mount lives in memory and is never written to disk, which is useful for scratch data or sensitive temporary files. In production I avoid bind-mounting broad host paths, and never the Docker socket without a strong reason.

Weak answerUses bind mounts everywhere because they are familiar, then hits permission errors and host-specific paths when the app moves servers.
Next they will askA container running as a non-root user cannot write to its bind mount. Why, and how do you fix it properly?
Q04BasicImage Creation, Management, and Registry
Interviewer

What is the difference between CMD and ENTRYPOINT, and why does the exec form matter?

What they are testing: Understanding of PID 1, signal handling and graceful shutdown

Strong answer

ENTRYPOINT sets the executable the container runs; CMD supplies default arguments, or the whole command if there is no ENTRYPOINT. Arguments after the image name in docker run replace CMD, while replacing ENTRYPOINT needs the entrypoint flag. The exec form, written as a JSON array, runs my process directly as PID 1. The shell form wraps it in /bin/sh -c, so the shell is PID 1 and usually does not pass SIGTERM on. Then docker stop sends SIGTERM, nothing reaches the app, and after the grace period, ten seconds by default, it gets SIGKILL with no clean shutdown. So I use exec form, and if the app does not reap child processes I add an init with the init flag.

Weak answerSays they are basically the same and picks one at random, unaware of why their containers always take ten seconds to stop.
Next they will askYour entrypoint is a shell script that sets up config and then starts the app. How do you make sure the app still receives signals?
Core · 5The day-to-day knowledge the job runs on. Most of the score comes from here.
Q05CoreImage Creation, Management, and Registry
Interviewer

Walk me through a multi-stage build. Why would you use one?

What they are testing: Practical image slimming and attack-surface reduction

Strong answer

A multi-stage build has several FROM lines in one Dockerfile. The first stage, named for example build with FROM something AS build, has the full toolchain: compilers, package managers, test tools. It builds the artifact. The final stage starts from a small runtime image, like a slim, distroless or even scratch base for a static Go binary, and uses COPY with the from flag to pull in only the built artifact. The final image never contains the compiler, source code or build secrets, so it is smaller, faster to pull and has far fewer packages to patch. With BuildKit, stages the final target does not depend on are skipped, and I can target a test stage in CI.

Weak answerKnows the syntax but still copies the whole build stage across, so the final image is barely smaller and still contains the toolchain.
Next they will askYou moved to distroless and now there is no shell to debug with. How do you troubleshoot a running container?
Q06CoreNetworking
Interviewer

Explain Docker's network drivers. How do two containers on the same host find each other?

What they are testing: Default bridge versus user-defined bridge, DNS, and when host or overlay is appropriate

Strong answer

The bridge driver is the default: containers get a private IP on a host bridge and reach the outside through NAT, and I publish ports with the p flag to accept inbound traffic. The important detail is that the default bridge network has no name resolution, so containers can only reach each other by IP. On a user-defined bridge, Docker's embedded DNS lets containers resolve each other by name or alias, which is what Compose sets up automatically. Host networking skips isolation and uses the host's stack directly, useful for some performance or monitoring cases. None gives no network. Overlay spans multiple hosts in Swarm, and macvlan or ipvlan put containers directly on the physical network.

Weak answerLinks containers with the legacy link flag or hardcodes container IPs, which break as soon as a container is recreated.
Next they will askWhat is the difference between EXPOSE in a Dockerfile and publishing a port with the p flag?
Q07CoreOrchestration
Interviewer

How do you use Docker Compose for local development, and what would you change before using it anywhere near production?

What they are testing: Practical Compose skills and awareness of its limits

Strong answer

Compose describes the whole stack in one file: services, networks, volumes, environment and ports, and I run it with docker compose up using the v2 plugin. For local dev I bind-mount the source for live reload, use an env file for settings, and add healthchecks so depends_on with condition service_healthy actually waits for the database instead of just its container starting. Profiles let me keep optional services like a mail catcher out of the default run. Before anything production-like I remove the source bind mounts, pin image tags or digests, set restart policies and resource limits, move secrets out of env files, and configure log rotation. For real multi-host production I would use Swarm or Kubernetes rather than plain Compose.

Weak answerThinks depends_on alone waits until the database is ready, so the app crashes on first start and they add sleep commands to fix it.
Next they will askDevelopers say the Compose stack takes five minutes to rebuild after every change. Where do you start?
Q08CoreSecurity
Interviewer

How would you harden a container image and its runtime settings for production?

What they are testing: Least privilege applied at build time and run time, plus supply-chain checks

Strong answer

At build time: a minimal base image, a multi-stage build so tools are not shipped, a USER instruction so the process does not run as root, and pinning the base image by digest. I scan images in CI with a tool like Docker Scout or Trivy and fail the build on fixable critical issues. At run time: drop all Linux capabilities and add back only what is needed, set no-new-privileges, use a read-only root filesystem with tmpfs for scratch, set memory and CPU limits, and never run privileged or mount the Docker socket into an app container. On the host, rootless mode removes root from the daemon itself. For signing, Docker Content Trust has been retired, so I would use Sigstore cosign or Notation.

Weak answerSays they scan images, but everything still runs as root with the default capabilities and the Docker socket mounted into a CI container.
Next they will askWhy is mounting the Docker socket into a container effectively giving it root on the host?
Q09CoreSecurity
Interviewer

How do you keep secrets like API keys and registry credentials out of your images?

What they are testing: Knowing that ARG and ENV leak, and the right build-time and run-time alternatives

Strong answer

First rule: secrets never go in ARG or ENV, and never get copied into a layer, because ENV is baked into the image config and build arguments used in a step show up in the image history. Deleting a file in a later layer does not remove it from the earlier one either. For build-time needs, such as a private package token, I use BuildKit secret mounts: pass it with the secret flag on docker build and read it in a RUN step with mount type secret, so it is only available during that step. At run time, the orchestrator injects secrets, for example Swarm or Kubernetes secrets mounted as files. And .dockerignore keeps local .env files out of the build context.

Weak answerPasses the token as a build argument and deletes it in a later RUN step, believing that removes it from the image.
Next they will askA secret was already pushed in an image layer to a public registry. What do you do, in what order?
Advanced · 3Depth checks. They separate the cert holder from the practitioner.
Q10AdvancedOrchestration
Interviewer

Swarm or Kubernetes: when would you still choose Docker Swarm in 2026?

What they are testing: Balanced judgement about orchestration trade-offs rather than hype

Strong answer

Kubernetes is the default for most new platforms because of its ecosystem, managed offerings and hiring pool, and that is what I would pick for a large multi-team platform. Swarm still makes sense for a small team running a modest number of services on a few hosts that wants orchestration without running a Kubernetes control plane. Swarm mode is built into Docker Engine, uses Compose-format stack files, gives you overlay networking, rolling updates, encrypted secrets and Raft-based managers, ideally three or five so a quorum survives a failure. The trade-offs are a much smaller ecosystem, fewer managed options, and fewer people who know it. I would make the decision on team size, existing skills and how much the platform must grow.

Weak answerSays Swarm is dead and nobody uses it, or the reverse, without any reasoning about team size, skills or operational cost.
Next they will askWhy do Swarm and Raft-based systems recommend an odd number of manager nodes?
Q11AdvancedImage Creation, Management, and Registry
Interviewer

Your CI builds take twelve minutes and images are 1.5 GB. How do you bring both down?

What they are testing: Concrete build optimisation with BuildKit, cache backends and image design

Strong answer

I would measure first: docker history shows which layers are heavy, and the build output shows which steps miss the cache. For size: a multi-stage build with a slim or distroless final stage, cleaning package manager caches in the same RUN that installs, and a tight .dockerignore. For speed: reorder so dependencies install before source is copied, and because CI runners are usually ephemeral, export the build cache to the registry with buildx, using cache-to and cache-from, so the next run starts warm. BuildKit cache mounts keep package manager downloads between builds without adding them to the image. Then I would compare before and after numbers, so the change is visible to the team.

Weak answerSuggests a bigger CI runner or switching base image to Alpine without measuring which layers or steps are actually slow.
Next they will askAfter switching to Alpine, a Python service builds much slower and behaves differently. Why might that be?
Q12AdvancedSecurity
Interviewer

What is the difference between rootless mode, a non-root USER in the image, and user namespace remapping?

What they are testing: Precise understanding of which layer each control protects

Strong answer

A non-root USER in the image means the process inside the container runs as an unprivileged user. That helps, but the daemon is still root, and if the container is misconfigured, for example privileged, root on the host is close. User namespace remapping with userns-remap maps root inside containers to an unprivileged range of UIDs on the host, while the daemon itself still runs as root. Rootless mode goes further: the daemon and the containers both run as a normal user inside a user namespace, so a daemon or runtime bug does not hand out host root. Rootless needs subordinate UID and GID ranges set up and has some networking and feature limitations. In practice I layer them: non-root images everywhere, and rootless where the host allows it.

Weak answerThinks adding USER to the Dockerfile means the whole Docker setup is rootless and secure, mixing up the container process and the daemon.
Next they will askA developer asks for the Docker socket inside their CI job to build images. What safer options would you offer?
Scenario · 3Something is broken or ambiguous. They want your reasoning out loud, in order.
Q13ScenarioInstallation and Configuration
Interviewer

A container exits immediately after docker run, with no obvious error. How do you debug it?

What they are testing: Systematic use of logs, exit codes and inspect, plus the foreground-process concept

Strong answer

First docker ps with the a flag to see the exit code and status, then docker logs on the container ID to read whatever it printed. docker inspect gives the exact exit code, the OOMKilled flag, and the command and entrypoint it actually ran. A common cause is that the main process is not a long-running foreground process, for example a service that daemonises itself or a script that finishes, and the container stops when PID 1 exits. Other causes are a missing environment variable, a wrong path in CMD, or a binary built for another architecture, which shows as exec format error. To look around, I run the image with the entrypoint overridden to sh and test the start command by hand.

Weak answerAdds a sleep infinity or tail command to keep it running, which hides the real failure and ships a container that runs nothing useful.
Next they will askdocker inspect shows exit code 137. What are the likely causes and how do you tell them apart?
Q14ScenarioStorage and Volumes
Interviewer

The disk on your build server is full and Docker is the cause. What do you do now, and what do you change so it does not happen again?

What they are testing: Safe cleanup without destroying data, and a lasting fix

Strong answer

Right now: docker system df shows how much space images, containers, volumes and build cache use. I clear the safe things first: stopped containers, dangling images and old build cache with docker builder prune, then unused images. I am careful with volumes, because pruning those can delete data a stopped container still needs, so I check what they belong to first. I also check container logs, because the default json-file driver does not rotate logs, and one chatty container can fill a disk. For the lasting fix I set log rotation with max-size and max-file in daemon.json or switch to the local driver, schedule cache pruning with a retention filter, and alert on disk usage before it hits the limit.

Weak answerRuns docker system prune with the all and volumes flags straight away on a shared server, wiping data and caches other teams relied on.
Next they will askHow would you set limits so one team's builds cannot exhaust the shared build server again?
Q15ScenarioNetworking
Interviewer

In a Compose stack, the app logs connection refused when it tries to reach the database. Both containers are up. What is going on?

What they are testing: Container networking basics under pressure: localhost, service names, readiness, binding

Strong answer

I check the usual suspects in order. One, the app is connecting to localhost, which inside a container means the container itself, not the database. It should use the Compose service name, like db, which resolves through the project network. Two, timing: the database container is up but not accepting connections yet, so I add a healthcheck and depends_on with condition service_healthy, and make the app retry. Three, the database is listening only on 127.0.0.1 inside its container, so it must bind to all interfaces. Four, a port mix-up: containers on the same network use the container port, not the host-published port. I confirm by running a shell in the app container and testing the connection directly.

Weak answerPublishes the database port to the host and points the app at the host IP, which works by accident and exposes the database.
Next they will askIt works in Compose but fails in CI, where the same tests run in a pipeline service container. What differs?
Behavioural · 2How you work with people. Templates below - fill them with your own story.
Q16BehaviouralSoft skills
Interviewer

Tell me about a time you introduced containers, or a container practice, to a team that was not using it.

What they are testing: Influence, pragmatism and whether adoption actually stuck

Strong answer (template)

This is a template; fill it with your own story. Situation: what the team was doing before, for example setting up local environments by hand with a long wiki page. Task: what you set out to change and why it mattered to them, not just to you. Action: how you started small, maybe one service with a Compose file and a Makefile, how you got feedback from developers, documented it, and handled objections like slow builds on laptops. Result: something measurable, such as new starters running the stack on day one instead of day three, or fewer works-on-my-machine bugs. Finish with what you would do differently, because that shows reflection rather than salesmanship.

Weak answerDescribes forcing a big migration on everyone at once, with no mention of developer feedback or measurable benefit.
Next they will askWhich developer objection was hardest to answer, and did you change your approach because of it?
Q17BehaviouralSoft skills
Interviewer

Tell me about a time a build or deployment you owned broke something. How did you handle it?

What they are testing: Ownership, honest communication and prevention

Strong answer (template)

This is a template for your own story. Situation: the change and the impact, for example a base image update that broke TLS for a service in staging or production. Task: your responsibility, since you owned the pipeline or the change. Action: show that you raised it quickly instead of quietly fixing it, rolled back first to restore service, then found the root cause with evidence, such as a missing CA bundle in the new base. Result: the time to recover and the impact, stated plainly. Then the prevention you added, for example pinning base images by digest, a smoke test in the pipeline, or a staged rollout. Interviewers want ownership without excuses and a process that improved.

Weak answerBlames the upstream image or another team, or tells a story with no rollback, no communication and nothing changed afterwards.
Next they will askHow do you balance keeping base images patched against the risk that updates break things?

Get the theory airtight before the interview

Interviewers build follow-ups on the fundamentals. The Docker DCA app has exam-style Docker DCA questions with an explanation for every option, so the basics stay automatic when the questions get harder.

App StoreGoogle PlayFree Docker DCA practice test

The practical task

Expect some version of this. Companies vary the details, not the shape.

PRACTICAL TASKFix and harden a Dockerfile and Compose stackTake-home, 2-3 h, or live, 60 min

You get a small web API with a Dockerfile and a docker-compose.yml for the API plus PostgreSQL. The image is over 1 GB, builds slowly on every code change, runs as root, and the API fails to connect to the database on first start. Make the image smaller and faster to build, harden it, fix the startup problem, and write a short README explaining each change.

  1. Measure first: record image size, build time and docker history output before changing anything
  2. Rewrite as a multi-stage build, copy dependency files before source, and add a tight .dockerignore
  3. Run as a non-root user, use exec-form CMD, pin the base image, and keep secrets out of ARG and ENV
  4. Add a database healthcheck and depends_on with condition service_healthy, plus app-side retries
  5. Use the service name for the database host and stop publishing the database port to the host
  6. Show before and after numbers and note the trade-offs you chose in the README

Hire vs no-hire:Hires measure before and after, explain why each line exists, fix the startup race properly instead of adding sleep, and leave a stack another developer can run first time from the README.

Questions to ask them

"Do you have any questions for us?" is still being scored. Four that land well for a DevOps Engineer (Docker-focused) role:

Where do your containers run in production: Kubernetes, Swarm, ECS, or something else?Shows you know Docker skills are applied differently per platform and helps you pitch your answers.
How long does a typical CI build take, and who owns the Dockerfiles: platform or app teams?Points at real pain you can help with and tells you how much you will be shaping standards.
How do you handle base image updates and vulnerability findings today?Signals security awareness and reveals whether patching is planned work or constant firefighting.
What would a great first ninety days look like for this role?Shows you think about impact and gives you the hiring manager's real priorities.

Mistakes that sink candidates

MistakeDescribing containers as lightweight virtual machinesInsteadExplain namespaces, cgroups and the shared kernel. It changes how you reason about security and compatibility.
MistakeFixing startup races with sleep commandsInsteadUse healthchecks, depends_on with condition service_healthy, and retry logic in the app.
MistakeRunning everything as root with the Docker socket mountedInsteadShow a non-root USER, dropped capabilities, read-only filesystem and safer build options like rootless BuildKit.
MistakeOnly knowing Docker from tutorials, with no production storyInsteadPrepare one real example per area: a build you sped up, an image you shrank, an incident you debugged.
MistakeDismissing Kubernetes or Swarm without reasonsInsteadTalk about trade-offs: team size, ecosystem, managed options and operational cost.

What the Docker Certified Associate (DCA) does and does not prove

What the Docker Certified Associate (DCA) gets you

The DCA is still offered by Mirantis, but it rarely appears as a requirement in job postings, so treat it as a supporting signal rather than a filter-passer. It helps most for junior candidates and for roles at companies that run Mirantis Kubernetes Engine or Swarm. Paired with a CKA or a cloud associate cert, it rounds out a DevOps profile.

What it does not prove

The blueprint still leans on Swarm and Mirantis enterprise products and has not caught up with everything in modern Docker workflows, such as BuildKit cache exports, supply-chain signing after Docker Content Trust was retired, or CI-heavy build pipelines. It also does not test production judgement: debugging under pressure, image governance across teams, or choosing an orchestrator. Interviews test these directly.

Pay:Range anchored on the BLS May 2025 median for network and computer systems administrators ($99,130) and Indeed's October 2026 US average for DevOps engineers ($135,209). Cloud and Kubernetes depth, on-call duties, location and seniority move it most.

Still sitting the Docker DCA?

Pass it first time and walk into the interview with the credential on your CV. The Docker DCA app has exam-style Docker DCA questions with an explanation for every option.

App StoreGoogle PlayFree Docker DCA practice test

FAQ

Do Docker interviews still matter if the company runs Kubernetes?

Yes. Kubernetes runs container images, and those images are still usually built with Docker or BuildKit. Interviewers check that you can write efficient, secure Dockerfiles and debug container behaviour, because bad images cause slow deploys, security findings and confusing failures no matter which orchestrator runs them. Expect Docker questions early in the loop, then Kubernetes questions on top.

Is the Docker Certified Associate still worth taking in 2026?

It is still offered by Mirantis, and studying for it builds solid fundamentals. As a hiring signal it is weaker than the CKA or a cloud certification, and few postings ask for it by name. If your budget only allows one cert, a Kubernetes or cloud cert usually opens more doors, with Docker skills shown through projects.

What hands-on exercise should I expect?

Most often you will fix or write a Dockerfile and a Compose file: shrink an image, speed up a build, run as non-root, and make services start reliably. Some companies ask you to debug a container that exits or cannot reach a database. Practise narrating what you check and why, and always show before and after numbers.

How deep should I go on Linux internals for a Docker interview?

Know what namespaces and cgroups do, how signals reach PID 1, how file permissions interact with users in containers, and basic networking like NAT and DNS. You do not need kernel development knowledge, but explaining why a container behaves a certain way earns far more credit than memorised commands.

What portfolio project helps most?

A small multi-service app with a multi-stage Dockerfile, a Compose file with healthchecks, a CI pipeline that builds with a registry cache, scans the image and pushes on merge, and a README with image size and build time before and after. It covers most of what interviewers ask and gives you real stories to tell.

Sources

Figures on this page come from Mirantis and the other primary sources below:

Checked November 4, 2026. Fees, outlines and eligibility rules change — confirm with Mirantis before you book.