How would you split AKS deployments across dev, QA, UAT, and prod in Azure DevOps?

One deployment pipeline with a stage per environment is a reasonable starting point if releases are meant to move through QA, UAT, and prod in order. Put the common deployment steps in a template, then pass in the environment-specific settings rather than maintaining four copies.

Use separate Azure DevOps Environments and service connections for each target. Scope the connections to what each environment needs, keep configuration in environment-specific variable groups, and attach approval checks to UAT or prod where needed. The deployment jobs can still use KubernetesManifest.

The tradeoff is that a run waiting for approval is part of the same release flow. If teams need to move environments independently, separate pipelines may fit better.

I'd split the deployment pipelines when QA, UAT, and prod need separate release buttons. A QA deployment shouldn't have to wait around for someone to approve an unrelated prod release.

They don't need different implementations, though. Have each pipeline call the same deployment template and select the build or image to deploy. That gives you independent runs without four versions of the KubernetesManifest logic drifting apart.

Separate build from deployment first. CI can build the image, run unit tests, push it to the nonprod registry, and publish enough information for CD to identify that exact image. A deployment pipeline can be triggered by CI completion for an automatic dev deployment, while later environments can use a manual run that selects the intended build or image.

For a separate prod registry, a promotion step can use az acr import to copy the tested image. Identify it by digest rather than relying on a tag that could be moved, and verify the destination image before deployment. That promotion step needs its own permissions, so CI doesn't have to get push access to prod.

A single registry is another option if its access controls meet your separation requirements. The choice depends on how much isolation you need, not on whether the YAML is combined or split.

There's also a useful split between early integration testing and the release path. A feature branch can deploy to a sandbox or dev environment for testing before merge. After merge to the main branch, a separate pipeline can run the sequential QA, UAT, and production stages.

That keeps the fast feedback path distinct from the more controlled release flow. Whether the later stages should remain sequential depends on whether your environments are supposed to advance together.

Native pipeline deployments can work for this, so I wouldn't switch tools just to get approvals. The architectural difference is worth considering, though: a pipeline pushes changes to the cluster, while a GitOps controller pulls desired state and reconciles it.

If push access from deployment pipelines becomes a security or operational concern, that is a reason to evaluate the pull-based model. It is a separate decision from whether you use one Azure pipeline or several.