Microsoft AZ-400 Practice Test 23

Question 220

Another project uses ephemeral agents yet downloads multi-year history for every small documentation change. Which unsupported assumption should the engineer challenge FIRST?

A shallow clone is not appropriate without checking tools that need earlier tags or full commit ancestry.
A feature flag is not a substitute for access control, and leaving flags permanently unmanaged adds risk.
A tag name such as v2.0 does not prove immutable content if maintainers may silently move the tag.
Requiring a pull request does not make code from an untrusted fork safe to execute with deployment credentials.

Explanation

Correct Answer

A shallow clone is not appropriate without checking tools that need earlier tags or full commit ancestry. This is the relevant unsupported assumption because source retrieval should match the build's history requirements rather than always download the entire repository.

Incorrect Answers

This caution is valid in design and implement branching strategies for the source code, but it is not the failure assumption illustrated by this scenario. The directly relevant risk is: A shallow clone is not appropriate without checking tools that need earlier tags or full commit ancestry.

Question 221

A team accidentally pushes a force update to a shared branch and several developers lose their expected merge bases. Which design or operational change MOST directly satisfies the requirement?

Enable the applicable signed-commit requirements and validate identities and branch policy behavior at merge time.
Maintain a supported-branch matrix and track cherry-pick or merge application for required patches.
Define a release/hotfix branch flow with reviewed back-merges or cherry-picks into supported branches.
Disable force pushes on protected branches and use reviewed recovery to restore known-good commit state.

Explanation

Correct Answer

Shared branch history needs protection against unreviewed rewriting to preserve collaboration and provenance. The most directly responsive design or operational step is: Disable force pushes on protected branches and use reviewed recovery to restore known-good commit state. Confirm the result by: Attempt a force push in a test protected branch and verify policy denial and audit evidence.

Incorrect Answers

Commit authenticity controls address provenance only when verified identities and enforcement are configured. The relevant evidence instead is: Disable force pushes on protected branches and use reviewed recovery to restore known-good commit state.

Multi-version source support requires explicit patch propagation and documented branch retirement. The acceptance criterion here is: Disable force pushes on protected branches and use reviewed recovery to restore known-good commit state.

Long-lived maintenance lines require explicit propagation of fixes to prevent divergent defects. What must be demonstrated is: Disable force pushes on protected branches and use reviewed recovery to restore known-good commit state.

Question 222

After the team applies this response: Disable force pushes on protected branches and use reviewed recovery to restore known-good commit state. In the situation—A team accidentally pushes a force update to a shared branch and several developers lose their expected merge bases. Which evidence BEST demonstrates the response is effective?

Attempt a merge with an unsigned commit and verify the protection rule and identity records reject it.
Verify a contributor can propose a PR and that merging still requires the required independent checks.
Review a simulated bypass attempt and the resulting audit record and independently authorized exception.
Attempt a force push in a test protected branch and verify policy denial and audit evidence.

Explanation

Correct Answer

This evidence directly verifies the proposed control under the stated failure scenario: Attempt a force push in a test protected branch and verify policy denial and audit evidence. The governing engineering principle is: Shared branch history needs protection against unreviewed rewriting to preserve collaboration and provenance.

Incorrect Answers

Commit authenticity controls address provenance only when verified identities and enforcement are configured. The appropriate comparison is: Attempt a force push in a test protected branch and verify policy denial and audit evidence.

A safe branch strategy must balance collaborative change proposals with protected shared integration. The relevant evidence instead is: Attempt a force push in a test protected branch and verify policy denial and audit evidence.

Branch policy integrity depends on tightly limited bypass privileges and transparent exceptional use. The acceptance criterion here is: Attempt a force push in a test protected branch and verify policy denial and audit evidence.

Question 223

A second group uses permissive Git pushes in release branches and cannot determine when history changed. Which engineering principle BEST explains the relevant requirement?

Approval integrity requires binding review decisions to the current content of the change, not an earlier version.
An emergency workflow should shorten lead time without abandoning auditable source-control safeguards.
Shared branch history needs protection against unreviewed rewriting to preserve collaboration and provenance.
Branch protection relies on trustworthy status results that apply to the submitted change.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: Shared branch history needs protection against unreviewed rewriting to preserve collaboration and provenance. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

Approval integrity requires binding review decisions to the current content of the change, not an earlier version. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Shared branch history needs protection against unreviewed rewriting to preserve collaboration and provenance.

An emergency workflow should shorten lead time without abandoning auditable source-control safeguards. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Shared branch history needs protection against unreviewed rewriting to preserve collaboration and provenance.

Branch protection relies on trustworthy status results that apply to the submitted change. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Shared branch history needs protection against unreviewed rewriting to preserve collaboration and provenance.

Question 224

A second group uses permissive Git pushes in release branches and cannot determine when history changed. Which unsupported assumption should the engineer challenge FIRST?

