Docker Scenario Based Questions 2026, 25 Real

Experienced Docker rounds are not trivia, they are troubleshooting. Candidates report interviewers describe a broken container or build and ask you to diagnose and fix it live. This guide collects 25 real scenarios from candidate-reported rounds and public preparation resources, each with the diagnosis, the fix, and the exact commands.

The diagnostic toolkit: docker logs, docker inspect, docker exec, docker stats, docker history. Reach for these before guessing.

Container Lifecycle Scenarios (S1 to S9)

S1. A container exits immediately after starting. Why?

Diagnosis: The container's main process (PID 1) finished or crashed. A container runs only as long as its foreground process. A common cause: the CMD runs a background service then exits, or the app crashes on startup.

Fix: Run the process in the foreground (do not daemonize), check docker logs <id> for the crash, and ensure the entrypoint blocks. Candidate-reported as the single most common scenario.

S2. docker logs shows nothing but the app should be logging. Why?

Diagnosis: The app logs to a file inside the container or buffers stdout. Docker captures stdout/stderr of PID 1.

Fix: Log to stdout/stderr and disable output buffering (e.g., PYTHONUNBUFFERED=1 for Python, flush in Node).

S3. A container is "Up" but the app is unreachable from the host. Why?

Diagnosis: Missing or wrong port publish, the app binds to 127.0.0.1 instead of 0.0.0.0, or the wrong host port.

Fix: Publish with -p 8080:80, bind the app to 0.0.0.0 so it accepts external connections, and verify with docker port <id>. Candidate-reported as a frequent networking trap.

S4. The container restarts in a loop. Diagnose.

Diagnosis: The app crashes and a restart: always policy keeps relaunching it. Check docker logs and docker inspect for the exit code and restart count.

Fix: Resolve the crash root cause (config, missing dependency, failed connection); the restart loop is a symptom, not the problem.

S5. docker exec works but the change disappears on restart. Why?

Diagnosis: Changes to the container's writable layer are ephemeral; recreating the container discards them.

Fix: Bake permanent changes into the image (Dockerfile) or persist data in a volume. Interactive exec edits are for debugging only.

S6. A process inside the container ignores SIGTERM and is killed forcibly. Why?

Diagnosis: PID 1 does not forward signals or the app does not handle SIGTERM, so docker stop waits then sends SIGKILL after the grace period.

Fix: Handle SIGTERM for graceful shutdown, and use an init (--init or tini) to reap zombies and forward signals when the app is not PID-1-aware.

S7. The container shows the wrong timezone or locale. Fix.

Diagnosis: The base image has minimal locale/timezone data.

Fix: Set TZ and install tzdata, or mount the host's timezone; for locale install the needed locale package in the Dockerfile.

S8. A health check keeps failing though the app works. Diagnose.

Diagnosis: The healthcheck command, interval, or start period is wrong (e.g., checking before the app finishes booting).

Fix: Add a --start-period, verify the healthcheck command runs inside the container, and ensure it targets the right port and path.

S9. Two containers cannot resolve each other by name. Why?

Diagnosis: They are on the default bridge network (no automatic DNS for the legacy bridge) or on different user-defined networks.

Fix: Put them on the same user-defined network, which provides name-based DNS resolution.

Image and Build Scenarios (S10 to S17)

S10. The image is 1.5 GB and pulls slowly. How do you shrink it?

Diagnosis: A heavy base image, build tools left in the final image, and no layer cleanup.

Fix: Use a multi-stage build (compile in a builder stage, copy only artifacts into a slim runtime image), pick a minimal base, combine RUN steps, and add a .dockerignore. Candidate-reported as a guaranteed scenario.

S11. Every code change rebuilds the whole image slowly. Why?

Diagnosis: The Dockerfile copies all source before installing dependencies, so any code change invalidates the dependency layer cache.

Fix: Copy the lockfile and install dependencies first, then copy source. Order layers from least to most frequently changing.

S12. A secret ended up in the image. How did it leak and how do you fix it?

Diagnosis: A secret passed via build ARG or copied in then deleted still lives in an earlier layer (layers are immutable history).

Fix: Use BuildKit secret mounts (--mount=type=secret) so the secret never persists in a layer, and rotate the exposed secret. Candidate-reported as a security-focused scenario.

S13. docker history shows a giant layer. What does that tell you?

Diagnosis: A single RUN added and did not remove large files, or copied a big artifact. Each instruction is an immutable layer; deleting a file in a later layer does not shrink earlier ones.

Fix: Remove temporary files within the same RUN, or restructure with multi-stage builds.

S14. The build works locally but fails in CI. Common causes?

Diagnosis: Different base image digest, missing build context files (excluded by .dockerignore), platform/architecture mismatch (arm64 vs amd64), or cache differences.

