Microsoft DevOps Engineer Expert Practice Test (AZ-400)

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.

git reflog records every change to the tips of references (like branches) in the local repository, including those created by reset, merge, and pull operations. Because you have already fetched the force-pushed changes, the reflog for your remote-tracking branch (origin/release) contains the history of its tip, including the hash it pointed to before the fetch. By inspecting the reflog, you can find the previous hash and restore the branch. The default retention for unreachable reflog entries is 30 days. git fsck --lost-found can find dangling objects but lacks the chronological context of the reflog, making it harder to identify the correct commit. git log --graph only shows commits in the current reachable history and will not show the lost commits. git stash list is for managing stashed changes and is unrelated to commit history recovery.

Service hooks let an Azure DevOps project push event-based notifications to external systems. Creating a Service hooks subscription with the "Work item updated" trigger allows you to:

• Filter on exact field changes (State equals Done and Area Path equals Fabrikam\Web) so no other updates raise the event.
• Specify the LOB endpoint's URL as the webhook target.
• Add a custom header that carries the PAT for the LOB API. Because the event fires only when the filter matches, the LOB system receives the minimal number of calls required. The other options either poll, use unrelated pipeline triggers, or deliver notifications to Microsoft Teams rather than the LOB endpoint.

The Cycle Time and Lead Time widgets that are part of the Azure DevOps Analytics extension read data directly from the Analytics service, refresh automatically each time the dashboard loads, and provide built-in drill-through to the individual work items that compose the metric. Because the Analytics extension is included with Azure DevOps and does not depend on third-party tools, it satisfies the licensing and maintenance constraints. Power BI can meet the metric requirements but adds an external service and licensing overhead. Exporting to Excel or using a basic query-based chart requires manual refresh and lacks true cycle-time calculations, making them unsuitable for an automated management dashboard.

Azure Artifacts provides hosted feeds that support npm and NuGet. An upstream source can be configured for npmjs.com and nuget.org; the first restore caches the external package inside the feed so future restores succeed even if the public registry is unavailable. Feeds offer granular security where permissions can be set per package or per view. GitHub Packages can host packages but cannot proxy and cache upstream registries, Azure Container Registry is focused on container images, and deploying an on-premises proxy contradicts the requirement to avoid extra infrastructure.

Approvals that are defined as a check on an Azure DevOps environment are evaluated every time any pipeline job targets that environment. By adding a check of type "Approvals and checks" to the Prod environment and specifying the release-admins group and a minimum of two approvers, you ensure that the pause occurs before any deployment to Prod. Because the environment resource is shared, the same approval policy applies automatically to every YAML pipeline that references that environment without needing additional code. A ManualValidation task (or custom YAML fields) would embed the approval in a single pipeline, while branch policies or pool settings are unrelated to environment-level deployment approvals.

Scalar wraps several Git performance features (commit-graph, multi-pack-index, incremental repack, and prefetch) and can run them automatically through the Windows Task Scheduler or cron. Running "scalar register" inside an already-cloned repository adds the repo to Scalar's maintenance list and installs the scheduled background tasks that keep repository metadata up-to-date. The other options either disable automatic maintenance, require a fresh clone, or modify unrelated configuration and therefore will not continually optimize existing clones.

Cycle time measures the duration from when work begins on an item (e.g., when its state changes to 'Active') until it is completed. To calculate this metric for historical trends, a data source that records daily snapshots of work item states is required. The Azure DevOps Analytics 'Work Item Snapshot' view (and the corresponding WorkItemSnapshot entity in the OData feed) is designed for this purpose. It stores a daily snapshot of every work item, which allows Power BI to calculate the time spent between specific state transitions and aggregate these values over time. This entity supports the required grouping by Area Path and filtering by Work Item Type.

The 'Current Work Items' view only exposes the latest revision of each work item, so it lacks the historical data needed for trend calculations. The 'Work Item History' view tracks every single field change, making it overly granular and inefficient for calculating aggregate metrics like average cycle time; it is better suited for detailed auditing. The 'Legacy FlowFields' view is part of the deprecated Data Warehouse and is not available for Azure DevOps Services (cloud).

Running "git lfs migrate import" rewrites every reachable commit, replacing the large *.mp4 blobs with lightweight LFS pointer objects while preserving commit metadata. Using the --everything switch ensures all branches and tags are rewritten at once. After the force-push, the server no longer stores the binary blobs, so repository size drops dramatically. Because history is rewritten, every contributor must reclone or at least reset local references; a fresh clone is the simplest, least error-prone step.
Adding patterns to .gitattributes and simply running git gc cannot remove blobs that are already part of history. Creating a brand-new repository discards commit history, violating the requirement to keep it. Scalar improves performance for large repositories but does not migrate blobs into LFS or shrink repository size.

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.

The Visual Studio Test task (VisualStudioTest@2) can discover and run any test assemblies that use adapters supported by Visual Studio, including MSTest, NUnit, and xUnit tests compiled for .NET Framework, .NET Core, or native code. The task automatically publishes the results to Azure DevOps, so no additional PublishTestResults task is required.

DotNetCoreCLI@2 runs only .NET Core tests and does not handle native C++ tests.
CTask@1 (CTest) is limited to CMake/CTest native projects and cannot run managed-code tests.
PublishTestResults@2 merely uploads result files that have already been produced; it does not execute tests or discover assemblies, so it cannot satisfy the requirement by itself.

