Microsoft DevOps Engineer Expert Practice Test (AZ-400)

The dependsOn property at the stage level is used to enforce execution order, making the Test stage wait for the Build stage. By default, a stage with this dependency will only run if the preceding stage succeeds (an implicit condition: succeeded()). If any job within the Test stage's matrix fails, the Test stage itself fails. Because there are no subsequent stages with conditions that would override this outcome, the entire pipeline run will correctly be marked as failed.

Scalar accelerates work with very large repositories by creating a partial clone that downloads only the data a developer actually touches and by scheduling background maintenance to keep the local clone efficient. It runs as a thin layer over standard Git, so existing commands continue to work and the full history is preserved. Sparse checkout alone still requires the full object database to be downloaded, migrating to TFVC replaces Git entirely, and moving content to LFS targets binary files but does not solve the fundamental performance issues of cloning and fetching a multi-gigabyte history.

Installing the Azure Boards app for the GitHub organization establishes a secure connection between GitHub and Azure DevOps. When developers include the shorthand AB# in a commit message or pull-request title or description, the integration automatically creates links and updates the work item's development section. Other options either require custom scripting, rely on features that do not exist, or add unnecessary maintenance overhead while still lacking the automatic linking supported natively by the Azure Boards app.

Creating a custom security group at the organization level lets you manage membership in a single place. When you grant that group the Code → Read permission at the organization level, Azure DevOps automatically creates a corresponding group inside every current and future project, inheriting the read-only permission for all repositories. Because the group has no permissions for Boards, Pipelines, or other resources, consultants can only view code. Adding consultants as Stakeholders would prevent any code access, while creating or modifying project-level groups would require changes each time a new project is added.

Configuring a branch policy on the main branch lets you gate every pull request. A required Build Validation policy queues the designated pipeline automatically and blocks approval until the build and unit tests pass. Adding the Backend Leads group as Required reviewers with the minimum-reviewer count set to 2 ensures that two members of that group must approve the PR. Enabling Comment resolution required prevents completion while any discussion thread is still active. Because policies are evaluated continuously, developers can enable Auto-complete when they click Complete; the PR is then merged automatically as soon as the build and review policies finish, satisfying the final requirement. The other options either fail to enforce the build, do not restrict approval to the required group, or cannot guarantee automatic completion after policies succeed.

An Azure Artifacts npm feed can be configured with an upstream source that transparently caches any package downloaded from npmjs.org, ensuring future builds are not affected if the package is later removed from the public registry. Within the same feed you can create views (for example, Development, Test, and Production) and promote specific package versions between those views after they pass validation. Development pipelines resolve packages from a less-restricted view, while production pipelines are scoped to the Production view, satisfying the approval gate. GitHub Packages, direct registry references, or a custom mirror either fail to cache automatically, lack built-in promotion workflows, or introduce unnecessary management overhead.

The matrix strategy supports the maxParallel setting, which caps the number of matrix replicas that can run at the same time. Setting maxParallel to 2 ensures that no more than two of the six matrix jobs execute concurrently, thereby limiting consumption of Microsoft-hosted parallel jobs while still running all six test combinations sequentially. Adding dependsOn would require splitting the job into separate definitions and would still launch multiple agents unless manually serialized. Using a runtime expression on Agent.JobServerParallelism does not throttle matrix concurrency. Switching to self-hosted agents avoids Microsoft-hosted job charges but does not satisfy the requirement to keep using Microsoft-hosted agents while simply limiting concurrency.

After a force-push rewrites a remote branch's history, the lost commit objects still exist on the server for a time but are no longer referenced by the branch tip. When you run git fetch in your local repository, your remote-tracking branch (origin/feature-alpha) is updated to match the new, incorrect tip. Critically, Git records this change in your local reflog for that remote-tracking branch. By running git reflog origin/feature-alpha, you can inspect the recent history of that reference and find the commit SHA it pointed to just before the fetch updated it. Once you have the correct SHA, you can restore the branch on the remote (e.g., git push origin <sha>:refs/heads/feature-alpha). The other commands are incorrect; git revert creates new commits instead of restoring old ones, git cherry-pick requires you to already know the commit SHA, and git fetch --force is not the correct command for discovering lost commit hashes.

A pipeline-level concurrency block lets you place all runs of the pipeline into the same named group and, when cancelInProgress is set to true, Azure Pipelines automatically cancels any earlier queued or running instance as soon as a newer run is queued. This guarantees that at most one run is active, eliminating wasted agent minutes.

Batching a CI trigger defers queuing new runs until the current one completes but does not cancel a running build, so multiple runs can still execute consecutively.

Retention policies control how long completed runs and their artifacts are stored; they do not affect how many runs can execute concurrently.

Pool settings such as demands or a fictitious minimumParallelJobs property cannot limit pipeline-level concurrency or cancel in-progress runs.

Stakeholder access in Azure DevOps permits viewing, creating, and editing work items, as well as accessing boards and dashboards, but blocks access to Repos and Pipelines-exactly what the finance analysts need without granting excess rights. In GitHub, an outside collaborator is not an organization member yet can be granted read, write, or admin permission for selected repositories. Granting the UX designer outside-collaborator status with write permission on only the required repository lets the designer clone and push while keeping every other repository and organization resource inaccessible. The alternative choices either over-provision analysts (Basic access) or grant the designer broader or insufficient rights, violating least-privilege principles.

