Microsoft Practice Questions, Discussions & Exam Topics by our Authors

DRAG DROP - You have an Azure DevOps release pipeline as shown in the following exhibit. You need to complete the pipeline to configure OWASP ZAP for security testing. Which five Azure CLI tasks should you add in sequence? To answer, move the...

Author: Olivia · Last updated Jun 17, 2026

You have a build pipeline in Azure Pipelines that uses different jobs to compile an application for 10 different architectures. The build pipeline takes approximately one day to complete. You need to reduce the time it takes to execute the build pipeline. Which two actions ...

Understanding the scenario: The build pipeline in Azure Pipelines takes approximately one day to complete, and the goal is to reduce the time it takes for the build pipeline to execute. The pipeline has multiple jobs to compile an application for 10 different architectures. Option Analysis: A) Move to a blue/green deployment pattern - Reasoning: A blue/green deployment pattern is used to reduce downtime during application deployment by maintaining two environments: a blue environment (current) and a green environment (new). This is typically a deployment strategy to ensure continuous availability, not a technique for reducing build pipeline execution time. - Why Rejected: This option does not address the build time problem at all. It's more about deployment and has no impact on speeding up the build process. - Scenario: Use this for deployment strategies, not build time reduction. B) Create a deployment group - Reasoning: A deployment group is a collection of target machines or environments where deployments can be made. While helpful for organizing target machines for deployment, this does not impact build pipeline execution time directly. - Why Rejected: This option is focused on organizing and executing deployments, not optimizing the build pipeline for reduced execution time. - Scenario: Use this for deployment tasks, not to speed up builds. C) Increase the number of parallel jobs - Reasoning: Increasing the number of parallel jobs in your build pipeline can significantly speed up the build process by allowing multiple jobs to run at the same time. This is particularly useful when there are multiple jobs for different architectures (as in the scenario), and you can execute them simultaneously. - Why Selected: By running jobs in parallel, the build time can be drastically reduced, especially if the jobs are independent (compiling for different architectures). This action directly addresses the problem ...

Author: CrimsonViperX · Last updated Jun 17, 2026

You are creating a build pipeline in Azure Pipelines. You define several tests that might fail due to third-party applications. You need to ensure that the build pipeline completes su...

Scenario Breakdown: You are creating a build pipeline in Azure Pipelines, and you have tests that may fail due to third-party applications being unavailable. The goal is to ensure that the build pipeline completes successfully even if these tests fail due to external dependencies (third-party applications). Option Analysis: A) Configure the build pipeline to use parallel jobs - Reasoning: Configuring parallel jobs allows multiple jobs to run simultaneously, which can speed up the pipeline. However, this option does not address the issue of third-party application failures or allow the pipeline to complete successfully if certain tests fail. - Why Rejected: Parallel jobs are focused on performance (speeding up execution), not on handling test failures due to external factors. This does not solve the problem of ensuring the build completes successfully when tests fail due to third-party application unavailability. - Scenario: Use this option if you want to speed up pipeline execution, but it doesn't address the goal of handling failing tests due to third-party service issues. B) Configure flaky tests - Reasoning: Flaky tests are tests that are known to occasionally fail due to external or unstable factors. Azure Pipelines provides a feature to mark such tests as "flaky." When flaky tests are marked as such, Azure Pipelines will not fail the build if the test fails once or twice in a row, instead marking the result as flaky and allowing the build to continue. - Why Selected: This directly addresses the problem. By marking tests as flaky, Azure Pipelines will not block the build even if the third-party application causes those specific tests to fail, as long as the failures are intermittent or due to external factors. - Scenario: Use this option when you have known tests that fail intermittently due to external factors (like third-party applications being unavailabl...

Author: Mia · Last updated Jun 17, 2026

DRAG DROP - You have an Azure subscription that contains a resources group named RG1. RG1 contains the following resources: * Four Azure virtual machines that run Windows Server and have Internet Information Services (IIS) installed. * SQL Server on an Azure virtual machine. * An Azure Load Balancer. You need to deploy an application to the virtual machines in RG1 by using Azure Pipelines. Which four actions should you perform in sequence? To answer, move the appropriate actions from th...

Author: ElectricLionX · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. Your company has a project in Azure DevOps for a new web a...

Understanding the scenario: You are working with a project in Azure DevOps for a new web application, and the goal is to ensure that when code is checked in, a build runs automatically. Option Analysis: A) Yes - Reasoning: In Azure DevOps, Continuous Integration (CI) is a process where every time code is checked in or a change is made to the repository, a build is triggered automatically. This is done by enabling continuous integration in the Triggers tab of the build pipeline. - Enabling CI in the build pipeline ensures that a build is automatically triggered whenever a code change is committed to the repository (or to a specific branch if configured). - This directly meets the goal of running a build when code is checked in. - Why Selected: By enabling Continuous Integration (CI), the pipeline will automatically start building every time changes are pushed to the repository. This is the correct configuration to ensure that a build runs when code is checked in. - Scenario: Use this ...

Author: Alexander · Last updated Jun 17, 2026

You have an Azure DevOps organization named Contoso and an Azure DevOps project named Project1. You plan to use Microsoft-hosted agents to build container images that will host full Microsoft .NET Framework apps in a YAML pipeline in Project1. What are two possible virtual machine images that you can use fo...

Understanding the scenario: You need to use Microsoft-hosted agents in Azure DevOps to build container images that will host full Microsoft .NET Framework apps. The build will be carried out in a YAML pipeline in the Project1 of the Contoso Azure DevOps organization. Requirements: - You need a virtual machine image for the Microsoft-hosted agent pool that supports building .NET Framework apps. - The .NET Framework requires Windows-based environments, as it’s a Microsoft-specific framework and doesn't run on Linux or macOS environments. Option Analysis: A) vs2017-win2016 - Reasoning: The vs2017-win2016 image is a Windows-based image with Visual Studio 2017 and Windows Server 2016. This image is suitable for building and compiling .NET Framework applications, as it supports the necessary environment for Windows-based technologies, including the .NET Framework. - Why Selected: This option is ideal because it provides a Windows environment with the necessary tools for building .NET Framework apps. - Scenario: Use this when you need a Windows Server 2016 environment with Visual Studio 2017, suitable for .NET Framework apps. B) ubuntu-16.04 - Reasoning: Ubuntu 16.04 is a Linux-based image, and while it can support some Microsoft technologies like .NET Core, it cannot run .NET Framework apps because they are Windows-specific. .NET Framework requires a Windows-based environment. - Why Rejected: This option does not meet the requirement because it’s a Linux image and .NET Framework apps cannot run on Linux-based environments. - Scenario: Use this if you're working with .NET Core or other Linux-based technologies, but not for .NET Framework. C) win1803 - Reasoning: The win1803 image is a ...

