Free Microsoft Certified: DevOps Engineer Expert (AZ-400) Sample Questions

Correct answer: B — Lead Time for Changes

• A. Incorrect. Mean Time to Restore (MTTR) measures the average time to recover from a production failure, not the time from commit to deployment.
• B. Correct. Lead Time for Changes is one of the four key DORA metrics and specifically measures the amount of time it takes for a code change to go from committed or approved to being successfully deployed in production.
• C. Incorrect. Change Failure Rate measures the percentage of deployments that cause a failure in production, reflecting release stability, not speed.
• D. Incorrect. Deployment Frequency measures how often code is deployed to production, indicating agility, but does not measure elapsed time from commit to deployment.

Correct answer: B — Cycle Time

• A. Incorrect. Lead Time for Changes measures the time from code commit to running in production, which includes waiting time before work begins. It does not track only the active work duration.
• B. Correct. Cycle Time measures the time from when work starts on an item (e.g., first commit) until it is deployed, capturing the active development duration.
• C. Incorrect. Deployment Frequency measures how often deployments occur, not the duration of a single work item.
• D. Incorrect. Time to Recover measures how quickly service is restored after an incident, unrelated to work item completion time.

Correct answer: B — DocFX and an Azure DevOps wiki extension

• A. Swagger Inspector is used for testing and exploring APIs, not for generating documentation from code comments. A PowerShell script could automate tasks but does not address the need to extract documentation from source comments, and it lacks seamless integration with Azure DevOps wiki publishing.
• B. DocFX is a documentation generator that can extract API documentation from code comments and source code. An Azure DevOps extension for wiki publishing can then publish the generated documentation to an Azure DevOps wiki as part of the CI/CD pipeline, meeting the requirement.
• C. Postman is primarily for API testing and creating collections, not for generating documentation from code comments. A custom build task could automate steps, but the combination does not directly fulfill the requirement of generating docs from source comments and publishing to a wiki.
• D. Azure API Management is designed for managing and exposing APIs, not for generating documentation from code comments. A release gate controls deployment approvals, not documentation generation or publishing, making this combination unsuitable.

Correct answer: A — Create a new service hook subscription and paste the webhook URL.

• A. Correct. After creating an incoming webhook in Teams, you must create a service hook subscription in Azure DevOps and configure it to use the webhook URL as the target. Service hooks are the built-in mechanism to send event notifications (such as release deployments) to external services like Microsoft Teams.
• B. Incorrect. Installing the Azure Boards app in Teams integrates work item tracking into Teams but does not configure release deployment notifications via a webhook. The webhook integration requires a service hook subscription, not the Azure Boards app.
• C. Incorrect. Project notifications in Azure DevOps send alerts via email to users or groups, not to a Teams channel via a webhook. To send messages to a Teams channel, you must use a service hook subscription targeting the webhook URL.
• D. Incorrect. While it is technically possible to call the Teams REST API from a pipeline, this is not the standard or intended method for release deployment notifications. The correct approach is to use Azure DevOps service hooks, which are designed for this purpose and require minimal configuration.

Correct answer: B — Add the file path and the expert's username to the CODEOWNERS file

• A. Branch protection rules can require reviews before merging, but they do not automatically assign specific reviewers based on file changes. They enforce general review requirements, not file-specific assignments.
• B. The CODEOWNERS file allows you to define file paths and associate them with GitHub usernames or teams. When a pull request modifies those files, GitHub automatically requests a review from the specified owners. This is the standard built-in mechanism for routing reviews based on file changes.
• C. A GitHub Action could comment on the pull request to notify the expert, but it does not automatically request a formal review. The expert would still need to manually navigate to the PR and submit a review. This is a custom automation rather than GitHub's native review assignment system.
• D. A webhook can trigger external notifications (e.g., email) when files change, but it does not integrate with GitHub's review request system. It would require additional custom logic to request a review and does not provide the native automatic review assignment that CODEOWNERS offers.

Correct answer: A — Link bug to test case via 'Tested by' and enforce commit linking in branch policies