Uploading the certificate to the Library as a secure file and adding a DownloadSecureFile@1 task meets every stated requirement. Secure files are stored encrypted in Azure DevOps, are not exposed in the repository, and the task downloads them to a temporary location that is deleted automatically at the end of the job. Secret variables or Azure Key Vault can hold text values but do not natively handle binary certificate files or guarantee automatic cleanup. Committing the file-even in a private submodule-places the sensitive data in source control, violating the security constraint.

GitHub environment-level secrets are exposed only to workflows that explicitly reference the environment and are always redacted in log output, meeting GitHub's scoping and masking needs.

In Azure DevOps, a variable group that is linked to an Azure Key Vault keeps the secret encrypted, lets multiple pipelines consume it, and automatically synchronizes when the secret is rotated in Key Vault.

Repository or organization secrets in GitHub do not limit access to a particular environment, and plain pipeline variables in Azure DevOps do not support automatic rotation from Key Vault. Service connections authenticate to Azure but do not distribute the secret to jobs. Therefore, using environment secrets in GitHub together with a Key Vault-linked variable group in Azure Pipelines is the only option that fulfills every constraint.

The Azure DevOps action in an Azure Monitor action group authenticates by using a personal access token (PAT). The PAT must be generated beforehand in the target Azure DevOps organization and scoped to at least Work Items (read and write). Without supplying the PAT, Azure Monitor cannot connect to Azure DevOps to create work items. Service hooks, IDE extensions, and app registrations are not required for this integration.

Using the Cache task creates a pipeline-managed cache on the agent pool. The key can include a hash of pom.xml so the cache is automatically invalidated when dependencies change. Subsequent jobs on any Microsoft-hosted agent will download the cache from Azure Storage instead of Maven Central, greatly reducing run time and egress cost while requiring no agent customization. Pipeline artifacts are intended for sharing outputs between jobs or runs and do not provide automatic invalidation, Git LFS would bloat the repository and increase storage cost, and selecting a different hosted image does not guarantee the required dependencies will be pre-installed.

Trunk-based development keeps a single long-lived trunk (often named main) that every developer merges into at least once per day, so the build pipeline can always build from one branch with a linear history. Short-lived feature branches are created only when necessary and are merged back rapidly, minimizing integration risk. Hotfix and release branches are also cut from the trunk, allowing urgent fixes to ship immediately while normal feature work continues. GitFlow and other long-lived feature branching models intentionally introduce multiple permanent branches (for example, develop or feature branches) that delay integration and complicate the history. A forking workflow spreads work across personal repositories, which hampers the required frequent integration and centralized CI.

In Azure Pipelines you control the execution order of jobs inside a stage by using job-level dependencies. By adding "dependsOn: Deploy-Database" to the Deploy-WebApp job (or, equivalently, listing the job name under the dependsOn collection) you create an explicit dependency graph. The job will start only after its dependency finishes and returns a successful result. Including the default "condition: succeeded()" (or explicitly setting the condition) further guarantees the second deployment runs only on a successful upstream result. Relying on task order, variable polling, or assuming deployment jobs run after regular jobs does not guarantee sequencing across separate jobs and therefore cannot ensure reliably ordered dependency deployments.

Branch policies provide granular merging restrictions. Requiring a minimum number of reviewers and adding a build-validation policy blocks completion of any pull request until both conditions are met. Preventing Contributors from bypassing the policy is achieved by explicitly denying the "Bypass policies when pushing" permission on the main branch for the Contributors group. Granting that same permission to Project Administrators lets them override the policy when needed. No other option simultaneously enforces the reviews and build, blocks Contributors from overriding, and still lets administrators merge in emergencies.

The requests and dependencies tables store data for incoming requests and outgoing calls, respectively. Both tables share the same correlation identifier, operation_Id, which enables end-to-end analysis of a single transaction. By projecting the identifier from each table and performing an inner join on operation_Id, you can correlate each /api/checkout request with its dependency calls. After the join, summarizing the two duration columns over a time bin produces a single chart that compares the average server processing time (requestDuration) with the average time spent in external calls (dependencyDuration). Queries that look only at requests or only at dependencies-or that filter on the wrong column-cannot expose which side contributes more to the total latency.

A branch policy can enforce PR-based reviews and build validation. Setting "Minimum number of reviewers" to 2, clearing "Allow requestors to approve," and enabling "Reset approvals when new changes are pushed" satisfies the review-workflow rules. Adding a build-validation check ensures the pipeline passes before completion. Permissions, not a branch lock, are needed to keep the branch usable while protecting it; denying Force push and Delete on the branch security tab prevents both actions and, because Contribute is not explicitly allowed, blocks direct pushes but still permits the PR merge service account. The other answers fail by either locking the branch (which disables merges), allowing self-approval, omitting approval resets, or leaving the branch unprotected against direct or force pushes.

Azure DevOps can render Mermaid diagrams that are written in Markdown, but the diagram must be enclosed in a fenced code block whose language identifier is mermaid. Placing the keyword mermaid after the opening triple backticks activates the built-in renderer and the diagram is displayed as graphics. PlantUML blocks are not rendered natively, there is no setting to enable a special preview mode, and file extensions such as .mmd are not used to trigger rendering inside a wiki page.