Author: Emma · Last updated Jun 17, 2026

SNAPSHOT - You currently use JIRA, Jenkins, and Octopus as part of your DevOps processes. You plan to use Azure DevOps to replace these tools. Which Azure DevOps service should you use to replace each tool? To answer, select the ...

Author: Sophia Clark · Last updated Jun 17, 2026

Your company has a project in Azure DevOps. You need to ensure that when there are multiple builds pending deployment, only t...

Understanding the scenario: Your company has a project in Azure DevOps, and you want to ensure that when there are multiple builds pending deployment, only the most recent build is deployed. The objective is to prevent older builds from being deployed if there are newer builds that are waiting for deployment. Option Analysis: A) Deployment conditions - Reasoning: Deployment conditions control when and how deployments occur based on certain criteria. While they provide the ability to manage deployments, they don't specifically control the deployment of the most recent build in the case of multiple pending builds. - Why Rejected: Deployment conditions are useful for controlling when a deployment happens (e.g., after a successful build or under specific conditions), but they don’t directly ensure that only the most recent build is deployed when multiple builds are pending. - Scenario: Use this when you need specific pre-deployment conditions, but it won't help in the case of choosing only the most recent build. B) Deployment queue settings - Reasoning: Deployment queue settings can be configured to ensure that only one deployment is active at a time, and they allow you to define rules for managing the order in which deployments are handled. - Automatic deployment cancellation can be enabled in these settings to ensure that if a new build is queued for deployment, it will cancel any pending deployments for older builds and deploy the most recent build. - Why Selected: This option directly addresses the requirement to ensure that only the most recent build is deployed, by automatically canceling older pending deployments in favor of the most recent one. - Scenario: Use this when you want to ensure that only the most recent build is...

Author: Julian · Last updated Jun 17, 2026

Your company develops a client banking application that processes a large volume of data. Code quality is an ongoing issue for the company. Recently, the code quality has deteriorated because of an increase in time pressure on the development t...

Static code analysis is a technique used to examine the codebase for potential bugs, vulnerabilities, code quality issues, or adherence to coding standards before the code is run. The main goal is to detect problems early, preventing issues from reaching production. Let’s break down the options and determine the most appropriate phase for static code analysis: A) Integration Testing Integration testing is conducted after individual components or units of the application are tested and integrated to ensure that they work together. At this point, the code has already been executed in some form, and testing is focused on how different modules interact. Static code analysis typically happens before code execution, so integration testing is not the ideal time to perform static code analysis. Rejected because static analysis should happen earlier to catch issues before they manifest during testing. B) Staging Staging is the environment where the application is deployed to simulate production before the final release. While staging is important for validating the application's behavior in a near-production setting, it is primarily focused on testing the runtime aspects of the system. Static code analysis, by contrast, does not require running the code and should be done earlier, at the point where the code is still in development or being built. Rejected because...

Author: John · Last updated Jun 17, 2026

DRAG DROP - You have a project in Azure DevOps that uses packages from multiple public feeds. Some of the feeds are unreliable. You need to consolidate the packages into a single feed. Which three actions should you perform in sequence? To answer, move the approp...

Author: Ishaan · Last updated Jun 17, 2026

SNAPSHOT - You have the Azure DevOps pipeline shown in the following exhibit. Use the drop-down menus to select the answer choice that completes each statement based on the information pre...

Author: VioletCheetah55 · Last updated Jun 17, 2026

SIMULATION - You have an Azure function hosted in an App Service plan named az400-123456789-func1. You need to configure az400-123456789-func1 to upgrade the functions automatically whenever new code is committed to the master branch of https:// g...

To automatically upgrade an Azure function whenever new code is committed to the master branch of a GitHub repository, you would need to set up continuous deployment (CD) via GitHub integration with the Azure Function. This can be done directly within the Azure portal using the Deployment Center. Let’s analyze the available options to determine the correct approach. A) Azure Functions Settings This option focuses on configuring function-specific settings, such as the function app runtime, versions, or hosting plans. While this is crucial for managing the Azure Function's settings, it doesn't deal with automating deployments from GitHub. Rejected because it does not offer a way to connect to a GitHub repository for continuous deployment. B) Deployment Center The Deployment Center in the Azure portal allows you to configure continuous integration and continuous deployment (CI/CD) directly from version control systems like GitHub. By linking your GitHub repository with the Azure Function, it automatically deploys the latest code whenever changes are made to the specified branch (in this case, the master branch). This aligns perfectly with the requirement to auto-upgrade the functions on new code commits. Selected because the Deployment Center is specifically designed for automating deployments from a GitHub repository, ensuring the function ap...

Author: Maya · Last updated Jun 17, 2026

DRAG DROP - You need to use Azure Automation State Configuration to manage the ongoing consistency of virtual machine configurations. Which five actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. NOTE...

Author: Emma · Last updated Jun 17, 2026

You are developing an application. The application source has multiple branches. You make several changes to a branch used for experimentation. You need to update the main branch to capture the changes made to the experime...

In this scenario, you want to update the main branch with the changes made in the experimentation branch and override the history of the Git repository. Let's go over each option and why some of them are rejected: A) Rebase: - What it does: Rebase takes the changes from one branch and applies them on top of another branch. It rewrites the commit history by moving the base of the branch to a new commit. - Why it could work: You can rebase the experimentation branch onto the main branch to apply its changes in a linear history. However, this doesn’t directly override the history of the main branch, but it can lead to a cleaner history. - Why it is rejected: Although rebase allows you to bring changes in an organized manner, it doesn't inherently "override" the history of the main branch. Also, rebase can be complex in case of conflicts and does not truly "override" the main branch's history with the experimentation branch’s content. B) Fetch: - What it does: Fetch retrieves changes from a remote repository without merging them into the current branch. - Why it is rejected: Fetch only pulls the latest updates from a remote branch but doesn’t modify your local branches or history. It do...