A normal push permission is not necessarily authorization to rewrite already published branch history.
Creating a permanent branch for every feature does not automatically reduce merge or release risk.
Creating strict branch policies does not protect a repository when every contributor can disable them.
An urgent production issue does not by itself justify disabling all protected-branch rules.

Explanation

Correct Answer

A normal push permission is not necessarily authorization to rewrite already published branch history. This is the relevant unsupported assumption because shared branch history needs protection against unreviewed rewriting to preserve collaboration and provenance.

Incorrect Answers

This is the relevant unsupported assumption because trunk-based integration limits divergence and makes failures easier to attribute when tests run on each change. What must be demonstrated is: A normal push permission is not necessarily authorization to rewrite already published branch history.

Creating strict branch policies does not protect a repository when every contributor can disable them. The appropriate comparison is: A normal push permission is not necessarily authorization to rewrite already published branch history.

This is the relevant unsupported assumption because an emergency workflow should shorten lead time without abandoning auditable source-control safeguards. The relevant evidence instead is: A normal push permission is not necessarily authorization to rewrite already published branch history.

Question 225

An organization has repositories across two GitHub organizations and external partners need access to only one shared module. Which design or operational change MOST directly satisfies the requirement?

Enable the applicable signed-commit requirements and validate identities and branch policy behavior at merge time.
Publish the reusable module into an appropriately scoped separate repository or package with controlled partner access.
Define a release/hotfix branch flow with reviewed back-merges or cherry-picks into supported branches.
Restrict tag creation and update permissions and use protected or signed annotated release tags where supported.

Explanation

Correct Answer

Cross-repository collaboration should expose only intended source and dependencies across trust boundaries. The most directly responsive design or operational step is: Publish the reusable module into an appropriately scoped separate repository or package with controlled partner access. Confirm the result by: Verify partner credentials can retrieve the required module version but cannot access unrelated internal source.

Incorrect Answers

Commit authenticity controls address provenance only when verified identities and enforcement are configured. The needed step here is to publish the reusable module into an appropriately scoped separate repository or package with controlled partner access.

Long-lived maintenance lines require explicit propagation of fixes to prevent divergent defects. The appropriate remedy is to publish the reusable module into an appropriately scoped separate repository or package with controlled partner access.

Release labels are trustworthy only when the tagged revision and tag governance are controlled. Instead, the response must publish the reusable module into an appropriately scoped separate repository or package with controlled partner access.

Question 226

After the team applies this response: Publish the reusable module into an appropriately scoped separate repository or package with controlled partner access. In the situation—An organization has repositories across two GitHub organizations and external partners need access to only one shared module. Which evidence BEST demonstrates the response is effective?

Verify partner credentials can retrieve the required module version but cannot access unrelated internal source.
Verify a contributor can propose a PR and that merging still requires the required independent checks.
Review a simulated bypass attempt and the resulting audit record and independently authorized exception.
Attempt a merge with an unsigned commit and verify the protection rule and identity records reject it.

Explanation

Correct Answer

The governing engineering principle is: Cross-repository collaboration should expose only intended source and dependencies across trust boundaries.

Incorrect Answers

A safe branch strategy must balance collaborative change proposals with protected shared integration. The relevant control is to verify partner credentials can retrieve the required module version but cannot access unrelated internal source.

Branch policy integrity depends on tightly limited bypass privileges and transparent exceptional use. The needed step here is to verify partner credentials can retrieve the required module version but cannot access unrelated internal source.

Commit authenticity controls address provenance only when verified identities and enforcement are configured. The appropriate remedy is to verify partner credentials can retrieve the required module version but cannot access unrelated internal source.

Question 227

Another company clones a sensitive monorepo into a partner account to share one library. Which engineering principle BEST explains the relevant requirement?

Branch protection relies on trustworthy status results that apply to the submitted change.
Release labels are trustworthy only when the tagged revision and tag governance are controlled.
Cross-repository collaboration should expose only intended source and dependencies across trust boundaries.
Git merge strategies can change commit identity while preserving review provenance through stable PR references.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: Cross-repository collaboration should expose only intended source and dependencies across trust boundaries. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

Branch protection relies on trustworthy status results that apply to the submitted change. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Cross-repository collaboration should expose only intended source and dependencies across trust boundaries.

Release labels are trustworthy only when the tagged revision and tag governance are controlled. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Cross-repository collaboration should expose only intended source and dependencies across trust boundaries.

Git merge strategies can change commit identity while preserving review provenance through stable PR references. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Cross-repository collaboration should expose only intended source and dependencies across trust boundaries.

Question 228

Another company clones a sensitive monorepo into a partner account to share one library. Which unsupported assumption should the engineer challenge FIRST?

