A municipal developer packages the inspection API as a Docker artifact for later runs on laptops and in OCI. Which statement correctly distinguishes image from container?
Select an answer to reveal the explanation.
Short Explanation
An image is the sealed recipe card; a container is one meal cooked from that card. You version and ship the card; you start, stop, and replace each meal.
Full Explanation
A Docker image is the read-only packaged filesystem plus metadata—the immutable artifact you build, tag, push, and pull for the inspection API. A container is a running instance of that image: process lifecycle, writable layer, and runtime configuration layered on the template. You version and distribute the image; you start, stop, replace, and inspect containers. Keeping that distinction clear prevents wrong mental models about what lives in a registry versus what occupies a host.
Calling the container the immutable template and the image the running process reverses the terms and will mislead every later discussion of push, pull, and scale. Treating image and container as interchangeable names for a Kubernetes Pod conflates Docker packaging with an orchestration object that can hold multiple containers. Saying a container is only the Dockerfile text confuses the recipe with both the built artifact and the runtime instance; an image is not born from the first HTTP request either.
Exam caveat: multiple containers can share one image; stopping or removing containers does not remove the image unless you explicitly delete it. Operational check: after docker build, list images and running containers separately and confirm the same image ID backs more than one container name when you run the inspection API twice.