Microsoft AZ-400 Practice Test 22

Question 210

After the team applies this response: Split privileged content into independently controlled repositories or boundaries rather than rely on sparse checkout. In the situation—A monorepo includes credentials, while external contractors should only work on the public web frontend subtree. Which evidence BEST demonstrates the response is effective?

Verify a contributor can propose a PR and that merging still requires the required independent checks.
Introduce a new commit or target update and confirm the policy requires a current successful validation run.
Test contractor access to the separate sensitive repository and confirm authorization differs from the frontend.
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: Git checkout optimization is not an access-control mechanism because authorized clones can request other objects.

Incorrect Answers

A safe branch strategy must balance collaborative change proposals with protected shared integration. The relevant control is to test contractor access to the separate sensitive repository and confirm authorization differs from the frontend.

Merge gates must verify the code state that will be integrated, not a stale earlier validation. The needed step here is to test contractor access to the separate sensitive repository and confirm authorization differs from the frontend.

Commit authenticity controls address provenance only when verified identities and enforcement are configured. The appropriate remedy is to test contractor access to the separate sensitive repository and confirm authorization differs from the frontend.

Question 211

A separate program assumes sparse checkout prevents developers from viewing restricted infrastructure files. Which engineering principle BEST explains the relevant requirement?

Multi-version source support requires explicit patch propagation and documented branch retirement.
Release labels are trustworthy only when the tagged revision and tag governance are controlled.
Branch protection relies on trustworthy status results that apply to the submitted change.
Git checkout optimization is not an access-control mechanism because authorized clones can request other objects.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: Git checkout optimization is not an access-control mechanism because authorized clones can request other objects. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

Multi-version source support requires explicit patch propagation and documented branch retirement. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Git checkout optimization is not an access-control mechanism because authorized clones can request other objects.

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: Git checkout optimization is not an access-control mechanism because authorized clones can request other objects.

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: Git checkout optimization is not an access-control mechanism because authorized clones can request other objects.

Question 212

A separate program assumes sparse checkout prevents developers from viewing restricted infrastructure files. Which unsupported assumption should the engineer challenge FIRST?

Creating a permanent branch for every feature does not automatically reduce merge or release risk.
Hiding a folder from the working directory does not make committed secrets inaccessible to repository readers.
A configured required check does not protect a branch when its workflow can be omitted without blocking.
Preventing developers from opening change branches can push work outside the reviewed source system.

Explanation

Correct Answer

Hiding a folder from the working directory does not make committed secrets inaccessible to repository readers. This is the relevant unsupported assumption because git checkout optimization is not an access-control mechanism because authorized clones can request other objects.

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: Hiding a folder from the working directory does not make committed secrets inaccessible to repository readers.

Question 213

A project uses Git submodules for shared libraries but builds break because the submodule pointer references a deleted commit. Which design or operational change MOST directly satisfies the requirement?

Pin shared source dependencies to accessible immutable revisions and validate submodule or package availability in CI.
Configure Azure Repos policies to reset or require renewed approvals when updates change the reviewed PR content.
Enable the applicable signed-commit requirements and validate identities and branch policy behavior at merge time.
Define a release/hotfix branch flow with reviewed back-merges or cherry-picks into supported branches.

Explanation

Correct Answer

Source dependency reproducibility depends on fixed, accessible references and explicit retrieval processes. The most directly responsive design or operational step is: Pin shared source dependencies to accessible immutable revisions and validate submodule or package availability in CI. Confirm the result by: Clone the release at an exact revision and verify every declared dependent repository can be resolved.

Incorrect Answers

Approval integrity requires binding review decisions to the current content of the change, not an earlier version. The appropriate comparison is: Pin shared source dependencies to accessible immutable revisions and validate submodule or package availability in CI.

Commit authenticity controls address provenance only when verified identities and enforcement are configured. The relevant evidence instead is: Pin shared source dependencies to accessible immutable revisions and validate submodule or package availability in CI.