• A. Correct. This establishes a direct relationship between the bug and the test case using the 'Tested by' link, and enforces that every commit references a work item (e.g., the bug) via branch policies. This creates the full chain from bug work item to code commit to test case.
• B. Incorrect. Query-based test suites organize test cases but do not link them to bugs. Pre-commit hooks are not the standard Azure DevOps mechanism for enforcing work item traceability, and this option lacks explicit bug-to-test-case linking.
• C. Incorrect. Combining bug and test case work item types is not a standard or recommended practice in Azure DevOps. Pull request validation enforces quality checks but does not create explicit traceability links between bugs, commits, and test cases.
• D. Incorrect. A build pipeline can run tests and link outcomes to commits, but this does not provide traceability from the bug work item to the test case or commit. It only links test results to builds, not the required end-to-end chain.

Correct answer: A — Create a hotfix branch from the release, apply the fix, and merge back to release and main.

• A. Correct. In GitFlow, urgent fixes on a release branch should be done via a hotfix branch created from the release branch. This isolates the fix, allows testing, and the hotfix is then merged back to both the release branch (to include in the release) and main (to keep main current). This ensures consistency and traceability.
• B. Incorrect. Committing directly to the release branch bypasses the isolation provided by a hotfix branch and risks destabilizing the release. Creating a new release branch from an unstable state is not recommended in GitFlow.
• C. Incorrect. Cherry-picking the fix only to main after the release is finalized delays the fix in main and does not address the defect in the active release branch. It also risks inconsistencies if other branches depend on the fix sooner.
• D. Incorrect. Reverting the defective commit removes the change but does not provide a fix; the question requires applying a fix. Moreover, immediately merging the revert to main may introduce instability if not properly tested, and it does not establish a corrected version across both branches cleanly.

Correct answer: B — rebase and fast-forward

• A. Incorrect. A merge with no fast-forward creates a merge commit that preserves the separate branch lineage, but it does not result in a linear history. It is useful when you want to keep the feature branch's history visible, but it introduces a merge commit.
• B. Correct. Rebase and fast-forward first replays the commits from the feature branch onto the tip of the target branch, then fast-forwards the branch pointer. This results in a linear commit history without any merge commits, which is ideal for maintaining a clean project history.
• C. Incorrect. A squash merge combines all commits from the feature branch into a single commit. This loses the individual commit history and does not preserve the original sequence of changes, unlike rebasing and fast-forwarding.

Correct answer: B — Execute `scalar register` inside the repository to enable background maintenance and sparse checkout.

• A. Incorrect. `scalar clone` creates a new optimized clone, but does not apply optimizations to an existing repository. Replacing the repository is not the efficient approach for an existing clone.
• B. Correct. Running `scalar register` inside the repository enables Scalar's background maintenance and sparse checkout features, optimizing performance for existing clones without requiring a full re-clone.
• C. Incorrect. There is no `git scalar init` command. Scalar is a separate tool; its optimizations are applied via `scalar register` or `scalar clone`, not through a Git subcommand.
• D. Incorrect. Manually editing `.git/config` is not the required or recommended method. Scalar provides supported commands to register and configure repositories; manual configuration is incomplete and error-prone.

Correct answer: B — partial (--filter=blob:none)

• A. Incorrect. A shallow clone (--depth 1) fetches only the most recent commit history but still downloads all file contents, including large binary objects. It does not defer blob retrieval until checkout.
• B. Correct. A partial clone with --filter=blob:none fetches the repository without downloading any blob objects (such as large binaries) until they are explicitly checked out or accessed. This is ideal for CI pipelines that initially need only the current source code while deferring large assets.
• C. Incorrect. A bare clone (--bare) creates a repository without a working directory, typically used for server-side hosting. It does not address the need to avoid downloading large binary objects and is not suitable for a CI pipeline that requires a working tree.

Correct answer: B — Enable test impact analysis to run only tests affected by the changed code

