Docker Interview Questions for AI Training Work

An image is a read-only, layered template built from a Dockerfile, containing the filesystem and configuration needed to run something. A container is a running (or stopped) instance of that image, with its own writable layer on top for any runtime changes. You can run many independent containers from the same image, each isolated from the others despite sharing the underlying image layers.

Each instruction in a Dockerfile produces a layer, and Docker reuses a cached layer if that instruction and everything before it are unchanged. Putting instructions that change often, like copying application source code, after instructions that rarely change, like installing dependencies, means dependency installation stays cached across builds and only the actual code-copy layer rebuilds, which speeds up iterative builds significantly.

A volume is managed entirely by Docker and stored in Docker's own storage area, making it portable across environments and easier to back up or migrate. A bind mount maps a specific path on the host filesystem directly into the container, useful for local development when you want live changes to source code on the host to appear immediately inside the container without a rebuild.

A multi-stage build lets you use one stage with a full build toolchain, like a compiler or a large SDK, to produce build artifacts, then copy only those artifacts into a lean final stage based on a minimal base image. That keeps the shipped image small and reduces its attack surface, since none of the build-time tooling, source code, or intermediate files end up in the image that actually runs in production.

`ENTRYPOINT` defines the fixed executable a container runs and is hard to override at `docker run` time without an explicit flag. `CMD` provides default arguments that get appended to `ENTRYPOINT`, or the default command if `ENTRYPOINT` isn't set, and can be overridden simply by passing arguments to `docker run`. Combining both, a fixed `ENTRYPOINT` with a default `CMD`, is a common pattern for images meant to behave like a single command-line tool.

I'd start with `docker logs` on the failed container to see the actual exit reason, since a crash-on-start almost always logs something before dying. If logs are empty, I'd check the exit code with `docker inspect`, common causes there are a missing environment variable that's present locally but not in the deploy config, or a base image mismatch between architectures, like building on ARM locally and deploying to an x86 host.

I'd first check what's actually in the image with a tool like `dive`, since large images are usually explained by a small number of layers rather than being uniformly bloated. Common fixes are switching to a slim or alpine base image, using a multi-stage build to drop build tools from the final image, and cleaning up package manager caches within the same layer they were created in, since a later `rm` in a new layer doesn't shrink the image.

I'd put the two communicating containers on a shared user-defined Docker network, which also gives them DNS-based service discovery by container name, and leave the third container on a different network or none at all. Docker's default bridge network doesn't provide this isolation as cleanly, so a purpose-built user-defined network is the more explicit and reliable way to control which containers can reach each other.

A build worked on my machine but failed in CI because a base image tag like `node:18` had moved to a newer patch version between the two builds, and that patch introduced a breaking change in a transitive dependency. I pinned the base image to a specific digest instead of a floating tag, which made the build fully reproducible, and it changed how I write Dockerfiles now, always pinning versions explicitly rather than trusting a tag to stay stable.

The team's main worry was operational unfamiliarity with Docker, not a technical objection. I containerized one low-risk internal service first as a proof of concept, documented the exact deployment steps, and let the team see the actual failure modes and rollback process in a low-stakes setting before proposing it for anything customer-facing. Seeing it work in practice addressed the concern faster than any argument about it would have.