Glossary — Speak the Language
The five friends may use lunch box words, but in job interviews and documentation people use these. This page has everything you need to talk about Docker with confidence: a quick-reference table, a set of interview-ready answers (the kind of thing you can say out loud in an interview), and a Classic Interview Q&A section with the questions that come up again and again.
Quick Reference
| Term | Lunch box meaning | Plain meaning |
|---|---|---|
| Docker | The magic lunch box system | A platform for building, sharing, and running applications in isolated, portable environments |
| Container | A packed lunch box | A lightweight, isolated process that runs an application with all its dependencies — shares the host OS kernel but has its own filesystem |
| Image | A recipe card | A read-only template containing the OS, libraries, runtime, and app code — used to create containers |
| Dockerfile | The recipe instructions | A text file with step-by-step instructions for building a Docker image |
| Layer | A Tupperware in the stack | Each instruction in a Dockerfile adds a layer; layers are cached and reused across builds |
| Registry | The shared kitchen shelf | A storage service for Docker images (Docker Hub, AWS ECR, GitHub Container Registry) |
| Docker Hub | The public kitchen shelf | Docker's default public registry — millions of free and paid images |
| Tag | The label on the lunch box | A name + version label for an image (e.g., nginx:1.25) — latest is the default |
| Volume | The Tupperware for leftovers | Persistent storage managed by Docker — data survives container removal |
| Bind Mount | Linking your fridge to the container | Mapping a host directory into a container — changes on either side are reflected instantly |
| tmpfs Mount | A temporary plate | In-memory storage that disappears when the container stops |
| Network | The lunch box carrier's compartments | An isolated bridge that lets containers communicate with each other and the host |
| Bridge network | The default compartment | Docker's default network — containers on the same bridge can talk; others can't |
| Port mapping | The straw hole in the lunch box | Maps a host port to a container port (-p 8080:80) so external traffic reaches the container |
| Docker Compose | The lunch box carrier | A tool for defining and running multi-container apps using a YAML file |
| docker-compose.yml | The carrier's manifest | The YAML file listing all services, networks, and volumes for a multi-container app |
| Service | A type of lunch in the carrier | A category of containers defined in docker-compose (e.g., "web", "db") |
| Detached mode | Letting the lunch box run on its own | Running a container in the background (-d flag) — it continues after the terminal closes |
| Interactive mode | Opening the lunch box and stepping inside | Running a container with -it so you can type inside it |
| Entrypoint | The first thing the lunch box does when opened | The main command a container runs — cannot be overridden without --entrypoint |
| CMD | The default dish | The default command for a container — can be overridden at docker run |
| Health check | Quality inspector | A command Docker runs periodically to verify a container is working correctly |
| Cache | The pre-cooked ingredients shelf | Docker stores intermediate layers so rebuilds skip unchanged steps |
| Prune | Cleaning out expired food | Remove unused Docker objects (docker system prune) |
| Dockerignore | The scraps drawer | A file listing paths Docker should exclude from the build context |
| Multi-stage build | Cooking in a big kitchen, serving in a small box | Using multiple FROM instructions to build in one image and copy artifacts to a smaller final image |
| Daemon | The kitchen manager running in the background | The Docker Engine process that handles all Docker operations |
| Docker Desktop | The kitchen management app | A GUI application for managing Docker on Mac and Windows |
| OCI | The lunch box industry standard | Open Container Initiative — the standards Docker follows for image and container formats |
| Ephemeral | Disposable lunch boxes | Containers are temporary by default — data is lost when removed unless volumes are used |
Interview-Ready Answers
These are written the way you'd actually say them in an interview — a definition, when to use it, and the gotcha interviewers listen for.
Core Concepts
Container A container is a lightweight, isolated process that packages an application together with everything it needs to run — libraries, runtime, configuration, and dependencies. Unlike a virtual machine, it shares the host operating system's kernel, which makes it much faster to start and much smaller in size. Containers are the "it works everywhere" solution — you build once and run the same on any machine with Docker. The gotcha: containers are ephemeral by default. If the container is removed, its data is gone. Use volumes for anything that needs to survive.
Image An image is a read-only template used to create containers. It contains the operating system, application code, runtime, libraries, and configuration, all stacked in layers. When you run an image, Docker creates a writable container from it. Images are built from Dockerfiles and stored in registries. The gotcha: images are immutable. You never modify an image — you build a new one. This is what makes them predictable and safe.
Dockerfile A Dockerfile is a text file with step-by-step instructions for building a Docker image. Each instruction (FROM, COPY, RUN, CMD) adds a layer to the image. Dockerfiles are the "recipe" for your application. The gotcha: layer ordering matters. Copy dependency files before source code so that dependency installation is cached and doesn't rerun on every code change.
Volume A volume is a persistent storage mechanism managed by Docker. It lives outside the container's writable layer, so data survives container restarts and removal. Volumes are the answer to "where do I store my database data?" The gotcha: bind mounts (mapping a host directory) work for development but volumes are better for production because they're managed by Docker and portable across platforms.
Architecture & Networking
Multi-stage build A multi-stage build uses multiple FROM instructions in a single Dockerfile. The first stage compiles or builds the application, and the second stage copies only the built artifacts into a smaller, cleaner final image. This dramatically reduces image size (often from gigabytes to megabytes) and removes build tools from the production image. The gotcha: you must name stages with AS and reference them with --from.
Health check A health check is a command Docker runs periodically to verify that a container is functioning correctly. It can return healthy, unhealthy, or starting. Health checks are critical for production because a container can be "running" but actually broken. The gotcha: health checks add overhead. Use lightweight checks (curl, wget, pg_isready) and reasonable intervals.
Port mapping
Port mapping (-p HOST:CONTAINER) connects a port on your computer to a port inside the container. Without it, the container's ports are isolated and unreachable from outside. The gotcha: the format is HOST:CONTAINER, not CONTAINER:HOST. -p 8080:80 means "host port 8080 → container port 80."
Docker Compose
Docker Compose is a tool for defining and running multi-container applications using a YAML file. It manages services, networks, and volumes as a single unit. You write docker-compose.yml once and run docker compose up to start everything. The gotcha: Compose is for single-host orchestration. For multi-host (multiple servers), you need Kubernetes or Docker Swarm.
Best Practices
Layer caching Docker caches each layer of an image. If a layer hasn't changed since the last build, Docker reuses it instead of rebuilding. This makes rebuilds dramatically faster. The gotcha: COPY and ADD invalidate all subsequent layers. Put rarely-changing layers (like dependency installation) before frequently-changing layers (like source code).
.dockerignore A .dockerignore file lists files and directories that Docker should exclude from the build context. Without it, Docker sends everything (including .git, node_modules, and .env) to the daemon, making builds slower and images larger. The gotcha: .dockerignore looks like .gitignore but uses Docker-specific syntax. Always create one.
Classic Interview Q&A
Q1: What is the difference between a Docker container and a virtual machine?
Answer: A container shares the host OS kernel and isolates the application at the process level. A VM includes an entire guest OS and runs on a hypervisor. Containers start in milliseconds, use far less memory, and are more portable. VMs provide stronger isolation because they have their own kernel. In practice, containers are preferred for microservices and CI/CD, while VMs are used when you need different operating systems or strong security boundaries.
Q2: What is the difference between COPY and ADD in a Dockerfile?
Answer: COPY copies files from the build context into the image. ADD does the same but also supports URL downloads and automatic tar extraction. In practice, always prefer COPY — it's explicit and predictable. ADD's extra features can cause unexpected behavior and are rarely needed.
Q3: What is the difference between CMD and ENTRYPOINT?
Answer: CMD provides the default command that runs when a container starts. It can be overridden at docker run. ENTRYPOINT defines the main executable and is harder to override (requires --entrypoint). The common pattern is to use ENTRYPOINT for the main command and CMD for default arguments. For example, ENTRYPOINT ["python"] CMD ["app.py"] runs "python app.py" by default but allows overriding just the arguments.
Q4: How do you reduce Docker image size?
Answer: Use multi-stage builds to separate build dependencies from runtime. Use small base images (alpine, distroless, scratch). Combine RUN instructions to reduce layers. Remove unnecessary files with .dockerignore. Don't install dev tools in production images. The biggest wins are usually multi-stage builds and switching from full images to alpine variants.
Q5: What happens to container data when the container is removed?
Answer: By default, all data in the container's writable layer is lost when the container is removed. This is by design — containers are ephemeral. To persist data, use Docker volumes or bind mounts. Volumes are managed by Docker and survive container removal. Bind mounts map a host directory into the container, so data stays on the host.
Q6: Explain the Docker build cache. How does it work?
Answer: Docker caches each layer of an image. When you rebuild, Docker checks each instruction. If the instruction and its inputs haven't changed, Docker reuses the cached layer. COPY and ADD invalidate the cache for all subsequent layers based on file checksums. To maximize cache hits, put stable layers (base image, dependency installation) before changing layers (source code). The --no-cache flag forces a full rebuild.
Q7: What is the difference between docker-compose down and docker-compose down -v?
Answer: docker-compose down stops and removes containers and networks but leaves volumes intact. docker-compose down -v also removes named volumes, which means all persistent data (databases, uploaded files) is deleted. Use -v only when you want a completely fresh start.