• A. Path filters in CI triggers help decide whether a pipeline runs based on changed paths, but they do not automatically select which unit tests to execute inside the build. They are useful for skipping entire pipelines or stages, not for granular, test-level selection across many services.
• B. Test impact analysis dynamically determines which tests are affected by code changes and runs only those tests. This is a built-in feature in Azure DevOps that scales efficiently for large repositories and directly minimizes build time.
• C. A script that inspects git diff can work, but it is a custom solution that adds maintenance overhead and can become brittle as the repository grows. It duplicates functionality that test impact analysis provides more reliably.
• D. Manually setting a pipeline variable at queue time does not scale well, as it requires human intervention for each build and does not automate test selection based on code changes, contradicting the goal of minimizing build time in CI.

Correct answer: A — Cobertura

• A. Cobertura is a widely supported code coverage format in Azure DevOps. The PublishCodeCoverageResults task can parse Cobertura XML files and display the results in the code coverage tab.
• B. CSV is not a supported format for the PublishCodeCoverageResults task. Azure DevOps expects a machine-readable coverage report format, not a flat data export like CSV.
• C. XML by itself is too generic and does not specify the coverage schema Azure DevOps needs. The task requires a supported format such as Cobertura or JaCoCo XML.
• D. HTML is typically used for human-readable coverage reports but cannot be parsed by the PublishCodeCoverageResults task. The task requires a machine-readable supported format.

Correct answer: C — automated test run

• A. Incorrect. While a build pipeline can publish code coverage, the status check is typically configured to require the result of the build/test run itself, not specifically the publishing step. The branch policy blocks the PR based on the validation outcome, which is broader than just publishing coverage.
• B. Incorrect. A release pipeline approval is a manual or automated gate for deployments, not for enforcing code coverage requirements in pull requests. Coverage enforcement depends on automated validation via test runs.
• C. Correct. An automated test run that includes a code coverage check (e.g., using a task like 'PublishCodeCoverageResults' with a threshold) can be configured as a status check on a branch policy to block pull requests if coverage is too low. This is the typical way to enforce code coverage.
• D. Incorrect. Manual review is a human process and cannot automatically enforce code coverage thresholds. Automated validation via an automated test run is required to block PRs based on low coverage.

Correct answer: B — Unit testing of resource properties in isolation

• A. Integration testing using actual Azure resource deployment is a higher-level test (e.g., end-to-end or integration testing), not a foundational testing level for IaC. It validates deployed resources work together, but it is broader than a unit-level test.
• B. Unit testing in IaC focuses on validating individual resource definitions, parameters, or properties in isolation. Scripting individual resource properties is a foundational testing level for IaC, verifying components before deploying real infrastructure.
• C. Static code analysis of template files checks template structure and quality without deploying resources. It is a code quality activity rather than a distinct testing level such as unit or integration testing.
• D. Linting with the Bicep CLI is a form of static validation that catches syntax and style issues. It is useful pre-deployment but not considered a testing level for validating IaC functionality.

Correct answer: A — Configure on-premises DSC nodes to pull configurations from Azure Automation over outbound HTTPS

• A. Correct. Azure Automation DSC supports pull mode, where on-premises nodes periodically pull configurations from an Azure Automation endpoint over outbound HTTPS. This is the recommended approach for secure and scalable DSC management, requiring no inbound firewall rules.
• B. Incorrect. Opening inbound port 5986 for WinRM is used for remote management, not for Azure Automation DSC pull communication. DSC pull mode uses outbound HTTPS (port 443) to communicate with Azure Automation, so inbound ports are unnecessary and less secure.
• C. Incorrect. Azure File Sync is used for synchronizing files between Windows Server and Azure Files, not for managing DSC configurations. It does not provide DSC pull functionality or relay DSC configurations to Azure Automation.
• D. Incorrect. A VPN gateway is not required for Azure Automation DSC because the nodes can communicate with Azure Automation over the public internet using outbound HTTPS. Exposing servers via VPN is not the intended or necessary configuration for DSC pull mode.

Correct answer: A — Using `bicep decompile` on an exported ARM template

