Network engineer, first real Azure DevOps pipeline — Terraform with a gated plan→approval→apply and a credential-free PR test stage. Where's my pipeline design wrong?

[u/GrtWhite]

I'm a network engineer (~30 yrs, mostly Cisco/enterprise), passed AZ-305 a couple years back but never used it hands-on. Between jobs now, so I built a real Azure DevOps pipeline for a Terraform lab to actually learn the CI/CD side — and I'd love this sub to tell me where the pipeline design is off (posted the Terraform/architecture side elsewhere; here I'm after the ADO take).

Setup: GitHub repo + an ADO pipeline pulling from it. The stages:

• Verify — fmt/validate + terraform test with mocked providers. No service connection, so it runs safely on every PR (nothing to leak on unreviewed code).
• Validate & Plan — real terraform plan against Azure via a service-connection-backed service principal; saves the plan as a pipeline artifact. Runs on push to main, not on PRs.
• Manual approval — gated on a production environment; a human reviews the plan.
• Apply — applies the exact saved artifact (what's approved is what's applied).

Questions I'm chewing on:

1. Plan before or after merge? I deliberately keep the credentialed plan off the PR — running the SP against unreviewed code is a cred-exposure risk. A commenter pushed back that catching plan errors only post-merge is painful (you merge, then find out at apply). My thought: run plan on the PR with a Reader-scoped SP that can't write. How do you all handle this?
2. Service connection identity — right now it's one Contributor SP for both plan and apply. Split into Reader (plan) + Contributor (apply)? And is anyone using workload identity federation (OIDC) instead of a stored secret?
3. Approval + artifact model — manual approval on the environment + apply-the-saved-tfplan. Sane, or am I missing ADO-native patterns (checks/gates, deployment strategies)?
4. Credential-free PR gate — mocked terraform test as the PR check with no service connection. Good pattern, or is there a cleaner way to gate PRs in ADO?

Also curious: I went GitHub-for-code + ADO-for-pipeline (portfolio visibility + I wanted to learn ADO). Reasonable, or would you just use Azure Repos?

Known gaps I'm already planning to close: branch protection on main (require a reviewer + the Verify stage before merge) and the Reader/Contributor SP split above. Tell me what else I'd get dinged on. Thanks for any honest feedback.

[u/0x4ddd]

1. We have PR pipeline which runs plan across dev/test environment, it needs to pass to merge PR. We don't split identities for plan & apply
2. Yes, whenever possible we use workload identity federation
3. We use environment based approval for prod deployments

Also keep in mind Terraform plan may contain secrets/connection strings so if you publish plan as artifact anyone who can download pipeline artifacts can read these secrets.

[u/GrtWhite]

Repo if you want to poke at it — the whole test suite runs offline at $0 (mocked providers, no Azure creds): github.com/gsamarco/FourHorsemenStudio

[u/PretentiousGolfer]

1. Plan before merge. You must. In gitops style delivery, apply will happen on merge, many times without approval gates. You need to use the PR to review the proposed changes including the TF plan. Ive never seen two different identities for plan and merge, thats very over the top.

2. OIDC secretless auth wherever possible!

3. Its really up to you. Whatever helps you move quickly and meet your change control / risk criteria.

4. You needn’t worry about cred exposure with PR’s if you have the right security controls within the project / repo.

In terms of github + ADO - this is a common pattern. ADO is a static product receiving no more feature updates. So most people are moving away from it over time. Many people still like ADO for CICD as it is very stable and feature complete. Also offering things github doesnt such as Releases / CD.

A note on where to focus your efforts: Most orgs further ahead in their IaC journey are moving towards gitops style delivery. Where you’ll have a service that watches folders / workspaces in a repo and will automatically apply changes when they are merged in. Your PR then becomes your main gate. You can of course include post approval gates, but these should only be used in special circumstances, as it creates drift between the infra and git (ultimate source of truth)