DOP-C02 SDLC Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a new branch and push that instead.

  Why it's wrong here

  Creating a new branch and pushing that instead does not update the original branch in AWS CodeCommit, so the remote branch remains missing the local commits that caused the rejection. Any developers or pipelines watching the original branch will never see the changes, and the new branch creates a separate line of development that would require a future pull request or merge to integrate. It also fails to address the root cause: the local branch is still behind the remote's new commits.

• ✗

  Use 'git push --force' to overwrite the remote branch.

  Why it's wrong here

  Using 'git push --force' overwrites the remote branch with your local history, discarding any commits on the remote that are not present locally. This is a non-fast-forward update that can permanently destroy commits created by other team members, break shared feature work, and make the repository's history inconsistent. CodeCommit may also block force pushes through branch policies, but even if allowed, it is dangerous and does not incorporate the remote changes you need.

• ✓

  Pull the latest changes using 'git pull --rebase' and then push.

  Why this is correct

  Running 'git pull --rebase' fetches the remote branch's new commits and replays your local commits one by one on top of that updated history, producing a linear, fast-forwardable branch. After the rebase, your local branch contains all remote commits, so the subsequent 'git push' is a clean fast-forward rather than a rejected non-fast-forward update. This synchronizes the branch without creating a merge commit or losing any work.

• ✗

  Delete the remote branch and push again.

  Why it's wrong here

  Deleting the remote branch and pushing again is highly disruptive because it removes a shared reference that other developers, CI/CD pipelines, and CodeCommit pull requests may depend on, making their local clones inconsistent. It also does not solve the rejection: if you have not fetched the remote's latest commits, pushing again from your stale local branch will still be rejected and could orphan existing work when the branch is recreated. The correct fix is to integrate remote changes locally, not destroy the remote ref.

Go deeper

Related to this question