• A. Correct. The `bicep decompile` command converts an exported ARM JSON template into a Bicep file, enabling quick migration from existing ARM templates to Bicep without manual rewriting.
• B. Incorrect. Manually copying properties from the portal is a manual authoring approach, not a Bicep feature. It does not leverage any built-in helper command and is error-prone.
• C. Incorrect. `az bicep restore` is a valid command used to restore external module dependencies for a Bicep file, not to generate or import infrastructure definitions from a resource group.
• D. Incorrect. Bicep does not support importing Terraform state files. Terraform state is part of Terraform's workflow and cannot be directly converted by a native Bicep command.

Correct answer: C — GitHub Actions workflows

• A. Azure Pipelines with YAML supports pipeline-as-code and self-hosted runners, but it does not natively integrate with GitHub as seamlessly as GitHub Actions, and it lacks a free tier specifically for open-source projects.
• B. Jenkins with GitHub plugin can integrate with GitHub and support self-hosted runners, but it does not natively offer a free tier for open-source projects and requires more manual setup and maintenance compared to GitHub Actions.
• C. GitHub Actions natively integrates with GitHub repositories, uses YAML for pipeline-as-code, provides a free tier for open-source projects, and supports self-hosted runners, making it the ideal choice for this scenario.
• D. Azure DevOps classic release pipelines are UI-based, not defined as code, and lack native GitHub integration and a free tier for open-source projects, so they do not meet the requirements.

Correct answer: A — eq(variables['RunTests'], 'true')

• A. Correct. The function `eq(variables['RunTests'], 'true')` is the proper syntax in Azure Pipelines YAML conditions. It compares the value of the variable `RunTests` to the string 'true' using the `eq` function, which is required because conditions use expression functions rather than operators like `==`.
• B. Incorrect. This expression uses the `==` operator, which is not supported in Azure Pipelines YAML conditions. The correct approach is to use the `eq` function. Additionally, using dot notation for variables is acceptable, but the comparison must be function-based.
• C. Incorrect. This expression combines `succeeded()` and `variables.RunTests` with `and()`, but `variables.RunTests` is not a valid condition—it must be a boolean expression. Moreover, `succeeded()` is unnecessary here, and the variable syntax is incomplete without a proper comparison.

Correct answer: A — slot swap

• A. Correct. A slot swap in Azure App Service swaps the staging (green) slot with the production (blue) slot, instantly redirecting traffic to the new version without changing the endpoint URL. This is the standard method for blue-green deployments in App Service.
• B. Incorrect. A DNS update changes where a domain name resolves, which can affect endpoints and require propagation time. It is not the App Service blue-green mechanism used to switch traffic between deployment slots; slot swaps avoid DNS propagation delays.
• C. Incorrect. A traffic manager profile swap is used for load balancing across regions or services, not for swapping deployment slots within a single App Service. This would alter traffic routing configuration rather than provide a direct production cutover without endpoint change.

Correct answer: C — resource

• A. Incorrect. A 'completion' trigger is not a valid trigger type in Azure Pipelines for this scenario. Completion triggers are not used to chain pipelines based on resource dependencies.
• B. Incorrect. A 'scheduled' trigger runs a pipeline at a specified time or interval, not based on the completion of another pipeline. This does not ensure dependency on an upstream pipeline.
• C. Correct. A 'resource' trigger in Azure Pipelines allows you to configure a pipeline to run when a resource (such as another pipeline) is updated or completes successfully. This is the correct way to chain pipelines. In Azure DevOps YAML, you configure a resource trigger on a pipeline resource to start the downstream pipeline when the upstream pipeline completes successfully.

Correct answer: C — Use 'Export to YAML', then convert task groups into YAML templates and reference existing variable groups.

• A. Incorrect. Rewriting each build step manually in YAML without using reusable templates or variable groups is inefficient, error-prone, and ignores Azure DevOps features that improve maintainability and consistency.
• B. Incorrect. Azure DevOps does not support exporting a classic pipeline to JSON as a standard workflow. This approach is unsupported, unnecessarily complex, and error-prone.
• C. Correct. Using the 'Export to YAML' feature provides a direct conversion path. Converting task groups into YAML templates and referencing existing variable groups follows best practices for reusability and maintainability.
• D. Incorrect. Running duplicate pipelines in parallel may help validate changes, but it is not the recommended method for converting a classic pipeline to YAML. It does not address proper reuse of templates or variable groups and can lead to inconsistencies.

