Microsoft DevOps Engineer Expert Practice Test (AZ-400)

Using the AzureKeyVault@2 task downloads the required secrets during the job directly from Azure Key Vault. The secrets are exposed to the pipeline only as in-memory secret variables, which are automatically masked in logs and are not saved to artifacts. Because the values remain in Key Vault and are never stored in Azure DevOps, project or build administrators cannot later view them in the portal. Manually created secret variables (whether in a variable group or in YAML) are stored and can be viewed by anyone with edit privileges, and encrypted files checked into Git still expose the decryption key to the pipeline. Therefore, retrieving secrets just-in-time from Key Vault with AzureKeyVault@2 is the only option that satisfies every stated constraint.

GitHub Flow is a lightweight workflow designed for continuous delivery. Its core practice involves creating short-lived feature branches from the main branch, which must always be in a deployable state. All changes are integrated via pull requests, which require peer review (approvals) and successful automated checks (CI builds) before being merged. This process ensures traceability and quality. Committing directly to main, using long-lived branches like develop or release (as in GitFlow), or bypassing pull requests are all inconsistent with the GitHub Flow model.

The Requirement traceability report relies on the dedicated "Tests" link type. When you add a link of this type between a requirement-level work item (such as a User Story or Bug) and one or more test cases, Azure DevOps automatically:

• Lists the relationship in the Boards and Test Plans UIs.
• Rolls up the latest automated or manual test outcome for every linked test case.

Because tags, iteration paths, or text in titles do not create formal links, they are ignored by the traceability views and queries.

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.

The query must:

• Retrieve request telemetry from the last day (requests table, timestamp filter).
• Use the percentile aggregation to compute the 95th-percentile duration for each operationName.
• Filter out any operation whose P95 is not above 3 000 ms.
• Return only the five operations with the highest P95 values.

The correct query meets every criterion: requests | where timestamp > ago(1d) | summarize P95 = percentile(duration, 95) by operationName | where P95 > 3000 | top 5 by P95 desc

The distractors fail because they either:

• Compare the raw duration column instead of the percentile result (making the filter ineffective).
• Use average rather than percentile, giving the wrong measure of tail latency.
• Keep operations below 3 000 ms or sort ascending, returning the fastest operations instead of the slowest.

Workload Identity Federation lets Azure DevOps request a short-lived Azure AD access token for a specific app registration by presenting the pipeline's OpenID Connect (OIDC) token. No client secret or certificate is stored in Azure DevOps, and the service principal created for the registration can be assigned granular roles (for example, at a single resource-group scope). Microsoft-hosted agents cannot use managed identity, a stored publish profile exposes long-lived secrets, and a classic service principal with a client secret still requires secret storage and rotation.

VM Insights collects performance counters through the Azure Monitor agent. To build dependency and process maps on Windows machines, the solution also relies on the Dependency agent. When you enable VM Insights with AMA, Azure automatically installs (or expects) both the Azure Monitor agent and the Dependency agent on Windows hosts. The Log Analytics (MMA) and Telegraf agents are not used in this architecture, and AMA alone does not generate dependency data on Windows.

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.

Trunk-based development keeps everyone merging into a single mainline at least daily, allowing CI pipelines to detect integration problems quickly. Short-lived feature branches let teams isolate work but are merged back to main as soon as the build is green, keeping divergence small. When a product increment ships, a release branch is cut from the mainline; hot-fixes are applied to that release branch and cherry-picked into main so new development can continue unhindered. Gitflow encourages long-lived develop and feature branches, delaying integration. Environment branches or permanent release branches cause parallel work streams that contradict the daily-merge CI goal. Fork-based workflows target open-source contributions rather than coordinated internal teams.

The MicrosoftSecurityDevOps@1 task, provided by the Microsoft Security DevOps extension, orchestrates multiple analyzers (for example CredScan, ESLint, Bandit, PoliCheck, IaC scanners, and dependency-vulnerability tools) in a single step, emits standardized SARIF output, and allows you to set a fail-threshold for high-severity issues. CodeQLAnalysis@0 only performs static code analysis, while Dependency Check and Trivy each cover a single scope (dependency or container scanning). None of those alternatives meet the requirement to run comprehensive, multi-tool scanning through one task.

Enabling VM Insights (Azure Monitor for VMs) at the subscription, resource group, or workspace level automatically deploys the Azure Monitor Agent (or Log Analytics VM extension on older images) to every selected VM, configures a data collection rule, and begins sending guest-level performance counters such as CPU, memory, and logical disk metrics to the chosen Log Analytics workspace. The built-in Insights workbook then surfaces this data across all onboarded machines.

Installing the Diagnostics extension only streams basic platform metrics and requires per-VM configuration. Container Insights is intended for Kubernetes nodes or Azure Container Instances, not standard VMs. A guest-configuration policy audit does not collect performance data or populate the Insights workbook. Therefore, enabling VM Insights is the correct first step.

Configuring a quality gate on the environment targeted by the 'Deploy' stage is the correct approach. The 'Tests pass ratio' check can be added as a gate, which evaluates the results from the preceding 'Build' stage. Setting its threshold to 95 ensures that the 'Deploy' stage will only start if 95% or more of the tests passed. This method uses built-in functionality to control promotions between stages based on quality metrics.

