Learn how to query Azure DevOps in a practical way: list YAML pipelines, inspect repository files, and review users or groups using Azure CLI, REST API, and PowerShell. This guide focuses on real administration, audit, and troubleshooting tasks.

Azure DevOps CLI and REST API Pipelines Repos Access review Checked: 27 June 2026

Azure DevOps Queries: Pipelines, Repos and Users

Azure DevOps queries are useful when you need to understand how a project is really wired together: which YAML pipelines exist, where pipeline files live, which repositories are active, and which users or groups have access.

This updated guide keeps the workflow practical and readable. It uses the Azure DevOps CLI where it is simple, and the REST API where the CLI is either limited or not the cleanest option.

Quick answer When to use Setup Query pipelines Query repos and files Query users and groups PowerShell script Common mistakes Useful links

Quick answer

Use Azure DevOps queries when you need a reliable view of your delivery platform without clicking through every project, repository, or pipeline manually.

Find YAML pipelinesList pipeline names, IDs, folders and YAML file paths across a project.
Inspect repository filesFind pipeline YAML files, templates, scripts and configuration paths in Azure Repos.
Audit users and groupsReview users, access levels, groups and membership data for governance checks.
Simple rule: use Azure CLI for quick one-off queries, REST API for repeatable reporting, and PowerShell when you want a reusable admin script.

Why Azure DevOps queries matter

In small projects, it is usually easy to find a pipeline or repository manually. In larger Azure DevOps organisations, the same task becomes harder. Projects grow, repositories multiply, YAML templates move, and access is often inherited through groups.

That is where queries become useful. They give you a faster way to answer practical platform questions:

  • Which pipelines are YAML-based?
  • Where are the pipeline YAML files stored?
  • Which repositories contain deployment templates or scripts?
  • Who has access to the organisation or project?
  • Which groups exist and may be used for permissions?
  • Which results should be exported for review, migration, or audit?
Important: querying Azure DevOps is not the same as changing Azure DevOps. Start read-only, confirm the result shape, and only then build remediation scripts.

Setup and authentication

Microsoft documents the Azure DevOps extension as the Azure CLI command extension for Azure DevOps Services. It supports commands such as az pipelines, az repos, az devops user, and az devops invoke.

Install and configure Azure DevOps CLI

az extension add --name azure-devops
az extension update --name azure-devops
az devops configure --defaults organization=https://dev.azure.com/<organization> project=<project>

Authenticate safely

For quick local administration, a PAT is still common. However, Microsoft recommends using Microsoft Entra tokens for new integrations where possible, and using PATs sparingly. If you use a PAT, keep the scope narrow and avoid hardcoding it in scripts.

$env:AZURE_DEVOPS_EXT_PAT = "<your-pat>"
az devops configure --defaults organization=https://dev.azure.com/<organization> project=<project>
TaskTypical minimum permissionNotes
List pipelines Pipelines or Build: Read Use for pipeline inventory and migration checks.
Read repository files Code: Read Needed to inspect YAML, templates, scripts and repository items.
List users and groups Graph/User read access Often requires organisation-level visibility or admin rights.
Run broad audit reports Read-only access across target projects Prefer a dedicated automation identity for repeatable reporting.

Query Azure Pipelines

Microsoft’s Azure DevOps CLI includes the az pipelines command group for managing pipelines. For inventory work, start with az pipelines list and then use REST API when you need paging, richer output, or automation-friendly processing.

List pipelines with Azure CLI

az pipelines list --query "[].{Name:name, Id:id, Folder:folder, Revision:revision}" -o table
az pipelines show --id <pipeline-id> -o json

Filter YAML pipelines with Azure CLI

az pipelines list \
  --query "[?configuration.type == 'yaml'].{Name:name, Id:id, Folder:folder, Yaml:configuration.yamlFilename}" \
  -o table

List pipelines with REST API and PowerShell

The Azure DevOps Pipelines REST API supports listing pipelines with GET https://dev.azure.com/{organization}/{project}/_apis/pipelines?api-version=7.1. This is the more reliable approach when building reusable reports.

$pat = $env:AZDO_PAT
$organization = "<organization>"
$project = "<project>"

$headers = @{
  Authorization = "Basic " + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat"))
}

$uri = "https://dev.azure.com/$organization/$project/_apis/pipelines?api-version=7.1"
$pipelines = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get

$pipelines.value | Select-Object name, id, folder, @{Name="Yaml";Expression={$_.configuration.yamlFilename}}
Practical tip: always capture the pipeline ID as well as the name. Pipeline names can change, but the ID is what you usually need for follow-up API calls.

Query repositories and files

Use az repos for repository-level queries, then use the Git Items REST API to list or retrieve files. This avoids relying on CLI commands that do not expose every file-query scenario cleanly.

List repositories

az repos list --query "[].{Name:name, Id:id, DefaultBranch:defaultBranch}" -o table
az repos show --repository <repo-name> -o json

List files under a folder with REST API

