25 Docker interview questions

Listen for: A strong answer starts by reproducing the exact command or Compose service, checking image tag and build context, then comparing environment variables, mounted files, working directory, user, exposed ports, and startup command. They should use docker logs, docker inspect, docker exec, and minimal changes to isolate one variable at a time.

Red flag: They immediately rebuild everything or change the application code without first comparing container configuration to the local environment.

Listen for: Look for practical prioritization: pin a maintained base image, reduce layers where useful, separate dependency install from source copy for cache reuse, add a non-root user, remove build-only tools from the final image, and use .dockerignore. They should explain trade-offs, not just say “use Alpine” for every workload.

Red flag: They focus only on image size and ignore security, reproducibility, and cache behavior.

Listen for: They should understand that localhost inside a container is the container itself, not the host or another service. Good signals include checking service names on the Compose network, container health, port versus expose, startup ordering versus readiness, logs, network aliases, and whether Postgres is bound to the right interface.

Red flag: They suggest using the host machine’s public IP as the default fix for container-to-container communication.

Listen for: A solid answer mentions excluding node_modules, .git, local build artifacts, secrets, test outputs, caches, and large generated files unless intentionally needed. They should connect this to build speed, cache invalidation, accidental secret leakage, non-reproducible builds, and remote BuildKit builders receiving unnecessary context.

Red flag: They think .dockerignore is only a cosmetic cleanup file and has no effect on security or build performance.

Listen for: They should collect the exact image digest or tag, docker run or Compose command, entrypoint and command, environment differences, CI runner architecture, logs, exit code, working directory, mounted files, permissions, and resource limits. Good candidates check whether CI overrides the command or runs without expected secrets.

Red flag: They assume CI is broken and cannot name specific runtime differences to inspect.

Listen for: They should explain that EXPOSE is image metadata and documentation for intended listening ports, while -p or Compose ports publishes a container port to the host. It matters for host access, local development, test runners, service discovery assumptions, and avoiding accidental exposure of internal-only services.

Red flag: They believe EXPOSE alone makes a service reachable from the host or the internet.

Listen for: Strong answers discuss BuildKit/buildx cache mounts, registry-backed cache, ordering Dockerfile layers for dependency reuse, splitting dependency and source copy steps, .dockerignore, multi-stage builds, pinned base images, and avoiding unnecessary apt updates. They should mention measuring build steps and cache hit rates rather than guessing.

Red flag: They only suggest adding more CPU or using a smaller base image without analyzing cache misses.

Listen for: Listen for buildx with a named builder, platform-specific testing, QEMU versus native builders, avoiding architecture-specific package assumptions, publishing a multi-arch manifest, and pinning base images that support both platforms. They should discuss verifying with docker buildx imagetools inspect and running smoke tests per architecture.

Red flag: They assume a single local docker build automatically creates a correct multi-architecture image.

Listen for: A mature answer separates exploitability from policy. They would inspect affected packages, whether vulnerable code is reachable, fixed base tags, rebuild freshness, distro security status, and compensating controls. They should propose a time-bound remediation path and avoid both panic upgrades and blanket dismissal.

Red flag: They say internal containers do not need patching or scanning.

Listen for: Good candidates distinguish development convenience from production reproducibility. Bind mounts are flexible but host-dependent and permission-prone; named volumes suit durable container-managed data; baked files improve immutable deployments and repeatability. They should mention backup, ownership, SELinux/AppArmor contexts, portability, and how mounts can hide image contents.

Red flag: They recommend bind mounts for all persistent data in every environment.

Listen for: They should discuss running as a non-root user, setting UID/GID deliberately, using COPY --chown, adjusting volume ownership in an entrypoint only when necessary, and documenting local development UID mapping. Stronger answers mention user namespaces, rootless Docker, and avoiding chmod 777 as a shortcut.

Red flag: They solve it by running everything as privileged or recursively chmodding mounted directories to 777.

Listen for: Look for pinned base image digests when appropriate, locked language dependencies, deterministic build arguments, avoiding latest, controlled package repositories, BuildKit provenance/SBOM where useful, and a clear rebuild process. They should understand that reproducibility includes inputs, architecture, build environment, and registry immutability.

Red flag: They claim Docker builds are automatically reproducible because the Dockerfile is committed.

Listen for: A good answer uses a base Compose file plus override files or profiles, with clear environment-specific configuration and minimal duplication. They should avoid leaking production secrets into local config, distinguish build versus image references, use healthchecks for dependencies, and keep CI deterministic.

