A cloud architect needs to change the network configuration at a company that uses GitOps to document and implement network changes. The Git repository uses main as the default branch, and the main br

Question

Options

• AUse the main branch to make and commit the changes back to the remote repository.
• BCreate a new branch for the change, then create a pull request including the changes.
• CCheck out the development branch, then perform and commit the changes back to the remote
• DRebase the remote main branch after making the changes to implement.

• A
  5% (1)
• B
  86% (18)
• C
  5% (1)
• D
  5% (1)

Explanation

In a GitOps workflow, the main branch represents the source of truth for the current desired state of the environment, and branch protection rules prevent direct commits to it. The standard GitOps process is to create a feature or change branch from main, make and commit changes to that branch, then open a pull request (PR) for peer review and automated validation before merging into main. This ensures changes are reviewed and tested before being applied. Committing directly to main (A) would be blocked by the branch protection rule. Checking out a development branch (C) is not a standard GitOps practice unless that branch exists and is the designated integration branch. Rebasing main after making changes (D) is a destructive and non-standard workflow that bypasses the review process.

No community discussion yet for this question.