Docker Builds u0026 Container Publishing with GitHub Actions Quiz Quiz

Assess your understanding of building Docker images and publishing containers using GitHub Actions. Explore key workflows, best practices, and troubleshooting points for efficient Docker automation in continuous integration and deployment pipelines.

1. Workflow Triggering

   Which workflow trigger should you configure in your workflow file if you want a container image to be built and published only when changes are pushed to the main branch?

   1. on: push: branches: [main]
   2. on: deploy: all_branches: true
   3. on: publish: branches: [main]
   4. on: commit: branches: [master]

   Explanation: Setting 'on: push: branches: [main]' ensures that the workflow runs only when pushes are made to the main branch, which is typically desired for production container builds. The 'on: publish' trigger is not a valid option, so it would not work. Choosing 'on: commit: branches: [master]' is incorrect because it references a different branch name and uses an invalid event. 'on: deploy: all_branches: true' would not restrict the actions to the main branch and uses an incorrect syntax.

2. Caching Docker Layers

   What is the main benefit of using a caching strategy for Docker image layers within a CI pipeline that repeatedly builds similar images?

   1. Disables image scan warnings during builds
   2. Forces all steps to run regardless of cache
   3. Reduces build time by reusing unchanged layers
   4. Allows simultaneous multi-image publishing

   Explanation: Caching Docker image layers reduces build time because unchanged layers don't need to be rebuilt on subsequent runs. While caching can speed up processes, it does not enable multi-image publishing or affect image scan warnings. Forcing all steps to run regardless of cache contradicts the purpose of caching, which is to avoid unnecessary repeated work.

3. Storing Secrets

   When pushing container images from a workflow, which is the safest way to handle container registry credentials such as a username and password?

   1. Upload a text file with credentials to the repository
   2. Store them as encrypted secrets in the workflow settings
   3. Include them in plain text within the workflow YAML file
   4. Hard-code them into the Dockerfile as environment variables

   Explanation: Storing credentials as encrypted secrets in workflow settings ensures they are kept confidential and only minimally exposed during the workflow run. Including credentials as plain text in YAML files or uploading text files containing passwords introduces significant security risks. Hard-coding secrets in Dockerfiles is unsafe because they become part of the image and can be accessed by others.

4. Multi-Platform Builds

   Suppose your project requires creating container images for both x86 and ARM architectures. Which action should you incorporate in your workflow to enable multi-platform Docker builds?

   1. Disable cross-compilation in the build process
   2. Enable 'buildz' in the workflow configuration
   3. Set the platform to 'universal' in the Dockerfile
   4. Use a build step with 'buildx' support

   Explanation: 'buildx' provides extended features for building multi-platform images, making it the right solution for supporting both x86 and ARM. There is no valid 'buildz' feature; it is a plausible typo. Setting the platform to 'universal' is not recognized by Docker builds. Disabling cross-compilation prevents multi-platform support rather than enabling it.

5. Publishing Best Practices

   What is typically recommended when tagging a container image for publishing to a registry from an automated workflow?

   1. Always remove all tags after each push
   2. Assign only a random hash as the tag
   3. Use both a version-specific tag and a 'latest' tag
   4. Tag every image as 'experimental' regardless of status

   Explanation: Applying both a version-specific tag and a 'latest' tag makes it easier to identify and pull specific releases while maintaining an easy-to-find default version. Random hashes as tags are not human-friendly for tracking releases. Tagging every image as 'experimental' is misleading in a production scenario. Removing all tags after pushing would make it difficult to reference or use the images later.