What is a Docker image?

In this article

1. Before you start
2. Why interviewers ask this
3. Docker image from first principles
4. The Staff-level answer
5. The rubric
6. Three variants of this question
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page belongs to the DevOps and cloud learning path, which lists what to learn and in what order.

Why interviewers ask this

A candidate who cannot say what an image is also struggles to explain slow builds, bloated deployments and why a rollback pulled the wrong version. The question is a cheap way to find out whether you understand what you ship, not just which commands you type.

A weak answer says "an image is like a container" or "a lightweight virtual machine." A strong answer separates the image (a fixed template) from the container (a running instance of it), names layers, and says that tags are movable labels. A Staff-level answer adds consequences: layers are shared and cached, so instruction order decides rebuild cost, and a digest, not a tag, identifies exactly what runs. Candidates report this question in DevOps, backend and platform interviews, usually as the opener for a longer Docker or Kubernetes discussion.

Docker image from first principles

Docker image

A Docker image is a read-only package that bundles an application's files, libraries, minimal operating-system files and default settings, stored as a stack of layers plus a manifest that lists them. Docker or any compatible runtime uses it as the template to start containers. Building an image never starts the application, and a built image never changes.

Image layer

An image layer is a read-only set of filesystem changes, such as files added, changed or deleted, produced by one build instruction and stored once under its content hash. Any image that contains the same layer reuses the stored copy instead of keeping its own.

Image digest

An image digest is a content hash of an image's manifest, written as sha256: followed by a long hexadecimal string, that names exactly one image. If a single byte of the content changes, the digest changes, which makes it a stronger identifier than a tag, because a tag can be moved to a different image.

In plain words

Picture a stack of transparent sheets. Each sheet has some items drawn on it. Looking from above, you see all the items at once. The stack is sealed, so nobody can redraw a sheet. That sealed stack is an image.

A container is a running instance of an image: an isolated process on the host that sees the image's files as its own file system. Think of the stack plus one blank sheet on top, where the process may write in pencil. The pencil sheet is thrown away with the container.

The analogy breaks in one place. A later sheet can cover an item, but the item still sits on the sheet below. So covering a file does not make the stack lighter.

In one precise sentence, a Docker image is an immutable, layered file system plus metadata, such as the default command, that a runtime turns into a container. Docker's documentation (updated 2026-02-21) describes an image as a standardized package with the files and configuration needed to run a container, and says images are immutable and built from layers.

Step 1: A Dockerfile starts from a base image

A Dockerfile is a text file that lists, in order, the instructions Docker follows to build an image. The first instruction names a base image to build on. Everything after it adds to that base.

# Illustrative Dockerfile for a small Python app
FROM python:slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Input: a base image and a list of instructions. Output, after the build: a new image. The first line picks the starting stack. The lines that begin with COPY (the copy instruction) bring files from your folder into the image. The line that begins with RUN (the run instruction) executes a command at build time, here installing libraries. The last line records the default command a container will run, and does not run it during the build.

You now know where an image comes from: a recipe, applied on top of an existing image. The next step shows what each line leaves behind.

Step 2: Each instruction adds one read-only layer

An image layer is the record of what one instruction changed. After the base image, each instruction that changes files, such as copying files in or running an install command, adds a layer on top of the stack. Instructions that set the default command mainly store settings in the image's configuration. You can list the layers of a local image with docker history.

Each layer is stored under a hash of its content. Two layers with identical content have the same hash, so Docker keeps one copy. That answers the opening question. In an illustrative pair of images, app A has layers of 80, 120, 60 and 2 megabytes and app B has 80, 120, 45 and 3, so they total 262 and 248 megabytes.¹ They share the 80 and 120 megabyte layers, so disk holds 310 megabytes rather than 510, a saving of 200.¹ Pulling B after A downloads only B's two private layers.

Layers also feed the build cache. Docker reuses a stored layer when its instruction and files are unchanged. Once one layer changes, every layer above it is rebuilt.

Step 3: A manifest and a digest identify the image

A manifest is a small document that lists the image's configuration and its layers, each by its hash. The configuration holds the default command, environment variables and similar settings. The Open Container Initiative (OCI) publishes an image specification for this format, which is why different tools can build and run the same image.

The hash of the manifest is the image digest. It names one image exactly. A tag is a human-readable label, such as python:slim, that points at an image in a registry. A registry is a server that stores images and hands them out by name, tag or digest.

Tags can be moved: a publisher can point the same tag at a new image tomorrow. The tag latest is only the tag Docker uses when you give none. It does not mean "newest". If you need the exact same bytes on every machine, reference the digest.

You now know how an image is named. Last, how it becomes something that runs.

Step 4: A container adds one writable layer on top

