Microsoft AZ-400 Practice Test 1

Question 1

A platform team tracks deployment incidents in chat while the associated Azure Boards work items remain unlinked to code changes and releases. Which design or operational change MOST directly satisfies the requirement?

Configure Azure Pipelines or GitHub Actions notifications with environment, job result, revision and owner details.
Link work items, pull requests, commits, builds, releases and incident records using consistent identifiers and supported integrations.
Count successful target-environment deployments separately from runs, approvals and failed attempts.
Provide a maintained project onboarding runbook with permissions, repository layout, pipelines and support escalation.

Explanation

Correct Answer

End-to-end delivery traceability connects business requests and defects to the exact implemented and deployed change. The most directly responsive design or operational step is: Link work items, pull requests, commits, builds, releases and incident records using consistent identifiers and supported integrations. Confirm the result by: Trace a sampled customer incident through its linked work item, approved change, build and deployed release with matching IDs.

Incorrect Answers

Useful collaboration notifications convey the specific action context and accountable response path. The relevant control is to link work items, pull requests, commits, builds, releases and incident records using consistent identifiers and supported integrations.

Delivery metrics should use actual environment outcomes rather than intermediate pipeline activity. The needed step here is to link work items, pull requests, commits, builds, releases and incident records using consistent identifiers and supported integrations.

Repeatable project documentation must identify prerequisites and verification steps for the intended audience. The appropriate remedy is to link work items, pull requests, commits, builds, releases and incident records using consistent identifiers and supported integrations.

Question 2

After the team applies this response: Link work items, pull requests, commits, builds, releases and incident records using consistent identifiers and supported integrations. In the situation—A platform team tracks deployment incidents in chat while the associated Azure Boards work items remain unlinked to code changes and releases. Which evidence BEST demonstrates the response is effective?

Trace a sampled customer incident through its linked work item, approved change, build and deployed release with matching IDs.
Emit a controlled test event and inspect delivery, signature verification and duplicate-processing behavior.
Reconcile unique work item IDs and source totals before publishing the Power BI dataset.
Compare raw Azure Boards state history to calculated lead-time components for delayed work items.

Explanation

Correct Answer

This evidence directly verifies the proposed control under the stated failure scenario: Trace a sampled customer incident through its linked work item, approved change, build and deployed release with matching IDs. The governing engineering principle is: End-to-end delivery traceability connects business requests and defects to the exact implemented and deployed change.

Incorrect Answers

Event-driven collaboration integrations require authenticity, reliable delivery and duplicate-safe processing. Instead, the response must trace a sampled customer incident through its linked work item, approved change, build and deployed release with matching IDs.

Dashboards require validated query grain and data lineage to prevent misleading delivery counts. The relevant control is to trace a sampled customer incident through its linked work item, approved change, build and deployed release with matching IDs.

Flow diagnostics require knowing which stages consume elapsed time, not just a single end-to-end average. The needed step here is to trace a sampled customer incident through its linked work item, approved change, build and deployed release with matching IDs.

Question 3

A second team has GitHub Issues and Azure Boards records that cannot be traced to the pull request that corrected a production defect. Which engineering principle BEST explains the relevant requirement?

Reliable test metrics separate reproducibility and meaningful verification from the volume of green results.
Delivery performance measurement should balance flow speed with change stability and recovery outcomes.
Flow diagnostics require knowing which stages consume elapsed time, not just a single end-to-end average.
End-to-end delivery traceability connects business requests and defects to the exact implemented and deployed change.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: End-to-end delivery traceability connects business requests and defects to the exact implemented and deployed change. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

Reliable test metrics separate reproducibility and meaningful verification from the volume of green results. That principle concerns design and implement appropriate metrics and queries for devops, whereas this specific incident is governed by: End-to-end delivery traceability connects business requests and defects to the exact implemented and deployed change.

Delivery performance measurement should balance flow speed with change stability and recovery outcomes. That principle concerns design and implement appropriate metrics and queries for devops, whereas this specific incident is governed by: End-to-end delivery traceability connects business requests and defects to the exact implemented and deployed change.

Flow diagnostics require knowing which stages consume elapsed time, not just a single end-to-end average. That principle concerns design and implement appropriate metrics and queries for devops, whereas this specific incident is governed by: End-to-end delivery traceability connects business requests and defects to the exact implemented and deployed change.

Question 4

A second team has GitHub Issues and Azure Boards records that cannot be traced to the pull request that corrected a production defect. Which unsupported assumption should the engineer challenge FIRST?

A closed ticket alone does not demonstrate which reviewed source revision resolved the associated production issue.
A successful final rerun cannot erase evidence that an automated test is unstable.
A historical chart alone cannot ensure that an emerging pipeline bottleneck receives timely attention.
Completing a wiki checklist does not prove the new team's repository permissions are least privilege.