Copying a whole private repository for one dependency unnecessarily exposes unrelated proprietary code.
An urgent production issue does not by itself justify disabling all protected-branch rules.
A fix applied on one maintenance branch is not automatically present on every supported branch.
The original feature-branch SHA is not necessarily the commit identifier recorded after a squash merge.

Explanation

Correct Answer

Copying a whole private repository for one dependency unnecessarily exposes unrelated proprietary code. This is the relevant unsupported assumption because cross-repository collaboration should expose only intended source and dependencies across trust boundaries.

Incorrect Answers

This caution is valid in design and implement branching strategies for the source code, but it is not the failure assumption illustrated by this scenario. The directly relevant risk is: Copying a whole private repository for one dependency unnecessarily exposes unrelated proprietary code.

Question 229

A team uses Azure Repos repository permissions with broad inherited Contributor access and cannot explain unexpected branch deletions. Which design or operational change MOST directly satisfies the requirement?

Separate untrusted PR validation from privileged deployment workflows and restrict secret-bearing jobs to trusted approved contexts.
Use short-lived branches and frequent validated integration to a protected main branch, with release controls separated from integration.
Maintain a supported-branch matrix and track cherry-pick or merge application for required patches.
Audit effective permissions and inherited group grants, then narrow the permission model to required actions.

Explanation

Correct Answer

Source control access must be evaluated as effective permissions across direct and inherited grants. The most directly responsive design or operational step is: Audit effective permissions and inherited group grants, then narrow the permission model to required actions. Confirm the result by: Recalculate effective grants and test that the affected user cannot perform restricted branch deletion.

Incorrect Answers

Source contribution and deployment authorization are different trust boundaries that must be enforced independently. Instead, the response must audit effective permissions and inherited group grants, then narrow the permission model to required actions.

Trunk-based integration limits divergence and makes failures easier to attribute when tests run on each change. The relevant control is to audit effective permissions and inherited group grants, then narrow the permission model to required actions.

Multi-version source support requires explicit patch propagation and documented branch retirement. The needed step here is to audit effective permissions and inherited group grants, then narrow the permission model to required actions.

Question 230

After the team applies this response: Audit effective permissions and inherited group grants, then narrow the permission model to required actions. In the situation—A team uses Azure Repos repository permissions with broad inherited Contributor access and cannot explain unexpected branch deletions. Which evidence BEST demonstrates the response is effective?

Introduce a new commit or target update and confirm the policy requires a current successful validation run.
Verify a contributor can propose a PR and that merging still requires the required independent checks.
Change a file covered by the rule and verify a skipped or failed required check prevents merging.
Recalculate effective grants and test that the affected user cannot perform restricted branch deletion.

Explanation

Correct Answer

The governing engineering principle is: Source control access must be evaluated as effective permissions across direct and inherited grants.

Incorrect Answers

Merge gates must verify the code state that will be integrated, not a stale earlier validation. The acceptance criterion here is: Recalculate effective grants and test that the affected user cannot perform restricted branch deletion.

A safe branch strategy must balance collaborative change proposals with protected shared integration. What must be demonstrated is: Recalculate effective grants and test that the affected user cannot perform restricted branch deletion.

Branch protection relies on trustworthy status results that apply to the submitted change. The appropriate comparison is: Recalculate effective grants and test that the affected user cannot perform restricted branch deletion.

Designing and Implementing Microsoft DevOps Solutions (AZ-400) Practice Tests

Microsoft AZ-400 Practice Test 21 - 10 Questions (Last Reviewed 25-Oct-2026)
Microsoft AZ-400 Practice Test 22 - 10 Questions (Last Reviewed 24-Oct-2026)
Microsoft AZ-400 Practice Test 23 - 10 Questions (Last Reviewed 23-Oct-2026)
Microsoft AZ-400 Practice Test 24 - 10 Questions (Last Reviewed 22-Oct-2026)
Microsoft AZ-400 Practice Test 25 - 10 Questions (Last Reviewed 21-Oct-2026)

Pass Your Microsoft AZ-400 Exam Easy!

Question 220

Explanation

Correct Answer

Incorrect Answers

Question 221

Explanation

Correct Answer

Incorrect Answers

Question 222

Explanation

Correct Answer

Incorrect Answers

Question 223

Explanation

Correct Answer

Incorrect Answers

Question 224

Explanation

Correct Answer

Incorrect Answers

Question 225

Explanation

Correct Answer

Incorrect Answers

Question 226

Explanation

Correct Answer

Incorrect Answers

Question 227

Explanation

Correct Answer

Incorrect Answers

Question 228

Explanation

Correct Answer

Incorrect Answers

Question 229

Explanation

Correct Answer

Incorrect Answers

Question 230

Explanation

Correct Answer

Incorrect Answers

Designing and Implementing Microsoft DevOps Solutions (AZ-400) Practice Tests