Adding failTaskOnFailedTests: true to a PublishTestResults@2 task would fail the pipeline if any single test fails, which does not meet the 95% threshold requirement. The minimumTestsPassedPercentage parameter for the VsTest@2 task does not exist. Using a condition on the stage checks the status of the previous stage, but it does not evaluate the test pass percentage; the 'Build' stage would still succeed if tests ran but the pass rate was below 95% (assuming the test task itself did not fail).

The built-in PublishCodeCoverageResults task is used to publish reports, but it does not have an input to enforce a coverage threshold and fail the build. The correct approach, given the 'Build Quality Checks' extension is installed, is to use its provided task. The BuildQualityChecks task is specifically designed to act as a quality gate, allowing you to check metrics like code coverage and fail the build if a defined threshold is not met. Using a custom PowerShell script would require more effort than using the pre-built extension. A branch policy applies to pull request validation (typically for differential coverage), not the overall coverage of a main pipeline build.

The query must first filter the Requests table to the last 30 minutes and exclude rows where the duration value is missing. The summarize operator then calculates an aggregate - in this case the average - grouped by operation_Name, with Kusto automatically naming the new column avg_duration (or the name given in the assignment). Finally, sort (or order by) must be applied in descending order so that the largest average duration is shown first. Options that use isempty instead of isnotempty, use extend for aggregation, or sort ascending do not meet one or more of the stated requirements.

GitHub Actions natively supports OIDC federation to both Azure and AWS, allowing workflows to exchange a GitHub-issued token for short-lived cloud credentials at runtime without storing any secrets. This directly satisfies the FedRAMP requirement. Furthermore, the YAML workflow file resides in the same repository as the code, meeting another key requirement.

The distractors suggesting the use of long-lived access keys stored in repository secrets or traditional service connections explicitly violate the security policy. While modern Azure Pipelines also support OIDC via Workload Identity Federation for both Azure and AWS, choosing this option for a repository already in GitHub would require setting up a separate Azure DevOps project and service connections, introducing more components than the native GitHub Actions solution. Therefore, GitHub Actions is the solution that meets all requirements with the least additional components.

Trunk-based development keeps all developers working in or very close to the main branch. Short-lived feature branches (often measured in hours or a few days) are merged back quickly through pull requests, which greatly reduces long-running divergence and merge conflicts. When a feature is not ready, it is typically hidden behind a feature flag, so deployments can continue on the same main line without blocking release frequency.

GitFlow relies on long-lived develop and release branches that introduce greater divergence and are not optimized for multiple weekly releases. Release Flow does support continuous delivery, but it uses short-lived release branches that are removed once a release is complete-maintaining them indefinitely would conflict with the stated goal of minimizing branch history. A forking workflow isolates every developer in a personal fork; while appropriate for large open-source projects, it adds extra overhead and does not inherently address the need for rapid, low-conflict integration. Therefore, adopting trunk-based development with short-lived feature branches and feature flags is the best fit.

While Azure Pipelines YAML files support several retention settings, they do not provide a way to set a separate, shorter retention period for artifacts compared to the build record itself. The days and minimumToKeep settings in the YAML retention block control the retention of the entire run record. To delete artifacts on a different schedule than the run, you must configure the 'Days to keep artifacts' setting in the pipeline's specific settings through the web UI. The other requirements, such as setting the number of days to keep the run, the minimum number of runs to keep, and scoping the policy to a specific branch, are all configurable within the YAML file.

The deploy stage must evaluate two facts before it runs: the overall pipeline has succeeded so far and the current run's branch is main. The predefined variable Build.SourceBranch contains the fully qualified branch name (for example, "refs/heads/main"). Therefore the correct expression combines succeeded() with an equality check on Build.SourceBranch by using the and() expression helper. Using Build.SourceBranchName would omit the refs/heads/ prefix, && operators are not valid YAML expressions, always() would ignore failures, and comparing Build.Reason does not restrict the branch that triggered the run.

Workload identity federation lets an Azure AD application (service principal) trust the JSON Web Token (JWT) issued to each Azure DevOps job. Because the token exchange is based on OpenID Connect, no client secret or certificate is stored in Azure DevOps. The service principal created for the subscription can be restricted to the required resource groups. Managed identities cannot be used by Microsoft-hosted agents, and storing a client secret or personal access token keeps a long-lived secret that contradicts the requirement to remove stored credentials.

The GitHub Issues Marketplace task lets you create or update issues in a repository directly from an Azure Pipeline without writing custom REST calls. By using the task, you can supply the previously stored PAT, set the action to Create, assign the issue to $(Build.RequestedForEmail) (the last pusher), and apply any required labels. When the task runs after a failed job, GitHub automatically sends its normal e-mail and web notifications to everyone watching the repository, fulfilling the notification requirement.

Using a Bash script or an Azure CLI task would work but would involve hand-crafting REST requests, increasing maintenance. A Service Hook in GitHub cannot be triggered from Azure Pipelines; service hooks send events out of GitHub, not into it. A branch protection rule only blocks merges and does not generate issues or notifications, so it does not meet the stated goals.