Explanation

Correct Answer

A closed ticket alone does not demonstrate which reviewed source revision resolved the associated production issue. This is the relevant unsupported assumption because end-to-end delivery traceability connects business requests and defects to the exact implemented and deployed change.

Incorrect Answers

A successful final rerun cannot erase evidence that an automated test is unstable. The acceptance criterion here is: A closed ticket alone does not demonstrate which reviewed source revision resolved the associated production issue.

A historical chart alone cannot ensure that an emerging pipeline bottleneck receives timely attention. What must be demonstrated is: A closed ticket alone does not demonstrate which reviewed source revision resolved the associated production issue.

This is the relevant unsupported assumption because repeatable project documentation must identify prerequisites and verification steps for the intended audience. The appropriate comparison is: A closed ticket alone does not demonstrate which reviewed source revision resolved the associated production issue.

Question 5

An engineering team uses long-lived feature branches, leaving urgent production fixes stranded behind several unreviewed changes. Which design or operational change MOST directly satisfies the requirement?

Include scan execution status, coverage, severity, exceptions and remediation age in security metrics.
Move shared engineering documentation into a reviewed wiki or repository with versioned Markdown and ownership.
Adopt a documented GitHub Flow or trunk-based workflow with protected mainline and small reviewed pull requests.
Maintain reviewable Mermaid or architecture-as-code diagrams with the design documentation and repository history.

Explanation

Correct Answer

Short integration cycles and controlled mainline changes reduce drift while keeping responsibility for each change visible. The most directly responsive design or operational step is: Adopt a documented GitHub Flow or trunk-based workflow with protected mainline and small reviewed pull requests. Confirm the result by: Examine branch lifetime, pull-request review records and successful mainline integration for a sample of changes.

Incorrect Answers

Security visibility must account for detection coverage and unresolved exceptions, not only reported finding counts. The relevant evidence instead is: Adopt a documented GitHub Flow or trunk-based workflow with protected mainline and small reviewed pull requests.

Versioned collaborative documentation keeps operational guidance reviewable alongside the changes it describes. The acceptance criterion here is: Adopt a documented GitHub Flow or trunk-based workflow with protected mainline and small reviewed pull requests.

Diagrams managed as code improve traceability and review when they change with the architecture. What must be demonstrated is: Adopt a documented GitHub Flow or trunk-based workflow with protected mainline and small reviewed pull requests.

Question 6

After the team applies this response: Adopt a documented GitHub Flow or trunk-based workflow with protected mainline and small reviewed pull requests. In the situation—An engineering team uses long-lived feature branches, leaving urgent production fixes stranded behind several unreviewed changes. Which evidence BEST demonstrates the response is effective?

Reconstruct incidents using monitoring timelines, incident histories and verified service restoration points.
Trace a released tag to the generated change list and confirm included PRs match shipped commits.
Reconcile Azure Pipelines or GitHub Actions run history against the dashboard filters and included attempts.
Examine branch lifetime, pull-request review records and successful mainline integration for a sample of changes.

Explanation

Correct Answer

This evidence directly verifies the proposed control under the stated failure scenario: Examine branch lifetime, pull-request review records and successful mainline integration for a sample of changes. The governing engineering principle is: Short integration cycles and controlled mainline changes reduce drift while keeping responsibility for each change visible.

Incorrect Answers

A time-to-restore metric must follow the customer-visible outage, not administrative ticket lifecycle changes. The appropriate remedy is to examine branch lifetime, pull-request review records and successful mainline integration for a sample of changes.

Automated release-note generation is credible when driven by the exact version boundary and reviewed history. Instead, the response must examine branch lifetime, pull-request review records and successful mainline integration for a sample of changes.

Pipeline metrics are reliable only when their population includes the failure states relevant to engineering decisions. The relevant control is to examine branch lifetime, pull-request review records and successful mainline integration for a sample of changes.

Question 7

A second product has a high-traffic shared repository but no agreed branching model or short-feedback integration routine. Which engineering principle BEST explains the relevant requirement?

Dashboards require validated query grain and data lineage to prevent misleading delivery counts.
Flow diagnostics require knowing which stages consume elapsed time, not just a single end-to-end average.
Short integration cycles and controlled mainline changes reduce drift while keeping responsibility for each change visible.
Delivery performance measurement should balance flow speed with change stability and recovery outcomes.

Explanation

Correct Answer

The second engineering situation illustrates the control boundary captured by this principle: Short integration cycles and controlled mainline changes reduce drift while keeping responsibility for each change visible. The scenario is not resolved by an unrelated pipeline or policy activity.