GitHub Flow prescribes creating a short-lived branch from 'main' for every piece of work, pushing commits to that branch, and opening a pull request. The pull request triggers CI, enforces at least one approving review, and, after all checks pass, is merged back into 'main'. Using the squash and merge method keeps a linear history, and an automated pipeline can deploy 'main' on every successful merge. Having long-lived environment branches, promoting changes between multiple stable branches, or committing directly to 'main' violate GitHub Flow because they either lengthen branch life, bypass reviews/tests, or fragment the single source of truth.

To stop direct pushes to a branch, the Contribute permission for that branch must be denied. Denying Contribute prevents users from pushing commits or merging directly. Developers still need Read to fetch the branch and Contribute to pull requests to submit pull-requests that target the branch. Setting Contribute to pull requests to Allow (or leaving it Inherited when it is Allow) lets them create PRs even though Contribute is denied. Denying Create branch would block them from creating feature branches, and denying Read would block all access. Simply relying on branch policies without changing permissions would still allow a user who has Contribute to bypass the policy by pushing directly from the command line. Therefore, the correct configuration is: Read = Allow (or Inherited), Contribute = Deny, Contribute to pull requests = Allow.

Installing the Azure Boards app for the GitHub organization establishes an OAuth-based connection between the Azure DevOps project and the GitHub repositories. After the app is configured, including the pattern AB# in a commit message or pull request description automatically creates links that are visible in both Azure Boards and GitHub. This provides end-to-end traceability without additional manual steps. Simply pasting URLs into pull requests, configuring generic webhooks, or adding a build-time Associate-Work-Items task either fails to create bidirectional links or requires ongoing manual work, so none of those alternatives satisfy the requirements.

Creating two dependent stages guarantees the ordering constraint: the schema is migrated before any new pods become eligible to receive traffic. By using the built-in canary deployment strategy of the Kubernetes manifest task, the pipeline automatically handles incremental traffic shifts (e.g., 10%, 30%, 100%) and provides checkpoints for manual approval or automatic health evaluation, allowing a safe roll-back if issues occur. The other options either cannot guarantee that the migration runs first, do not provide true canary traffic shifting, or risk running the migration multiple times.

The most secure way for Azure Pipelines to interact with a GitHub repository is through the official Azure Pipelines GitHub App. Installing the app at the organization or repository level creates an OAuth-based trust that allows Azure Pipelines to fetch sources, create webhooks automatically, and publish status checks and commit statuses without storing a PAT inside Azure DevOps. A PAT (even if scoped to repo:status) would violate the stated policy, while webhooks alone cannot authenticate Azure Pipelines to post status checks. Enabling Dependabot is unrelated to build status integration, so the only action that meets both requirements is installing the Azure Pipelines GitHub App and granting it access to the repository.

The BuildTestResultDailySummary entity is already aggregated by pipeline run date, branch, and outcome counts. It also exposes the IsRerun flag, which allows you to filter out rerun attempts directly in the OData query. Because the data is pre-grouped, you only need to apply a date window and branch filter in Power BI to calculate the rolling average pass rate. Other entities either provide only detailed per-test records (requiring heavy aggregation) or lack branch and rerun information, which would force additional joins or calculations.

The query must calculate the difference between the resolution and creation timestamps, skip rows that do not yet have a ResolvedTime_t value, and average the resulting timespans over the last 30 days. Extending with a TTR column makes the calculation explicit, and summarize avg(TTR) returns a single timespan representing MTTR. Options that do not filter NULL resolution dates risk dividing by zero or skewing results, and queries that subtract in the wrong order produce negative durations.

Git Large File Storage (LFS) stores the binary content outside the normal Git object database and leaves a small pointer in the repository, so clone and fetch operations transfer only the pointer unless the actual file is requested. The command git lfs migrate import rewrites existing commits, replacing matching file patterns with LFS pointers so that the original large blobs are removed from history. After the migration, pushes succeed because no individual Git object exceeds the Azure Repos 100 MB limit, and future commits of those file types are automatically handled by LFS. Sparse checkout and repository splitting leave the large objects in the history that is pushed, so the size limitation still applies. Azure Repos does not provide server-side support for git-fat, and simply initializing git-fat on clients would not prevent large objects from being rejected.

The SecurityRecommendation table contains one record when Defender for Cloud first detects a vulnerability (Status == "Active") and another when the issue is fixed (Status == "Resolved").

The correct query:

• Filters on critical severity (RecommendationSeverity == "High") and the Container Registry recommendation type.
• Creates pairs of Active/Resolved records for the same recommendation by using arg_min() to get the first detection and arg_max() to get the time it was resolved.
• Calculates the positive time difference in hours using datetime_diff(), then averages it with avg() to obtain MTTR.

The distractors are incorrect because they:

• Use the wrong table (SecurityAlert), which tracks threats instead of vulnerability recommendations.
• Calculate the time difference with the datetime_diff arguments in the wrong order, which would produce negative values.
• Attempt to calculate a time difference on a single record without first pairing the "Active" and "Resolved" records, which is logically incorrect and references a non-existent column.