Long-lived maintenance lines require explicit propagation of fixes to prevent divergent defects. The acceptance criterion here is: Pin shared source dependencies to accessible immutable revisions and validate submodule or package availability in CI.

Question 214

After the team applies this response: Pin shared source dependencies to accessible immutable revisions and validate submodule or package availability in CI. In the situation—A project uses Git submodules for shared libraries but builds break because the submodule pointer references a deleted commit. Which evidence BEST demonstrates the response is effective?

Review a simulated bypass attempt and the resulting audit record and independently authorized exception.
Audit a security fix across affected maintenance branches and confirm relevant deployed versions include it.
Introduce a new commit or target update and confirm the policy requires a current successful validation run.
Clone the release at an exact revision and verify every declared dependent repository can be resolved.

Explanation

Correct Answer

The governing engineering principle is: Source dependency reproducibility depends on fixed, accessible references and explicit retrieval processes.

Incorrect Answers

Branch policy integrity depends on tightly limited bypass privileges and transparent exceptional use. What must be demonstrated is: Clone the release at an exact revision and verify every declared dependent repository can be resolved.

Multi-version source support requires explicit patch propagation and documented branch retirement. The appropriate comparison is: Clone the release at an exact revision and verify every declared dependent repository can be resolved.

Merge gates must verify the code state that will be integrated, not a stale earlier validation. The relevant evidence instead is: Clone the release at an exact revision and verify every declared dependent repository can be resolved.

Question 215

Another enterprise copies dependencies through undocumented shell scripts and cannot reproduce a deployment. Which engineering principle BEST explains the relevant requirement?

Long-lived maintenance lines require explicit propagation of fixes to prevent divergent defects.
Feature flags can decouple code integration from user exposure when defaults and cleanup are governed.
Trunk-based integration limits divergence and makes failures easier to attribute when tests run on each change.
Source dependency reproducibility depends on fixed, accessible references and explicit retrieval processes.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: Source dependency reproducibility depends on fixed, accessible references and explicit retrieval processes. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

Long-lived maintenance lines require explicit propagation of fixes to prevent divergent defects. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Source dependency reproducibility depends on fixed, accessible references and explicit retrieval processes.

Feature flags can decouple code integration from user exposure when defaults and cleanup are governed. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Source dependency reproducibility depends on fixed, accessible references and explicit retrieval processes.

Trunk-based integration limits divergence and makes failures easier to attribute when tests run on each change. That principle concerns design and implement branching strategies for the source code, whereas this specific incident is governed by: Source dependency reproducibility depends on fixed, accessible references and explicit retrieval processes.

Question 216

Another enterprise copies dependencies through undocumented shell scripts and cannot reproduce a deployment. Which unsupported assumption should the engineer challenge FIRST?

A submodule URL alone is not enough to identify the version used by a released build.
An approval on yesterday's diff is not proof that today's updated diff was reviewed.
A tag name such as v2.0 does not prove immutable content if maintainers may silently move the tag.
Preventing developers from opening change branches can push work outside the reviewed source system.

Explanation

Correct Answer

A submodule URL alone is not enough to identify the version used by a released build. This is the relevant unsupported assumption because source dependency reproducibility depends on fixed, accessible references and explicit retrieval processes.

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 submodule URL alone is not enough to identify the version used by a released build.

Question 217

A high-volume repository runs frequent full history clones in every build, consuming bandwidth and release time. Which design or operational change MOST directly satisfies the requirement?

Capture the merge strategy, resulting commit identities and PR linkage in work and build records.
Define a release/hotfix branch flow with reviewed back-merges or cherry-picks into supported branches.
Use supported shallow or partial fetch configuration where safe, while retaining complete history for versioning steps that require it.
Adopt an explicit small-change integration policy using feature flags for incomplete behavior where appropriate.

Explanation

Correct Answer