Author: Ella · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You use Azure Pipelines to build and test a React.js application. You have a pipeline that has a single job. You discover that installing JavaScript packages from npm takes approximately ...

In this scenario, the goal is to reduce the pipeline execution time by addressing the issue of installing JavaScript packages from npm, which takes approximately five minutes during each pipeline run. Let's analyze the solution and each option: Solution: Define a container job that uses a custom container with pre-installed JavaScript packages - How it works: By using a custom container that already has the required JavaScript packages pre-installed, the pipeline can skip the step of downloading and installing these packages from npm. This should significantly reduce the execution time for that part of the pipeline. - Why it meets the goal: Defining a container job with pre-installed JavaScript packages will speed up the build process because the npm install step, which is time-consuming, is avoided. The time-consuming installation process is eliminated, and the pipeline can focus on other tasks like building, testing, and deploying the application. A) Yes: - This ...

Author: Mia · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You use Azure Pipelines to build and test a React.js application. You have a pipeline that has a single job. You discover that installin...

In this scenario, the goal is to reduce the pipeline execution time, particularly focusing on the time it takes to install JavaScript packages from npm, which takes approximately five minutes during each run. Let's analyze the solution and each option: Solution: Enable pipeline caching - How it works: Azure Pipelines offers caching to speed up workflows by storing dependencies or build outputs between pipeline runs. For npm packages, enabling caching will allow the pipeline to reuse previously downloaded dependencies, so they don't need to be reinstalled from scratch during every run. - Why it meets the goal: By enabling pipeline caching, the dependencies (such as npm packages) are stored in a cache. On subsequent pipeline runs, if the dependencies haven't changed, the cached versions will be reused, and the installation time can be greatly reduced. This solution effectively minimizes the time spent on repetitive tasks like installing the same npm packages. A) Yes: - This is the co...

Author: Abigail · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You use Azure Pipelines to build and test a React.js application. You have a pipeline that has a single job. You discover that installing JavaScr...

Let's analyze whether enabling parallel jobs in Azure Pipelines would help reduce the pipeline execution time for installing JavaScript packages. Solution: Enabling Parallel Jobs - How it works: Enabling parallel jobs in Azure Pipelines allows you to run multiple tasks or jobs concurrently, rather than sequentially. For instance, you could run tests, builds, or other steps at the same time, instead of one after the other, which can speed up the overall pipeline execution. - Why it doesn’t directly meet the goal: Parallel jobs are useful when you have multiple independent tasks that can run concurrently, but in this scenario, the issue is specifically with the time it takes to install npm packages, which is a sequential task. Enabling parallel jobs will not reduce the time taken for npm installation because that step will still need to run sequentially. While you could run tests or other tasks in parallel, the bottleneck of npm install will remain unless the npm installation itself is optimized (via caching, for example). A) Yes: - This would be the ...

Author: Arjun · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You plan to create a release pipeline that will deploy Azure resources by using Azure Resource Manager templates. The release pipeline will create the following resources: * Two resource groups * Four Azure virt...

Let's analyze the solution and the options: Solution: Create two standalone templates, each of which will deploy the resources in its respective group - How it works: Creating two standalone ARM templates means that you would define one template for deploying the resources into one resource group (e.g., virtual machines) and a second template for the other resource group (e.g., SQL databases). Each template would be responsible for the resources in its respective group. - Why it could work: This solution would allow you to deploy resources to the respective resource groups by splitting the deployment tasks across two ARM templates. You can trigger the deployment of each template independently in your release pipeline, which is a simple and straightforward approach to deploying resources into different resource groups. - Why it may not meet the goal: While this solution is viable, it may not be the most efficient way to deploy resources that are logically related. If you need to deploy resources that are interdependent (for example, virtual machines and SQL databases that need to be configured together), splitting the deployment into two separate templates could lead to complications. Specifically, there may be timing or dependency issues that require additional management (such as handling the order of deployment or ensuring dependencies are corr...

Author: StarryEagle42 · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You plan to create a release pipeline that will deploy Azure resources by using Azure Resource Manager templates. The release pipeline will create the following resources: * Two resource groups ...

In this scenario, you are tasked with deploying multiple resources using Azure Resource Manager (ARM) templates in a release pipeline. The solution provided is to create a single standalone template that will deploy all resources. Let's break down the key considerations and evaluate the solution. Key considerations: 1. Resource Group Deployment: The scenario involves creating two different resource groups: one for the four Azure virtual machines and another for the two Azure SQL databases. Each resource group can be managed separately, but they can still be defined in the same ARM template. 2. Resource Group Management in ARM Templates: ARM templates allow you to deploy resources into different resource groups, but the resources within a single ARM template need to be declared accordingly. In this case, deploying resources like VMs and SQL databases across different resource groups is possible by specifying the `resourceGroup` for each resource. However, a single ARM template could become complex if the resources have dependencies on each other. 3. Modularization of Templates: While a single ARM template can theoretically deploy all the resources, for larger projects, it is often better to modularize deployments into multiple templates. This allows for better maintainability and easier tracking of resource d...

Author: Sam · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure DevOps project. Your build process creates several artifacts. You need to depl...

Let's break down the solution to understand whether it meets the goal of deploying artifacts to on-premises servers. Key Components in the Scenario: 1. Artifacts in Azure DevOps: The goal is to deploy build artifacts, which typically are the output files or packaged components of your application after a build process. 2. Kubernetes Cluster on On-Premises: By deploying a Kubernetes cluster on-premises, you are setting up a containerized environment where applications can be run. Kubernetes itself isn't necessarily a requirement for simple artifact deployment but could be used if you need to containerize your application and manage it within a Kubernetes environment. 3. Helm Agent: Helm is a package manager for Kubernetes, and using it to manage deployments in the Kubernetes cluster can be useful if you are deploying containerized applications or microservices into the cluster. However, the use of Helm implies that the deployment will be Kubernetes-centric, and this may not align with simple artifact deployment scenarios, particularly if the artifacts aren’t containerized. 4. Download Build Artifacts Task: This task is used in the Azure DevOps release pipeline to download the build artifacts from the build pipeline. While this is a good step in getting the artifacts, it does not directly address how these artifacts will be deployed on an on-premises server if the server is not managed vi...

