Lesson 1 of 30

Images, Containers & Registries

Q: What's the actual difference between a Docker image and a Docker container, and where does a registry fit in?

A strong answer covers: An image is a read-only, layered blueprint built from a Dockerfile; a container is a running (or stopped) instance of an image with its own writable layer and process; One image can produce many independent containers, which don't affect each other or the image; A registry is where images are stored and distributed (push/pull), not something that runs anything itself.

Three nouns get used almost interchangeably in casual conversation — image, container, registry — and interviews specifically probe whether you actually know which is which.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

Two containers, web1 and web2, are both started from the same myapp:1.4.0 image. web1 is stopped and deleted. What happens to web2 and the image?

web2 also stops, since both containers were sharing one running processBoth are unaffected — each container has its own independent writable layer and processThe image is deleted too, since it was only referenced by these two containers

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Images, Containers & Registries

What interviewers actually ask about this, and what a strong answer has to cover.

What's the actual difference between a Docker image and a Docker container, and where does a registry fit in?

A strong answer covers

An image is a read-only, layered blueprint built from a Dockerfile; a container is a running (or stopped) instance of an image with its own writable layer and process
One image can produce many independent containers, which don't affect each other or the image
A registry is where images are stored and distributed (push/pull), not something that runs anything itself

Likely follow-ups

Why is pinning a deploy to myapp:latest risky, versus pinning to an explicit version or digest?
If a container is stopped, is it safe to assume its resources are fully reclaimed? What command actually removes it?

Practice these with the AI interviewer →

The plain-language idea

Three distinct objects, one vocabulary problem:

An image is a read-only, layered filesystem snapshot — your app plus its exact runtime environment, built once from a Dockerfile. An image never runs; it's a blueprint.
A container is a running (or stopped) instance of an image, with its own writable layer on top and its own process, network namespace, and lifecycle. The same image can produce many independent containers.
A registry is where images are stored and versioned for distribution — Docker Hub is the default public one, but most real teams run a private registry (AWS ECR, GitHub Container Registry, self-hosted) so proprietary images never touch a public host.

The relationship: you docker build a Dockerfile into an image, docker push that image to a registry, then docker pull and docker run it anywhere to produce a container.

See it in a real thing: one image, many containers

docker build -t myapp:1.4.0 .          # Dockerfile -> image
docker push registry.example.com/myapp:1.4.0   # image -> registry

docker run -d --name web1 myapp:1.4.0  # image -> container #1
docker run -d --name web2 myapp:1.4.0  # image -> container #2 — same image, independent process

Image: blueprint. Container: one running instance of it.Step 1 of 3

One image, built once from a Dockerfile — a read-only blueprint. It never runs by itself.

web1 and web2 share the same read-only image layers underneath — Docker doesn't duplicate that data — but each gets its own writable layer, its own memory, and its own process. Stopping and deleting web1 never touches the image or web2; the image is the reusable blueprint, the container is one disposable instance of it.

What people usually miss

Watch out

A tag is not a stable identity. myapp:latest is a mutable pointer that can point at a different image tomorrow — a real deploy pipeline pins an explicit version (myapp:1.4.0) or, more strictly, a content-addressed digest (myapp@sha256:...), because "latest" silently changing out from under a running system is a real, recurring incident category.
An image ID is content-addressed. It's a hash of the image's actual layer contents, not an arbitrary counter — which is what makes docker pull able to detect "I already have this exact image" and skip re-downloading identical layers.
A registry is not a container runtime. It's just storage and distribution for images — nothing about a registry runs anything; that's the whole job of the docker run step, on whatever host pulls the image.
Stopping a container isn't the same as removing it. A stopped container still exists (with its writable layer intact, restartable with docker start) until it's explicitly removed with docker rm — a common early mistake is assuming a stopped container is already gone.

Why this matters in interviews

"What's the difference between an image and a container?" is asked often enough to be a genuine filter question — not because it's hard, but because casual Docker usage lets people get by without ever needing the precise distinction. Answering with the blueprint/instance relationship, unprompted, signals real usage rather than memorized definitions.