Understanding Docker Images u0026 Layers Quiz Quiz

Explore core concepts of Docker images and layers with scenario-based questions. This quiz assesses your understanding of image structure, layer management, optimization techniques, and common pitfalls in containerization workflows.

1. Understanding Layer Structure

   What happens if a Dockerfile instruction near the beginning of a build is changed before rebuilding the image?

   1. No layers are rebuilt if caching is enabled
   2. Only the changed layer and the final layer are rebuilt
   3. All previous layers remain unchanged and only the new instruction is built
   4. All layers after the changed instruction are rebuilt

   Explanation: When an instruction is modified in a Dockerfile, all subsequent layers built on top of it will be invalidated and need to be rebuilt. This ensures consistency and reliability in the image. The option about only rebuilding the changed and final layer is incorrect because all following layers are affected. If caching is enabled, it only helps when instructions haven't changed, so saying no layers are rebuilt is incorrect. It's also misleading to say only the new instruction is rebuilt, as dependent layers must be recreated as well.

2. Image Layer Caching

   Why is it beneficial to place instructions that change infrequently near the top of a Dockerfile?

   1. It increases layer caching efficiency during image builds
   2. It prevents outdated layers from being deleted
   3. It reduces the size of the final image
   4. It makes image pulls faster from the registry

   Explanation: Placing infrequently changing instructions near the top maximizes the effectiveness of the build cache, so these layers do not need to be rebuilt every time. Image pull speed is generally not affected by instruction order but by overall image size. The image size itself is determined by content, not instruction ordering. Layer deletion is unrelated to Dockerfile instruction placement.

3. Shared Layers Across Images

   If two images share a common base layer but have different application code, how does this affect disk space usage?

   1. Every rebuild creates new copies of all layers
   2. The shared base layer is only stored once on disk
   3. Only the larger image keeps the base layer
   4. Each image always duplicates all its layers on disk

   Explanation: Docker stores image layers using content-based hashes, so any layer that is identical between images will be stored only once to optimize disk usage. It's incorrect that each image duplicates all layers; only unique layers are duplicated. The idea that only the larger image keeps the base layer is incorrect, as all images reference the shared layer. Rebuilds only create new copies for altered layers, not for layers unchanged.

4. Layer Optimization Techniques

   Which strategy helps to minimize the number of layers in a Docker image without affecting the final result?

   1. Combining related commands into a single RUN instruction
   2. Splitting each command into individual RUN instructions
   3. Adding extra COPY instructions for backup files
   4. Duplicating the base image setup in every layer

   Explanation: By chaining multiple commands into one RUN instruction, you reduce the number of intermediate layers created, making the image more efficient. Adding extra COPY instructions actually increases the number of layers and may lead to redundancy. Splitting each command into its own RUN creates unnecessary layers. Duplicating the base image setup is inefficient and increases image size unnecessarily.

5. Identifying Impactful Instructions

   Which Dockerfile instruction most often leads to creating a new layer that significantly increases image size if misused?

   1. WORKDIR
   2. COPY
   3. CMD
   4. EXPOSE

   Explanation: COPY adds files or directories from the build context to the image, and unnecessary or large files can greatly increase the image size if not managed carefully. CMD only sets default commands for the container, not adding data, so it doesn't affect size. EXPOSE simply indicates which ports should be accessible, without impacting size. WORKDIR sets the working directory and doesn't store files, so it has minimal impact on image size.