Microsoft AZ-400 Practice Test 24

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.

Question 231

Another project changes an individual's role but the effective policy remains elevated through a nested group. Which engineering principle BEST explains the relevant requirement?

Release labels are trustworthy only when the tagged revision and tag governance are controlled.
Source control access must be evaluated as effective permissions across direct and inherited grants.
Merge gates must verify the code state that will be integrated, not a stale earlier validation.
Approval integrity requires binding review decisions to the current content of the change, not an earlier version.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: Source control access must be evaluated as effective permissions across direct and inherited grants. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

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: Source control access must be evaluated as effective permissions across direct and inherited grants.

Merge gates must verify the code state that will be integrated, not a stale earlier validation. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Source control access must be evaluated as effective permissions across direct and inherited grants.

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: Source control access must be evaluated as effective permissions across direct and inherited grants.

Question 232

Another project changes an individual's role but the effective policy remains elevated through a nested group. Which unsupported assumption should the engineer challenge FIRST?

A direct Deny or removal from one group may not describe the complete effective authorization picture.
Preventing developers from opening change branches can push work outside the reviewed source system.
A successful build attached to an earlier commit does not prove the final merge candidate is safe.
An approval on yesterday's diff is not proof that today's updated diff was reviewed.

Explanation

Correct Answer

A direct Deny or removal from one group may not describe the complete effective authorization picture. This is the relevant unsupported assumption because source control access must be evaluated as effective permissions across direct and inherited grants.

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 direct Deny or removal from one group may not describe the complete effective authorization picture.

Question 233

An engineer uses git reset --hard on the shared main branch to undo a faulty release, erasing approved later commits. Which design or operational change MOST directly satisfies the requirement?

Define a release/hotfix branch flow with reviewed back-merges or cherry-picks into supported branches.
Use short-lived branches and frequent validated integration to a protected main branch, with release controls separated from integration.
Use a reviewed git revert or equivalent compensating commit for published shared history instead of rewriting main.
Restrict tag creation and update permissions and use protected or signed annotated release tags where supported.

Explanation

Correct Answer

Reverting shared source changes should preserve an auditable, non-destructive history where possible. The most directly responsive design or operational step is: Use a reviewed git revert or equivalent compensating commit for published shared history instead of rewriting main. Confirm the result by: Trace the reversal commit to the bad change and verify later approved commits remain reachable.

Incorrect Answers

Long-lived maintenance lines require explicit propagation of fixes to prevent divergent defects. The appropriate remedy is to use a reviewed git revert or equivalent compensating commit for published shared history instead of rewriting main.

Trunk-based integration limits divergence and makes failures easier to attribute when tests run on each change. Instead, the response must use a reviewed git revert or equivalent compensating commit for published shared history instead of rewriting main.

Release labels are trustworthy only when the tagged revision and tag governance are controlled. The relevant control is to use a reviewed git revert or equivalent compensating commit for published shared history instead of rewriting main.

Question 234

After the team applies this response: Use a reviewed git revert or equivalent compensating commit for published shared history instead of rewriting main. In the situation—An engineer uses git reset --hard on the shared main branch to undo a faulty release, erasing approved later commits. Which evidence BEST demonstrates the response is effective?

Review branch ages, merge history, test status and mainline stability across a recent release cycle.
Trace the reversal commit to the bad change and verify later approved commits remain reachable.
Inspect a disabled feature's merge, guarded runtime behavior and subsequent enabled production release.
Compare a merged PR to the final mainline commit and the artifact built from that commit.

Explanation

Correct Answer

The governing engineering principle is: Reverting shared source changes should preserve an auditable, non-destructive history where possible.

Incorrect Answers

Trunk-based integration limits divergence and makes failures easier to attribute when tests run on each change. The needed step here is to trace the reversal commit to the bad change and verify later approved commits remain reachable.

Feature flags can decouple code integration from user exposure when defaults and cleanup are governed. The appropriate remedy is to trace the reversal commit to the bad change and verify later approved commits remain reachable.

Git merge strategies can change commit identity while preserving review provenance through stable PR references. Instead, the response must trace the reversal commit to the bad change and verify later approved commits remain reachable.

Question 235

Another team needs to revert a published change while preserving collaborative history. Which engineering principle BEST explains the relevant requirement?

Release labels are trustworthy only when the tagged revision and tag governance are controlled.
An emergency workflow should shorten lead time without abandoning auditable source-control safeguards.
Reverting shared source changes should preserve an auditable, non-destructive history where possible.
Source contribution and deployment authorization are different trust boundaries that must be enforced independently.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: Reverting shared source changes should preserve an auditable, non-destructive history where possible. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

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: Reverting shared source changes should preserve an auditable, non-destructive history where possible.

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: Reverting shared source changes should preserve an auditable, non-destructive history where possible.

Source contribution and deployment authorization are different trust boundaries that must be enforced independently. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Reverting shared source changes should preserve an auditable, non-destructive history where possible.

Question 236

Another team needs to revert a published change while preserving collaborative history. Which unsupported assumption should the engineer challenge FIRST?

Resetting a local branch pointer does not safely undo a published change for every collaborator.
Preventing developers from opening change branches can push work outside the reviewed source system.
The original feature-branch SHA is not necessarily the commit identifier recorded after a squash merge.
A patch merged into main does not automatically remediate an already supported older release.

Explanation

Correct Answer

Resetting a local branch pointer does not safely undo a published change for every collaborator. This is the relevant unsupported assumption because reverting shared source changes should preserve an auditable, non-destructive history where possible.

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: Resetting a local branch pointer does not safely undo a published change for every collaborator.