When Docker starts a container, it does not copy the image. It stacks a thin writable layer on top of the read-only layers and starts the process. The storage documentation (updated 2026-06-02) describes this writable container layer and the copy-on-write behavior: changing a file that lives in a lower layer first copies it up into the writable layer.

Because of that design, many containers can run from one image and share its layers on disk, each with its own thin top layer. When a container is removed, its writable layer goes with it. Data that must outlive the container belongs in a volume, which is storage managed outside the image layers.

The image itself never changes while containers run. That immutability is what makes "the same image in testing and in production" a meaningful sentence.

1 · Base2 · Layers3 · Digest4 · ContainerReplay

Step-by-step description

1. The Dockerfile starts from a base image.
2. Each instruction adds a read-only layer.
3. A manifest and digest name the image.
4. A container adds a writable layer.

• A Dockerfile starts from a base image.
• Each instruction that changes files adds one read-only layer.
• A manifest lists the layers by hash, and the digest names the image.
• A container adds one thin writable layer on top of the image.

Worked examples: layer sharing, build cache and multi-stage size

The numbers below are illustrative layer sizes run through a short script; the arithmetic, not the sizes, is what to practice.¹

For the build cache, assume copying files takes about 1 second and installing libraries about 45 seconds (illustrative). If the Dockerfile copies all code first and then installs libraries, a one-line code change rebuilds 2 of 3 layers and costs 46 seconds.¹ If it copies only the dependency list, installs, and then copies the code, the same change rebuilds 1 of 4 layers and costs 1 second.¹

For size, a multi-stage build compiles in one stage and copies only the result into a clean final stage. Take a build stage with an 80 megabyte base, a 600 megabyte toolchain, 5 megabytes of source and 12 megabytes of output (illustrative). Shipping it as one stage gives a 697 megabyte image. Shipping only base plus output gives 92 megabytes, 605 megabytes smaller, or 86.8% less.¹

Text description of the diagram

• A single-stage image is 697 megabytes in the illustrative example.
• The multi-stage final image is 92 megabytes, which is 605 megabytes smaller.

The Staff-level answer

What makes it Staff-level: it states the consequence (sharing and cache invalidation) and the engineering response (instruction order, multi-stage builds), not only the definition.

The rubric

Three variants of this question

What is the difference between a Docker image and a container?

An image is the fixed, read-only template. A container is a running instance of it, with a thin writable layer and a process. You can start many containers from one image.

What is the difference between a Docker image and a virtual machine image?

A virtual machine image holds a full operating system, including its kernel, for a hypervisor to boot. A Docker image holds only the files an application needs, and its containers share the host's kernel, so they start as ordinary processes.

What does the latest tag on a Docker image mean?

It is only the default tag Docker uses when none is given. Nothing makes it the newest version, and a publisher can point it at any image, so use a specific tag or a digest when you need repeatable results.

Common mistakes

• "An image is a running container." (wrong) A container is an instance; an image never runs. (right) "A container runs from an image and adds a writable layer."
• "Deleting a file in a later step makes the image smaller." (wrong) The earlier layer still holds the bytes. (right) "I remove temporary files in the same instruction that created them, or I use a multi-stage build."
• "The latest tag always gives me the newest version." (wrong) It is only a default tag. (right) "I pin a specific tag, or the digest for exact bytes."
• "Docker images contain a whole operating system with its own kernel." (wrong) They hold user-space files; the kernel is the host's. (right) "Images package files and libraries, and containers share the host kernel."

Follow-up questions

How do you make a Docker image smaller?

Start from a smaller base image, use a multi-stage build so compilers and test tools stay out of the final stage, and remove temporary files in the instruction that created them. In the worked example the multi-stage build removes 605 of 697 illustrative megabytes.¹

Why does the order of Dockerfile instructions matter?

The build cache reuses layers only up to the first change. Put rarely changing steps, such as installing dependencies, first and frequently changing code last. A continuous integration (CI) server such as Jenkins benefits on every build of a continuous delivery (CD) pipeline.

Should you pin a Docker image by tag or by digest?

Pin by digest when you need the exact same bytes everywhere, because a tag can be moved to a different image. A readable tag is fine for development, where convenience matters more than repeatability.

Where are Docker images stored?

Locally, Docker keeps layers in its storage area on the host. Shared images live in a registry, from which hosts and orchestrators pull them; the Kubernetes interview questions show how a cluster does that at scale.

What happens to files a container writes?

Files a container writes go into the container's writable layer, which is removed with the container. Use a volume for data that must survive.

Sources

1. What is an image? — Docker Docs, 21 Feb 2026
2. Storage drivers — Docker Docs, 2 Jun 2026