Microsoft DevOps Engineer Exam Prep

A successful build does not establish that the right version reached production, that deployment access was appropriately restricted, or that a failing service will produce useful diagnostic evidence. Microsoft DevOps engineering connects these decisions. The work spans the change request, the reviewed code, the tested release, and the feedback needed to operate it.

GitHub and Azure DevOps support collaboration as well as automation. A pull request proposes a change for review before it is merged. Linking that change to its work item preserves the reason for the work, while keeping unrelated changes separate makes review and independent reversal more manageable. These practices matter when a team needs to explain what changed or undo one regression without discarding other work.

Continuous integration (CI)

Frequent integration of code into a shared repository, supported by automated builds and tests that expose problems with the combined code.

Continuous delivery (CD)

Automation that moves a tested build through validation and deployment environments. A production release can still require an approval even when the surrounding work is automated.

The distinction matters when choosing a control. Code review decides whether a proposed change should enter a branch. A deployment approval authorizes use of a protected environment. A passing test is evidence about the checks that ran, not a substitute for either decision. The people allowed to edit delivery instructions should not automatically be able to remove a production owner's approval requirement.

Deployment also differs from exposing a feature to users. A canary rollout starts with a limited subset and expands after observing health. A feature flag controls whether already-deployed behavior is enabled. Both require a clear response to failure, but they solve different problems. Choosing between them depends on whether the requirement concerns deploying a version, controlling feature availability, or limiting initial exposure.

Operational feedback gives those choices evidence. Instrumentation is the collection of measurements and diagnostic records about a running service. Metrics summarize behavior, while a distributed trace connects the work performed across services for one operation. Delivery-process measurements answer a different question. In Azure Boards, lead time includes waiting after a work item is created, whereas cycle time begins when work first becomes active. Confusing these measures can send a team toward the wrong bottleneck.

AZ-400, Designing and Implementing Microsoft DevOps Solutions, assesses decisions across this delivery process. Microsoft expects experience in both Azure administration and development, strong skills in at least one, and experience with both GitHub and Azure DevOps. Earning the DevOps Engineer Expert credential also requires an eligible associate certification. Recognizing a sound answer is useful preparation, but configuring, running, and troubleshooting the corresponding solution remains a separate practical skill.

How to Use This Tool:

Choose a mixed round for broader sampling or a named domain for focused review. Each untimed scenario has four choices and accepts one answer.

1. Choose Domain and Question count. The default is Mixed domains · uniform sample with 10 questions. Mixed rounds allow 2, 5, 10, 20, or 40 questions. Build and release pipelines allows 2, 5, 10, or 20. The other domains allow 2 or 5. Switching to a focused domain keeps an allowed count or resets it to 5.
   If Saved attempt unavailable appears, choose Clear saved link and start a new round. An incompatible saved attempt cannot be resumed as a current round.
2. Select Feedback. After each answer, the default, shows the correction and explanation before you advance. At the end records each answer without revealing correctness until the final review.
3. Set an optional Replay seed under Advanced, then choose Start exam practice. Blank or whitespace-only input uses az400-practice, and surrounding whitespace is ignored. The field retains complete Unicode characters up to 128 UTF-16 code units, so some emoji use two units. If a seed warning remains, replace the entry with a shorter valid text seed.
4. Choose one answer after reading all the scenario's constraints. Selection immediately records and locks the answer in either feedback mode. Use Next question to continue and View results after answering the final question.
   End round discards the current attempt and returns to setup. It does not submit an incomplete round for a final score.
5. Review the explanations in Missed answer review and the complete Answer ledger. Use the linked documentation to check the requirement you missed, then choose a retry or select Practise domain beside the domain that needs attention.

Interpreting Results:

During a round, the answered count and progress percentage measure completion, not correctness. The final summary shows correct answers out of all questions in that round. Despite the heading Readiness review, there is no calibrated readiness band or pass prediction. Microsoft's technical exams use a scaled score from 1 to 1,000 with a passing score of at least 700. That is not a rule that 70% correct in this practice equals a pass.

Domain performance shows correct and missed counts for the questions actually sampled. A longer bar may simply mean more questions were asked in that domain. Not sampled in this round means untested, not zero ability or demonstrated competence. Use the domain counts alongside the full official objectives, especially after a short mixed round. If the chart is unavailable, the written domain counts remain useful and Retry chart can retry the display.

Retry missed starts a new attempt containing only the missed questions. Replay same seed repeats the same question and option order, which is useful for revisiting explanations but not an independent test. Try a new seed makes another draw from the same eligible pool without guaranteeing unseen questions. Improvement on familiar items should lead to checking the underlying skill in a practice environment, not an assumption of mastery.

Technical Details:

Single-answer scoring treats each scenario as one equally weighted decision. The credited choice must satisfy the stated requirements. An unanswered question differs from an incorrect answer, even though neither contributes a point.

Scoring a delivery-decision round

Let C be correct answers, A answered questions, and N all questions selected for the round. A correct answer earns 1 point and an incorrect answer earns 0, with no partial credit or deductions. Total points equal C, possible points equal N, and the final score is displayed as C/N.

The percentage equivalent of that score uses all selected questions, including any still unanswered.

Progress instead counts every answered question, whether correct or incorrect.

Unanswered questions remain in N without being counted as misses. Correct and missed counts add up to A. Raw accuracy and progress remain unrounded. Counts are exact integers, and the visible progress percentage is rounded to the nearest whole percent, with exact halves rounded up. Completing every question unlocks the final review.

These messages describe completion and misses, not examination passing thresholds.

Official objectives and authored coverage