Correct answer: C — Deploy agents in a VM Scale Set with autoscale rules that scale to zero when no jobs are queued.

• A. Incorrect. A local task on each agent VM is difficult to centrally manage and unreliable for Azure DevOps agent pools. It also risks shutting down a VM while a job is still running if idle detection is not precise enough, leading to job failures.
• B. Incorrect. A fixed schedule stops and starts all VMs regardless of actual build demand, which can cause missed jobs or delays if work arrives outside business hours. It does not optimize cost based on real agent utilization.
• C. Correct. Deploying agents in a Virtual Machine Scale Set with autoscale rules dynamically adjusts the number of agent VMs based on queue demand, including scaling down to zero when no jobs are pending. This is the most cost-effective and Azure-native approach for maintaining build agents.
• D. Incorrect. Manual intervention is operationally inefficient and prone to human error. It does not provide automated cost optimization or rapid scaling for changing build demand.

Correct answer: C — Convert to YAML

• A. Incorrect. 'Save as YAML' is not a valid action in Azure DevOps for converting a classic pipeline. The classic pipeline editor does not provide a direct save-to-YAML option.
• B. Incorrect. 'Export to YAML' is not the standard UI command for this conversion. While there is an option to view or download the YAML definition, the specific action to transform a classic pipeline into a YAML pipeline is called 'Convert to YAML'.
• C. Correct. 'Convert to YAML' is the documented action in Azure DevOps that generates a YAML-based pipeline from a classic pipeline. This option creates a new YAML pipeline file based on the existing classic pipeline configuration.

Correct answer: A — The partner feed was not added as an upstream source.

• A. Correct. If the partner feed was never added as an upstream source, packages from it will not be available in your feed. Azure Artifacts requires explicit configuration of each upstream source.
• B. Incorrect. Azure Artifacts supports multiple upstream sources, including both public and private feeds. Having more than one upstream source is a valid configuration.
• C. Incorrect. Package visibility is not determined by the use of Semantic Versioning. Azure Artifacts works with standard package versioning and the absence of packages is a configuration issue, not a versioning format issue.
• D. Incorrect. There is no need to manually add a package first. Upstream sources are discovered and cached automatically based on configuration and package requests.

Correct answers: B, C, E — Azure Artifacts AD permissions; GitHub Packages repository permissions; GitHub Packages multi-format support

• A. Incorrect. Public feeds are for sharing packages publicly, not for unified access control or auditing.
• B. Correct. Azure Artifacts AD permissions integrate with Azure Active Directory for centralized identity and access control, supporting consistent governance and auditing across Azure DevOps.
• C. Correct. GitHub Packages repository permissions allow granular access control at the repository level, aligning with organizational policies and enabling auditing of package access.
• D. Incorrect. Gated views are used for package promotion workflows and visibility control, not for access control or auditing.
• E. Correct. GitHub Packages multi-format support is necessary to host NuGet, npm, and Maven packages in a single location, complementing the access control features to provide a unified strategy across both platforms.
• F. Incorrect. Upstream sources are for caching and proxying external packages, not for access control or auditing.

Correct answer: B — Enable push protection in the secret scanning settings

• A. Branch protection rules enforce policies like required reviews or status checks but do not directly enable secret scanning. Secret scanning is configured separately via GitHub Advanced Security settings.
• B. Enabling push protection blocks secrets from being pushed to the repository, directly preventing leakage. This is a built-in feature of GitHub Advanced Security for Azure DevOps.
• C. A pre-commit hook scans locally but is a developer-side safeguard that cannot be enforced centrally. It relies on each developer installing and maintaining the hook, making it unreliable for organizational policy.
• D. Installing the extension enables secret scanning capabilities in Azure DevOps, but the specific action to block secrets on push is push protection. The extension is a prerequisite, not the direct automation step.

