Design and implement source control →hardMultiple ChoiceObjective-mapped

AZ-400 Design and implement source control Practice Question

Network Topology

Refer to the exhibit. A team wants to release version 1.0 from the main branch. They notice that the tag v1.0 is already on the current main commit. However, they also see that the origin/feature/experiment branch has commits that are not merged into main. What is the most likely scenario?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The experiment branch contains experimental work that was not intended for release; the tag v1.0 correctly marks the release on main.

The tag v1.0 is on the current main commit (9a8b7c6). The feature/experiment branch (1a2b3c4) is a child of the initial commit, but it is not merged into main. The main branch has commits that are ahead of the experiment branch. The team wants to release v1.0 from main; the tag already exists. The presence of the experiment branch not merged suggests that it was not intended for this release. The most likely scenario is that the experiment branch was created from an older commit and is not ready for release, so it was not merged. The release v1.0 is correctly tagged on main.

Answer analysis

Option-by-option breakdown

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

✗
The team should delete the experiment branch because it is not merged.
Why it's wrong here
Deleting the experiment branch is a repository hygiene decision, not a release requirement. Git branches are lightweight pointers, and retaining an unmerged branch preserves the experimental work intact for future investigation, cherry-picking, or revival. Nothing in the scenario indicates the team has finished with that work, and forcing deletion could cause irreversible loss of code history.
✗
The tag v1.0 was applied to the wrong commit; it should be on the merge commit of the experiment branch.
Why it's wrong here
The tag v1.0 could not be 'on the merge commit of the experiment branch' because that merge commit does not exist on main—the experiment branch has not been merged. Tagging a hypothetical merge commit would be impossible, and even tagging the experiment branch's current tip would label a commit that contains unreviewed, experimental changes. Release tags must point to commits already integrated into the release branch, so the current tag on main is the only valid placement.
✗
The main branch is missing the experiment branch commits; a merge is required before release.
Why it's wrong here
Merging the experiment branch into main before release is not inherently required; doing so risks introducing unstable, incomplete, or unvalidated code into the final release. A release pipeline typically builds and tags from main, and the experiment branch is deliberately isolated to avoid contaminating that stable line. The absence of those commits does not make the release defective—it simply reflects that the experimental work was intentionally excluded.
✓
The experiment branch contains experimental work that was not intended for release; the tag v1.0 correctly marks the release on main.
Why this is correct
The experiment branch was created for isolated, exploratory work and has intentionally never been merged into main, so none of its commits are part of the v1.0 release history. Tagging the main branch's commit correctly captures the exact state of the code that was built, tested, and validated for release. This is consistent with standard branching practices where release tags are applied to integration branches, not to feature or experiment branches.

Go deeper

AZ-400 Design and implement source control Practice Question

Why each option matters

Option-by-option breakdown

Related to this question