Microsoft DevOps Engineer Expert Practice Test (AZ-400)

Trunk-based development keeps one authoritative branch that contains the template code for every environment, ensuring all environments are created from the same files. A multi-stage YAML pipeline triggered by a pull-request validation build enforces automated linting and syntax checks before the code is merged. After the PR is approved and the main branch is updated, the same pipeline automatically proceeds to the dev, test, and prod deployment stages in sequence, each guarded by branch protection, environment checks, and approvals. The other options either duplicate templates across multiple long-lived branches or repositories-violating requirement 1-or deploy automatically on every push without the PR gate required in requirement 3.

The correct approach involves a two-job workflow. The analyze job must be configured to run only after the build job completes successfully; this is accomplished by adding a needs: build property to the analyze job. To run all of the job's steps inside the desired container, the container property is specified at the analyze job level, referencing the image that the build job pushed to the registry. This ensures the entire analysis, including the CodeQL init, build, and analyze steps, runs in the hardened container environment. The other options propose using non-existent parameters like build-mode or run-in-container, or incorrectly scope the container to a single step, which would not satisfy the security requirement for the entire analysis process.

A log alert rule in Azure Monitor can run a Kusto query against the Log Analytics workspace and evaluate it on a fixed schedule. When the threshold condition is met, the alert fires and invokes the actions defined in an attached action group. By choosing Logic App as the action type, you can call a Logic App workflow that uses the built-in Azure DevOps connector to create a work item (for example, a bug) and include any details returned by the query. Continuous export cannot write directly to Azure DevOps, Azure DevOps service hooks deliver events from Azure DevOps to external systems rather than the reverse, and Smart Detection rules in Application Insights only send notifications such as e-mail-they do not automatically open work items.

In Azure Pipelines, jobs within the same stage run in parallel by default unless an explicit dependency is declared with dependsOn. Adding dependsOn: [UnitTests, ApiTests] to the PublishArtifacts job correctly configures the pipeline to wait for both UnitTests and ApiTests to complete successfully before starting. Since the two test jobs have no dependencies on each other, they will execute concurrently. Using only a condition statement does not establish an execution order; the job would still attempt to run in parallel with the others. The strategy: parallel property is set on a job, not a stage, and is used to run multiple instances of that single job, not to coordinate different jobs. Moving PublishArtifacts to a separate stage would work but is explicitly forbidden by the question's constraints.

Approvals and checks such as group-based manual approval and Azure Monitor alert gates are properties of the environment itself. They are configured once on the Production environment (through the Azure DevOps portal or by using the REST API). Any YAML pipeline that references that environment automatically inherits those checks. YAML does not include syntax to declare or override environment approvals or gates inside a pipeline file, so attempting to add approvals: or similar keys to the YAML will be ignored or cause an error. Organization-level policies and variable group permissions do not provide deployment gating for an environment.

A template can expose a string parameter that the consuming pipeline sets to the name of its preferred variable group. Inside the template you reference that parameter in the variables section by using compile-time expression syntax. When the caller provides a different value for that parameter, the variable-group reference is replaced at template expansion, allowing the same template to work with any variable group. Referencing the variable group through a runtime variable such as $(varGroup) or environment variables will not work because the group name must be resolved before the pipeline is run. Task group parameters and predefined system variables cannot be used to inject an arbitrary variable-group name.

The git lfs migrate import command rewrites the repository's history, replacing the specified paths with LFS pointer files and adding the binary content to the LFS store. It preserves commit hashes except for those whose blobs are rewritten and automatically updates tags and branch tips. After the rewrite, a force-with-lease push is required to replace the server-side history. Merely tracking patterns with git lfs track affects only future commits, while git filter-branch requires complex scripting and is discouraged for large histories. Azure Repos has no server option named "Large File Checkout," so enabling such a setting would not migrate existing blobs.

To export web-api-cert with its private key, the pipeline needs Secret - Get permission because Key Vault stores the PFX payload of a certificate as a secret. Fetching the certificate object alone would return only public metadata, not the private key.

To create the JWT without exposing the private key, the pipeline must invoke the Sign operation against the jwt-signing key. That requires Key - Sign permission. No other key operations (for example, Decrypt or Get) are necessary because the pipeline does not need to read or decrypt the key material.

Therefore, the minimal permission set is:

• Secrets: Get
• Keys: Sign

All other answer choices either omit a required permission or grant unnecessary operations that violate the least-privilege principle.

The permission that overrides branch policies during the PR completion process is "Bypass policies when completing pull requests." Granting this permission to release managers lets them complete a PR without satisfying reviewer or build requirements. Setting the same permission to Deny (or leaving it Not set) for all other groups ensures that nobody else can circumvent the branch policies. "Bypass policies when pushing" applies only to direct pushes, not PR completions. "Force push (rewrite history)" allows history rewrites but does not affect policy checks. "Contribute to pull requests" lets users comment or vote but does not override policies.