Microsoft’s Git Items API can list files and folders from a repository. Use scopePath to target a folder and recursionLevel when you need nested results.

$uri = "https://dev.azure.com/$organization/$project/_apis/git/repositories/$repoId/items?scopePath=/pipelines&recursionLevel=Full&api-version=7.1"
$items = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get

$items.value |
  Where-Object { $_.gitObjectType -eq "blob" } |
  Select-Object path, objectId

Get the content of a YAML file

$filePath = "/azure-pipelines.yml"
$encodedPath = [System.Web.HttpUtility]::UrlEncode($filePath)
$uri = "https://dev.azure.com/$organization/$project/_apis/git/repositories/$repoId/items?path=$encodedPath&includeContent=true&api-version=7.1"
$file = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
$file.content
Correction from many older examples: repository refs are branches and tags, not repository file listings. To inspect files, use the Git Items REST API or az devops invoke against the Git Items endpoint.

Query users, groups and access

Access review is one of the most useful reasons to query Azure DevOps. The CLI is good for a quick user list, while the Graph REST API is better for scripted user and group inventory.

List users with Azure CLI

az devops user list --query "members[].{DisplayName:user.displayName, Mail:user.mailAddress, AccessLevel:accessLevel.licenseDisplayName}" -o table

List users with Graph REST API

Microsoft’s Graph Users API returns users in pages, so proper production scripts should handle continuation tokens for large organisations.

$uri = "https://vssps.dev.azure.com/$organization/_apis/graph/users?api-version=7.1-preview.1"
$users = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
$users.value | Select-Object displayName, mailAddress, principalName, descriptor

List groups with Graph REST API

$uri = "https://vssps.dev.azure.com/$organization/_apis/graph/groups?api-version=7.1-preview.1"
$groups = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
$groups.value | Select-Object displayName, principalName, descriptor
Governance angle: user and group queries are especially useful before a project migration, tenant clean-up, security review, or DevOps maturity assessment.

PowerShell script: list YAML pipelines in a project

This script lists YAML pipelines in a single Azure DevOps project. It returns the pipeline name, ID, folder and YAML file path. It intentionally stays read-only.

param(
    [Parameter(Mandatory = $true)]
    [string]$Organization,

    [Parameter(Mandatory = $true)]
    [string]$Project,

    [Parameter(Mandatory = $true)]
    [string]$Pat
)

$baseUrl = "https://dev.azure.com/$Organization/$Project"
$headers = @{
    Authorization = "Basic " + [Convert]::ToBase64String(
        [Text.Encoding]::ASCII.GetBytes(":$Pat")
    )
}

function Invoke-AzDoGet {
    param([Parameter(Mandatory = $true)][string]$Uri)

    Invoke-RestMethod -Uri $Uri -Headers $headers -Method Get
}

$pipelinesUri = "$baseUrl/_apis/pipelines?api-version=7.1"
$pipelines = Invoke-AzDoGet -Uri $pipelinesUri

$pipelines.value |
    Where-Object { $_.configuration.type -eq "yaml" } |
    Select-Object `
        @{Name="PipelineName"; Expression={$_.name}},
        @{Name="PipelineId"; Expression={$_.id}},
        @{Name="Folder"; Expression={$_.folder}},
        @{Name="YamlPath"; Expression={$_.configuration.yamlFilename}} |
    Sort-Object PipelineName |
    Format-Table -AutoSize

Run the script

$pat = Read-Host "Azure DevOps PAT" -AsSecureString
$plainPat = [Runtime.InteropServices.Marshal]::PtrToStringAuto(
    [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pat)
)

.\List-YamlPipelines.ps1 -Organization "contoso" -Project "platform" -Pat $plainPat

Example output

PipelineName       PipelineId  Folder        YamlPath
------------       ----------  ------        --------
Build-WebApp       12          \\Apps        /pipelines/build-webapp.yml
Deploy-Platform    34          \\Platform    /deploy/platform.yml
Do not hardcode PATs. Use environment variables, a secure prompt, a secret store, or a managed authentication pattern depending on where the script runs.

Common mistakes

MistakeWhy it mattersBetter approach
Hardcoding PATs Secrets can leak through Git, logs, screenshots or command history. Use Microsoft Entra auth where possible, or store PATs securely with minimal scope and short lifetime.
Using preview API versions forever Preview APIs can change and may not be ideal for long-lived scripts. Use stable api-version=7.1 where available; use preview only where the endpoint requires it.
Assuming CLI output has every property CLI commands may simplify or omit fields that are present in REST responses. Use REST API for reporting where you need full object details.
Ignoring paging and continuation tokens Large organisations may return partial results only. Check API docs for continuation tokens and loop until all results are returned.
Confusing branches with files Refs APIs are not file-tree APIs. Use Git Items API for file paths and content.

Final view: Azure DevOps queries are not just a scripting trick. They help you understand the real state of a project: pipelines, repositories, YAML files, users, and groups. Start with read-only queries, validate the results, then turn the useful ones into reusable reports or governance scripts.