Red flag: They put every environment difference into one large Compose file with many conditional workarounds.

Listen for: Strong answers define defaults for base images, non-root runtime users, healthchecks where useful, BuildKit syntax, multi-stage structure, labels, SBOM/provenance, .dockerignore, vulnerability handling, and image tagging. They allow exceptions based on runtime requirements, compliance, performance, and supportability, with documented review rather than rigid templates.

Red flag: They propose one universal Dockerfile template for every language and workload.

Listen for: They should discuss immutable tags or registry policies, deploying by digest, signed images with Cosign or Notation where appropriate, CI-controlled promotion, audit trails, retention policy, and separating build tags from release tags. Good answers include detection and rollback, not just prevention.

Red flag: They rely on developers remembering not to push the same tag again.

Listen for: Listen for avoiding raw docker.sock exposure, using rootless BuildKit/buildx, isolated runners, least-privilege credentials, short-lived registry tokens, network restrictions, user namespaces, and ephemeral build environments. They should know docker.sock is effectively host-root access and design workflows around that risk.

Red flag: They mount /var/run/docker.sock into arbitrary build containers and call it secure because the container is non-root.

Listen for: A strong answer separates local developer workflow from production orchestration. They preserve Compose for fast local feedback where it fits, align images, health endpoints, configuration, and graceful shutdown behavior, and avoid pretending Compose maps one-to-one to Kubernetes. They also plan documentation, CI tests, and phased service migration.

Red flag: They insist Docker Compose must be eliminated immediately or that Kubernetes YAML can be generated blindly from Compose.

Listen for: They should mention BuildKit secrets and SSH mounts for build-time access, avoiding ARG/ENV for secrets, checking image history, using runtime secret stores or orchestrator-managed secrets, limiting file permissions, and rotating exposed credentials. Good answers include scanning and incident response for leaked secrets.

Red flag: They pass tokens as build args and assume multi-stage builds always remove the risk.

Listen for: They should inspect docker system df, images, containers, volumes, BuildKit cache, logs, overlay2 usage, and application data before pruning. Strong candidates protect named volumes and running containers, coordinate change windows if needed, adjust log rotation, and fix retention policies rather than running broad prune commands blindly.

Red flag: They immediately run docker system prune -a --volumes on a production host.

Listen for: Good answers include ownership labels, versioning and digest tracking, vulnerability scanning gates, SBOM/provenance artifacts, promotion between environments, signature verification, retention rules, rollback availability, end-of-life handling for base images, and rebuild cadence. They should balance governance with developer usability and automation.

Red flag: They only define naming conventions and ignore patching, promotion, and deprecation.

Listen for: Look for centralized but flexible build standards: BuildKit/buildx builders, registry cache, language-specific templates, secret handling, SBOM/provenance, image signing, vulnerability gates, and clear ownership. Strong candidates discuss self-service developer experience, exception handling, metrics from build logs, and avoiding a brittle one-size-fits-all pipeline.

Red flag: They design a single monolithic pipeline that every repository must use exactly the same way.

Listen for: Strong answers cover Compose profiles, project naming, isolated networks, named volumes for stateful services, seed data, healthchecks, predictable ports, non-root containers, secret handling for local-only values, and easy reset commands. They should prioritize fast onboarding while preventing accidental calls to real production services.

Red flag: They mount production credentials into local containers to make development realistic.

Listen for: They should propose buildx, native or emulated builders, per-platform tests, dependency validation, manifest list publication, digest-based deployment, and clear tag strategy. Good answers include handling platform-specific bugs, base image compatibility, caching per architecture, and rollback if one architecture fails validation.

Red flag: They publish one tag after testing only on the engineer’s laptop.

Listen for: A strong answer includes approved base images, locked dependencies, SBOM generation, provenance attestations, vulnerability scanning with documented risk acceptance, image signing, registry access control, immutable promotion, audit logs, and emergency patch flow. They should keep controls automated in CI and avoid blocking teams with manual ticket-heavy steps.

Red flag: They rely mainly on a spreadsheet of approved images maintained by hand.

Listen for: Listen for isolation boundaries: separate hosts or pools for trust levels, rootless Docker where feasible, user namespaces, read-only filesystems, dropped capabilities, seccomp/AppArmor/SELinux profiles, resource limits, network segmentation, logging, and restricted daemon access. Strong answers recognize Docker is not a hard multi-tenant security boundary by default.

Red flag: They run all workloads on the same Docker daemon and depend only on container names for separation.