Correct answer: B — Add a pipeline task to run docker scan before push

• A. Incorrect. Enabling Defender for Cloud scanning on Azure Container Registry provides vulnerability assessment for images already in the registry, but it is not a pipeline task that can fail a build before the image is pushed. It is a registry-level control, not a direct CI/CD pipeline automation.
• B. Correct. Adding a pipeline task such as docker scan (or a similar tool) before pushing an image integrates vulnerability scanning directly into the CI process. This allows the build to fail if critical vulnerabilities are found, ensuring early detection and compliance.
• C. Incorrect. While third-party tools like Aqua Security can be integrated into Azure DevOps pipelines and provide strong container security, the question typically expects the most direct Azure-native pipeline-based automation. Using a third-party tool is a valid but not the simplest approach in this context.
• D. Incorrect. Branch policies in Azure DevOps can enforce code reviews and build validation, but they do not scan container images themselves. Image scanning requires a pipeline task or registry-level scanner; branch policies alone cannot perform vulnerability scanning.

Correct answer: B — packages: write

• A. Incorrect. The 'contents: write' permission controls repository file contents, source code, and branch management. It does not grant access to manage packages in GitHub Packages.
• B. Correct. The 'packages: write' permission is specifically used to publish, install, update, and delete packages in GitHub Packages. This is the required scope for writing packages.
• C. Incorrect. The 'actions: write' permission is related to GitHub Actions workflows, including creating and managing workflow runs and artifacts. It does not cover package write operations.
• D. Incorrect. The 'deployments: write' permission is used for deployment-related operations, such as managing deployment statuses and environments. It is not a permission for writing packages.

Correct answer: B — Basic + Test Plans

• A. Incorrect. The Basic access level includes features for code repositories, work items, and pipelines, but does not include access to Azure Test Plans.
• B. Correct. Basic + Test Plans is the Azure DevOps access level that includes all Basic features plus access to Test Plans, test suites, and test cases, which is required for test management.
• C. Incorrect. Stakeholder access is a free, limited level intended for viewing and minimal contribution. It does not include Test Plans or full development capabilities.
• D. Incorrect. Visual Studio Subscriber access provides full Azure DevOps features, but the minimal access level that specifically includes Test Plans is Basic + Test Plans, not Visual Studio Subscriber.

Correct answer: C — Enable Key Vault auto-rotation and define a rotation policy for the secret.

• A. Incorrect. A timer-triggered Azure Function is a custom solution that does not natively integrate with Key Vault's auto-rotation. Restarting the database is unnecessary and risky for a secret rotation workflow.
• B. Incorrect. An Azure Automation runbook adds custom orchestration and does not leverage Key Vault's native rotation capabilities. Sending a webhook notification does not itself rotate the secret.
• C. Correct. Azure Key Vault supports auto-rotation of secrets with a defined rotation policy. This is the most secure and native way to automate secret rotation, requiring minimal custom code. It can also trigger dependent services via Event Grid.
• D. Incorrect. A Logic App provides a custom workflow but is not the native secret-rotation feature of Key Vault. The app reload step is application-specific and adds unnecessary complexity.

Correct answer: C — Key Vault access policy with permissions to manage storage account keys

• A. Incorrect. While a managed identity with the Storage Account Key Operator Service Role can technically access storage account keys, this approach does not provide centralized secret management. The key is still exposed to the automation runbook, and best practice for managing sensitive information is to use Azure Key Vault.
• B. Incorrect. Granting a service principal the Contributor role on the storage account provides broad management permissions, violating the principle of least privilege. It is overprivileged for key management and does not offer secure secret storage.
• C. Correct. A Key Vault access policy with permissions to manage storage account keys allows secure, centralized storage and controlled access to keys without hardcoding credentials. This aligns with best practices for managing sensitive information in automation.

Correct answer: C — Performance blade: select 'GetCatalog', group by 'Cloud role instance'

