--- title: "Azure DevOps: Fix \"Acquiring an agent from the cloud\"" description: "Stuck on \"Acquiring an agent from the cloud\"? Check pool saturation, parallel job ceilings, VNet permissions, and blocked egress before editing YAML." canonical: "https://adamtheautomator.com/acquiring-agent-from-cloud-azure-devops/" --- # Azure DevOps: Fix "Acquiring an agent from the cloud" > Stuck on "Acquiring an agent from the cloud"? Check pool saturation, parallel job ceilings, VNet permissions, and blocked egress before editing YAML. Source: https://adamtheautomator.com/acquiring-agent-from-cloud-azure-devops/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![Azure DevOps: Fix "Acquiring an agent from the cloud"](https://adamtheautomator.com/wp-content/uploads/publisher/4065d9c85b2b812bbb79d18090b8cf1a/5c974fd06f45af85a7518ad43dc562c6698da0193a329039cdfb527daac90167.webp) # Azure DevOps: Fix "Acquiring an agent from the cloud" [![](https://secure.gravatar.com/avatar/d0b9d42e21e5622713f8b693aa5c0f9244d5f7dd200ed29b8398f52dee5de337?s=192&d=mm&r=g)Adam Bertram](https://adamtheautomator.com/author/adam-bertram/)2 November 202613 min. read Categories: [DevOps](/category/devops/) Tags:[Azure](/tag/azure/)[Azure Pipelines](/tag/azure-pipelines/)[Azure Monitor](/tag/azure-monitor/)[Azure CLI](/tag/azure-cli/)[DevOps](/tag/devops/) Table of Contents * [What “Acquiring an agent from the cloud” Actually Means](#what-acquiring-an-agent-from-the-cloud-actually-means) * [Copy the Request Identifier Before Anything Else](#copy-the-request-identifier-before-anything-else) * [Read the Queue State Before You Change Anything](#read-the-queue-state-before-you-change-anything) * [Cause 1: Parallel Jobs and Maximum Agents Are Separate Ceilings](#cause-1-parallel-jobs-and-maximum-agents-are-separate-ceilings) * [Read the Agent Inventory Against Both Ceilings](#read-the-agent-inventory-against-both-ceilings) * [Cause 2: An Image Demand No Idle Agent Can Satisfy](#cause-2-an-image-demand-no-idle-agent-can-satisfy) * [When the Image Demand Exceeds the Image on Disk](#when-the-image-demand-exceeds-the-image-on-disk) * [Cause 3: VNet Injection Fails Before the VM Ever Boots](#cause-3-vnet-injection-fails-before-the-vm-ever-boots) * [Roles, Delegation, and the Address Space](#roles-delegation-and-the-address-space) * [Cause 4: The Subnet Cannot Reach the Agent Binaries](#cause-4-the-subnet-cannot-reach-the-agent-binaries) * [Validate From Inside the Subnet](#validate-from-inside-the-subnet) * [Cause 5: Azure Capacity and the SKU You Pinned](#cause-5-azure-capacity-and-the-sku-you-pinned) * [Cause 6: A Canceled Build Leaves an Orphaned Request](#cause-6-a-canceled-build-leaves-an-orphaned-request) * [A Ten-Minute Diagnostic Sequence](#a-ten-minute-diagnostic-sequence) * [Making the Next Queue Wait Shorter](#making-the-next-queue-wait-shorter) * [What to Do in the Next Fifteen Minutes](#what-to-do-in-the-next-fifteen-minutes) Your deploy job has been sitting on “Acquiring an agent from the cloud” for twenty-two minutes. The pipeline status says running, but no agent has picked up the work, no log lines are scrolling, and the only thing moving is the elapsed timer climbing toward the platform timeout. You open a second tab, confirm the code is fine, and start wondering whether the fix is a YAML change, a pool setting, or a support ticket. The platform prints “Acquiring an agent from the cloud” while the job request moves through several systems, each of which fails in a different way. The job can be waiting on Azure DevOps parallel jobs, on pool capacity, on a virtual network that will not delegate, on a subnet that cannot reach a download endpoint, or on a lease left behind by a build someone canceled an hour ago. This guide walks you through that same sequence, starting with the line your console printed: read the queue state, name the failing system, and only then change something. ## What “Acquiring an agent from the cloud” Actually Means Three console variants reach the same pipeline log, and engineers report all three in Microsoft Q&A threads rather than in the product documentation. The bare “Acquiring an agent from the cloud” means the job exists in the queue but has not been matched to a pool provider. The longer form, “Acquiring an agent from the cloud: We are provisioning an agent for request ``”, means a pool accepted the job and is building a machine for it, as [a Q&A thread on a VNet-integrated pool](https://learn.microsoft.com/en-us/answers/questions/5607779/azure-managed-pools-with-vnet-integration-agent-fa) reports. A third variant, “Pool provider seems slow, we notified pool provider at ``”, means the provider acknowledged the request and is still working, which is the line quoted in [a Q&A thread on a 45-minute acquisition timeout](https://learn.microsoft.com/en-us/answers/questions/5979523/pipeline-stuck-at-acquiring-an-agent-from-the-clou). ### Copy the Request Identifier Before Anything Else Those three lines point at three different subsystems, so the first diagnostic step is copying the full line, including any request identifier and timestamp. The request identifier is the thread that ties the pipeline console to the pool’s own telemetry, and it is the only value that survives when the console shows a generic timeout. * * * _**Reality Check: Waiting is the right move while a cold start is still inside its documented ceiling and the wrong move once the job outlives it. A healthy cold start finishes in minutes, and a queue past the ceiling never resolves itself.**_ * * * Microsoft documents the normal case plainly. In the [Managed DevOps Pools troubleshooting guide](https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/troubleshooting?view=azure-devops), the standby agent section states: “If Standby agent mode is disabled, Managed DevOps Pools agents are started on demand when a pipeline is queued, and while typically a fresh agent takes only a few moments to start, sometimes it can take up to 15 minutes.” Fifteen minutes of on-demand provisioning is the documented ceiling for a cold machine. A job still queued after that has crossed from slow to broken. ## Read the Queue State Before You Change Anything Two data sources decide most cases: how many jobs the organization may run, and what the pool is doing with the requests it received. Azure DevOps answers the first, Managed DevOps Pools metrics answer the second. Start with the jobs queued or running now. The Azure CLI reports them per project. Queue time is the number that matters: a job queued eighteen minutes ago with no start time is a capacity problem, not a code problem. ```bash # table output drops a column named id, so the alias keeps the run identifier visible; --output json shows it either way az pipelines runs list \ --project "$PROJECT" \ --status inProgress \ --top 50 \ --query "[].{runId:id,pipeline:definition.name,queued:queueTime}" \ --output table ``` Then read the pool’s saturation metrics from the resource. `Demand` is the total active demand on the pool, `Ready` is the count of agents waiting for work, and `Starting` is the count of machines coming up. A pool with `Demand` at 12, `Ready` at 0, and `Starting` at 0 has nothing coming up, so the request will sit there. The metric names come from the [Managed DevOps Pools monitoring reference](https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/monitor-pool?view=azure-devops), which lists `AllocationDurationMs` alongside `Demand`, `Ready`, `Allocated`, `NotReady`, `Starting`, and `Provisioned`. The chart below tracks those metrics during a stall. ![Flat 2D line chart of pool saturation during a stuck queue](https://adamtheautomator.com/wp-content/uploads/publisher/d60f700766efa96477e62e23324c17be4fe5f71cfa7f3e017d3a59c38a6799dd.png) _Stalled pool saturation_ ```bash az monitor metrics list \ --resource "$POOL_RESOURCE_ID" \ --metric "Demand,Ready,Starting,Allocated,NotReady" \ --interval PT1M \ --aggregation Maximum \ --query "value[].{metric:name.localizedValue,latest:timeseries[0].data[-1].maximum}" \ --output table ``` A `Demand` line that stays above zero while `Starting` stays at zero describes a request the pool cannot satisfy. That is the moment to stop reading logs and start checking the two ceilings below. ## Cause 1: Parallel Jobs and Maximum Agents Are Separate Ceilings Managed DevOps Pools agents count as self-hosted agents to Azure DevOps, so every running job consumes a self-hosted parallel job. The organization’s parallel job count is a licensing limit, and it is completely independent of the pool’s own size. Microsoft’s guide spells out both limits with a concrete number: “For example, if your organization’s self-hosted parallel count is 10, your organization can run only 10 self-hosted pipeline jobs concurrently. If more than 10 pipelines are queued, only 10 at a time can run.” The pool has its own ceiling. “The **Maximum agents** setting configures the maximum count of running agents in your Managed DevOps Pool. If the **Maximum agents** setting is 5, Managed DevOps Pools can run a maximum of five concurrent pipelines.” The two limits have different owners. An engineer raises `Maximum agents` to 20, sees no improvement, and never checks the [parallel jobs licensing page](https://learn.microsoft.com/en-us/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops) that governs the other number. | Ceiling | What it limits | Where you change it | | --- | --- | --- | | Self-hosted parallel jobs | Concurrent jobs the organization may run | Organization-level parallel job settings, shared by every project | | `Maximum agents` | Running agents inside one Managed DevOps Pool | Pool settings | This article covers an execution that never starts; the [guide to idle agents and queue stalls](https://adamtheautomator.com/azure-devops-idle-agents-queue-stalls/) covers the pool once agents are running. ### Read the Agent Inventory Against Both Ceilings The agent inventory shows whether the pool is full. Passing `--include-assigned-request true` makes idle and busy agents distinguishable in one command. ```bash az pipelines agent list \ --pool-id "$POOL_ID" \ --include-assigned-request true \ --query "[].{name:name,status:status,assigned:assignedRequest.jobId}" \ --output table ``` If every agent reports `online` with an `assignedRequest` and the queue still grows, the pool is saturated and the fix is capacity, either more maximum agents or fewer concurrent jobs. If agents report `offline` while holding an assigned request, read the next two sections, because the pool is not doing what its size suggests. An `offline` agent with no assignment is a different condition: that machine is stopped, so the queue is short of agents rather than short of a matching request. ## Cause 2: An Image Demand No Idle Agent Can Satisfy Stateful pools reuse agents between jobs to keep caches and build output on disk. That saving turns into the trap once the pool hits its maximum. Microsoft defines the mechanism in the [scaling documentation](https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/configure-scaling?view=azure-devops): “**Grace Period** (`gracePeriodTimeSpan`) configures the amount of time an agent in a stateful pool waits for new jobs before shutting down after all current and queued jobs finish.” ### When the Image Demand Exceeds the Image on Disk Combine that grace period with a pool at its maximum. Suppose eight stateful agents are idle with Ubuntu 22.04 on disk and someone moves the pipeline to Ubuntu 24.04. The orchestrator cannot dispatch the job to those eight agents because their image does not satisfy the demand. It also cannot build a ninth agent because the pool already holds its maximum. The idle agents keep their slots until the grace period expires, so the job waits out the entire grace window on a machine it will never use. * A warm agent that does not match the job’s image is capacity you cannot spend until the grace window expires. Cloud providers call this a demand mismatch; platform teams experience it as a mystery, and the [Developer Community report on Managed DevOps Pools acquisition delays](https://developercommunity.microsoft.com/t/11107372) shows the same symptoms in the wild. The evidence is in the pool’s state metrics: `NotReady` climbing while `Allocated` stays flat, and `TimeSpentInPreviousStateMs` showing long durations against the `PreviousState` and `NewState` dimensions. The fastest correction is shortening the grace period while the image transition is in flight, and then restoring it. A pool that keeps eight warm agents overnight and switches base images every quarter should schedule that switch as a maintenance window. Re-run the job after the grace window closes. A start on the new image, with `NotReady` falling back to zero, confirms the mismatch was the cause. ## Cause 3: VNet Injection Fails Before the VM Ever Boots When a pool injects agents into your own virtual network, provisioning fails before a VM ever boots, and Microsoft documents the failure as a pool creation error with a code that almost nobody reads. Microsoft’s guide publishes the exact failure: `Validation failure "UnauthorizedAccessToVirtualNetwork": "DevOpsInfrastructure service principal does not have Read access to virtual network in resource group . Give Reader and Network Contributor access to DevOpsInfrastructure service principal and try again."` The identity in that message is a Microsoft-managed service principal that appears in your tenant for Managed DevOps Pools. It is not your deployment service principal, and granting your own pipeline identity network rights does nothing for it. Find it by display name, then list what it actually holds at the virtual network scope. ```bash SP_ID=$(az ad sp list --filter "displayname eq 'DevOpsInfrastructure'" --query "[0].id" --output tsv) az role assignment list \ --assignee "$SP_ID" \ --scope "$VNET_ID" \ --include-inherited \ --query "[].{role:roleDefinitionName,scope:scope}" \ --output table ``` `--include-inherited` adds the assignments the principal inherits from the subscription; drop the flag to see only the roles granted on the virtual network itself. ### Roles, Delegation, and the Address Space Three conditions must all be true before provisioning proceeds, and each fails silently in its own way. * The identity needs both roles on the virtual network. The [networking configuration guide](https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/configure-networking?view=azure-devops) states that “the `DevOpsInfrastructure` principal has `Reader` and `Network Contributor` access on the virtual network,” which is the pair the failure message above asks you to grant. * The subnet must be delegated to the pool. The same guide requires delegation to `Microsoft.DevOpsInfrastructure/pools`, and that delegation grants exclusive use: “The preceding steps delegate the subnet for exclusive access by the pool. Other pools or resources can’t use the subnet.” * The network must share the pool’s region and avoid the block Microsoft reserves for its own control plane. Delegation is also a lock on the address space, so a subnet your security team later hands to a firewall appliance will stop provisioning with no obvious relationship to the change. The reserved block carries the same kind of trap. Microsoft warns: “Managed DevOps Pools uses the `172.17.0.0/16` IP address range for its internal operations. Don’t choose this range for your VNET.” When a peered network or a private endpoint uses that range inside your own network, the agent resolves the control plane into the local route table and the connection fails with `dial tcp 172.17.x.x:443: connect: no route to host`. ```bash az network vnet subnet show \ --resource-group "$RG" \ --vnet-name "$VNET" \ --name "$SUBNET" \ --query "{prefix:addressPrefix,delegation:delegations[0].serviceName}" \ --output json ``` A `null` delegation or a nonempty `ipConfigurations` array on that subnet is enough to block every pool that targets it. Fixing it takes minutes; finding it without the delegation check takes an afternoon. ## Cause 4: The Subnet Cannot Reach the Agent Binaries The machine can be allocated, booted, and still useless, because the agent has to download its own binaries before it can register. When egress is blocked, the pool reports `UnableToDownloadWorkerCheckNetwork` or an endpoint-qualified variant, and Microsoft’s [error code reference](https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/monitor-pool?view=azure-devops) defines that family as “The Network infrastructure is blocking access to one of the prerequisite endpoints.” The TLS-specific variant, `UnableToDownloadWorkerCheckNetwork_TLSIssue`, means “TLS Handshake failed when contacting prerequisite endpoints,” which is usually [a proxy performing inspection](https://adamtheautomator.com/azure-devops-pipeline-down-troubleshooting-guide/) rather than a missing allowlist entry. ### Validate From Inside the Subnet Microsoft publishes a validation script for exactly this test. `ValidateMDPEndpoints.ps1`, documented in the networking guide, must run from a machine attached to the same subnet as the pool. From your laptop the result describes your laptop. The documented dependencies include the control plane and the agent download path: | Endpoint | Purpose | | --- | --- | | `*.prod.manageddevops.microsoft.com` | Managed DevOps Pools control plane | | `rmprodbuilds.azureedge.net` | Worker binaries and initialization scripts | | `*.queue.core.windows.net` | Worker queue communication | | `download.agent.dev.azure.com` | Azure DevOps agent download | | `dev.azure.com` | Agent registration | The diagram below maps the path those endpoints define, from the agent’s first control-plane call to the final binary download. ![Left-to-right agent egress path with a blocked endpoint](https://adamtheautomator.com/wp-content/uploads/publisher/717f5db1eab144de0f98aa5bbf3edee7e8bb96aa5a6410233a10ada7070089dd.png) _Blocked egress path_ The complete list, including the operating system package repositories that Linux images need over HTTP port 80, lives in [Microsoft’s outbound connectivity guidance](https://aka.ms/mdp-network-outbound-connectivity). Azure service tags alone do not cover these hosts, because the list mixes Microsoft control plane endpoints with CDN and distribution repositories. One more failure hides here. Even with DNS resolving and TCP connecting, the request can die at exactly 100 seconds. The error code `TaskCanceled` is defined as “The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.” A firewall rule that allows the destination but throttles or inspects the transfer produces a timeout that looks nothing like a blocked port. ## Cause 5: Azure Capacity and the SKU You Pinned Some stuck queues are Azure capacity: the region can simply have nowhere to put the machine. The error codes separate the cases: `ClusterOutOfCapacity` means the clusters mapped to your subscription are full, `ConstraintsCannotBeAllocated` means the request was too restrictive, and `SkuNotAvailable` means the region has no capacity for that specific size. Microsoft’s definition for the constraint case is blunt: “Allocation failed. VM(s) with the following constraints cannot be allocated, because the condition is too restrictive. Please remove some constraints and try again.” The [pool settings documentation](https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/configure-pool-settings?view=azure-devops) describes the mitigation: “Managed DevOps Pools supports up to five agent sizes per pool by using Instance mix.” A pool that offers one size fails when that size is unavailable in the region; a pool that offers three compatible sizes gets scheduled on whichever one has capacity. Instance mix is the difference between a capacity incident and a 20-minute delay. Re-run the failed job and watch `Demand` fall while `Allocated` rises; if the queue clears, the SKU constraint was the cause. ## Cause 6: A Canceled Build Leaves an Orphaned Request [Canceling a run does not always free its agent slot](https://adamtheautomator.com/azure-devops-idle-agents-queue-stalls/). That guide follows the same lease from the pool side; here the question is why the console line never advances. The [Microsoft Q&A thread on permanently stuck hosted agents](https://learn.microsoft.com/en-us/answers/questions/5793414/microsoft-hosted-agents-permanently-stuck-orphaned) documents a community-reported incident pattern: a YAML stage carrying `condition: always()` still queues an agent request after the parent run transitions to canceled, and the dispatcher holds that request against pool capacity, attached to an agent that will never come online. Reporters in that thread describe waits of roughly 45 minutes. But no Managed DevOps Pools page states a lease duration for this case, so treat the figure as a reported observation rather than a documented limit. The thread also reports that `jobCancelTimeoutInMinutes` does not shorten the wait, because the setting applies to a job that is already running rather than to a request still waiting for an agent. On a pool with a maximum of one agent, or on a free tier with a single parallel job, one canceled run blocks every pipeline in the organization for the rest of the lease. The only reliable recovery is waiting it out, which is why the symptom is worth knowing before anyone spends a day on YAML that was never the problem. ## A Ten-Minute Diagnostic Sequence The order below moves from cheapest to most expensive, follows the sequence a job request travels before an agent starts, and produces evidence you can attach to a support case. The [pipeline start troubleshooting guide](https://learn.microsoft.com/en-us/azure/devops/pipelines/troubleshooting/troubleshoot-start?view=azure-devops) covers the agent-side failures that show up once a request does reach an agent. | Cause | Primary trace | Section | | --- | --- | --- | | Parallel jobs exhausted | Queue time with no start time | Cause 1 | | Image demand mismatch | `NotReady` climbing, `Allocated` flat | Cause 2 | | Virtual network permission or delegation | `UnauthorizedAccessToVirtualNetwork` | Cause 3 | | Blocked egress | `UnableToDownloadWorkerCheckNetwork` | Cause 4 | | Azure capacity or pinned SKU | `ClusterOutOfCapacity`, `SkuNotAvailable` | Cause 5 | | Orphaned request after a canceled run | Request held past the run’s end | Cause 6 | 1. Copy the full queue line, with the request identifier and timestamp, from the pipeline log. 2. Compare the queued job count against self-hosted parallel jobs and `Maximum agents`. 3. Query `Demand`, `Ready`, `Starting`, `Allocated`, and `NotReady` across the last hour. 4. List agents with assigned requests, then check for idle agents that cannot satisfy the image demand. 5. Read the pool overview’s error code and failure stage for that request. 6. If an error code names a virtual network, verify roles, delegation, region, and the reserved range. 7. If the code names a download or setup failure, run `ValidateMDPEndpoints.ps1` from the pool’s own subnet. Steps two through five take about four minutes and resolve most cases before anyone touches a network rule. * * * _**Pro Tip: Run the endpoint validation from a jump host in the same subnet, not from your workstation. The script’s result describes only the route, proxy, DNS, and firewall path that the agent will actually traverse.**_ * * * ## Making the Next Queue Wait Shorter A pool that always has one warm agent via a [standby agent schedule](https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/configure-scaling?view=azure-devops#standby-agent-mode) absorbs a burst that would otherwise spend fifteen minutes on a cold start, and [Microsoft’s troubleshooting guide recommends the conservative path for new pools](https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/troubleshooting?view=azure-devops): use manual standby mode for the first month, then switch to automatic once usage history exists, because the automatic model needs that history to forecast. The same guide’s standby percentage advice applies to mixed-image pools: if 75 percent of jobs use the Windows image, that image’s standby percentage should be 75, or the pool keeps warming the wrong machine. Alerting closes the remaining gap. An alert on `AllocationDurationMs` above your acceptable queue time, and on `Demand` exceeding `Ready` plus `Starting` for more than ten minutes, converts a silent queue into a page. Both metrics exist in the pool’s namespace and stream to Azure Monitor, so the alert is a metric alert rather than a custom query. Capacity planning deserves one number on a dashboard: peak concurrent jobs against purchased parallel jobs. The two ceilings from Cause 1 drift apart quietly, and the drift always shows up as a queue rather than as an error. ## What to Do in the Next Fifteen Minutes If a job is stuck right now, read the full queue line first, then check parallel jobs and `Maximum agents`, then the pool’s error code for that request. Those three reads separate a capacity problem from a provisioning problem, and the error code tells you which. * A virtual network error sends you to roles, delegation, and the `172.17.0.0/16` range. * A download or setup error sends you to egress, with `ValidateMDPEndpoints.ps1` run from the pool’s own subnet. * A capacity error sends you to instance mix instead of a retry against the same SKU. When the code names no cause, walk the [documented agent start sequence](https://learn.microsoft.com/en-us/azure/devops/pipelines/troubleshooting/troubleshoot-start?view=azure-devops) one phase at a time and compare each phase with the pool’s most recent state change. Six conditions share one sentence in the platform output, and each leaves a distinct trace: a metric, an error code, or a role assignment. Those traces are readable in minutes once you know which one to ask for. None of the checks above require a support ticket. And most of them don’t even require a pipeline edit. The Azure CLI commands in this article were checked against Azure CLI 2.85.0 with the `azure-devops` extension 1.0.8, and the vendor statements were checked against the Microsoft Learn Managed DevOps Pools pages as published in October 2026. Share this article [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fadamtheautomator.com%2Facquiring-agent-from-cloud-azure-devops%2F&text=Azure%20DevOps%3A%20Fix%20%22Acquiring%20an%20agent%20from%20the%20cloud%22)[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fadamtheautomator.com%2Facquiring-agent-from-cloud-azure-devops%2F)[Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fadamtheautomator.com%2Facquiring-agent-from-cloud-azure-devops%2F) ## Related Posts ![](https://adamtheautomator.com/wp-content/uploads/publisher/4065d9c85b2b81efa4f7fcb198951a15/ba17f0bdb02d3ab988d2a22cae0caed456e4fdcb8e356215804b14c1b3d34c38.jpg) ### [Force Security Scans with Azure DevOps Extends Templates](/force-security-scans-azure-devops-templates/) Enforce Azure DevOps security scans with an extends template that fails the build and a Required template check on the service connection. ![](https://adamtheautomator.com/wp-content/uploads/publisher/2e05d9c85b2b819f93afc24ff9cf331a/cc243abf3399435c522e346ae33dfd425022d22b25c2f30ec3f4222e9b893e33.webp) ### [Azure DevOps Agent Pools: Fix Idle Agents and Queue Stalls](/azure-devops-idle-agents-queue-stalls/) Diagnose idle Azure DevOps agents blocking your queue: check parallel jobs, agent demands, stuck leases, and pool scaling before you rebuild a pool. ![](https://adamtheautomator.com/wp-content/uploads/2026/03/featured_image.webp) ### [Prove Every Artifact: Supply Chain Security in Azure DevOps](/supply-chain-security-azure-devops/) Learn to implement software supply chain security in Azure DevOps with SBOM generation, artifact signing, dependency scanning, and deployment gate enforcement. ## Categories * [IT Ops](/category/it-ops/) * [Cloud](/category/cloud/) * [DevOps](/category/devops/) * [Home Ops](/category/home-ops/) * [Information Security](/category/infosec/) * [Software Development](/category/software-development/) ## Site * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Copyright 2026© ATA Learning | [Privacy Policy](/privacy/)