Question 237

A Git repository imports generated dependency directories, bloating history and causing noisy reviews after every build. Which design or operational change MOST directly satisfies the requirement?

Scope administrative bypass and require documented exception approval with audit logging for protected branch overrides.
Use short-lived branches and frequent validated integration to a protected main branch, with release controls separated from integration.
Adopt an explicit small-change integration policy using feature flags for incomplete behavior where appropriate.
Add appropriate ignore rules and remove generated tracked files while preserving lockfiles and reproducible build inputs.

Explanation

Correct Answer

Good repository hygiene versions intentional source inputs, not disposable locally generated outputs. The most directly responsive design or operational step is: Add appropriate ignore rules and remove generated tracked files while preserving lockfiles and reproducible build inputs. Confirm the result by: Check the tracked file inventory and perform a clean dependency restore followed by a successful controlled build.

Incorrect Answers

Branch policy integrity depends on tightly limited bypass privileges and transparent exceptional use. The relevant evidence instead is: Add appropriate ignore rules and remove generated tracked files while preserving lockfiles and reproducible build inputs.

Trunk-based integration limits divergence and makes failures easier to attribute when tests run on each change. The acceptance criterion here is: Add appropriate ignore rules and remove generated tracked files while preserving lockfiles and reproducible build inputs.

Feature flags can decouple code integration from user exposure when defaults and cleanup are governed. What must be demonstrated is: Add appropriate ignore rules and remove generated tracked files while preserving lockfiles and reproducible build inputs.

Question 238

After the team applies this response: Add appropriate ignore rules and remove generated tracked files while preserving lockfiles and reproducible build inputs. In the situation—A Git repository imports generated dependency directories, bloating history and causing noisy reviews after every build. Which evidence BEST demonstrates the response is effective?

Run a sample fork PR and verify it cannot read deployment secrets or use privileged production runners.
Trace a sample hotfix commit through production, the supported release branch and the main development branch.
Check the tracked file inventory and perform a clean dependency restore followed by a successful controlled build.
Review a simulated bypass attempt and the resulting audit record and independently authorized exception.

Explanation

Correct Answer

This evidence directly verifies the proposed control under the stated failure scenario: Check the tracked file inventory and perform a clean dependency restore followed by a successful controlled build. The governing engineering principle is: Good repository hygiene versions intentional source inputs, not disposable locally generated outputs.

Incorrect Answers

Source contribution and deployment authorization are different trust boundaries that must be enforced independently. The relevant control is to check the tracked file inventory and perform a clean dependency restore followed by a successful controlled build.

Long-lived maintenance lines require explicit propagation of fixes to prevent divergent defects. The needed step here is to check the tracked file inventory and perform a clean dependency restore followed by a successful controlled build.

Branch policy integrity depends on tightly limited bypass privileges and transparent exceptional use. The appropriate remedy is to check the tracked file inventory and perform a clean dependency restore followed by a successful controlled build.

Question 239

Another team commits package caches and environment-specific outputs instead of reproducible dependency manifests. Which engineering principle BEST explains the relevant requirement?

Commit authenticity controls address provenance only when verified identities and enforcement are configured.
Approval integrity requires binding review decisions to the current content of the change, not an earlier version.
Merge gates must verify the code state that will be integrated, not a stale earlier validation.
Good repository hygiene versions intentional source inputs, not disposable locally generated outputs.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: Good repository hygiene versions intentional source inputs, not disposable locally generated outputs. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

Commit authenticity controls address provenance only when verified identities and enforcement are configured. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Good repository hygiene versions intentional source inputs, not disposable locally generated outputs.

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: Good repository hygiene versions intentional source inputs, not disposable locally generated outputs.

Merge gates must verify the code state that will be integrated, not a stale earlier validation. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Good repository hygiene versions intentional source inputs, not disposable locally generated outputs.

Question 240

Another team commits package caches and environment-specific outputs instead of reproducible dependency manifests. Which unsupported assumption should the engineer challenge FIRST?

A successful build attached to an earlier commit does not prove the final merge candidate is safe.
A tag name such as v2.0 does not prove immutable content if maintainers may silently move the tag.
An approval on yesterday's diff is not proof that today's updated diff was reviewed.
Adding a path to .gitignore does not stop tracking files that are already committed in Git.

Explanation

Correct Answer

Adding a path to .gitignore does not stop tracking files that are already committed in Git. This is the relevant unsupported assumption because good repository hygiene versions intentional source inputs, not disposable locally generated outputs.

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: Adding a path to .gitignore does not stop tracking files that are already committed in Git.

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

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)
Microsoft AZ-400 Practice Test 26 - 10 Questions (Last Reviewed 20-Oct-2026)

Pass Your Microsoft AZ-400 Exam Easy!

Question 230

Explanation

Correct Answer

Incorrect Answers

Question 231

Explanation

Correct Answer

Incorrect Answers

Question 232

Explanation

Correct Answer

Incorrect Answers

Question 233

Explanation

Correct Answer

Incorrect Answers

Question 234

Explanation

Correct Answer

Incorrect Answers

Question 235

Explanation

Correct Answer

Incorrect Answers

Question 236

Explanation

Correct Answer

Incorrect Answers

Question 237

Explanation

Correct Answer

Incorrect Answers

Question 238

Explanation

Correct Answer

Incorrect Answers

Question 239

Explanation

Correct Answer

Incorrect Answers

Question 240

Explanation

Correct Answer

Incorrect Answers

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