• A. Incorrect. Availability tests measure endpoint reachability and response times from synthetic test locations, but they focus on synthetic monitoring rather than analyzing actual user request performance for a specific operation across regions. They do not provide an out-of-the-box view of average response times per operation grouped by region.
• B. Incorrect. The Application Map visualizes dependencies and component relationships in your application. Filtering by dependency type 'HTTP' helps inspect dependencies, but it does not offer a direct view of average response times for a specific operation (e.g., 'GetCatalog') grouped by region.
• C. Correct. The Performance blade under Operations allows you to select a specific operation like 'GetCatalog' and group the results by dimensions such as 'Cloud role instance', which corresponds to the Azure region where the instance runs. This provides an out-of-the-box view comparing average response times across regions.
• D. Incorrect. The Failures blade is designed for investigating exceptions, failed requests, and error conditions. Filtering by exception type like 'Timeout' can help diagnose issues, but it does not provide the average response time analysis for a specific operation.

Correct answers: A, B — Open the Failures blade, filter to the Service Bus dependency, and examine the exception types and stack traces.; Run a KQL query to filter failed Service Bus dependencies grouped by timestamp and target queue.

• A. Correct. The Failures blade in Application Insights is designed for investigating failed requests and dependencies. Filtering to the Service Bus dependency narrows the analysis, and examining exception types and stack traces helps identify the root cause of the failures.
• B. Correct. Running a KQL query against the dependencies table filters for failed Service Bus calls and summarizes the count by timestamp and target, which helps identify the affected queue and the time pattern of failures, aiding root cause analysis.
• C. Incorrect. Scaling the Service Bus namespace to premium tier is a remediation action, not an investigation step. The immediate focus should be on diagnosing the root cause before taking any corrective measures.
• D. Incorrect. Live Metrics provides near real-time data, but it is not the best tool for analyzing historical failure spikes or detailed failure information. Connection counts to Service Bus do not directly reveal the cause of dependency failures.
• E. Incorrect. Application Map visualizes the topology of your application and its dependencies, confirming connectivity, but it does not provide detailed failure analysis or root cause information for dependency failures.
• F. Incorrect. The Performance blade shows dependency duration and latency trends, but it does not directly help identify the root cause of failures. For failure investigation, failure-centric views and queries are more appropriate.

Correct answer: C — Assign the built-in Azure Policy for VM Insights to auto-install agents on compliant VMs.

• A. Incorrect. While Azure Automation can run scripts, it is not the most scalable or native method for this scenario. PowerShell may not be ideal for Linux VMs, and this approach requires maintaining and ensuring reliable execution of scripts across all VMs.
• B. Incorrect. Manually installing agents on 200 production VMs is labor-intensive, directly conflicts with the requirement to avoid manual intervention, and increases the risk of configuration drift and inconsistent deployment.
• C. Correct. The built-in Azure Policy for VM Insights automatically deploys the Log Analytics and Dependency agents to compliant VMs, providing a standardized, scalable, and automated approach with minimal manual effort. This is the native and supported method for enabling VM Insights at scale.
• D. Incorrect. While Desired State Configuration can enforce configurations, it is not the standard or simplest Azure-native approach for enabling VM Insights on Linux VMs. Azure Policy with auto-installation is the more appropriate mechanism for this scenario.

Correct answer: A — Microsoft.ApplicationInsights.AspNetCore

• A. Correct. Microsoft.ApplicationInsights.AspNetCore is the official and widely used NuGet package for enabling Application Insights telemetry in ASP.NET Core and .NET Core applications. It integrates seamlessly to collect requests, dependencies, exceptions, and other telemetry.
• B. Incorrect. Azure.Monitor.OpenTelemetry.AspNetCore is an OpenTelemetry-based package for sending telemetry to Azure Monitor. While it is a valid option for telemetry collection, it is not the standard or default package for Application Insights; it is used when adopting the OpenTelemetry approach.
• C. Incorrect. Microsoft.AspNetCore.Diagnostics.HealthChecks is used for adding health check endpoints to an ASP.NET Core application. It does not instrument the application for telemetry collection, and it is not related to Azure Monitor or Application Insights.