Study Hub / Docker Certified Associate (DCA) / Domain 2.0
Docker Certified Associate (DCA) Domain 2.0: Image Creation, Management, and Registry — Explained
Domain 2.0 is about the artifacts of Docker: how images are built from Dockerfiles, how layers make them efficient, and how registries store and distribute them. The image is the unit of Docker — understand it deeply.
Dockerfiles: recipes for images
- What a Dockerfile is — a text recipe: start FROM a base image, RUN commands to install things, COPY in your code, declare the CMD/ENTRYPOINT that runs at container start.
- Layer caching — each instruction creates a cached layer. Rebuilds reuse unchanged layers — so order matters: put slow-changing steps (dependency installs) before fast-changing ones (your code).
- Multi-stage builds — build in one stage (compilers, SDKs), copy only the result into a slim final stage. Small, secure production images without build tools.
- .dockerignore — excludes files from the build context (like .gitignore for builds): faster builds, no secrets accidentally baked in.
Layers, tags, and image anatomy
- Images are layered and read-only — stacked filesystem layers, each the diff of one instruction. Containers add a thin writable layer on top; delete the container and its writes vanish.
- Sharing — images sharing base layers store them once. Ten images FROM the same base = one copy of the base on disk.
- Tags vs. digests — tags (
:1.4) are movable labels; digests (@sha256:…) identify exact content.:latestis convenient and non-reproducible — pin versions that matter. - Image size discipline — slim bases, multi-stage builds, no build tools in production images. Smaller images pull faster, scan cleaner, and attack-surface less.
Registries: where images live
- What a registry does — stores images, serves pulls, controls access. Docker Hub is the public default; companies run private registries (Docker Trusted Registry / Harbor / cloud registries) for their own images.
- Repositories vs. registries — a registry hosts many repositories (one per image name), each holding tagged versions.
registry.example.com/team/app:2.0= registry / repository / tag. - Push/pull flow —
docker pushuploads new layers;docker pulldownloads missing ones. Only changed layers transfer — the rest is already local. - Signing and trust — content trust (Notary) signs images so consumers verify publisher identity and integrity. Pulling unsigned images from the internet is trusting strangers.
- Pruning — unused images, containers, and build cache accumulate:
docker system prunereclaims the disk. Registries need retention policies too.
The must-memorize table: Dockerfile instructions
What each instruction does.
| Instruction | Does | Notes |
|---|---|---|
| FROM | Sets the base image | First instruction; defines the starting layers |
| RUN | Executes a command at build time | Each RUN is a layer — combine with && where sensible |
| COPY / ADD | Copies files into the image | COPY is preferred; ADD has magic (tar/URL) you rarely want |
| WORKDIR | Sets the working directory | Creates it if missing; prefer over cd |
| ENV | Sets environment variables | Baked into the image — not for secrets |
| EXPOSE | Documents which ports the app uses | Documentation + inter-container discovery; doesn't publish |
| CMD / ENTRYPOINT | Default command at container start | ENTRYPOINT is harder to override; CMD is the default args |
Try it: 4 sample questions
Sample questions to check your understanding of this domain. Answers and full reasoning are tucked under each one.
1. A Dockerfile installs dependencies (slow, rarely changes) and then copies application code (fast, changes constantly). Why does the order matter?
- A. A. It doesn't — Docker rebuilds everything every time
- B. B. Layer caching: unchanged early layers are reused, so putting stable steps first makes rebuilds fast
- C. C. COPY must always be the last instruction by law
- D. D. RUN instructions can't come before COPY
Show answer & reasoning
B. Docker caches each layer and reuses it when the instruction and its inputs haven't changed. Dependencies-first means code changes only rebuild the last layers — seconds instead of minutes. Reverse the order and every code tweak reinstalls all dependencies. Order is performance.
2. A team's builds include the full JDK and build tools, producing 1.2GB production images. What is the standard fix?
- A. A. Buy bigger registry storage
- B. B. Multi-stage builds — compile in a builder stage, copy only the artifact into a slim runtime image
- C. C. Compress the image with gzip manually
- D. D. Use :latest tags
Show answer & reasoning
B. Multi-stage builds separate build-time needs (JDK, compilers) from runtime needs (JRE + app): the final image carries only what runs. Smaller images pull faster, scan faster, and expose less attack surface. Storage (A) treats the symptom.
3. Two teams push different images that both start FROM the same base image. How much extra disk does the second image's base layers consume?
- A. A. A full second copy
- B. B. Nothing extra — identical layers are stored once and shared
- C. C. Half, due to compression
- D. D. It depends on the tag name
Show answer & reasoning
B. Layers are content-addressed: identical layer = identical hash = stored once, referenced twice. This sharing is why a host with 50 images isn't 50× the base size — and why standardizing base images pays off in disk, pull time, and scanning.
4. A developer accidentally committed AWS keys into a Dockerfile ENV line and pushed the image to a registry. What are the two failures?
- A. A. ENV is deprecated; keys belong in CMD
- B. B. Secrets baked into image layers are permanent and distributed — use build secrets / runtime injection instead
- C. C. Registries can't store ENV variables
- D. D. AWS keys don't work in containers
Show answer & reasoning
B. Image layers are forever: anyone who pulls the image (now or from any cache/mirror) gets the keys, and "deleting" the line later doesn't purge existing copies. Secrets must arrive at runtime (mounted secrets, env from orchestrator) — never baked into layers. Rotate the keys immediately.
This was one domain. The simulator drills all 6.
This free preview covered Images & Registry (Domain 2.0, 20%). Not covered here: Orchestration (Domain 1.0, 25%); Security (Domain 5.0, 15%). Swarm orchestration and Docker security — the most scenario-heavy DCA material — stay in the paid guide and practice bank. The ByteBar Practice Exam Simulator drills every domain with 1,000 exam-style questions — $9.99 one-time unlocks all 28 exams. Prefer to read? The full DCA Study Guide is in the ByteBar shop on Etsy.
Practice Exam Simulator — $9.99 one-time, all 28 exams Full Study Guides on Etsy