The practice targets the English AZ-400 skills measured as of July 27, 2026, using a question bank dated September 12, 2026. Its 40 original scenarios are distributed as follows. Official percentages describe the examination blueprint, not score weights or guaranteed quotas in a practice round.

Selection is uniform across eligible questions in the chosen domain or mixed pool, without replacement within a round. It does not enforce the official domain proportions. Selecting all 40 questions includes the entire authored bank, not the entire AZ-400 syllabus. Broader objectives include areas such as container and database deployments, repository scaling, configuration management, and additional security controls.

Reproducing a round requires the same seed, domain, question count, feedback mode, and compatible question-bank and session versions. Changing feedback mode can change which questions appear as well as their order. A new seed cannot create content beyond the existing pool, and a full-pool round necessarily repeats that pool's questions.

Job ordering, failure conditions, and approval ownership

Within an Azure Pipelines stage, listing a deployment job after a build job does not establish a dependency. A declaration such as dependsOn: Build makes the deployment wait for that job. A custom condition then determines whether it may run, replacing the normal success condition rather than adding to it.

For a dependent job that requires successful prerequisites and the main branch, both checks belong in the condition.

condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

The dependency still needs to be declared separately. A branch-only condition omits the success requirement. Similarly, merely publishing a test report does not necessarily fail a job whose test runner exited successfully. For PublishTestResults@2, failTaskOnFailedTests: true makes reported test failures fail the publishing task.

Authorization is separate from execution order. In Azure DevOps Services, resource owners manage approvals and checks outside the pipeline's YAML, the text format used to declare its work. Editing that YAML does not remove those resource checks. An exclusive lock addresses another requirement by allowing only one run at a time to use the protected resource. Approval alone does not prevent concurrent deployments.

Tested artifacts and version meaning

A deployment that must use a particular build should consume that build's published artifact. Another job may run on a different agent, so its local files cannot be assumed to contain the earlier output. Rebuilding from the latest source can produce different bytes. Azure Artifacts package versions are also immutable once published, so a failure later in a run does not make the published version available for overwriting.

Semantic Versioning 2.0.0 communicates changes to a declared public application programming interface (API) through major, minor, and patch numbers. For a stable API currently at 2.6.4, the next version depends on what the release changes.

These stable-API rules should not be assumed for initial-development versions beginning with zero. Build metadata does not affect version ordering and is not a substitute for a required major, minor, or patch increment.

Workflow identity and diagnostic evidence

OpenID Connect (OIDC) allows a GitHub Actions job to present signed identity claims to a supporting cloud provider and obtain short-lived cloud credentials. The trust relationship must restrict which repositories and execution contexts may assume the intended role. Replacing a long-lived secret does not justify granting broader permissions.

For Application Insights correlation using the field names in these scenarios, operation_Id connects telemetry from one logical operation. An individual span, or unit of work, has its own id, while operation_ParentId links it to its parent. Grouping by a user session instead can combine unrelated operations.

Aggregation answers a different diagnostic question. Given the scenario's table named Requests with a datetime column named Timestamp, this Kusto Query Language (KQL) expression counts stored records in five-minute groups.

Requests
| summarize Requests=count() by bin(Timestamp, 5m)

Without grouping, the count would be one total rather than a time series. The table and column names are the scenario's stated schema, not universal names for every monitoring workspace. Sampling can retain only part of the telemetry, so these stored records do not necessarily represent every request. A missing individual trace is not proof that its request never occurred.

Limitations and Privacy:

The scenarios are independently authored and unofficial, not reproduced Microsoft exam questions. This practice does not claim Microsoft affiliation or endorsement, and completing a round does not award a credential. Difficulty is not calibrated to the examination. This is conceptual single-answer practice, not a simulation of case studies, labs, or hands-on delivery work. Microsoft does not disclose the exact question mix or guarantee that a particular attempt will contain labs.

The named English objective edition does not establish the update date of every localized exam. Product availability also matters when applying an explanation. GitHub environment reviewer features depend on repository visibility and plan, while App Service deployment slots require a supporting service tier. Check the current exam and product documentation rather than treating an authored scenario as an availability guarantee.

Scoring happens in the browser, but the page address also saves the attempt's replay details and submitted answers in encoded, unencrypted form. Someone receiving that address can restore the attempt and inspect its answers. Addresses can remain in browser history and be sent to the site when opened or reloaded. Keep credentials, personal information, and confidential project details out of the replay seed.

Page assets, optional chart and document features, and opened documentation links can use the network. Exported ledgers include responses. If a warning says the attempt could not be saved in the link, the saved attempt is cleared from the URL while answers remain on the current page. Keep the page open to finish and preserve the ledger before resetting. Reloading will not recover those unsaved answers.

Worked Examples:

References:

• Study guide for Exam AZ-400: Designing and Implementing Microsoft DevOps Solutions, Microsoft.
• Microsoft Certified: DevOps Engineer Expert, Microsoft.
• Exam scoring and score reports, Microsoft.
• Exam duration and exam experience, Microsoft.
• Use continuous integration, Microsoft.
• What is continuous delivery?, Microsoft.
• Configure lead time and cycle time widgets, Microsoft.
• Pipeline conditions, Microsoft.
• PublishTestResults@2: Publish Test Results v2 task, Microsoft.
• Define approvals and checks, Microsoft.
• Publish and download pipeline artifacts, Microsoft.
• Semantic Versioning 2.0.0, Semantic Versioning.
• OpenID Connect, GitHub.
• Application Insights Classic API: Data model for telemetry correlation, Microsoft.
• summarize operator, Microsoft.
• Sampling in Azure Monitor Application Insights with OpenTelemetry, Microsoft.
• Deployments and environments, GitHub.
• Set up staging environments in Azure App Service, Microsoft.