Docker interview questions

What a strong answer covers

• Acknowledge that both provide isolated environments but differ in their virtualization approach.
• Explain that VMs virtualize hardware, requiring a full guest OS for each instance, leading to larger size and slower startup.
• Describe containers as virtualizing the OS, sharing the host OS kernel, making them lighter, faster, and more resource-efficient.
• Highlight the 'hypervisor' for VMs versus the 'Docker Engine' for containers as the underlying technology.

Where people lose the point

• ×Confusing containers as a lightweight form of VM without explaining the shared kernel.
• ×Failing to mention the resource efficiency and speed benefits of containers.
• ×Incorrectly stating that containers have their own full operating system.

What a strong answer covers

• Define a Docker image as a lightweight, standalone, executable package that includes everything needed to run a piece of software, including the code, runtime, system tools, libraries, and settings.
• Explain that an image is a static, read-only template, analogous to a class in object-oriented programming.
• Define a Docker container as a runnable instance of an image, analogous to an object created from a class.
• State that containers are dynamic, isolated processes that can be started, stopped, moved, and deleted, and can have a writable layer on top of the image.

Where people lose the point

• ×Using the terms interchangeably without clear distinction.
• ×Not emphasizing the read-only nature of an image versus the writable layer of a container.
• ×Failing to use a clear analogy (e.g., blueprint vs. house, class vs. object).

What a strong answer covers

• Explain that `docker run` is used to create a *new* container from an image and then start it.
• Detail that `docker run` is used for the initial deployment or when you need a fresh instance of an application.
• Explain that `docker start` is used to restart an *existing*, stopped container.
• Clarify that `docker start` preserves the container's previous state (e.g., data in its writable layer, configuration) from when it was last stopped.

Where people lose the point

• ×Suggesting `docker run` is for restarting existing containers.
• ×Not mentioning that `docker start` requires a container ID or name, not an image name.
• ×Failing to highlight the preservation of state with `docker start`.

What a strong answer covers

• Define a Dockerfile as a text document containing all the commands a user could call on the command line to assemble an image.
• Explain its purpose as a blueprint or script for building Docker images automatically.
• Highlight that it ensures reproducibility and consistency in image creation.
• Mention that it allows for version control of the image build process.

Where people lose the point

• ×Describing it as a configuration file for running containers, rather than building images.
• ×Not emphasizing its role in automation and reproducibility.
• ×Confusing it with `docker-compose.yml`.

What a strong answer covers

• FROM: Specifies the base image for the build, e.g., `FROM ubuntu:22.04` or `FROM node:18-alpine`.
• RUN: Executes commands during the image build process, typically for installing packages or compiling code, e.g., `RUN apt-get update && apt-get install -y curl`.
• COPY: Copies files or directories from the host machine (build context) into the image, e.g., `COPY . /app`.
• CMD: Provides defaults for an executing container, which can be overridden at runtime, e.g., `CMD ["nginx", "-g", "daemon off;"]`.
• EXPOSE: Informs Docker that the container listens on the specified network ports at runtime, e.g., `EXPOSE 80`.

Where people lose the point

• ×Confusing `RUN` (build-time) with `CMD` or `ENTRYPOINT` (run-time).
• ×Providing vague descriptions without concrete examples of usage.
• ×Listing instructions that are less common or more advanced without context.

What a strong answer covers

• Explain that `CMD` provides default arguments for an executing container, which can be easily overridden when running the container.
• Provide a use case for `CMD`: defining the default command for an application, like `CMD ["nginx", "-g", "daemon off;"]` for a web server.
• Explain that `ENTRYPOINT` configures a container to run as an executable, making the image behave like a command.
• Provide a use case for `ENTRYPOINT`: creating a utility image where the `ENTRYPOINT` is the tool itself (e.g., `ENTRYPOINT ["curl"]`), and `CMD` provides default flags (e.g., `CMD ["-s"]`).

Where people lose the point

• ×Stating that `CMD` cannot be overridden.
• ×Not explaining how `CMD` acts as arguments to `ENTRYPOINT` when both are present.
• ×Failing to provide clear, distinct use cases for each instruction.

