What is the difference between an image and a container?
An image is a read-only, static template containing instructions for creating a container, while a container is a runnable instance of that image, adding a writable layer on top for runtime modifications.
The fundamental relationship between an image and a container can be understood by comparing them to a class and an object in object-oriented programming. An image is the class—a static blueprint that defines what the application should look like. A container is the object—a running instance created from that blueprint that can be started, stopped, moved, and deleted. Images are immutable and can be shared, while containers are ephemeral and have a lifecycle.
- 1
Immutability vs mutability: Images are completely read-only and cannot be changed after creation. Containers add a thin writable layer on top of the image layers, allowing runtime modifications like writing logs, creating temporary files, or updating application state.
- 2
State: An image is a static artifact that can be stored in a registry and versioned. A container is a dynamic runtime environment that has a lifecycle (created, running, paused, stopped, deleted).
- 3
Storage: Images are stored in layers and shared across multiple containers to save disk space. Each container adds its own thin writable layer, which is why creating many containers from the same image consumes minimal additional space.
- 4
Persistence: Images persist indefinitely until explicitly deleted. Containers are ephemeral by nature—when deleted, all changes in the writable layer are lost unless volumes were used to persist data.
- 5
Names: Images are identified by repository and tag (e.g., ubuntu:22.04). Containers have unique IDs and can optionally be assigned human-readable names.
The layering mechanism is crucial to understanding this relationship. A Docker image consists of multiple read-only layers stacked on top of each other. When you create a container, Docker adds a new thin, writable layer on top of these existing layers—this is often called the container layer. All changes made to the container during its lifetime (creating files, modifying configuration, installing packages) are written to this writable layer. When the container is deleted, this writable layer is discarded, but the underlying image layers remain intact and unchanged .
This separation enables powerful workflows. You can run multiple containers from the same image, each with its own isolated writable layer. For example, you could run five separate nginx containers from the same image, each serving different content because their writable layers contain different website files. You can also commit a container's changes to create a new image using docker commit, which saves the current state of the writable layer as a new image layer, though this practice is generally discouraged in favor of using Dockerfiles for repeatable builds .
Scenario Questions
0-2 years experience
- 1You need to run a simple Python script in Docker. Walk me through whether you would use an image or a container, and what each represents.
- 2If you delete a container but keep the image, what happens when you start a new container from that image?
2-5 years experience
- 1Your CI pipeline builds an image, but during deployment the container fails to start because a file is missing. How would you investigate whether the issue is with the image or the container runtime?
- 2We have a service that needs to be updated with a new library version. Explain the steps you’d take using images and containers, and why you’d prefer one over the other for rolling updates.
5-8 years experience
- 1Our platform spins up thousands of containers from a shared base image. Discuss the trade‑offs of using a single large monolithic image versus multiple smaller layered images in terms of storage, network bandwidth, and start‑up latency.
- 2During a high‑traffic incident we notice that containers are pulling the same image repeatedly, causing registry throttling. How would you redesign the image‑container workflow to mitigate this at scale?
8+ years experience
- 1We are migrating a legacy on‑prem application to a cloud‑native architecture. Outline the strategy for converting the existing binaries into immutable images and how you’d manage container lifecycle across multiple teams to ensure security and compliance.
- 2Your organization wants to enforce a policy that no container can run without a signed image. Describe the architectural changes needed in the CI/CD pipeline, registry, and runtime to enforce this, and how you’d handle exceptions.
Follow-up Questions
- Can you give an example of when you’d need to inspect the writable layer of a container?
- How does Docker’s copy‑on‑write mechanism affect the relationship between image and container?
- What implications does image immutability have for security patching?