Author: Mia · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure DevOps project. Your build process creates several artif...

Let's evaluate whether the proposed solution meets the goal of deploying artifacts to on-premises servers. Key Components in the Scenario: 1. Artifacts in Azure DevOps: The goal is to deploy build artifacts, which could be a variety of outputs like binaries, configuration files, etc. 2. Docker Build: The solution proposes deploying a Docker build to an on-premises server. Docker is primarily used for containerizing applications. If the artifacts produced by the build process are Docker images or applications that can run within containers, deploying them as Docker containers would be a suitable approach. However, if the artifacts are non-containerized items (such as files or executables), Docker deployment might not be necessary or relevant. 3. Download Build Artifacts Task: This task will download the artifacts produced during the build process. This step is critical as it fetches the necessary files to be deployed, but it doesn't directly define how these artifacts are actually deployed to the target on-premises server. Analysis of the Solution: - Docker Deployment: If your artifacts are Docker images (i.e., containerized ap...

Author: FrozenWolf2022 · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure DevOps project. Your build process creates several artifacts. You nee...

Let's break down the solution and assess whether it meets the goal of deploying artifacts to on-premises servers. Key Components in the Scenario: 1. Artifacts in Azure DevOps: The goal is to deploy the build artifacts produced by your build process. Artifacts typically refer to files such as binaries, configuration files, or application packages that were created during the build pipeline. 2. Azure Self-Hosted Agent: A self-hosted agent is an agent that runs on your on-premises server instead of using a Microsoft-hosted agent from Azure DevOps. By deploying a self-hosted agent to the on-premises server, you enable Azure DevOps to interact with and execute tasks directly on that server, which is crucial for deployments that happen within your on-premises environment. 3. Copy and Publish Build Artifacts Task: This task is used in Azure DevOps to copy build artifacts to a designated location and publish them so they can be consumed by subsequent stages (like release or deployment). While this task is useful for publishing the artifacts, it’s not directly responsible for the deployment of the artifacts to an on-premises server. It just makes the artifacts available for download in other pipelines or environments. Analysis of the S...

Author: Sara · Last updated Jun 17, 2026

You have a project in Azure DevOps named Project1. Project1 contains a pipeline that builds a container image named Image1 and pushes Image1 to an Azure container registry named ACR1. Image1 uses a base image stored in Docker Hub. You need...

To ensure that Image1 is updated automatically whenever the base image in Docker Hub is updated, let's evaluate each option carefully: Key Considerations: - Container Image Dependency: The goal is to ensure that when the base image in Docker Hub is updated, Image1 in your Azure Container Registry (ACR1) is automatically rebuilt and updated. - Automatic Trigger: The key requirement here is the automation of the update process when the base image changes. Azure DevOps pipelines can be configured to automatically trigger builds based on events or conditions, but those events must be properly configured. Option Analysis: 1. A) Enable the Azure Event Grid resource provider and subscribe to registry events: - Azure Event Grid can be used to subscribe to certain events in Azure, including changes to container images in an Azure Container Registry. However, this doesn't directly apply to updates in Docker Hub itself. - Event Grid would allow you to listen for events related to ACR1 (e.g., new images being pushed to ACR1) but would not be triggered when the base image in Docker Hub is updated. This would not fulfill the goal of automatically rebuilding Image1 when the base image changes in Docker Hub. Rejected: This option doesn't address the specific requirement of monitoring Docker Hub for base image updates. 2. B) Add a Docker Hub service connection to Azure Pipelines: - Adding a Docker Hub service connection to Azure Pipelines allows you to interact with Docker Hub from your pipeline, such as pulling base images and pushing images to repositories. - However, merely adding a service connection does not automate the rebuilding of Image1 when the base image is updated. It enables communication with Docker Hub, but it doesn't trigger the pipeline automatic...

Author: Ella · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure DevOps project. Your build process creates several artifacts. You need to de...

The solution provided involves deploying an Octopus Deploy server, setting up a polled Tentacle agent on an on-premises server, and adding an Octopus task to the deployment pipeline. Let's break down the key elements and assess if the solution meets the goal of deploying artifacts to on-premises servers: 1. Octopus Deploy server: Octopus Deploy is a tool for automating the deployment of applications, and it works well with Azure DevOps for managing deployment pipelines. The server itself is used to manage deployment processes and facilitate communication with agents. 2. Polled Tentacle agent: The Tentacle agent is used in Octopus Deploy to facilitate deployment to the target environment. The polled mode means that the Tentacle checks in with the Octopus server to see if any deployment tasks need to be executed. This is suitable for on-premises environments where the server may not be able to initiate the connection to Octopus due to firewall or network restrictions. 3. Adding an Octopus task to the deploymen...

Author: Liam · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You plan to create a release pipeline that will deploy Azure resources by using Azure Resource Manager templates. The release pipeline will create the following resources: * Two resource groups * Four Azure virtual machines in one resource group * Tw...

To determine whether the proposed solution meets the goal of deploying Azure resources using Azure Resource Manager (ARM) templates, let's break down the approach and consider its suitability for the given scenario. The solution proposed: 1. Main Template: The main template will deploy resources in one resource group (e.g., four Azure virtual machines). 2. Nested Template: A nested template will deploy resources in another resource group (e.g., two Azure SQL databases). Key considerations: - ARM Template Deployment: ARM templates allow you to define and deploy Azure resources declaratively. They can be used to deploy multiple resources within a single resource group or across multiple resource groups. - Nested Templates: ARM templates support the use of nested templates, which can be useful to modularize deployments, especially when you have complex configurations or resources in different locations or resource groups. A main template can deploy resources to one res...

Author: Julian · Last updated Jun 17, 2026

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You plan to create a release pipeline that will deploy Azure resources by using Azure Resource Manager templates. The release pipeline will create the following resources: * Two resource groups * Four Azure virtual machines in...

Let's assess whether the solution of creating a main template with two linked templates to deploy Azure resources across two resource groups meets the stated goal. Solution Breakdown: - Main Template: The main ARM template will coordinate the deployment of resources and use two linked templates. - Linked Templates: The first linked template will deploy resources (e.g., four virtual machines) in one resource group, while the second linked template will deploy resources (e.g., two Azure SQL databases) in another resource group. Key Factors to Consider: 1. ARM Template Linked Templates: In Azure Resource Manager (ARM), linked templates allow you to modularize deployments by splitting a larger deployment into smaller, reusable templates. This is useful when deploying resources in different scopes, such as multiple resource groups. The main template references the linked templates to deploy resources in separate resource groups. 2. Multiple Resource Groups: The scenario involves creating two resource groups, and then deploying resources into each of those groups (virtual machines in one and SQL databases in the other). This solution, with the main template coordinating th...

Author: Matthew · Last updated Jun 17, 2026

DRAG DROP - You are building an application that has the following assets: * Source code * Logs from automated tests and builds * Large and frequently updated binary assets * A common library used by multiple applications Where should you store each asset? To answer, drag the appropriate Azure services to the correct assets. Each service may be ...

Author: Leah Davis · Last updated Jun 17, 2026

You plan to share packages that you wrote, tested, validated, and deployed by using Azure Artifacts. You need to release multiple builds of each package by using a single feed. The solution...

To determine the best solution for sharing packages that you wrote, tested, validated, and deployed using Azure Artifacts, let's break down the requirements and each option: Requirements: - Release multiple builds of each package using a single feed. - Limit the release of packages that are in development, ensuring that only stable versions are available for release. Now, let's evaluate each option: A) Local Symbols: - Local symbols in Azure Artifacts are used for debugging and are typically related to debugging symbols for code. They are not designed to control or limit the release of packages in a feed. This option does not directly address the need for limiting the release of packages in development. B) Views: - Views in Azure Artifacts allow you to create virtual groups of packages from one or more feeds. You can create a view that combines multiple feeds or restricts access to certain packages, but it doesn't specifically help with controlling the release of in-development packages. Views can be useful for organizing packages but don't offer a built-in mechanism for limiting which versions are released based on the development status of the package. C) Global Symbols: - Global symbols are used to share symbols and debugging information across multiple packages or across multiple users or teams in ...