What a strong answer covers

• Explain that by default, data inside a container's writable layer is ephemeral and lost when the container is removed.
• State that Docker volumes provide a mechanism for persisting data generated by and used by Docker containers.
• Detail that volumes solve the problem of data loss, ensuring application data (e.g., database files, logs) survives container restarts or deletions.
• Mention that volumes also facilitate data sharing between containers and between a container and the host, and improve I/O performance compared to the container's writable layer.

Where people lose the point

• ×Confusing volumes with bind mounts without clarifying their differences.
• ×Not emphasizing the ephemeral nature of container data without volumes.
• ×Failing to mention data sharing or performance benefits.

What a strong answer covers

• Define Docker Compose as a tool for defining and running multi-container Docker applications.
• Explain that it uses a YAML file (`docker-compose.yml`) to configure all the application's services, networks, and volumes.
• State that it simplifies the management of complex, multi-service applications by allowing them to be started, stopped, and built with a single command.
• Provide use cases such as local development environments, testing, and small-scale production deployments where multiple interconnected services are required.

Where people lose the point

• ×Confusing Docker Compose with Docker Swarm or Kubernetes (orchestration tools for clusters).
• ×Not mentioning the `docker-compose.yml` file as its core configuration.
• ×Failing to highlight its benefit for multi-service applications.

What a strong answer covers

• Bridge network: The default network driver, creating a private internal network for containers on a single host to communicate. Good for single-host applications.
• Host network: Removes network isolation between the container and the Docker host, allowing the container to share the host's network stack. Useful for performance-critical applications or when direct host network access is needed.
• Overlay network: Connects multiple Docker daemons together, enabling swarm services to communicate across different hosts. Essential for multi-host, clustered deployments (e.g., Docker Swarm).
• None network: Disables all networking for a container, making it completely isolated. Used for containers that don't need network access or for custom networking setups.

Where people lose the point

• ×Only listing one or two drivers without explaining their specific use cases.
• ×Incorrectly describing the isolation properties of each network type.
• ×Confusing the purpose of `bridge` with `overlay` networks.

What a strong answer covers

• Explain that each instruction in a Dockerfile (e.g., FROM, RUN, COPY) creates a new read-only layer in the image.
• Describe how these layers are stacked on top of each other, forming the complete image, and how they are shared between images.
• Highlight the benefit of caching: if an instruction and its context haven't changed, Docker reuses the existing layer, speeding up builds.
• Mention that layering reduces storage space by allowing multiple images to share common base layers, and enhances security by making images immutable.

Where people lose the point

• ×Not mentioning the read-only nature of image layers.
• ×Failing to explain the caching mechanism and its impact on build speed.
• ×Incorrectly stating that layers are only for the final image, not for intermediate steps.

What a strong answer covers

• Explain `EXPOSE`: It's a Dockerfile instruction that serves as documentation, informing users that the container listens on specific ports at runtime. It does not actually publish the port.
• Clarify that `EXPOSE` is primarily for inter-container communication within a Docker network and for tools like `docker inspect`.
• Explain `-p` (publish): It's a `docker run` flag that actually maps a container port to a port on the host machine, making the container's service accessible from outside the Docker host.
• Provide an example: `EXPOSE 80` in Dockerfile, but `docker run -p 8080:80 my-app` to make it accessible on host's 8080.

Where people lose the point

• ×Stating that `EXPOSE` publishes the port to the host.
• ×Not emphasizing that `EXPOSE` is documentation, while `-p` is actual port mapping.
• ×Confusing the internal container port with the external host port.

What a strong answer covers

• Define multi-stage builds as a Dockerfile feature allowing the use of multiple `FROM` statements, each representing a distinct build stage.
• Explain the problem they solve: reducing final image size by separating build-time dependencies (compilers, SDKs) from runtime dependencies.
• Describe how they work: artifacts from an earlier stage (e.g., compiled binaries) are copied into a leaner, final stage, discarding all unnecessary build tools.
• Highlight benefits like smaller image sizes, improved security (less attack surface), and faster image pulls/pushes.

