Git Workflows for Infrastructure-as-Code Changes: Branching, PRs, and Conflict Resolution Quiz

Test your understanding of Git workflows for infrastructure-as-code projects, including best practices for branching strategies, pull request reviews, and handling merge conflicts. This quiz helps reinforce essential skills for effective version control and team collaboration in deploying infrastructure with code.

1. Development Branch Usage

   In a team managing infrastructure-as-code, why is it recommended to make feature changes in a dedicated branch instead of directly in the main branch?

   1. It increases merge conflicts automatically.
   2. It allows testing and reviewing changes before merging them to production.
   3. It deletes other team members' work.
   4. It prevents tracking of change history.

   Explanation: Making feature changes in a dedicated branch allows team members to review and test updates before they are merged into the production environment, reducing mistakes. Using a separate branch does not automatically cause more merge conflicts or prevent tracking of history. Additionally, it does not delete any team member's work, which would be inappropriate and not a common Git behavior.

2. Creating Pull Requests

   What is the main purpose of submitting a pull request (PR) after making changes to an infrastructure-as-code repository?

   1. To revert all existing code in the repository.
   2. To hide changes from other collaborators.
   3. To permanently delete the feature branch.
   4. To review and discuss changes before merging them into the base branch.

   Explanation: Submitting a pull request allows team members to review, comment on, and approve proposed changes before they enter the main codebase, ensuring code quality and alignment with project standards. Pull requests do not hide changes, delete the branch by default, or revert any code—they are a tool for collaboration and code review.

3. Handling Merge Conflicts

   If two team members edit the same section of a configuration file in separate branches, what is likely to happen when merging?

   1. The change will be merged with no issues every time.
   2. The older change will be automatically deleted.
   3. The repository will block further branches from being created.
   4. A merge conflict will occur requiring manual resolution.

   Explanation: When two people modify the same part of a file, a merge conflict typically arises and must be resolved manually for the repository to keep a clear state. The older change is not automatically deleted, and Git doesn't block branch creation because of this. Conflicts won't always merge perfectly; ignoring them risks infrastructure errors.

4. Branch Naming Conventions

   Which branch name is most appropriate for a new feature adding database support in an infrastructure-as-code project?

   1. feature/database-support
   2. zzz_branchtest
   3. main-backup
   4. delete-files-quickly

   Explanation: The name feature/database-support follows a clear convention describing the new feature's purpose, making collaboration and tracking easier. 'main-backup' and 'delete-files-quickly' are ambiguous or misleading, and 'zzz_branchtest' lacks clarity and professionalism, which risks confusion among collaborators.

5. Review Approval Requirement

   Why is requiring at least one team member's approval on a pull request recommended before merging infrastructure-as-code changes?

   1. It ensures code is reviewed for errors and security risks.
   2. It pressures the author to work faster.
   3. It stops tracking commit history.
   4. It prevents using version control.

   Explanation: Requiring approval means another set of eyes checks your work, potentially catching mistakes or risks before merging into main infrastructure code. Approval doesn't stop commit history, has no impact on version control usage, and isn't meant to rush team members.

6. Using the Main Branch

   What is the main branch typically used for in infrastructure-as-code repositories?

   1. Holding all unfinished experimental changes.
   2. Saving code without version history.
   3. Archiving unrelated project files.
   4. Storing the latest stable and deployable infrastructure code.

   Explanation: The main branch usually represents code that is stable and ready for deployment, providing a reliable baseline for releases. Storing experimental or unrelated project files in main would harm project organization, while removing version history defeats the purpose of version control.

7. Fast-Forward Merge Option

   In which situation is a fast-forward merge possible when integrating an infrastructure-as-code branch?

   1. When the feature branch and main branch have unrelated histories.
   2. When files have been deleted from both branches.
   3. When a merge conflict exists between branches.
   4. When no new changes have been made to the main branch since the feature branch was created.

   Explanation: A fast-forward merge is possible only if the main branch has not changed, meaning the feature branch can be added directly. Unrelated histories, conflicts, or simultaneous deletions in both branches require manual intervention or a different merge type.

8. Resolving a Simple Conflict

   If you encounter a simple merge conflict in a Terraform variable file, what step should you take to resolve it?

   1. Create a new repository to avoid conflict.
   2. Ignore the conflict and push your branch.
   3. Manually edit the file to combine the desired changes and then commit.
   4. Delete the variable file and try merging again.

   Explanation: Resolving a merge conflict involves checking both sets of changes and manually updating the file, then creating a commit that records the resolution. Deleting the file, ignoring the problem, or moving to a new repository can result in data loss or project disruption.

9. Best Practice for Avoiding Conflicts

   How can team members reduce the likelihood of frequent merge conflicts when working on infrastructure-as-code projects?

   1. Making all changes directly to the main branch without branches.
   2. Editing the same line of code repeatedly.
   3. Pulling the latest changes from the main branch frequently.
   4. Restoring old file versions every day.

   Explanation: Regularly updating your branch with the latest changes from main helps prevent conflicts by keeping your branch up to date. Working directly in main increases risk, restoring old versions is unnecessary, and editing the same code repeatedly is likely to cause more conflicts.

10. Documenting Infrastructure Changes

    Why is it useful to add a clear description to your pull request when submitting infrastructure-as-code updates?

    1. It randomly assigns reviewers to the request.
    2. It slows down the merging process.
    3. It hides parts of the change from other team members.
    4. It helps reviewers understand the purpose and impact of the changes.

    Explanation: A clear pull request description aids reviewers in quickly assessing what has changed and why, improving quality and efficiency during code review. It does not slow the process, hide information, or affect reviewer assignment.