This chapter covers Managed DevOps Pools, a feature that lets you create private, scalable pools of Azure virtual machines dedicated to running Azure Pipelines jobs. For the AZ-204 exam, this topic falls under Domain 1 (Compute) Objective 1.3: 'Create and manage Azure DevOps agents and pools.' Expect 1-2 questions on this topic, typically comparing Managed DevOps Pools with Microsoft-hosted and self-hosted agents. Mastering this chapter will help you choose the right agent strategy for security, compliance, and performance requirements.
Jump to a section
Imagine a large construction company that needs to build dozens of custom homes simultaneously. Each home requires specialized tools, lumber, and plumbing. Instead of each worker bringing their own tools (which may be incompatible or outdated), the company sets up a private fleet of fully equipped trucks. Each truck is pre-loaded with exactly the tools needed for the specific job—one truck has framing hammers, another has plumbing wrenches. The fleet manager (Azure DevOps) assigns a truck to a crew when a build starts, ensures the truck has the correct tools, and reclaims it when the build finishes. If a truck breaks down, the manager immediately dispatches a replacement. The manager also scales the fleet: during a busy week, it adds more trucks; during slow periods, it parks excess trucks to save fuel. This is exactly how Managed DevOps Pools work. They provide a pool of dedicated, pre-configured Azure virtual machines that are assigned to Azure Pipeline jobs. The pool manager handles provisioning, scaling, and cleanup, ensuring each job runs in a consistent, isolated environment without waiting for a shared agent to become available. The key difference from Microsoft-hosted agents is that you control the VM image, network, and scaling rules, just as the company controls the truck fleet.
What Are Managed DevOps Pools?
Managed DevOps Pools (MDP) are a type of Azure DevOps agent pool where the agents run on Azure virtual machines that are automatically provisioned, scaled, and managed by Azure DevOps. Unlike Microsoft-hosted agents, which are shared across tenants and have limited customization, MDP gives you full control over the VM image, size, network, and scaling behavior. MDP is part of the Azure DevOps managed agent infrastructure, but it is a separate service that you configure and pay for (the VMs incur Azure compute costs).
Why Managed DevOps Pools Exist
Before MDP, teams had two choices for running pipeline jobs:
Microsoft-hosted agents: convenient, no maintenance, but limited to predefined VM images, no admin access, and shared across tenants (potential for noisy neighbors).
Self-hosted agents: full control, but you must provision, patch, scale, and clean up VMs yourself.
MDP bridges the gap. It gives you the control of self-hosted agents (custom images, network isolation, persistent storage, admin access) with the convenience of Microsoft-hosted agents (automatic provisioning, scaling, and cleanup). MDP is ideal for organizations that need to comply with strict security policies, require specific software pre-installed, or need predictable performance without sharing resources.
How Managed DevOps Pools Work Internally
When you create a Managed DevOps Pool, you define: - Azure subscription: The pool runs in your own subscription, so you pay for the VMs. - VM size and image: You choose a VM SKU (e.g., Standard_D2s_v3) and a custom image (from Azure Compute Gallery or a managed image). - Scaling rules: Minimum and maximum number of idle VMs, and how many VMs to keep idle. - Networking: The VMs are deployed into a virtual network (VNet) you specify, enabling access to on-premises resources via VPN or ExpressRoute. - Agent specification: The agent software (Azure Pipelines Agent) is automatically installed on each VM.
Here is the lifecycle of a pipeline job using MDP:
Job Queued: A pipeline run triggers a job that requires a Managed DevOps Pool agent.
Pool Check: Azure DevOps checks the pool for an idle VM. If an idle VM is available, it assigns the job to that VM.
No Idle VM? Scale Up: If no idle VM exists and the pool hasn't reached its maximum size, Azure DevOps provisions a new VM using the defined image and configuration. This typically takes 2-5 minutes (depending on VM size and image complexity).
VM Provisioning: Azure DevOps creates the VM in your subscription, installs the agent software, and registers it with the pool.
Job Execution: The job runs on the VM. The agent executes tasks like dotnet build, npm install, or running tests.
Job Completion: After the job finishes, the VM is returned to the pool as idle (if the pool allows reuse) or is deleted (if the pool is configured to deprovision after each job). You can configure the pool to keep a certain number of idle VMs to reduce wait time for subsequent jobs.
Scale Down: If the number of idle VMs exceeds the configured maximum idle count for a set period (default: 30 minutes), Azure DevOps deletes the excess VMs to save cost.
Key Configuration Parameters
Maximum number of VMs: The total number of VMs that can be provisioned in the pool (default: 10, max: 1000).
Maximum number of idle VMs: The number of VMs to keep idle for immediate job assignment (default: 1).
Time to keep idle VMs: How long an idle VM stays before being deallocated (default: 30 minutes).
VM image: A custom image from Azure Compute Gallery or a managed image. The image must have the Azure Pipelines Agent installed and configured.
VM size: Any Azure VM size available in the region.
Subnet: The VNet subnet where VMs are deployed.
Agent specification: The agent version (e.g., 2.200.0).
Configuration and Verification Commands
To create a Managed DevOps Pool using Azure CLI:
az devops pool create --name MyPool \
--service-connection-id <service-connection-id> \
--max-vm-count 10 \
--max-idle-vm-count 2 \
--idle-vm-timeout 30 \
--vm-size Standard_D2s_v3 \
--image-reference /subscriptions/.../resourceGroups/.../providers/Microsoft.Compute/galleries/MyGallery/images/MyImage/versions/1.0.0 \
--subnet-id /subscriptions/.../resourceGroups/.../providers/Microsoft.Network/virtualNetworks/MyVNet/subnets/defaultTo list pools:
az devops pool listTo view pool details:
az devops pool show --pool-id <pool-id>Interaction with Related Technologies
Azure Compute Gallery: Used to store and version custom VM images. MDP uses these images to provision VMs. You can create a golden image with all required tools (e.g., Visual Studio, SDKs, security tools).
Azure Virtual Network: MDP VMs are deployed into your VNet, allowing them to access private resources (e.g., Azure SQL Database, on-premises servers) via private IPs.
Azure Key Vault: You can store secrets (e.g., service principal passwords) in Key Vault and access them from the agent using Managed Identity.
Azure Pipelines: The pipeline job definition references the pool by name. Example YAML:
pool:
name: MyPool
demands: Agent.OS -equals Windows_NTCost Considerations
You pay for the Azure VMs (compute, storage, networking) in your subscription. There is no additional Azure DevOps charge for using MDP beyond the standard Azure DevOps costs. However, you must have an Azure subscription with sufficient quota for the VM SKUs.
Limitations
MDP is only available for Azure DevOps Services, not for Azure DevOps Server.
VMs are provisioned in the same region as the Azure DevOps organization.
You cannot use MDP with Azure DevOps Server (on-premises).
The maximum number of VMs per pool is 1000.
The VM image must be prepared with the Azure Pipelines Agent installed. If not, the provisioning will fail.
Security Considerations
VMs run in your subscription, so you control network security groups (NSGs) and firewall rules.
The agent uses a service connection (Azure Resource Manager) to communicate with Azure DevOps. Ensure the service principal has appropriate permissions.
For sensitive workloads, use a private VNet and disable public IP addresses on the VMs (available in preview).
Create a Service Connection
Before you can create a Managed DevOps Pool, you need an Azure Resource Manager service connection in Azure DevOps that has permission to create VMs in your subscription. Go to Project Settings → Service Connections → New Service Connection → Azure Resource Manager. Choose either Service Principal (automatic) or Managed Identity. The service principal must have at least Contributor role on the resource group where VMs will be created. This connection is used by Azure DevOps to provision and manage VMs.
Create the Managed DevOps Pool
Navigate to Organization Settings → Agent Pools → Add Pool → Managed. Provide a name, select the Azure subscription and service connection, choose the VM image from Azure Compute Gallery, specify VM size, networking (VNet/subnet), and scaling limits (max VMs, max idle VMs, idle timeout). You can also set up agent specification (version). The pool will be created in a 'Provisioning' state. After a few minutes, it becomes 'Ready'.
Prepare a Custom VM Image
Create a VM in Azure, install all required software (e.g., .NET SDK, Node.js, Visual Studio Build Tools, security agents), and install the Azure Pipelines Agent. The agent must be configured to run as a service and to connect to the pool. Then, capture the VM as a managed image or add it to an Azure Compute Gallery. Ensure the image is generalized (sysprep for Windows, waagent -deprovision for Linux). The image must be in the same region as the Azure DevOps organization.
Configure Pipeline to Use Pool
In your Azure Pipeline YAML, set the pool name to the Managed DevOps Pool you created. Example: pool: name: MyManagedPool demands: Agent.OS -equals Linux When the pipeline runs, Azure DevOps will assign a VM from the pool. If no idle VM is available, it will provision a new one using the custom image. The job will execute on that VM, and after completion, the VM returns to the idle pool.
Monitor and Scale the Pool
Use the Azure DevOps portal to monitor pool utilization: number of busy VMs, idle VMs, and queued jobs. You can adjust scaling parameters (max VMs, idle count) dynamically. For cost optimization, set the idle timeout to a low value (e.g., 10 minutes) so that idle VMs are deallocated quickly. Use Azure Monitor to track VM costs and set budgets alerts.
Enterprise Scenario 1: Financial Services Compliance
A large bank needs to run CI/CD pipelines for a trading application. Compliance mandates that all build artifacts must be processed on VMs that are not shared with any other tenant. The bank also needs to install proprietary security scanning tools on the build agents. Using Microsoft-hosted agents is not possible because they are shared and cannot have custom software. Self-hosted agents would require the bank to manage patching, scaling, and high availability themselves. Managed DevOps Pools solve this: the bank creates a custom VM image with all security tools, deploys the pool into a private VNet with strict NSG rules, and sets scaling to a maximum of 5 VMs. The pool is configured to deprovision VMs after each job to ensure no data persists between runs. The bank pays only for the compute used. This setup meets compliance and reduces operational overhead by 70% compared to self-hosted agents.
Enterprise Scenario 2: Game Development with Large Assets
A game studio builds large Unity projects that require powerful VMs with GPU support. They need to use NV-series VMs with NVIDIA drivers. Microsoft-hosted agents do not offer GPU instances. The studio creates a Managed DevOps Pool with Standard_NC6s_v3 VMs, using a custom image that includes Unity, Visual Studio, and GPU drivers. The pool is configured with a maximum of 20 VMs and an idle timeout of 15 minutes. During a release, the pool scales up to 20 VMs, builds all platform targets in parallel, and then scales down. The studio saves costs by not paying for idle VMs. They also use a private VNet to access an on-premises license server for third-party tools.
Common Misconfigurations and Pitfalls
Image not prepared correctly: The most common issue is forgetting to install the Azure Pipelines Agent in the custom image. The pool provisioning will fail because the agent cannot register. Always test the image by creating a VM and manually running the agent.
Service connection permissions: If the service principal lacks Contributor role on the resource group, VM creation fails. Ensure the service connection is correctly scoped.
Quota limits: If you exceed your Azure VM quota for the chosen SKU, provisioning will fail. Request quota increases in advance.
Networking: If the VNet does not have outbound internet access (e.g., no NAT gateway), the agent cannot communicate with Azure DevOps. Use a NAT gateway or a proxy.
What AZ-204 Tests on Managed DevOps Pools
AZ-204 Objective 1.3: 'Create and manage Azure DevOps agents and pools.' The exam expects you to:
Differentiate between Microsoft-hosted, self-hosted, and Managed DevOps Pools.
Know when to use Managed DevOps Pools (custom images, isolation, VNet integration).
Understand the scaling behavior (idle VMs, maximum VMs, deprovision timeout).
Recognize the prerequisites (service connection, Azure Compute Gallery, custom image with agent installed).
Common Wrong Answers and Why Candidates Choose Them
'Managed DevOps Pools are free': Many candidates think MDP is included in Azure DevOps pricing. Wrong. You pay for the Azure VMs in your subscription. The management layer is free, but compute costs are incurred.
'You can use any VM image from the Azure Marketplace': While you can use Marketplace images, the exam emphasizes that you must prepare the image with the Azure Pipelines Agent. A raw Marketplace image will not work.
'Managed DevOps Pools are available for Azure DevOps Server': This is false. MDP is only for Azure DevOps Services (cloud). For on-premises, you must use self-hosted agents.
'Idle VMs are always kept for 30 minutes': The default is 30 minutes, but it is configurable. The exam might test that you can set it to any value (minimum 0, which means immediate deprovision after job).
Specific Numbers and Values to Memorize
Default maximum VMs per pool: 10 (configurable up to 1000).
Default idle VM count: 1.
Default idle VM timeout: 30 minutes.
VM provisioning time: 2-5 minutes.
Supported regions: Same as Azure DevOps organization region.
Prerequisite: Azure Resource Manager service connection with Contributor permissions.
Edge Cases and Exam Tricks
What if the custom image does not have the agent? Provisioning fails. The exam might present a scenario where the pool creation succeeds but no jobs run. The cause is the missing agent.
Can you use Managed DevOps Pools with Azure Pipelines in GitHub? Yes, MDP works with any Azure Pipeline, including those triggered from GitHub.
What happens if the pool reaches max VMs? New jobs are queued until a VM becomes idle. The exam might ask about job behavior when scaling limits are hit.
How to Eliminate Wrong Answers
If the question mentions 'custom software', 'private network', or 'compliance', the answer is likely Managed DevOps Pools or self-hosted. Choose MDP if the question also mentions 'automatic scaling' or 'no maintenance'.
If the question says 'no additional cost', eliminate MDP because VMs cost money.
If the question mentions 'on-premises', eliminate MDP because it requires Azure subscription.
Managed DevOps Pools run Azure Pipelines agents on Azure VMs in your own subscription, giving you control over the image, network, and scaling.
You must prepare a custom VM image with the Azure Pipelines Agent installed; otherwise, pool provisioning fails.
Default scaling: max 10 VMs, max 1 idle VM, idle timeout 30 minutes (all configurable).
MDP is only available for Azure DevOps Services, not Azure DevOps Server.
Use MDP when you need custom software, private network access, or compliance isolation.
You need an Azure Resource Manager service connection with Contributor permissions on the target resource group.
Costs are incurred for Azure VMs (compute, storage, networking) in your subscription.
Idle VMs are kept for a configurable timeout (default 30 min) before deprovisioning.
These come up on the exam all the time. Here's how to tell them apart.
Managed DevOps Pools
Runs in your Azure subscription; you pay for compute.
Custom VM images allowed (via Azure Compute Gallery).
Full admin access on VMs (install software, configure settings).
VNet integration for private resource access.
Scaling is automatic but configurable (max VMs, idle timeout).
Microsoft-Hosted Agents
Runs in Microsoft's subscription; no direct compute cost.
Predefined VM images only (Windows Server, Ubuntu, macOS).
No admin access; cannot install custom software.
No VNet integration; agents access internet only.
Scaling is automatic but not configurable; limited by Microsoft.
Managed DevOps Pools
Automatic provisioning and deprovisioning of VMs.
Automatic scaling based on configuration.
Agent software installed automatically from image.
VMs are ephemeral (data not persisted between jobs unless configured).
No manual patching; use updated images.
Self-Hosted Agents
Manual provisioning and deprovisioning of VMs or physical machines.
Scaling requires manual intervention or custom scripts.
Agent installation and configuration done manually.
VMs are persistent; data may linger unless cleaned.
Patching and maintenance are your responsibility.
Mistake
Managed DevOps Pools are free because they are part of Azure DevOps.
Correct
MDP incurs Azure compute costs for the VMs in your subscription. Azure DevOps does not charge extra for the pool management, but you pay for the underlying infrastructure.
Mistake
You can use any Azure VM image without modification.
Correct
The VM image must have the Azure Pipelines Agent installed and configured. A stock Marketplace image will not work because the agent is missing.
Mistake
Managed DevOps Pools are available for Azure DevOps Server (on-premises).
Correct
MDP is only available for Azure DevOps Services (cloud). For Azure DevOps Server, you must use self-hosted agents.
Mistake
Idle VMs are immediately deprovisioned after a job completes.
Correct
By default, idle VMs are kept for 30 minutes (configurable). They are only deprovisioned if they remain idle beyond the timeout or if the idle count exceeds the maximum.
Mistake
Managed DevOps Pools require a separate license.
Correct
No separate license is needed. You just need an Azure subscription and an Azure DevOps organization. The pool management is included with Azure DevOps.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, create a VM in Azure and install all required software. Then install the Azure Pipelines Agent (download from https://vstsagentpackage.azureedge.net/agent/...). Configure the agent to run as a service and register it with a pool (you can use a temporary pool). Generalize the VM (sysprep for Windows, waagent -deprovision for Linux). Capture the VM as a managed image or add it to Azure Compute Gallery. Finally, reference that image when creating the Managed DevOps Pool.
No. Managed DevOps Pools are specific to Azure Pipelines. GitHub Actions has its own self-hosted runner concept. However, you can use Azure Pipelines with GitHub as a source repository, and the pipeline can use a Managed DevOps Pool.
The maximum is 1000 VMs per pool. The default is 10. You can set it when creating the pool or update it later via the Azure DevOps portal or CLI.
Yes, but only if you provide a macOS VM image from Azure Compute Gallery. Azure supports macOS VMs (e.g., Standard_D2s_v3 on macOS). However, macOS images are not available in all regions.
Set a low idle timeout (e.g., 5 minutes) to deprovision idle VMs quickly. Use smaller VM sizes if adequate. Set a low maximum idle VM count (e.g., 0) to avoid keeping idle VMs. Use Azure Reservations for predictable workloads to get discounts on VM costs.
No. Managed DevOps Pools are a feature of Azure DevOps Services (cloud). For Azure DevOps Server, you must use self-hosted agents installed on your own machines or VMs.
You need to create a new image version and update the pool to reference the new image. Existing VMs will continue using the old image until they are deprovisioned. New VMs will use the updated image. You can force deprovision all VMs by scaling the pool down to 0.
You've just covered Managed DevOps Pools for Azure DevOps — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?