N10-009 Question 134
Single answerSource control: Version control, Central repository, Conflict identification, BranchingA network operations team stores firewall policies, switch configurations, and router templates in a Git-based central repository. During a maintenance window, an engineer creates a branch to update ACLs for a new application, while another engineer updates the same firewall policy file on the main branch to block a newly discovered threat. When the first engineer tries to merge the branch back into the central repository, the system reports a conflict in that file. Which action should the team take NEXT to preserve both intended changes and maintain proper version control practices?
- A
Force-push the branch to the central repository so the branch version replaces the main branch copy
- B
Manually review the conflicting sections, reconcile the intended ACL and threat-blocking changes, test the merged configuration, and then commit the resolved file
- C
Delete the feature branch and recreate the changes directly on the main branch to avoid future conflicts
- D
Revert the main branch security update, merge the feature branch, and then reapply the security change later
Show answer and explanation
Correct answer: B
Explanation
This question tests practical use of source control in network operations. A central repository allows multiple engineers to collaborate on infrastructure-as-code and device configuration files, but overlapping edits can create merge conflicts. In Git and similar version control systems, conflict identification occurs when the system cannot automatically determine how to combine changes. Best practice is to resolve the conflict manually, verify that both intended outcomes are preserved, and then commit the resolved version. Branching supports isolated work for features or maintenance tasks, while the central repository serves as the authoritative shared source. Common documentation and workflow guidance from Git-based platforms emphasizes reviewing conflicts carefully, avoiding force-pushes to shared branches, and testing merged configurations before deployment, especially for production network and security changes.
- A. Incorrect.
Incorrect. Force-pushing to overwrite the main branch would discard the other engineer's security-related update and is not an appropriate way to handle a merge conflict in shared source control. In centralized collaboration, force-push operations on shared branches are typically restricted because they can rewrite history and remove valid changes.
- B. Correct.
Correct. A reported merge conflict means both branches modified overlapping content and the conflict must be reviewed. The proper next step is to manually inspect the conflicting sections, combine the ACL additions and the threat-blocking update as intended, validate the result, and commit the resolution. This preserves version history, supports collaboration through a central repository, and follows standard Git conflict-resolution workflows.
- C. Incorrect.
Incorrect. Deleting and recreating the branch does not solve the underlying issue that two valid changes were made to the same file. This wastes time and can increase the chance of introducing errors. Branching exists specifically to allow parallel work, and conflicts are normally resolved rather than avoided by discarding branch history.
- D. Incorrect.
Incorrect. Reverting a valid security change just to make a merge easier creates unnecessary operational risk and breaks the normal workflow. The problem is not that the main branch was updated; the problem is that both changes affect the same file. The correct response is to merge and resolve the conflict, not temporarily remove important protections.