Learn the IT-English vocabulary of optimising container images: layers, multi-stage builds, base images and image size.
0 / 18 completed
1 / 18
A Dockerfile uses a 'multi-stage build'. What is its main benefit?
Multi-stage builds discard build-time dependencies, producing a lean final image with only what runs.
2 / 18
What is an image 'layer'?
Each Dockerfile instruction creates a layer — a cached filesystem diff that can be reused across builds.
3 / 18
Switching to a 'slim' or 'alpine' base image aims to do what?
Minimal base images shrink size and reduce the number of packages that could carry vulnerabilities.
4 / 18
Why combine related RUN commands with '&&' in one layer?
Combining commands reduces layer count and lets you delete temp files before the layer is committed.
5 / 18
Which sentence correctly uses 'image bloat'?
Image bloat is unnecessary size from including files not needed at runtime.
6 / 18
Reviewer: 'Hey team, I've noticed this PR builds a really large image – over 3GB. Could you explore optimizing the layers? Specifically, are we using unnecessary intermediate containers here that could be combined or reduced in size? It's impacting deployment times significantly.'
The reviewer is raising a valid concern about image bloat, which is a key issue in container image optimization. Combining layers and reducing their size minimizes the overall image footprint, leading to faster builds, reduced storage needs, and quicker deployments. Ignoring layer size as the reviewer suggests would be a missed opportunity for improvement.
7 / 18
Sarah: 'I've just submitted this PR. It builds fine locally, but the CI system is failing because the resulting image size is over 5GB! I'm getting a timeout during deployment.'
Mark (code reviewer): 'That's concerning. Let's investigate. Can you tell me if you're running multiple commands within each Dockerfile layer? Are there any unnecessary dependencies being copied into the final image that aren't required at runtime?'
This scenario highlights a common issue with container image optimization – inefficient layering. Each `RUN` command creates a new layer, and if these commands aren't carefully orchestrated, they can lead to significant 'image bloat'. The correct answer focuses on the impact of multiple commands in layers, directly addressing Mark's question about Sarah's build issues; options A and B misdiagnose the problem (code size or CI timeout), while option C accurately describes the core issue and solution, and option D suggests an unrelated cause.
8 / 18
Reviewer: 'Hey team, I've noticed this PR builds a really large image – over 3GB. Could you explore optimizing the layers? Specifically, are we using unnecessary intermediate containers here that could be combined or reduced in size? It's impacting deployment times significantly.'
The reviewer is raising a valid concern about image bloat, which is a key issue in container image optimization. Combining layers and reducing their size minimizes the overall image footprint, leading to faster builds, reduced storage needs, and quicker deployments. Ignoring layer size as the reviewer suggests would be a missed opportunity for improvement.
9 / 18
Sarah: 'I've just submitted this PR. It builds fine locally, but the CI system is failing because the resulting image size is over 5GB! I'm getting a timeout during deployment.'
Mark (code reviewer): 'That's concerning. Let's investigate. Can you tell me if you're running multiple commands within each Dockerfile layer? Are there any unnecessary dependencies being copied into the final image that aren't required at runtime?'
This scenario highlights a common issue with container image optimization – inefficient layering. Each `RUN` command creates a new layer, and if these commands aren't carefully orchestrated, they can lead to significant 'image bloat'. The correct answer focuses on the impact of multiple commands in layers, directly addressing Mark's question about Sarah's build issues; options A and B misdiagnose the problem (code size or CI timeout), while option C accurately describes the core issue and solution, and option D suggests an unrelated cause.
10 / 18
Reviewer: 'Hey team, I've noticed this PR builds a really large image – over 3GB. Could you explore optimizing the layers? Specifically, are we using unnecessary intermediate containers here that could be combined or reduced in size? It's impacting deployment times significantly.'
The reviewer is raising a valid concern about image bloat, which is a key issue in container image optimization. Combining layers and reducing their size minimizes the overall image footprint, leading to faster builds, reduced storage needs, and quicker deployments. Ignoring layer size as the reviewer suggests would be a missed opportunity for improvement.
11 / 18
Sarah: 'I've just submitted this PR. It builds fine locally, but the CI system is failing because the resulting image size is over 5GB! I'm getting a timeout during deployment.'
Mark (code reviewer): 'That's concerning. Let's investigate. Can you tell me if you're running multiple commands within each Dockerfile layer? Are there any unnecessary dependencies being copied into the final image that aren't required at runtime?'
This scenario highlights a common issue with container image optimization – inefficient layering. Each `RUN` command creates a new layer, and if these commands aren't carefully orchestrated, they can lead to significant 'image bloat'. The correct answer focuses on the impact of multiple commands in layers, directly addressing Mark's question about Sarah's build issues; options A and B misdiagnose the problem (code size or CI timeout), while option C accurately describes the core issue and solution, and option D suggests an unrelated cause.
12 / 18
Reviewer: 'Hey team, I've noticed this PR builds a really large image – over 3GB. Could you explore optimizing the layers? Specifically, are we using unnecessary intermediate containers here that could be combined or reduced in size? It's impacting deployment times significantly.'
The reviewer is raising a valid concern about image bloat, which is a key issue in container image optimization. Combining layers and reducing their size minimizes the overall image footprint, leading to faster builds, reduced storage needs, and quicker deployments. Ignoring layer size as the reviewer suggests would be a missed opportunity for improvement.
13 / 18
Sarah: 'I've just submitted this PR. It builds fine locally, but the CI system is failing because the resulting image size is over 5GB! I'm getting a timeout during deployment.'
Mark (code reviewer): 'That's concerning. Let's investigate. Can you tell me if you're running multiple commands within each Dockerfile layer? Are there any unnecessary dependencies being copied into the final image that aren't required at runtime?'
This scenario highlights a common issue with container image optimization – inefficient layering. Each `RUN` command creates a new layer, and if these commands aren't carefully orchestrated, they can lead to significant 'image bloat'. The correct answer focuses on the impact of multiple commands in layers, directly addressing Mark's question about Sarah's build issues; options A and B misdiagnose the problem (code size or CI timeout), while option C accurately describes the core issue and solution, and option D suggests an unrelated cause.
14 / 18
You're reviewing a PR that uses a Dockerfile with multiple layers. A teammate comments: 'This image is quite large – over 1GB. Can we explore ways to reduce the size?' Which of the following best explains why this might be happening and what you should suggest?
<strong>Option A:</strong>> Each `RUN` command creates a new layer, combining them all into one large image.
<strong>Option B:</strong>) Docker builds images sequentially, adding each instruction as a separate layer, regardless of dependencies.
<strong>Option C:</strong>) Using multiple layers is always beneficial for complex applications, ensuring greater flexibility and modularity.
<strong>Option D:</strong>) Each `RUN` command implicitly combines all subsequent commands into a single layer, minimizing image size.
The core principle of Docker layering is that each `RUN` instruction creates a new layer. Combining related commands with `&&` reduces the number of layers created, but doesn't fundamentally change this behavior. Option A accurately reflects how layers are built, and option C is a misleading overstatement.
15 / 18
Sarah: 'I've just submitted this PR. It builds fine locally, but the CI system is failing because the resulting image size is over 5GB! I'm getting a timeout during deployment.' Mark (code reviewer): 'That's concerning – let's investigate the layers.' What does Sarah likely mean when she mentions 'the resulting image size is over 5GB'?
<strong>Option A:</strong>) The CI system is configured to fail if any layer exceeds a certain byte limit.
<strong>Option B:</strong>) The final image built by Docker contains more data than expected, increasing its size and potentially causing deployment issues.
<strong>Option C:</strong>) The CI system is intentionally adding extra layers to improve security and performance.
<strong>Option D:</strong>) Sarah's local build environment has a different image size than the one deployed by the CI system.
Sarah's statement indicates that the final Docker image built during deployment is excessively large. This likely means there are redundant instructions or unnecessary data being included in the layers, leading to an inflated image size – a common problem when optimizing container images.
16 / 18
You're investigating why your Docker builds are taking so long. You notice that each `RUN` command in your Dockerfile is creating a new layer. What's the *most* effective immediate step to reduce build times?
<strong>Option A:</strong>) Increase the CPU resources allocated to the Docker daemon.
<strong>Option B:</strong>) Combine multiple `RUN` commands using `&&` within a single layer, where possible.
<strong>Option C:</strong>) Use a faster storage device for your Docker build environment.
<strong>Option D:</strong>) Delete all unused layers from the image to reduce its size.
Each `RUN` command creates a new layer, which requires Docker to re-execute the entire instruction set during each subsequent build. Combining commands using `&&` minimizes the number of layers and therefore significantly reduces rebuild times – this is the core optimization technique.
17 / 18
A developer tells you: 'I'm trying to optimize my Dockerfile, but I'm not sure how to best manage dependencies. Should I install all dependencies in a single layer or spread them across multiple layers?'
<strong>Option A:</strong>) Always install all dependencies in a single layer for simplicity and ease of management.
<strong>Option B:</strong>) Spread dependencies across multiple layers, installing them as needed during the build process.
<strong>Option C:</strong>) Use a multi-stage Dockerfile to separate build-time and runtime dependencies.
<strong>Option D:</strong>) Ignore dependency management entirely, as it's the primary cause of large image sizes.
Employing a multi-stage Dockerfile is *the* best practice for managing dependencies. It allows you to use one stage (typically larger) for building and installing dependencies, then copy only the necessary artifacts into a smaller, runtime-optimized image. This drastically reduces final image size.
18 / 18
You're reviewing a Dockerfile that has many `RUN` commands, each creating a new layer. Which of the following best describes the *primary* reason for this inefficiency?
<strong>Option A:</strong>) Docker automatically adds layers to every command for security purposes.
<strong>Option B:</strong>) Each `RUN` instruction creates a new, immutable layer in the image, regardless of whether it's dependent on previous layers.
<strong>Option C:</strong>) Docker layers are only created when a file is modified during the build process.
<strong>Option D:</strong>) Docker layers are optimized for speed, and multiple commands always result in faster builds.
The core inefficiency lies in Docker's layer system. Every `RUN` instruction creates a new, independent layer. This means that subsequent changes to the image require Docker to rebuild *all* layers after that point – this is what causes slow build times and large images.
What does the "Container Image Optimization & Layers" exercise practise?
Learn the IT-English vocabulary of optimising container images: layers, multi-stage builds, base images and image size.
How many questions are in this exercise?
This exercise has 18 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. 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 "Container Image Optimization & Layers" 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.