Where people lose the point

• ×Not clearly explaining how artifacts are copied between stages.
• ×Failing to emphasize the primary benefit of reduced image size.
• ×Confusing multi-stage builds with simply having multiple `RUN` commands.

What a strong answer covers

• Use minimal base images (e.g., Alpine) to reduce the attack surface and image size.
• Run containers as a non-root user (`USER` instruction) to limit potential damage if the container is compromised.
• Regularly scan images for vulnerabilities using tools like Docker Scout or Trivy.
• Implement resource limits (CPU, memory) to prevent denial-of-service attacks or resource exhaustion.
• Avoid storing sensitive information (passwords, API keys) directly in images or environment variables; use Docker Secrets or external secret management tools.

Where people lose the point

• ×Only mentioning one or two practices without explaining their security implications.
• ×Suggesting storing secrets directly in environment variables as a good practice.
• ×Failing to mention the importance of using minimal base images.

What a strong answer covers

• Use minimal base images (e.g., `alpine` variants) that contain only essential components.
• Implement multi-stage builds to separate build-time dependencies from runtime dependencies, copying only necessary artifacts to the final image.
• Leverage `.dockerignore` to exclude unnecessary files (e.g., `.git`, `node_modules` for runtime) from the build context.
• Combine `RUN` commands using `&&` to reduce the number of layers and clean up temporary files (e.g., `apt-get clean`).
• Remove unnecessary packages, caches, and documentation after installation.

Where people lose the point

• ×Only focusing on one strategy without a holistic view.
• ×Not explaining *why* a strategy reduces size (e.g., how multi-stage builds work).
• ×Suggesting methods that might compromise functionality or security.

What a strong answer covers

• Explain that resource limits can be set using `docker run` flags: `--memory` (or `-m`) for memory and `--cpus` or `--cpu-shares` for CPU.
• Describe `--memory` to set a hard limit on RAM, and `--cpus` to specify the number of CPU cores or `--cpu-shares` for relative CPU weighting.
• Explain the importance: prevents a single misbehaving container from consuming all host resources, leading to system instability or denial of service.
• Mention that resource limits ensure fair resource allocation among multiple containers and improve overall system reliability and performance predictability.

Where people lose the point

• ×Not providing specific `docker run` flags for setting limits.
• ×Failing to explain the 'why' – the importance of preventing resource exhaustion.
• ×Confusing CPU shares with absolute CPU core allocation.

What a strong answer covers

• Explain that Docker provides a consistent and isolated environment for building, testing, and deploying applications across all stages of the pipeline.
• Describe the 'build once, run anywhere' principle: a Docker image built in CI can be tested in staging and deployed to production without environmental discrepancies.
• Provide a high-level example: CI pipeline builds a Docker image from source code, runs tests inside a container, and if successful, pushes the image to a registry. CD pipeline then pulls this pre-built image and deploys it to production.
• Highlight benefits like faster deployments, reduced 'it works on my machine' issues, and easier rollback capabilities.

Where people lose the point

• ×Focusing too much on specific CI/CD tools rather than the Docker concepts.
• ×Not emphasizing the consistency and isolation benefits.
• ×Failing to connect the image registry as a key component in the CI/CD flow.

What a strong answer covers

• Define Named Volumes: Managed by Docker, stored in a Docker-managed part of the host filesystem, created explicitly (`docker volume create`). Preferred for persisting application data.
• Define Bind Mounts: Directly maps a file or directory from the host filesystem into a container. Managed by the user, dependent on host directory structure. Useful for development workflows.
• Compare: Volumes are more portable, easier to back up, and managed by Docker. Bind mounts offer fine-grained control over host paths but are less portable.
• Use Cases: Volumes for database data, application logs, or any data that needs to persist across container lifecycles. Bind mounts for sharing source code during development, configuration files, or host-specific data.

Where people lose the point

• ×Not clearly stating which is managed by Docker vs. the user.
• ×Failing to highlight the portability difference.
• ×Providing only one use case for each or confusing their primary applications.