Deployment Stacks: Treating Your Azure Deployments Like Real Resources

Hello Folks!

If you have ever come back from vacation to find a “mystery” storage account no one remembers creating, or watched a junior admin nuke a production resource because they clicked the wrong tile in the portal, this session is for you. Sydney Smith from the Azure Deployments team walked through Deployment Stacks at the Microsoft Azure Infrastructure Summit 2026, and the message is simple: classic Azure deployments are just history records, and history records cannot protect anything.

Deployment Stacks change that. A stack is a real Azure resource. It has a resource ID. It supports RBAC. It tracks what it owns. It can refuse to let people break it. That is a real upgrade to how we run Infrastructure as Code in Azure, and IT pros should be paying attention.

📺 Watch the session:

Why IT Pros Should Care

Let me cut through the noise. Here is why this matters to anyone running Azure infrastructure:

• Orphaned resources cost real money. Classic deployments do not track ownership. Remove a resource from your template, and the live resource sits in Azure forever, billing you and adding security risk.
• Deployment history is fragile. Anyone can groom it away. You lose the audit trail.
• There is no native change protection. Without stacks, the only thing standing between your production VNet and a midnight portal click is RBAC discipline. That is not enough.
• Drift is invisible. You cannot detect what you cannot define as the source of truth.
• No unified view. Resources scattered across resource groups or subscriptions are hard to manage as one unit.

Stacks give you a single lifecycle aware unit, with built in guardrails, that you can govern with RBAC and policy like any other Azure resource. That is the kind of plumbing IT operations has been asking for.

What are Deployment Stacks

A deployment stack is a native Azure resource that manages a group of resources as one lifecycle aware unit. It is the modern evolution of Azure deployments. Where a classic deployment is a record of what happened, a stack is a living thing that knows what it owns.

Key facts to anchor on:

• A stack is of type Microsoft.Resources/deploymentStacks. It is a first class Azure resource.
• A stack can span multiple resource groups and even multiple subscriptions.
• You feed it a Bicep or ARM JSON template, the same files you already have. No rewrite required.
• It produces a snapshot of the resources it manages, and uses that snapshot for lifecycle decisions.

Two feature sets do the heavy lifting:

1. Resource lifecycle management. Creates, updates, and deletes across scopes are managed as one operation.
2. Resource change protection. Stacks can apply deny assignments on the resources they manage, blocking changes that did not come through the stack itself.

That second point is the one that changes how you think about safety in production.

How Deployment Stacks change your workflow

Honestly, the syntax change is tiny. If you know az deployment group create, you already know az stack group create. Same template, same parameter files, same scope. You just swap deployment for stack and add a couple of new parameters.

What changes in the day to day:

• Your template becomes the source of truth. Remove a resource from Bicep, and the next stack run can clean it up automatically. No more manual hunt and delete.
• You get a portal view. The stack resource shows you what it manages, what is detached, and what the deny settings look like.
• You can clean up everything in one step. Deleting a stack with the right unmanage setting tears down all its resources and the empty resource groups, without you mapping out dependency order.
• Pipelines get cleaner. The bicep-deploy GitHub Action and the equivalent Azure DevOps task speak stacks natively. Create, validate, what-if, delete. Same shared package on the backend, so features hit GitHub and ADO at roughly the same time.

The honest tradeoff: stacks are powerful enough to delete things at scale. That is the whole point. So you need to think harder about which mode you pick.

Deny settings and lifecycle control

Two parameters carry most of the weight, and you need to understand both before you push a stack into production.

action-on-unmanage controls what happens when a resource leaves the template:

• detachAll: resources stay in Azure, the stack stops tracking them. This is the default and the safest. No delete operation. Good when you are still learning stacks.
• deleteResources: resources are deleted, the resource group stays.
• deleteAll: full cleanup. Resources go, empty resource groups go. This is what you pair with strict deny settings if you want the template to be the only source of truth.

deny-settings-mode controls who can change what:

• none: no protection. Anyone with RBAC can do anything. Use this only when you really mean it.
• denyDelete: blocks delete operations. Updates are still allowed.
• denyWriteAndDelete: the strict one. No changes outside the stack. This plus deleteAll makes your template the absolute source of truth.

A handy escape hatch: excludedActions lets you punch specific resource types or operations through the deny wall. For example, you can deny delete across the board but allow deleting your managed identities or storage accounts. Use this sparingly. Every exception is a future ticket.

A few honest tradeoffs to keep in mind:

• denyWriteAndDelete is strict on purpose. Portal admins will get permission errors. That is the feature, not a bug. Train your team.
• deleteAll is permanent. Pair it with what-if before every change so you do not nuke something by accident.
• Resources should not be managed by two stacks. The deny assignments from each stack will fight each other and block updates. If two apps share a SQL database, pull it in as an existing resource rather than dual managing it.
• Stacks are not just for Bicep. They consume ARM JSON templates today. Terraform users do not get the same first party stack experience, so if you live in Terraform world, stacks are not your tool.

Getting Started

You do not need a giant rollout plan. Pick something small and learn the parameters in a safe environment.

A practical path:

1. Pick a non production Bicep template you already trust. Anything that creates a small set of resources in one resource group works.
2. Deploy it as a stack with safe defaults. Use actionOnUnmanage=detachAll and denySettingsMode=denyDelete. You get protection without risking accidental deletes.
3. Try removing a resource from the template and redeploy. Watch how the resource shows up as detached in the portal. Get comfortable with what that looks like.
4. Graduate to deletes. When you trust the workflow, switch to deleteResources or deleteAll in a dev environment. Always run what-if first.
5. Adopt Stacks What-If. The newer Stacks What-If commandlet triangulates the stack snapshot, the live resource state, and the desired state from your template. The result is a far less noisy diff than classic what-if, and the RBAC model only needs read access on the what-if resource for follow up gets. Big win for production review workflows.
6. Wire it into your pipeline. The bicep-deploy GitHub Action and the Azure DevOps task both support type: deploymentStack with create, validate, and delete operations. Start with a create pipeline, then add a what-if pipeline for PR validation, then a cleanup pipeline that uses delete to tear down ephemeral environments.

If you hit an out of sync error between your stack and Azure, the bypass-stack-out-of-sync-error parameter lets the pipeline reconverge automatically instead of forcing a manual cleanup. Read the docs before you flip it on, but it saves real time when state drifts.

Resources

• Create and deploy Azure deployment stacks in Bicep
• Bicep documentation on Microsoft Learn
• What-If for ARM and Bicep deployments
• Deploy Bicep files by using GitHub Actions
• Azure Bicep on GitHub
• Bicep Deploy GitHub Action and ADO task
• Bicep and ARM community news and monthly call signup

Watch the rest of the Summit

If this session helped, there are plenty more where it came from. The full Microsoft Azure Infrastructure Summit 2026 playlist covers everything from Azure Local and Azure Files to AKS networking, SRE agents, and the keynote with Jeremy Winter. Worth a binge if you run Azure infrastructure for a living.

Microsoft Azure Infrastructure Summit 2026 playlist

Cheers!

Pierre Roman