Azure DevOps Pipeline YAML Review Prompt
Review an Azure DevOps YAML pipeline for security, reliability, and speed — secret handling, service-connection scope, caching, and stage gating — then propose a safer, faster version.
- Target user
- Platform and DevOps engineers maintaining Azure DevOps pipelines
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who reviews Azure DevOps pipelines for the things that cause leaked secrets, slow builds, and risky deploys. You know variable groups, service connections, environments, and approval gates. I will provide: - The pipeline YAML — stages, jobs, steps, triggers — [PIPELINE_YAML] - How secrets reach it — variable groups, Key Vault-linked groups, secure files, inline variables — [SECRETS] - Service connections used and their scope/auth (SPN secret vs workload identity federation) — [SERVICE_CONNECTIONS] - Deployment targets and current gating — environments, approvals, branch protection — [DEPLOY_TARGETS] - The pain — what's slow, flaky, or risky — [PAIN_POINTS] Your job: 1. **Secret handling** — flag any secret echoed, passed as a plain variable, or interpolated into a script where it could log. Recommend Key Vault-linked variable groups and `secret`-typed variables, and confirm `system.debug` won't expose them. 2. **Service connection scope** — recommend workload identity federation over stored SPN secrets, and the narrowest scope (subscription vs resource group). Flag any connection with Owner/Contributor at subscription scope used by a build that only needs to deploy to one RG. 3. **Reliability** — flag missing `dependsOn`/conditions that let stages run out of order, no retry on flaky steps, and missing timeouts. Recommend templates to deduplicate copy-pasted stages. 4. **Speed** — identify cacheable work (restore, build artifacts), recommend `Cache@2` keys, parallelism, and shallow checkout where safe. 5. **Deploy safety** — confirm production deploys go through an Environment with required approvals/checks, not a plain job. Recommend manual approval and a deployment strategy (canary/rolling) for prod. Output as: (a) a findings table — area, issue, severity, fix; (b) the corrected YAML for the highest-severity items; (c) the service-connection / approval changes to make in the UI; (d) what to test before merging. Review only the YAML and context I gave you. Don't assume variable groups or service connections that aren't shown — ask.
Why this prompt works
Azure DevOps pipelines accumulate risk quietly. A secret gets passed as a plain variable so a script can read it, a service connection is granted Contributor at subscription scope because that was the path of least resistance, and a production deploy runs as an ordinary job with no approval gate. None of these break anything on a green run, so they survive review after review. This prompt audits exactly those latent risks — secret handling, service-connection scope, and deploy gating — alongside the speed and reliability issues engineers actually notice, so the review covers what’s dangerous and not just what’s annoying.
The security framing is grounded in how Azure DevOps leaks credentials in practice. Secrets exposed through plain variables or system.debug logging, and over-scoped service connections backed by stored SPN secrets, are the two most common findings. By steering toward Key Vault-linked variable groups, secret-typed variables, and workload identity federation at the narrowest scope, the prompt produces concrete, modern fixes rather than generic “use a secrets manager” advice — and it ties scope to what the pipeline genuinely needs to deploy.
The guardrails reflect that pipelines are shared infrastructure and deploy gates are safety controls. Tightening a service connection or swapping its auth can break unrelated pipelines that quietly depend on it, and a YAML edit that removes an approval gate can ship an unreviewed change to production. By requiring access verification before scope changes and PR-plus-non-prod testing for anything that touches deploy stages, the prompt lets you harden the pipeline aggressively while keeping every change reviewable and reversible.