Fix: Pin image digests, build for the target platform with buildx, and ensure the build context matches.

S15. An ARM Mac builds an image that fails on an amd64 server. Why?

Diagnosis: The image was built for the build host's architecture.

Fix: Use docker buildx build --platform linux/amd64 (or multi-platform) to build for the target. Candidate-reported as increasingly common with Apple Silicon.

S16. COPY fails with "no such file or directory" though the file exists. Why?

Diagnosis: The file is outside the build context or excluded by .dockerignore, or the path is relative to the context root, not the Dockerfile.

Fix: Ensure the file is within the context and not ignored; paths are relative to the context.

S17. The same Dockerfile produces different images over time. Why?

Diagnosis: Unpinned base tags (node:latest) and unpinned package versions pull newer content on each build.

Fix: Pin base image digests and dependency versions for reproducible builds.

Runtime, Networking, and Resources (S18 to S25)

S18. A container is OOM-killed. Diagnose and fix.

Diagnosis: The process exceeded its memory limit; docker inspect shows OOMKilled: true.

Fix: Raise the --memory limit if justified, fix the leak or reduce memory use, and set appropriate runtime memory settings (e.g., JVM heap, Node --max-old-space-size) so the app respects the container limit. Candidate-reported as a strong senior scenario.

S19. CPU is pinned at 100% for one container. How do you contain it?

Diagnosis: No CPU limit, so a busy process consumes a full core and starves neighbors.

Fix: Set --cpus limits, and investigate the workload (a tight loop, missing async). Use docker stats to confirm.

S20. A bind-mounted file shows permission denied. Why?

Diagnosis: UID/GID mismatch between the host file owner and the container user, common with non-root containers.

Fix: Align the container user's UID with the host, adjust file ownership, or use a named volume instead of a bind mount.

S21. Containers cannot reach the internet. Diagnose.

Diagnosis: DNS misconfiguration, a custom network without a gateway, or host firewall rules.

Fix: Check docker network inspect, set --dns, and verify host networking and firewall. Test with docker run --rm busybox ping.

S22. Disk fills up over time on the Docker host. Why?

Diagnosis: Accumulated stopped containers, dangling images, unused volumes, and build cache.

Fix: docker system df to see usage, docker system prune (and prune -a --volumes carefully) to reclaim space. Automate cleanup in CI.

S23. A container can write to a volume but another cannot see the data. Why?

Diagnosis: They mount different volumes or different paths, or one uses a bind mount and the other a named volume.

Fix: Mount the same named volume at the expected path in both containers.

S24. The app inside the container connects to "localhost:5432" and fails. Why?

Diagnosis: Inside a container, localhost is the container itself, not the host or another container.

Fix: Use the service/container name (on a shared network) or host.docker.internal to reach the host. Candidate-reported as a near-universal trap.

S25. Scenario: design a secure, small production image for a Node app. Walk through it.

Docker Scenario Mock Test, 2026 Edition

5 original questions calibrated to the 2026 DevOps batch by Aditya Sharma, from candidate-reported patterns.

Question 1

A container exits immediately. The root cause is usually:

a) low disk b) PID 1 process finished or crashed c) wrong tag d) no volume

Solution: A container lives only while its foreground process runs. Answer: (b)

Question 2

Inside a container, "localhost" refers to:

a) the host b) the container itself c) another container d) the gateway

Solution: Use the service name or host.docker.internal to reach elsewhere. Answer: (b)

Question 3

To shrink a large image, the primary technique is:

a) gzip b) multi-stage builds c) more layers d) a bigger base

Solution: Build artifacts then copy only results into a slim runtime stage. Answer: (b)

Question 4

A code change rebuilds everything slowly because:

a) Docker is slow b) source is copied before dependency install, busting cache c) no volume d) wrong network

Solution: Install dependencies before copying source. Answer: (b)

Question 5

OOMKilled: true in inspect means:

a) network failure b) the process exceeded its memory limit c) CPU throttle d) disk full

Solution: Raise the limit or fix memory use, respecting the container limit. Answer: (b)

FAQ, Docker Scenario Questions

Q: How many scenarios appear in a round? Candidate-reported experienced rounds lean heavily on scenarios, often three to six troubleshooting cases.

Q: What commands should I master? docker logs, inspect, exec, stats, history, and system df/prune. They are your diagnostic kit.

Q: Do freshers get scenario questions? Lighter ones (container exits, port mapping). Resource limits and security skew experienced.

Q: What is the most-missed Docker scenario? The localhost-inside-container trap and PID 1 lifecycle, per candidate-reported feedback.

Docker Scenario Based Questions 2026, 25 Real Troubleshooting Cases

PapersAdda 2026 Placement Cycle