Author: Ethan · Last updated Jun 17, 2026

You have a project in Azure DevOps named Project1. Project1 contains a build pipeline named Pipe1 that builds an application named App1. You have an agent pool named Pool1 that contains a Windows Server 2019-based self-hosted agent. Pipe1 uses Pool1. You plan to implement another project named Project2. Project2 will have a build pipeline named Pipe2 that builds an application named App2. App1 and App2 have conflictin...

To minimize the possibility of conflicts between the build pipelines in Project1 and Project2 while minimizing infrastructure costs, we need to look at the available options and their implications. A) Add another self-hosted agent: Adding another self-hosted agent would result in a separate agent for each project, ensuring that the two pipelines do not interfere with each other. However, this would increase infrastructure costs, as you're adding more hardware or virtual machines to host the additional agent. Since the goal is to minimize infrastructure costs, this solution is not ideal. B) Add a Docker Compose task to the build pipelines: Adding a Docker Compose task can help isolate dependencies by running them inside containers. With Docker Compose, each pipeline could use a specific container with its required dependencies, and you can ensure that App1 and App2 do not interfere with each other. This option reduces infrastructure costs compared to adding another self-hosted agent because you are not adding additional machines—just containers within the same agent. This is a good option for minimizing conflicts and infrastructure costs. C) Change the self-hosted agent to use Red Hat Enterprise Linux (RHEL) 8: Switching to a Linux-based agent (RHEL 8) could help if the dependencies are more suited for Linux, but this doesn't directly address the proble...

Author: Michael · Last updated Jun 17, 2026

SIMULATION - You plan to store signed images in an Azure Container Registry instance named az4009940427acr1. You need to modify the SKU for az4009940427acr1 to support the planned images. The soluti...

To store signed images in an Azure Container Registry (ACR), you need to choose the appropriate SKU for the registry to support image signing. Azure Container Registry has different SKUs, each with its own set of features and pricing. The key factor here is to minimize costs while ensuring that the ACR can support image signing. Let's go through the options and considerations for modifying the SKU: Azure Container Registry SKUs Overview: 1. Basic SKU: - This SKU offers basic functionality for small, non-production use cases. - It supports basic container image storage and pull operations but does not include advanced features like image signing, which is important for your use case. 2. Standard SKU: - This SKU includes all the features of the Basic SKU and adds support for image signing. - The Standard SKU is cost-effective for production environments that need to store and manage container images. - Image signing is part of the Standard SKU, which makes it a suitable option for your requireme...

Author: Ella · Last updated Jun 17, 2026

You manage build pipelines and deployment pipelines by using Azure DevOps. Your company has a team of 500 developers. New members are added continually to the team. You need to automate the manag...

To automate the management of users and licenses in Azure DevOps for a growing team, we need to consider which tasks can be automated and which need to be performed manually. Here's an explanation of each option and the reasoning behind the selection: A) Modifying group memberships: - Automated Option: Group memberships can be automated using Azure Active Directory (Azure AD) and Azure DevOps, typically by syncing users from Azure AD groups to Azure DevOps groups. This can help manage group memberships efficiently, ensuring that users are automatically added to the correct groups based on roles or department affiliations. - Why it's rejected: Group memberships can be automated, so this task does not need to be done manually. B) Adding users: - Automated Option: Users can be added to Azure DevOps automatically by syncing with Azure Active Directory (Azure AD). This process can be managed via Azure AD sync or through automation tools like PowerShell or API calls. For large teams like yours, automatic user provisioning ensures that new members are added without manual intervention. - Why it's rejected: Adding users can be automated using Azure AD integration, so it doesn’t need to be done manually. C) Assigning entitlements: - Automated Option: In Azure DevOps, entitlements such as access permissions and role assignments can be managed ...

Author: Noah · Last updated Jun 17, 2026