Incorrect Answers

Dashboards require validated query grain and data lineage to prevent misleading delivery counts. That principle concerns design and implement appropriate metrics and queries for devops, whereas this specific incident is governed by: Short integration cycles and controlled mainline changes reduce drift while keeping responsibility for each change visible.

Flow diagnostics require knowing which stages consume elapsed time, not just a single end-to-end average. That principle concerns design and implement appropriate metrics and queries for devops, whereas this specific incident is governed by: Short integration cycles and controlled mainline changes reduce drift while keeping responsibility for each change visible.

Delivery performance measurement should balance flow speed with change stability and recovery outcomes. That principle concerns design and implement appropriate metrics and queries for devops, whereas this specific incident is governed by: Short integration cycles and controlled mainline changes reduce drift while keeping responsibility for each change visible.

Question 8

A second product has a high-traffic shared repository but no agreed branching model or short-feedback integration routine. Which unsupported assumption should the engineer challenge FIRST?

A pipeline execution starting is not proof that a deployable release reached production.
A long lead time does not by itself identify coding effort as the bottleneck.
A message saying deployment succeeded without target-environment context cannot prove a production release succeeded.
Creating more long-lived branches does not automatically make a shared codebase safer to integrate.

Explanation

Correct Answer

Creating more long-lived branches does not automatically make a shared codebase safer to integrate. This is the relevant unsupported assumption because short integration cycles and controlled mainline changes reduce drift while keeping responsibility for each change visible.

Incorrect Answers

This caution is valid in design and implement appropriate metrics and queries for devops, but it is not the failure assumption illustrated by this scenario. The directly relevant risk is: Creating more long-lived branches does not automatically make a shared codebase safer to integrate.

This caution is valid in configure collaboration and communication, but it is not the failure assumption illustrated by this scenario. The directly relevant risk is: Creating more long-lived branches does not automatically make a shared codebase safer to integrate.

Question 9

Business stakeholders cannot tell whether GitHub Project delivery cards reflect accepted pull requests or simply developer-reported progress. Which design or operational change MOST directly satisfies the requirement?

Establish explicit workflow states and automation that links GitHub pull requests and deployment outcomes to the appropriate project cards.
Include scan execution status, coverage, severity, exceptions and remediation age in security metrics.
Centralize versioned API contract documentation and configure release notifications for identified consumers.
Implement event correlation and idempotent updates using stable external IDs rather than always creating a new item.

Explanation

Correct Answer

Work item status is trustworthy only when transitions correspond to defined evidence in the engineering workflow. The most directly responsive design or operational step is: Establish explicit workflow states and automation that links GitHub pull requests and deployment outcomes to the appropriate project cards. Confirm the result by: Compare status transitions with linked PR merges and actual release evidence for a delivered feature.

Incorrect Answers

Security visibility must account for detection coverage and unresolved exceptions, not only reported finding counts. The needed step here is to establish explicit workflow states and automation that links GitHub pull requests and deployment outcomes to the appropriate project cards.

Communicating interface changes depends on discoverable authoritative contract versions and known recipients. The appropriate remedy is to establish explicit workflow states and automation that links GitHub pull requests and deployment outcomes to the appropriate project cards.

Cross-system communication should preserve one logical work record across retries and duplicate events. Instead, the response must establish explicit workflow states and automation that links GitHub pull requests and deployment outcomes to the appropriate project cards.

Question 10

After the team applies this response: Establish explicit workflow states and automation that links GitHub pull requests and deployment outcomes to the appropriate project cards. In the situation—Business stakeholders cannot tell whether GitHub Project delivery cards reflect accepted pull requests or simply developer-reported progress. Which evidence BEST demonstrates the response is effective?

Compare status transitions with linked PR merges and actual release evidence for a delivered feature.
Reconstruct incidents using monitoring timelines, incident histories and verified service restoration points.
Recalculate each dashboard metric from timestamped source, deployment and incident records using documented definitions.
Replay the calculation against raw test attempts and verify failure/retry records are not dropped.

Explanation

Correct Answer

The governing engineering principle is: Work item status is trustworthy only when transitions correspond to defined evidence in the engineering workflow.

Incorrect Answers

A time-to-restore metric must follow the customer-visible outage, not administrative ticket lifecycle changes. The relevant control is to compare status transitions with linked PR merges and actual release evidence for a delivered feature.

Delivery performance measurement should balance flow speed with change stability and recovery outcomes. The needed step here is to compare status transitions with linked PR merges and actual release evidence for a delivered feature.

Reliable test metrics separate reproducibility and meaningful verification from the volume of green results. The appropriate remedy is to compare status transitions with linked PR merges and actual release evidence for a delivered feature.