Trunk-based development encourages very short-lived branches that are merged back into the main (trunk) branch at least daily, which keeps the integration surface small and prevents the accumulation of merge debt. Pull-request policies can still be applied so that developers can work in isolation for a few hours, submit a PR, and integrate quickly. Extending the lifetime of feature branches or adding permanent develop and release branches does the opposite-it increases divergence and makes later merges riskier. Requiring personal forks without PR validation makes integration even less frequent and would undermine continuous delivery.

Azure Automanage Machine Configuration (based on the Guest Configuration agent) assigns a guest configuration policy that can both audit and remediate settings such as installed packages. The agent reevaluates approximately every 15 minutes, and compliance results are surfaced through Azure Policy for reporting and governance. Configuration code is written declaratively (DSC-style) and can be stored in source control such as GitHub. Azure Automation State Configuration provides DSC but has no direct Azure Policy integration. Azure App Configuration Feature Manager handles feature flags, not VM configuration. Azure Image Builder creates custom images and does not enforce ongoing configuration.

The correct approach is to connect Power BI directly to the Azure DevOps Analytics OData feed. The PipelineRuns entity set within the Analytics data model contains authoritative data for each execution of a YAML pipeline, including the outcome, environment details, completion date, and pipeline name. This allows for the creation of a report on successful production deployments per day with filtering capabilities, fulfilling the requirements with minimal custom work.

Creating an Analytics View is incorrect because this feature is limited to Azure Boards work item data and does not support pipeline data. Using Azure Boards work items with a specific tag is not an authoritative source for deployment outcomes and relies on manual process adherence. Enabling continuous export from Application Insights would require custom instrumentation in every pipeline to send deployment events, which violates the 'minimal custom coding' requirement.

A project- or pipeline-wide retention period would keep every run for five years, dramatically increasing storage consumption. Azure Artifacts retention policies cover only packages and do not preserve the entire pipeline run's logs or test results. Instead, the production stage can include a lightweight script or task that calls the Azure DevOps REST API to set the keepForever property to true for the current run. This action creates a retention lease that overrides normal cleanup policies, keeping the specific run and all of its artifacts indefinitely, while other runs continue to be deleted after 30 days.

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.

Setting the Git repositories security at the project level controls the default permissions that every repository inherits. By granting Allow on the Manage permissions right to the Release Managers group and setting Deny (or leaving Not set) for other groups such as Project Contributors, only Release Managers can edit repository or branch permissions. Because the setting is applied at the project scope, every current and newly created repository inherits the rule without further action. Branch policies or per-repository administrator assignments would have to be recreated for each repo, and Azure AD role assignments do not control granular Git permissions inside Azure DevOps.

Enabling VM Insights from the portal (or ARM/CLI) for the scale set is the quickest, lowest-effort method that also follows Microsoft's agent roadmap. The onboarding wizard automatically installs and configures the Azure Monitor agent (AMA) and the Dependency agent, then links them to the selected Log Analytics workspace. Installing only the Azure Diagnostics extension collects some metrics but cannot build dependency maps. Creating a Data Collection Rule plus manual Dependency agent installation meets the requirements but adds unnecessary administrative steps. Deploying the legacy Log Analytics (MMA) agent and Service Map solution is no longer recommended and conflicts with Microsoft's transition to AMA.

Enabling Container Insights from the Azure portal (Insights blade) pushes Microsoft-signed monitoring components to the cluster as a DaemonSet and automatically connects them to the selected Log Analytics workspace. This collects performance counters, container logs, and Kubernetes events that drive the Container Insights workbooks. Injecting the Application Insights SDK gathers only application telemetry, not node or container metrics. VM Insights targets traditional virtual machines and does not ingest Kubernetes events or container logs. Manually deploying the Helm chart also works, but it requires additional steps and script maintenance, making it slower and more error-prone than the portal-based enablement.

The query must filter the customMetrics table to the CheckoutTime metric for the required time range, then calculate the 95th percentile of the value column and group the result into one-day time buckets. The percentile() aggregation is the correct KQL function; pctile() is not valid syntax. Aggregating by one-hour bins or omitting the initial filter would not satisfy the reporting requirements, and averaging values would not produce a percentile-based metric.

A branch policy can enforce both reviewer and discussion-resolution requirements. Setting Minimum number of reviewers to 2 and adding the Security group as a required reviewer guarantees that at least two Security members approve every pull request. Enabling Require discussion resolution blocks completion while any active thread exists. Leaving Reset code reviewer votes when there are new changes cleared ensures that additional non-functional pushes (for example, typo fixes) do not throw away approvals already granted, so maintainers are not forced to restart the review cycle. Selecting the reset option would cancel approvals on every push, while lowering the reviewer count, making reviewers optional, or locking the branch without policies would all fail to meet one or more requirements.

The Azure DevOps Analytics Code Churn view (also referred to in OData as the CodeChurn table) records one row per file changed in each commit and exposes the LinesAdded and LinesDeleted measures. By aggregating these two measures over a time range you get total churn (lines added plus lines deleted) per repository. Work Item, Build, and Pull Request tables do not contain line-level code delta information, so they cannot provide churn metrics directly.