SNAPSHOT - Your company uses Team Foundation Server 2013 (TFS 2013). You plan to migrate to Azure DevOps. You need to recommend a migration strategy that meets the following requirements: * Preserves the dates of Team Foundation Version Control changesets * Preserves the changed dates of work items revisions Minimizes migration effort - * Migrates all TFS...

Author: Ming · Last updated Jun 17, 2026

Your company is building a new solution in Java. The company currently uses a SonarQube server to analyze the code of .NET solutions. You need to analyze and monitor the code qualit...

To analyze and monitor the code quality of the Java solution in your build pipeline, we need to select the correct tool that integrates with Java and allows for code analysis, especially using SonarQube. Let’s analyze each of the given options: A) Octopus: - Purpose: Octopus is a deployment automation tool, primarily used for managing and automating deployments, not for building or analyzing code. - Why it's rejected: Octopus doesn't help with code quality analysis or monitoring in a Java build pipeline. It’s mainly for deployment tasks and not relevant to the task of analyzing Java code quality. B) Chef: - Purpose: Chef is a configuration management tool used for automating infrastructure provisioning, such as setting up servers, databases, or applications. - Why it's rejected: Chef is not related to code quality analysis. It doesn’t support the analysis of code or Java-specific build tasks. It’s focused on managing infrastructure rather than source code analysis. C) CocoaPods: - Purpose: CocoaPods is a dependency manager primarily for iOS and macOS applications, usually used in Obj...

Author: Aarav2020 · Last updated Jun 17, 2026

Your company is building a new solution in Java. The company currently uses a SonarQube server to analyze the code of .NET solutions. You need to analyze and monitor the code qualit...

When selecting the task type for analyzing and monitoring the code quality of a Java solution, we need to consider the following factors: 1. Compatibility with Java: The task type must support Java-based build systems or environments. 2. Code quality analysis integration: Since the goal is to analyze code quality (using SonarQube), the selected task type must facilitate integration with tools like SonarQube or support Java-based static analysis tools. Breakdown of each option: A) Maven - Why selected: Maven is a popular build automation tool for Java projects. It is designed to manage the build lifecycle, dependencies, and reporting for Java-based applications. Maven has good integration with SonarQube, and there are existing plugins like the `SonarQube Scanner for Maven` that help analyze Java code during the build process and send the results to SonarQube. - Key Factor: Java-centric, easy integration with SonarQube, and compatible with Java solutions. B) CocoaPods - Why rejected: CocoaPods is a dependency manager used primarily for iOS and macOS applications. It is not related to Java or SonarQube and cannot be used for building or analyzing Java solutions...

Author: Emma Brown · Last updated Jun 17, 2026

You have an Azure subscription named Subscription1 that contains a custom Azure policy named Policy1. Policy1 is an audit policy that monitors naming convention compliance for the resources deployed to Subscription1. You have a pipeline named Pipeline1 in Azure Pipelines. Pipeline1 deploys Azure Resource Manager (ARM) reso...

To ensure that the resources deployed by Pipeline1 comply with Policy1 (an audit policy monitoring naming convention compliance), we need to focus on the correct process for compliance enforcement during or after the deployment. Let's break down the options: A) A pre-deployment task that runs a security and compliance assessment - Why selected: A pre-deployment task that runs a security and compliance assessment can help assess whether the resources being deployed to Subscription1 will comply with the policy before the deployment happens. This approach ensures that resources are validated against Policy1 before they are deployed, providing a proactive check and preventing non-compliant resources from being deployed. - Key Factor: Ensures that any non-compliant resources are flagged before deployment begins, avoiding possible policy violations. B) A post-deployment task that runs a security and compliance assessment - Why rejected: While this task can be useful to audit compliance after resources have been deployed, it does not prevent non-compliant resources from being deployed in the first place. Running compliance checks after deployment may result in the need for additional corrective actions (such as manual intervention to adjust non-compliant resources). - Key Factor: Post-deployment checks do not prevent policy violations at the t...

Author: Alexander · Last updated Jun 17, 2026

SNAPSHOT - You plan to use Desired State Configuration (DSC) to maintain the configuration state of virtual machines that run Windows Server. You need to perform the following: * Install Internet Information Services (IIS) on the virtual machines. * Update the default home page of the IIS web server. How should you configure the ...

Author: VenomousSerpent42 · Last updated Jun 17, 2026

You have a project in Azure DevOps. You need to push notifications about pull requests to a Microsoft Teams channel. The solutio...

To push notifications about pull requests to a Microsoft Teams channel while minimizing development effort, we need a solution that is straightforward and leverages existing tools as much as possible. Let's break down each option: A) Install the Azure Pipelines app for Teams and configure a subscription to receive notifications in the channel. - Why rejected: The Azure Pipelines app for Teams is primarily focused on sending notifications related to Azure Pipelines activities (builds, releases, etc.), not specifically for pull requests. While it can send general notifications, it is not the best fit if the primary goal is to get pull request notifications specifically. - Key Factor: Not designed for pull request notifications specifically, more suited for pipeline-related notifications. B) Use Azure Automation to connect to the Azure DevOps REST API and send messages to Teams. - Why rejected: This approach involves setting up Azure Automation, connecting to the Azure DevOps REST API, and manually configuring the messaging system for Teams. Although this is feasible, it would require significant development effort to implement and maintain, as you'd need to manage automation scripts, API calls, and ensure everything works correctly. This is more complex and involves more effort than necessary. - Key Factor: High development effort due to the custom implementation and need for managing API calls. C) Install the Azure Repos app for Teams and configure a subscription to receive notifica...

Author: Aria · Last updated Jun 17, 2026

SNAPSHOT - You are creating a YAML-based Azure pipeline to deploy an Azure Data Factory instance that has the following requirements: * If a Data Factory instance exists already, the instance must be overwritten. * No other resources in a resource group named Fabrikam must be affected. How should you compl...

Author: Stella · Last updated Jun 17, 2026

You have an Azure DevOps project that produces Node Package Manager (npm) packages. Multiple projects consume the packages. You need to configure Azure Artifacts to ensure that both the latest and pre...

