Advanced
Containers & Virtualization
#dockerfile#multi-stage-build#layer-caching
Dockerfile Writing Vocabulary
5 exercises — Master the English vocabulary of writing production-quality Dockerfiles: COPY vs ADD, CMD vs ENTRYPOINT, multi-stage builds, and layer caching.
0 / 26 completed
1 / 26
A code review comment reads: "You're using ADD to copy your application source into the image. Replace it with COPY — ADD has extra behaviour you don't need here, and it makes the Dockerfile harder to reason about."
Which statement best describes the key difference between COPY and ADD?
COPY is explicit; ADD has hidden "magic" that is rarely what you want.
Both
1. It can fetch files from remote URLs (a security risk if misused — the URL content is not verified at build time)
2. It automatically extracts
Docker's official best practices recommend using
Key vocabulary:
• COPY — Dockerfile instruction that copies local files or directories from the build context into the image
• ADD — like COPY, but also supports remote URL fetching and automatic archive extraction
• build context — the set of files sent to the Docker daemon when running
• layer — each Dockerfile instruction creates an immutable image layer stacked on the previous one
Both
COPY and ADD place files into the image, but ADD has two additional behaviours:1. It can fetch files from remote URLs (a security risk if misused — the URL content is not verified at build time)
2. It automatically extracts
.tar, .tar.gz, and other archive formatsDocker's official best practices recommend using
COPY for all local file operations and reserving ADD only for the rare case where automatic tar extraction is explicitly needed. Any valid use of ADD for remote URLs should be replaced by a RUN curl | tar pattern so the source and verification are explicit.Key vocabulary:
• COPY — Dockerfile instruction that copies local files or directories from the build context into the image
• ADD — like COPY, but also supports remote URL fetching and automatic archive extraction
• build context — the set of files sent to the Docker daemon when running
docker build• layer — each Dockerfile instruction creates an immutable image layer stacked on the previous one
2 / 26
A Dockerfile review note reads: "The final image weighs 1.4 GB because it includes the Node.js compiler toolchain and dev dependencies. Refactor to a multi-stage build — keep the build tools in the builder stage and use COPY --from=builder to bring only the compiled output into a slim final image."
What does COPY --from=builder do?
Multi-stage builds use COPY --from to extract only the artifacts that belong in the final image.
A multi-stage Dockerfile uses multiple
The result is a minimal final image containing only runtime artifacts. Combined with a distroless or
Key vocabulary:
• multi-stage build — a Dockerfile pattern using multiple FROM instructions to produce a minimal final image
• builder stage — an intermediate stage that compiles or bundles artifacts but is discarded from the final image
• COPY --from — copies files from a named stage or external image rather than the build context
• distroless — a minimal base image containing only the runtime (no shell, no package manager)
• final image size — the disk size of the published image; smaller means faster pulls and a smaller attack surface
A multi-stage Dockerfile uses multiple
FROM instructions. You can name a stage with AS (e.g., FROM node:20 AS builder). In a later stage, COPY --from=builder /app/dist ./dist copies only the compiled output — without any of the builder stage's Node modules, compiler, or test tooling making it into the final image.The result is a minimal final image containing only runtime artifacts. Combined with a distroless or
node:20-alpine base, images can shrink from GB to tens of MB, reducing pull time, attack surface, and storage costs.Key vocabulary:
• multi-stage build — a Dockerfile pattern using multiple FROM instructions to produce a minimal final image
• builder stage — an intermediate stage that compiles or bundles artifacts but is discarded from the final image
• COPY --from — copies files from a named stage or external image rather than the build context
• distroless — a minimal base image containing only the runtime (no shell, no package manager)
• final image size — the disk size of the published image; smaller means faster pulls and a smaller attack surface
3 / 26
A developer notices that npm install runs on every Docker build, even when only application source code changed. A senior engineer explains: "Copy package.json and package-lock.json first, run npm install, then copy the rest of the source. That way npm install only re-runs when dependencies actually change."
Which Docker build mechanism does this advice leverage?
Structuring the Dockerfile to exploit layer caching is the most common optimisation pattern.
Docker caches each layer. When a layer's instruction or its input files change, that layer and all subsequent layers are invalidated and re-executed. If you copy the entire source directory first, then
The fix is to copy only
Key vocabulary:
• layer cache — Docker's mechanism for reusing unchanged layers from a previous build
• cache invalidation — the event where a layer's hash changes, causing it and all downstream layers to re-execute
• cache hit — when Docker reuses a previously built layer without re-executing its instruction
• dependency manifest — a file declaring project dependencies (package.json, requirements.txt, go.mod)
• build time — total elapsed time for the
Docker caches each layer. When a layer's instruction or its input files change, that layer and all subsequent layers are invalidated and re-executed. If you copy the entire source directory first, then
npm install, any source file change invalidates the install layer — even if no dependency changed.The fix is to copy only
package.json + package-lock.json → run npm install → then copy the rest of the source. Now the install layer is only busted when package.json or package-lock.json actually changes, turning a 2-minute install into a cache hit on most builds.Key vocabulary:
• layer cache — Docker's mechanism for reusing unchanged layers from a previous build
• cache invalidation — the event where a layer's hash changes, causing it and all downstream layers to re-execute
• cache hit — when Docker reuses a previously built layer without re-executing its instruction
• dependency manifest — a file declaring project dependencies (package.json, requirements.txt, go.mod)
• build time — total elapsed time for the
docker build command to complete4 / 26
Two Dockerfile endings are compared in a team discussion:
Option A: CMD ["/app/server", "--port", "8080"]
Option B: ENTRYPOINT ["/app/server"] + CMD ["--port", "8080"]
A developer says: "Option B lets you override just the port flag at docker run time without replacing the binary." Which statement correctly explains the ENTRYPOINT / CMD relationship?
ENTRYPOINT is the fixed executable; CMD is the default argument list — separately overridable.
When you run
Both can be written in exec form (JSON array:
Key vocabulary:
• ENTRYPOINT — the fixed executable the container always runs; not overridden by docker run arguments
• CMD — default arguments to ENTRYPOINT (or the default command if ENTRYPOINT is not set); overridable at docker run
• exec form — JSON array syntax:
• shell form — string syntax: runs via
• PID 1 — the first process in the container; must handle SIGTERM for graceful shutdown
When you run
docker run myimage --port 9090, the value --port 9090 replaces the CMD defaults but not the ENTRYPOINT — the server binary still starts. This makes ENTRYPOINT + CMD the standard pattern for executable container images.Both can be written in exec form (JSON array:
["cmd", "arg"]) or shell form (plain string: cmd arg). Exec form is strongly preferred: the process becomes PID 1 and receives OS signals directly. Shell form wraps the command in /bin/sh -c, making the shell PID 1 and causing SIGTERM to not reach the application.Key vocabulary:
• ENTRYPOINT — the fixed executable the container always runs; not overridden by docker run arguments
• CMD — default arguments to ENTRYPOINT (or the default command if ENTRYPOINT is not set); overridable at docker run
• exec form — JSON array syntax:
["/app/server", "--port", "8080"]; receives OS signals directly• shell form — string syntax: runs via
/bin/sh -c; the shell becomes PID 1 and may swallow signals• PID 1 — the first process in the container; must handle SIGTERM for graceful shutdown
5 / 26
A senior engineer asks: "Add a standard header comment block at the top of the Dockerfile so future maintainers immediately understand the base image rationale, build target, build command, and owner — without reading the entire file."
Which example best represents a professional Dockerfile header block?
A professional Dockerfile header uses comments to convey rationale, usage, and ownership.
A well-structured header block (using
•
• Base image choice and rationale (why Alpine vs. Debian, why this specific version)
• Build target description (production runtime, test image, etc.)
• The exact
• Author / owning team and contact
Key vocabulary:
• syntax directive —
• LABEL — Dockerfile instruction adding key-value metadata to the image, readable via
• header comment block — structured comments at the top documenting purpose, usage, and ownership
• BuildKit — Docker's modern build backend with improved caching, parallelism, and secrets support
A well-structured header block (using
# comment lines) typically includes:•
# syntax=docker/dockerfile:1 — enables BuildKit features and must be the very first line• Base image choice and rationale (why Alpine vs. Debian, why this specific version)
• Build target description (production runtime, test image, etc.)
• The exact
docker build command to run• Author / owning team and contact
LABEL instructions (Option C) add machine-readable metadata inspectable via docker inspect — valuable for tooling — but do not serve as human-readable Dockerfile documentation. Option A is wrong: clear documentation is a best practice. Option B is too sparse to convey meaningful context.Key vocabulary:
• syntax directive —
# syntax=docker/dockerfile:1; must be the first line; opts into the BuildKit parser• LABEL — Dockerfile instruction adding key-value metadata to the image, readable via
docker inspect• header comment block — structured comments at the top documenting purpose, usage, and ownership
• BuildKit — Docker's modern build backend with improved caching, parallelism, and secrets support
6 / 26
During a Slack discussion about optimizing image size, a developer proposes using the
docker commit command to directly modify an existing container and create a new image. A senior engineer responds: 'That's not ideal; it creates a fragile build process and obscures the original steps. Let's use a Dockerfile instead.' What is the primary reason for the senior engineer's recommendation? [Image API Response]
{"status": "success", "message": "Dockerfile best practices promote reproducibility and clarity, while `docker commit` introduces unnecessary complexity and potential inconsistencies."}The senior engineer's recommendation stems from the fact that `docker commit` bypasses the defined build steps in a Dockerfile, leading to an unpredictable and difficult-to-reproduce build process. Using a Dockerfile enforces consistency, allows for version control of the build instructions, and provides greater transparency into how the image is created – which is crucial for maintainability and collaboration. `docker commit` creates a black box that obscures the original steps.
7 / 26
You're building a CI/CD pipeline to deploy your application. During a Slack discussion about image layers and build times, a developer suggests using multi-stage builds to minimize the final image size. Another developer responds: 'But if I use COPY --from=builder, won't that mean I have to manually copy all the necessary artifacts from one stage to another during the Docker build process? That seems overly complex.' Which of the following best describes why
COPY --from is a more efficient approach in this scenario?COPY --from leverages Docker's built-in layering mechanism. It allows you to copy specific artifacts (like compiled binaries or static assets) from one stage of a multi-stage build—the 'builder' stage in this case—directly into the final image layer without including the entire builder stage itself. This dramatically reduces the size of the final image and minimizes redundant layers, leading to faster build times compared to manually copying everything during the Docker build process.8 / 26
During a code review of a Dockerfile for a microservice, a developer proposes using `VOLUME` instructions to persist application data. A senior engineer pushes back, stating that relying on volumes can introduce unexpected complexities and potential security vulnerabilities. Which statement best describes the primary concern raised by the senior engineer regarding the use of
Option A: Using
Option B:
Option C:
Option D: Using
VOLUME instructions in a Dockerfile? Option A: Using
VOLUME always guarantees faster startup times compared to other storage methods.Option B:
VOLUME automatically handles data encryption and backups, simplifying operational tasks.Option C:
VOLUME can lead to inconsistencies in data management if not carefully configured, potentially causing application errors or data loss. Option D: Using
VOLUME is the only supported method for storing persistent data within a Docker container.The senior engineer's concern centers on the potential for misconfiguration and inconsistency when managing data with
VOLUME. While volumes *can* be used effectively, they require careful planning regarding mounting points, permissions, and synchronization – failing to do so can lead to data corruption or application instability. Options A, B, and D are all incorrect as they present oversimplified or misleading claims about the functionality of VOLUME instructions.9 / 26
During a standup update, the development team discussed issues with build times for their new API service. One developer reported that each Docker build took over 15 minutes, despite only minor code changes. The team lead asked, 'What are some strategies we could employ to significantly reduce these build times?'
The correct answer – utilizing caching mechanisms within the Docker image builder – directly addresses the problem of redundant dependency installations. Docker BuildKit's parallel builds and layer caching dramatically reduce build times by reusing previously built layers instead of rebuilding them from scratch. The other options represent broader CI/CD practices or less targeted solutions that wouldn't specifically address the identified bottleneck in the API service's Docker build process.
10 / 26
During a Slack discussion about optimizing image size, a developer proposes using the
docker commit command to directly modify an existing container and create a new image. A senior engineer responds: 'That's not ideal; it creates a fragile build process and obscures the original steps. Let's use a Dockerfile instead.' What is the primary reason for the senior engineer's recommendation? [Image API Response]
{"status": "success", "message": "Dockerfile best practices promote reproducibility and clarity, while `docker commit` introduces unnecessary complexity and potential inconsistencies."}The senior engineer's recommendation stems from the fact that `docker commit` bypasses the defined build steps in a Dockerfile, leading to an unpredictable and difficult-to-reproduce build process. Using a Dockerfile enforces consistency, allows for version control of the build instructions, and provides greater transparency into how the image is created – which is crucial for maintainability and collaboration. `docker commit` creates a black box that obscures the original steps.
11 / 26
You're building a CI/CD pipeline to deploy your application. During a Slack discussion about image layers and build times, a developer suggests using multi-stage builds to minimize the final image size. Another developer responds: 'But if I use COPY --from=builder, won't that mean I have to manually copy all the necessary artifacts from one stage to another during the Docker build process? That seems overly complex.' Which of the following best describes why
COPY --from is a more efficient approach in this scenario?COPY --from leverages Docker's built-in layering mechanism. It allows you to copy specific artifacts (like compiled binaries or static assets) from one stage of a multi-stage build—the 'builder' stage in this case—directly into the final image layer without including the entire builder stage itself. This dramatically reduces the size of the final image and minimizes redundant layers, leading to faster build times compared to manually copying everything during the Docker build process.12 / 26
During a code review of a Dockerfile for a microservice, a developer proposes using `VOLUME` instructions to persist application data. A senior engineer pushes back, stating that relying on volumes can introduce unexpected complexities and potential security vulnerabilities. Which statement best describes the primary concern raised by the senior engineer regarding the use of
Option A: Using
Option B:
Option C:
Option D: Using
VOLUME instructions in a Dockerfile? Option A: Using
VOLUME always guarantees faster startup times compared to other storage methods.Option B:
VOLUME automatically handles data encryption and backups, simplifying operational tasks.Option C:
VOLUME can lead to inconsistencies in data management if not carefully configured, potentially causing application errors or data loss. Option D: Using
VOLUME is the only supported method for storing persistent data within a Docker container.The senior engineer's concern centers on the potential for misconfiguration and inconsistency when managing data with
VOLUME. While volumes *can* be used effectively, they require careful planning regarding mounting points, permissions, and synchronization – failing to do so can lead to data corruption or application instability. Options A, B, and D are all incorrect as they present oversimplified or misleading claims about the functionality of VOLUME instructions.13 / 26
During a standup update, the development team discussed issues with build times for their new API service. One developer reported that each Docker build took over 15 minutes, despite only minor code changes. The team lead asked, 'What are some strategies we could employ to significantly reduce these build times?'
The correct answer – utilizing caching mechanisms within the Docker image builder – directly addresses the problem of redundant dependency installations. Docker BuildKit's parallel builds and layer caching dramatically reduce build times by reusing previously built layers instead of rebuilding them from scratch. The other options represent broader CI/CD practices or less targeted solutions that wouldn't specifically address the identified bottleneck in the API service's Docker build process.
14 / 26
During a Slack discussion about optimizing image size, a developer proposes using the
docker commit command to directly modify an existing container and create a new image. A senior engineer responds: 'That's not ideal; it creates a fragile build process and obscures the original steps. Let's use a Dockerfile instead.' What is the primary reason for the senior engineer's recommendation? [Image API Response]
{"status": "success", "message": "Dockerfile best practices promote reproducibility and clarity, while `docker commit` introduces unnecessary complexity and potential inconsistencies."}The senior engineer's recommendation stems from the fact that `docker commit` bypasses the defined build steps in a Dockerfile, leading to an unpredictable and difficult-to-reproduce build process. Using a Dockerfile enforces consistency, allows for version control of the build instructions, and provides greater transparency into how the image is created – which is crucial for maintainability and collaboration. `docker commit` creates a black box that obscures the original steps.
15 / 26
You're building a CI/CD pipeline to deploy your application. During a Slack discussion about image layers and build times, a developer suggests using multi-stage builds to minimize the final image size. Another developer responds: 'But if I use COPY --from=builder, won't that mean I have to manually copy all the necessary artifacts from one stage to another during the Docker build process? That seems overly complex.' Which of the following best describes why
COPY --from is a more efficient approach in this scenario?COPY --from leverages Docker's built-in layering mechanism. It allows you to copy specific artifacts (like compiled binaries or static assets) from one stage of a multi-stage build—the 'builder' stage in this case—directly into the final image layer without including the entire builder stage itself. This dramatically reduces the size of the final image and minimizes redundant layers, leading to faster build times compared to manually copying everything during the Docker build process.16 / 26
During a code review of a Dockerfile for a microservice, a developer proposes using `VOLUME` instructions to persist application data. A senior engineer pushes back, stating that relying on volumes can introduce unexpected complexities and potential security vulnerabilities. Which statement best describes the primary concern raised by the senior engineer regarding the use of
Option A: Using
Option B:
Option C:
Option D: Using
VOLUME instructions in a Dockerfile? Option A: Using
VOLUME always guarantees faster startup times compared to other storage methods.Option B:
VOLUME automatically handles data encryption and backups, simplifying operational tasks.Option C:
VOLUME can lead to inconsistencies in data management if not carefully configured, potentially causing application errors or data loss. Option D: Using
VOLUME is the only supported method for storing persistent data within a Docker container.The senior engineer's concern centers on the potential for misconfiguration and inconsistency when managing data with
VOLUME. While volumes *can* be used effectively, they require careful planning regarding mounting points, permissions, and synchronization – failing to do so can lead to data corruption or application instability. Options A, B, and D are all incorrect as they present oversimplified or misleading claims about the functionality of VOLUME instructions.17 / 26
During a standup update, the development team discussed issues with build times for their new API service. One developer reported that each Docker build took over 15 minutes, despite only minor code changes. The team lead asked, 'What are some strategies we could employ to significantly reduce these build times?'
The correct answer – utilizing caching mechanisms within the Docker image builder – directly addresses the problem of redundant dependency installations. Docker BuildKit's parallel builds and layer caching dramatically reduce build times by reusing previously built layers instead of rebuilding them from scratch. The other options represent broader CI/CD practices or less targeted solutions that wouldn't specifically address the identified bottleneck in the API service's Docker build process.
18 / 26
During a Slack discussion about optimizing image size, a developer proposes using the
docker commit command to directly modify an existing container and create a new image. A senior engineer responds: 'That's not ideal; it creates a fragile build process and obscures the original steps. Let's use a Dockerfile instead.' What is the primary reason for the senior engineer's recommendation? [Image API Response]
{"status": "success", "message": "Dockerfile best practices promote reproducibility and clarity, while `docker commit` introduces unnecessary complexity and potential inconsistencies."}The senior engineer's recommendation stems from the fact that `docker commit` bypasses the defined build steps in a Dockerfile, leading to an unpredictable and difficult-to-reproduce build process. Using a Dockerfile enforces consistency, allows for version control of the build instructions, and provides greater transparency into how the image is created – which is crucial for maintainability and collaboration. `docker commit` creates a black box that obscures the original steps.
19 / 26
You're building a CI/CD pipeline to deploy your application. During a Slack discussion about image layers and build times, a developer suggests using multi-stage builds to minimize the final image size. Another developer responds: 'But if I use COPY --from=builder, won't that mean I have to manually copy all the necessary artifacts from one stage to another during the Docker build process? That seems overly complex.' Which of the following best describes why
COPY --from is a more efficient approach in this scenario?COPY --from leverages Docker's built-in layering mechanism. It allows you to copy specific artifacts (like compiled binaries or static assets) from one stage of a multi-stage build—the 'builder' stage in this case—directly into the final image layer without including the entire builder stage itself. This dramatically reduces the size of the final image and minimizes redundant layers, leading to faster build times compared to manually copying everything during the Docker build process.20 / 26
During a code review of a Dockerfile for a microservice, a developer proposes using `VOLUME` instructions to persist application data. A senior engineer pushes back, stating that relying on volumes can introduce unexpected complexities and potential security vulnerabilities. Which statement best describes the primary concern raised by the senior engineer regarding the use of
Option A: Using
Option B:
Option C:
Option D: Using
VOLUME instructions in a Dockerfile? Option A: Using
VOLUME always guarantees faster startup times compared to other storage methods.Option B:
VOLUME automatically handles data encryption and backups, simplifying operational tasks.Option C:
VOLUME can lead to inconsistencies in data management if not carefully configured, potentially causing application errors or data loss. Option D: Using
VOLUME is the only supported method for storing persistent data within a Docker container.The senior engineer's concern centers on the potential for misconfiguration and inconsistency when managing data with
VOLUME. While volumes *can* be used effectively, they require careful planning regarding mounting points, permissions, and synchronization – failing to do so can lead to data corruption or application instability. Options A, B, and D are all incorrect as they present oversimplified or misleading claims about the functionality of VOLUME instructions.21 / 26
During a standup update, the development team discussed issues with build times for their new API service. One developer reported that each Docker build took over 15 minutes, despite only minor code changes. The team lead asked, 'What are some strategies we could employ to significantly reduce these build times?'
The correct answer – utilizing caching mechanisms within the Docker image builder – directly addresses the problem of redundant dependency installations. Docker BuildKit's parallel builds and layer caching dramatically reduce build times by reusing previously built layers instead of rebuilding them from scratch. The other options represent broader CI/CD practices or less targeted solutions that wouldn't specifically address the identified bottleneck in the API service's Docker build process.
22 / 26
During a code review of a Dockerfile for a new web application, Alex comments: 'I'm concerned about the size of this image. It's over 2GB! Can we use a `.dockerignore` file to exclude unnecessary files from being copied into the image?' Ben replies: 'That's a good start, but it won't significantly reduce the layer sizes – Docker still layers everything. We need a more targeted approach.' Which of the following best describes Ben's concern?
The `.dockerignore` file only prevents files from being *copied* into the image; it doesn't affect the layers themselves. Docker's layering system creates distinct layers for each command, and changes to these layers contribute to overall size. Ben is correctly pointing out that excluding files isn't a reliable strategy for dramatically reducing layer sizes in this context.
23 / 26
Sarah, the team's DevOps engineer, is drafting a pull request description for a Dockerfile that includes an `ENV` instruction to set the timezone. A colleague asks: 'Is it best practice to define timezones in environment variables or should we use a base image with the appropriate timezone already configured?' What's Sarah's most accurate response?
While flexibility is a consideration, setting timezones in base images is a standard practice. It eliminates inconsistencies across different environments and simplifies the Dockerfile. Defining timezone within an environment variable adds unnecessary complexity for a relatively simple configuration and doesn't inherently provide superior control.
24 / 26
During a standup meeting, David reports: 'Building our microservice Docker images consistently takes over 30 minutes. I've checked the build steps, and everything seems straightforward.' The team suggests investigating potential causes. Which of the following is MOST likely contributing to this long build time?
Multi-stage builds can significantly increase build times if not carefully optimized. Each stage creates a new layer in the Docker image, and numerous stages lead to more layers and longer build durations. The other options are less likely to be the primary cause of such a prolonged build time.
25 / 26
You're reviewing a Dockerfile for an application that needs to persist data. The developer has included the following instruction: `VOLUME /app/data`. A senior engineer raises concerns. Which of the following statements BEST explains their reservation?
Volumes are indeed managed by Docker, but they can introduce operational complexities. Permissions issues and lifecycle management (e.g., when containers are stopped/deleted) are common concerns with volumes. While suitable for some scenarios, they aren't always the simplest or most robust solution for persistent data.
26 / 26
During a Slack channel discussion about optimizing Docker image sizes, a developer proposes using `docker commit` to modify an existing running container and create a new image. A senior engineer responds: 'That's not ideal; it creates a history of changes which can be difficult to manage and understand. It also doesn't guarantee consistency.' What does the senior engineer MOST likely mean?
`docker commit` creates layers based on the changes made *within* a running container. This results in a history of modifications that can be difficult to manage and reproduce, leading to inconsistencies. The standard approach is to build images from Dockerfiles – which provides a clear audit trail and ensures consistent builds.
Frequently Asked Questions
What does the "Dockerfile Writing Vocabulary" exercise practise?
Practice Dockerfile vocabulary in English: COPY vs ADD, CMD vs ENTRYPOINT, multi-stage builds, layer caching, and professional documentation. 5 advanced exercises.
How many questions are in this exercise?
This exercise has 26 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Advanced. If the vocabulary feels difficult, browse the Containers & Virtualization category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Dockerfile Writing Vocabulary" part of a larger series?
Yes — it's one exercise in the Containers & Virtualization category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Containers & Virtualization category page for related exercises, or browse the main Exercises hub for other IT English topics.