Source retrieval should match the build's history requirements rather than always download the entire repository. The most directly responsive design or operational step is: Use supported shallow or partial fetch configuration where safe, while retaining complete history for versioning steps that require it. Confirm the result by: Compare pipeline clone time and confirm version calculation and checkout remain correct under the optimized fetch.

Incorrect Answers

Git merge strategies can change commit identity while preserving review provenance through stable PR references. Instead, the response must use supported shallow or partial fetch configuration where safe, while retaining complete history for versioning steps that require it.

Long-lived maintenance lines require explicit propagation of fixes to prevent divergent defects. The relevant control is to use supported shallow or partial fetch configuration where safe, while retaining complete history for versioning steps that require it.

Feature flags can decouple code integration from user exposure when defaults and cleanup are governed. The needed step here is to use supported shallow or partial fetch configuration where safe, while retaining complete history for versioning steps that require it.

Question 218

After the team applies this response: Use supported shallow or partial fetch configuration where safe, while retaining complete history for versioning steps that require it. In the situation—A high-volume repository runs frequent full history clones in every build, consuming bandwidth and release time. 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.
Push a controlled change after approval and confirm merge is blocked until required new review completes.
Audit a security fix across affected maintenance branches and confirm relevant deployed versions include it.
Compare pipeline clone time and confirm version calculation and checkout remain correct under the optimized fetch.

Explanation

Correct Answer

The governing engineering principle is: Source retrieval should match the build's history requirements rather than always download the entire repository.

Incorrect Answers

Source contribution and deployment authorization are different trust boundaries that must be enforced independently. The appropriate remedy is to compare pipeline clone time and confirm version calculation and checkout remain correct under the optimized fetch.

Approval integrity requires binding review decisions to the current content of the change, not an earlier version. Instead, the response must compare pipeline clone time and confirm version calculation and checkout remain correct under the optimized fetch.

Multi-version source support requires explicit patch propagation and documented branch retirement. The relevant control is to compare pipeline clone time and confirm version calculation and checkout remain correct under the optimized fetch.

Question 219

Another project uses ephemeral agents yet downloads multi-year history for every small documentation change. Which engineering principle BEST explains the relevant requirement?

Git merge strategies can change commit identity while preserving review provenance through stable PR references.
Source contribution and deployment authorization are different trust boundaries that must be enforced independently.
Source retrieval should match the build's history requirements rather than always download the entire repository.
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 retrieval should match the build's history requirements rather than always download the entire repository. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

The second engineering situation illustrates the control boundary captured by this principle: Git merge strategies can change commit identity while preserving review provenance through stable PR references. The acceptance criterion here is: Source retrieval should match the build's history requirements rather than always download the entire repository.

The second engineering situation illustrates the control boundary captured by this principle: Source contribution and deployment authorization are different trust boundaries that must be enforced independently. What must be demonstrated is: Source retrieval should match the build's history requirements rather than always download the entire repository.

The second engineering situation illustrates the control boundary captured by this principle: Approval integrity requires binding review decisions to the current content of the change, not an earlier version. The appropriate comparison is: Source retrieval should match the build's history requirements rather than always download the entire repository.

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.

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

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

Pass Your Microsoft AZ-400 Exam Easy!

Question 210

Explanation

Correct Answer

Incorrect Answers

Question 211

Explanation

Correct Answer

Incorrect Answers

Question 212

Explanation

Correct Answer

Incorrect Answers

Question 213

Explanation

Correct Answer

Incorrect Answers

Question 214

Explanation

Correct Answer

Incorrect Answers

Question 215

Explanation

Correct Answer

Incorrect Answers

Question 216

Explanation

Correct Answer

Incorrect Answers

Question 217

Explanation

Correct Answer

Incorrect Answers

Question 218

Explanation

Correct Answer

Incorrect Answers

Question 219

Explanation

Correct Answer

Incorrect Answers

Question 220

Explanation

Correct Answer

Incorrect Answers

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