To ensure both the latest and pre-release versions of npm packages are available for consumption in Azure Artifacts, you need to configure feed views and pipeline strategies carefully. Let's analyze each option and evaluate which one best meets the requirement. A) Create two feed views named @prerelease and @release, Set @release as the default view. Configure a release pipeline that tags the packages as release after successful testing. - Explanation: In this option, two views are created: one for pre-release versions (@prerelease) and one for stable release versions (@release). The release pipeline tags packages as "release" after successful testing. Setting @release as the default ensures that consumers who are looking for stable, production-ready packages will always get the latest stable version by default. - Why this is correct: This option allows you to separately manage pre-release and release versions. By tagging packages as "release" after testing, you can control which versions are considered stable and can be made available for general consumption. - Scenario: This is ideal for projects that need to handle both pre-release (testing versions) and stable versions of packages. It ensures clear separation of package versions and controls access to different types of versions. B) Create a feed view named @prerelease. Configure a release pipeline that tags the packages as release after successful testing. - Explanation: This option suggests only creating a pre-release view, meaning you wouldn't have a dedicated stable view (@release). Packages would be tagged as "release" after testing, but there is no separate feed for stable versions. - Why rejected: There’s no stable feed view for consumers who want production-ready packages. This doesn't fully meet the requirement of having both pre-release and stable packages separately. - Scenario: This might work in cases where all versions, including stable and pre-release, should be available from a single feed view, but it's not a complete solution for distinguishing between pre-release and sta...

Author: Sara · Last updated Jun 17, 2026

You have an Azure subscription that contains the resources shown in the following table. Project produces npm packages that are published to Feed1. Feed1 is consumed by multiple projects. You need to ensure that only tested packag...

In this scenario, the key objective is to ensure that only tested packages are available for consumption, while also minimizing development effort. Let’s break down and evaluate each option based on this goal. A) Create a feed view named @release and set @release as the default view. After the npm packages test successfully, configure a release pipeline that promotes a package to the @release view. - Explanation: This option creates a separate feed view called @release, and sets it as the default view, which means any consumer accessing the feed will receive stable versions by default. After the npm packages pass tests, a release pipeline promotes the package to the @release view, making only tested packages available to consumers. - Why this is correct: This is an effective solution because it ensures that only tested packages are available in the @release view, while minimizing complexity. By promoting the package to the @release view, there’s a clear separation of pre-release and stable versions, with the default view ensuring stability for consumers. - Scenario: This solution works well for projects where clear differentiation between pre-release (unproven) and stable (tested) packages is needed. It is also simple to implement and requires minimal development effort since only promotion of packages to the @release view is needed after testing. B) Create a feed view named @release and set @release as the default view. After the npm packages test successfully, configure a release pipeline that tags the packages as release. - Explanation: This option also creates a feed view named @release and sets it as the default view. However, instead of promoting the package to the @release view, it suggests tagging the packages as "release" after testing. - Why rejected: While this approach could work in some cases, it’s less effective because tagging alone doesn’t control which feed view consumers will access. Tagging does not create a distinct separation between tested and untested packages. The concept of views is more flexible and provides clearer access control over what is available to ...

Author: Liam123 · Last updated Jun 17, 2026

Your company has an Azure DevOps project that produces Node Package Manager (npm) packages. Multiple projects consume the packages. You need to minimize the amount of disk ...

In this scenario, the goal is to minimize the amount of disk space used by older npm packages in Azure Artifacts. To address this issue, we need to configure the appropriate retention settings to ensure that old, unused packages are cleaned up in a controlled manner. Let's evaluate the options based on this goal: A) The retention settings of the project’s release - Explanation: Retention settings related to releases govern how long release artifacts, such as release pipelines' outputs (including npm packages), are retained in Azure DevOps. However, this option focuses more on the retention of release artifacts (such as release logs and metadata) rather than directly managing npm packages in Azure Artifacts. - Why rejected: Although it helps control retention of release artifacts, it does not directly manage the retention of npm packages in Azure Artifacts, which is the primary concern here. This option is not directly related to controlling the storage of npm packages in the feed. - Scenario: This could be useful if you want to limit the size of release-related data, but it doesn't affect package retention. B) The retention settings of the project’s pipeline - Explanation: Pipeline retention settings control the retention of build artifacts produced by the pipeline, including npm packages generated during build runs. Azure Artifacts can be configured to automatically clean up older versions of packages that are no longer needed, minimizing disk space usage. - Why this is correct: This option allows you to control the number of versions of npm packages retained in the feed. By modifying pipeline retention settings, you can ensure that old, outdated npm packages (created by build pipelines) are automatically deleted after a certain period or after a specified number of versions, which directly addresses the concern of minim...

Author: Kai99 · Last updated Jun 17, 2026

SNAPSHOT - You manage the Git repository for a large enterprise application. You need to minimize the data size of the repository. How should you complete the commands? To answer, select the appropriate...

Author: RadiantPhoenixX · Last updated Jun 17, 2026

SIMULATION - You plan to deploy a template named D:Deploy.json to a resource group named Deploy-lod123456789. You need to modify the template to meet the following requirements, and then to deploy the template: * The address space must be reduced to support only 256 total IP addresses. * The subnet...

To deploy a template to the Azure portal with the specified requirements, you need to modify the address space and subnet address space within the template itself. The goal is to ensure the address space accommodates only 256 IP addresses and the subnet space accommodates only 64 IP addresses. Let's break down the requirements and the steps you would need to follow to modify the template: Key Requirements: 1. The address space must be reduced to support only 256 total IP addresses. - The address space in the template should be reduced to a subnet that can accommodate 256 IP addresses. A subnet with 256 addresses can be achieved by using a `/24` subnet mask, which gives exactly 256 IP addresses (including network and broadcast addresses). 2. The subnet address space must be reduced to support only 64 total IP addresses. - A subnet with 64 IP addresses can be achieved by using a `/26` subnet mask, which provides 64 IP addresses (including network and broadcast addresses). Modifying the Template: Assuming the `D:Deploy.json` template defines a Virtual Network (VNet) with an address space and subnets, you need to: - Modify the address space to be a `/24` CIDR (Classless Inter-Domain Routing) block for a network that supports 256 IP addresses. - Modify the subnet's CIDR to `/26` to support only 64 IP addresses. Explanation of Key Fields: - Address space: In the `D:Deploy.json` file, you would look for a section defining the `addressSpace` under the virtual network's properties and modify it to a smaller range that supports 256 addresses. Example: ```json "addressSpace": { "addressPrefixes": [ "10.0.0.0/24" ] ...

Author: FrostFalcon88 · Last updated Jun 17, 2026

SIMULATION - You need to configure an Azure web app named az400-123456789-main to contain an environmental variable named `MAX_ITEMS`. The environmental variable must have a ...

To configure an environmental variable in an Azure web app named `az400-123456789-main` with a value of `MAX_ITEMS` set to 50, follow these steps in the Azure portal. There are a few different ways to configure environment variables in Azure Web Apps, and I'll explain why one specific option is selected and reject others based on key factors. Steps and Options: 1. Option 1: Application Settings in the Azure Portal - Go to the Azure portal. - Navigate to your Web App (az400-123456789-main). - Under the Settings section, select Configuration. - In the Application settings tab, click + New application setting. - Set the name as `MAX_ITEMS` and the value as `50`. - Click Save to apply the changes. Reasoning for selection: This is the most straightforward and user-friendly method to set environment variables directly in the portal. The configuration changes will be automatically applied to the app and will be available in the app's environment as soon as the changes are saved. It’s perfect for setting simple environment variables like `MAX_ITEMS`. Rejection of other options: - App Service Plan: App service plans deal with scaling and pricing configurations, not environment variables. - Resource Groups: Resource groups contain the app resources but aren't used for configuring app-specific environment variables. - Azure CLI / ARM Templates: While these are valid for automation and scripting purposes, they are not the simplest option for this specific task when using the Azure portal. - App Settings in Code: While environment variables can also be set in code (e.g., in a `Dockerfile` or app configurat...

Author: Max · Last updated Jun 17, 2026

DRAG DROP - You provision an Azure Kubernetes Service (AKS) cluster that has RBAC enabled. You have a Helm chart for a client application. You need to configure Helm and Tiller on the cluster and install the chart. Which three commands should you recommend be run in sequence? To answer, move ...

Author: David · Last updated Jun 17, 2026

Your company builds a multi-tier web application. You use Azure DevOps and host the production application on Azure virtual machines. Your team prepares an Azure Resource Manager template of the virtual machine that you will use to test new features. You need to create a staging environment in Azure that meets the following requirements: * Minimizes the cost of Azure hos...

To create a staging environment in Azure that meets the specified requirements (minimizes cost, provisions virtual machines automatically, and uses a custom Azure Resource Manager template), we need to carefully consider the available options. Breakdown of Options: A) In Azure Cloud Shell, run Azure CLI commands to create and delete the new virtual machines in a staging resource group. - Reasoning: This approach would involve manually running Azure CLI commands to create and delete virtual machines. While it allows flexibility and control over the process, it does not meet the requirement of automating the provisioning of virtual machines. Additionally, manual steps do not scale well for a staging environment that needs to be created and deleted frequently. - Rejection: This method requires manual intervention and does not provide an automatic, repeatable solution. Also, it doesn't specifically address the cost minimization aspect as effectively as other options. B) In Azure DevOps, configure new tasks in the release pipeline to deploy to Azure Cloud Services. - Reasoning: Azure Cloud Services is an older Azure platform for hosting applications, and it is typically used for cloud service roles (e.g., worker roles and web roles), rather than individual virtual machines. - Rejection: Azure Cloud Services is not the ideal solution for virtual machine provisioning, especially in modern architectures, as it’s a legacy platform that is being replaced by more efficient and flexible solutions such as Virtual Machine Scale Sets (VMSS) and Azure DevTest Labs. Additionally, this option doesn't focus on minimizing costs or leveraging ARM templates efficiently. C) From Azure Cloud Shell, run Azure PowerShell commands to create and delete the new virtual machines in a staging resource group. - Reasoning: This approach involves using Azure PowerShell commands to create and delete virtual machines manually. Like Option A, this approach requires manual intervention and is not...

Author: Evelyn · Last updated Jun 17, 2026

DRAG DROP - You are implementing an Azure DevOps strategy for mobile devices using App Center. You plan to use distribution groups to control access to releases. You need to create the distribution groups shown in the following table. Which type of distribution group should you use for each group? To answer, drag the appropriate group types to the correct locations. Each group type may be used once,...

Author: Ethan · Last updated Jun 17, 2026

SIMULATION - You need to ensure that the https://contoso.com/statushook webhook is called every time a repository named az400123456789acr1 receives a new version of an image na...

Author: Sophia · Last updated Jun 17, 2026

SNAPSHOT - You need to create deployment files for an Azure Kubernetes Service (AKS) cluster. The deployments must meet the provisioning storage requirements shown in the following table. Which resource type should you use for each deployment? To answer, ...

Author: IceDragon2023 · Last updated Jun 17, 2026

Your company uses Azure DevOps to manage the build and release processes for applications. You use a Git repository for applications source control. You plan to create a new branch from an existing pull request. Later, you plan to merge the new branch and the target branch of the pull request. You need to use a pull request action to create th...

To achieve the goal of creating a new branch from an existing pull request and ensuring that the branch only uses a portion of the code from the pull request, let's evaluate the available options based on the requirements. Breakdown of Options: A) Set as default branch - Reasoning: This action allows you to set the default branch for the repository. The default branch is typically the primary branch (e.g., `main` or `master`) where changes are merged. This does not relate to creating new branches or managing specific portions of a pull request's code. - Rejection: This option doesn't meet the requirement because it does not help in creating a new branch or isolating a portion of code from the pull request. B) Approve with suggestions - Reasoning: This action allows you to approve a pull request but includes feedback and suggestions for changes. The pull request itself will still remain as is. This is a review and approval step, not a mechanism for branching or managing portions of code. - Rejection: While useful for code review, this option doesn't address the creation of a new branch based on part of the code from an existing pull request. C) Cherry-pick - Reasoning: Cherry-picking is the action of selecting specific commits from one branch and applying them to another branch. This allows you to selectively take portions of changes from a pull request and apply them to a new branch. You can choose...

Author: Mia · Last updated Jun 17, 2026