Management and Governance Infrastructure as code

Deployment stack

A deployment stack is an Azure Resource Manager resource that manages a group of resources deployed from a Bicep or ARM template, including lifecycle tracking, unmanaged-resource handling, and optional deny settings.

Source: Microsoft Learn - Create and deploy Azure deployment stacks in Bicep Reviewed 2026-05-13

Exam trap: Treating Deployment stack as a label instead of checking the resource scope, owner, and dependency chain.
Production check: Am I in the correct tenant, subscription, and resource group for this operation?

Practice this topic Microsoft Learn

Article details and learning context

Aliases: Azure deployment stack, Bicep deployment stack, Microsoft.Resources/deploymentStacks, ARM deployment stack
Difficulty: intermediate
CLI mappings: 4
Last verified: 2026-05-13
Review level: top250-pre130-priority-upgraded
Article depth: field-manual

Learning paths Learn Infrastructure as Code with Bicep Deployment stack

Related context Learning path: Infrastructure as Code with Bicep

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Deployment stack is an Azure Resource Manager resource that manages a set of template-deployed resources as a lifecycle unit. In Azure, it helps teams track managed resources, control cleanup behavior, and protect critical resources created through infrastructure as code. Plainly, it is a named control point that connects release intent with live resources, evidence, ownership, and rollback. A useful glossary definition should show where it lives, who can change it, what depends on it, and what signal proves it is working.

Why it matters

Deployment stack matters because deployment language is only useful when teams can connect it to a real Azure scope, a release decision, and repeatable evidence. When it is shallowly documented, engineers may troubleshoot the wrong app, slot, template, operation, deployment record, stack, or policy guardrail while the actual failure remains hidden. In enterprise Azure work, the value is shared language: application, platform, security, finance, and operations teams can discuss the same deployment object without guessing. That reduces incident time, improves audit quality, protects rollback options, and makes production releases safer because dependencies and failure modes are visible before change. Treat Deployment stack as production owned when customer traffic, regulated workloads, shared infrastructure, or release automation depends on it.

Technical context

Technically, Deployment stack appears in Bicep deployment stack definitions, Microsoft.Resources/deploymentStacks resources, stack managed-resource lists, actionOnUnmanage settings, deny settings, and deployment history and interacts with Azure Resource Manager, Bicep, and ARM templates. Configuration is reviewed through template file, managed resource list, and action on unmanage, while operators validate live state through stack provisioning state, managed resources, and deny assignment status. Scope defines which permissions, logs, CLI commands, deployment records, and downstream dependencies are relevant before production change.

Exam context

Compare with

Resource group deployment Complete deployment mode Resource lock

Where it is used

Where you see it

In Azure Resource Manager, a deployment stack appears as a resource that tracks resources created from a template at a chosen scope during release review.
In Bicep workflows, it appears when teams deploy infrastructure as a managed lifecycle group instead of loose resources during release review before production promotion when support engineers collect evidence.
In governance review, it appears when deny settings and action-on-unmanage behavior protect or clean up managed resources during release review before production promotion when support engineers collect evidence.

Common situations

Manage a related set of Azure resources as one deployment ownership boundary.
Track resources created by a template and understand which objects are managed together.
Apply controlled delete or detach behavior when cleaning up stack-managed resources.
Reduce drift between template intent and deployed Azure resources across environments.
Give platform teams clearer ownership, rollback, and cleanup records for landing-zone deployments.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Deployment stack in action for insurance claims processing Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Arcadia Claims, a insurance claims processing organization, needed to address shared claim-processing resources were deployed by templates but later modified manually, creating drift and uncertain ownership. The architecture team used Deployment stack as the control point for a measurable production improvement.

Goals

Manage related infrastructure as one lifecycle unit
Identify resources no longer described by the template
Protect critical resources from accidental deletion

Approach using Deployment stack

The platform team moved the resource group deployment into a deployment stack managed from Bicep. The stack tracked App Service, storage, Key Vault, and monitoring resources. Engineers validated updates before release, reviewed managed resources after deployment, and used deny settings for critical production components. The team validated Deployment stack in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Deployment stack in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes

Manual ownership confusion dropped across two platform squads
Unmanaged-resource review became part of every release
Accidental deletion attempts were blocked for protected resources

What to learn

Deployment stacks help teams operate infrastructure as a managed lifecycle group instead of disconnected resources.

Scenario 02 Deployment stack in action for industrial IoT Scenario, objectives, solution, measured impact, and takeaway.

Scenario

TerraFoods Manufacturing, a industrial IoT organization, needed to address factory telemetry landing zones left orphaned resources after template updates removed obsolete components. The architecture team used Deployment stack as the control point for a measurable production improvement.

Goals

Make cleanup behavior explicit during stack updates
Reduce orphaned resource spend
Preserve safe exceptions for shared components

Approach using Deployment stack

Architects adopted deployment stacks at resource-group scope and documented action-on-unmanage choices before each update. Nonproduction stacks deleted retired resources automatically, while production stacks detached approved shared resources. Stack state and managed-resource lists were reviewed in release meetings. The team validated Deployment stack in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Deployment stack in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer.

Potential outcomes

Orphaned monthly spend fell 31 percent
Production shared resources avoided accidental deletion
Cleanup decisions became visible in change records

What to learn

A deployment stack makes resource lifecycle decisions explicit instead of leaving cleanup to memory.

Scenario 03 Deployment stack in action for higher education research Scenario, objectives, solution, measured impact, and takeaway.

Scenario

NorthBay University, a higher education research organization, needed to address research labs needed self-service infrastructure while central IT required guardrails around changes to shared networking. The architecture team used Deployment stack as the control point for a measurable production improvement.

Goals

Enable repeatable lab deployments from Bicep
Protect shared network resources from contributor changes
Give researchers clear ownership of managed resources

Approach using Deployment stack

Central IT published Bicep templates deployed as deployment stacks. The stack managed lab resources while deny settings protected shared network components. Researchers received permissions for approved operations, and the stack record showed which resources belonged to each lab deployment. The team validated Deployment stack in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Deployment stack in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes

Lab provisioning time fell from days to hours
Unauthorized shared-network changes stopped
Resource ownership became clear for chargeback and support

What to learn

Deployment stacks combine self-service infrastructure with visible lifecycle management and control-plane protection.

Azure CLI

CLI checks for Deployment stack are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show scope, state, owner, permissions, history, slot configuration, stack settings, or deployment records. Run mutating, security-impacting, or cost-impacting commands only after approval, because the wrong scope can affect production availability, spend, or access.

Useful for

List and inspect Deployment stack configuration before making any production change.
Capture Deployment stack state as evidence for an incident, audit, or change review.
Compare Deployment stack settings across development, staging, and production environments.
Automate safe read-only checks for Deployment stack in runbooks and deployment validation.

Before you run a command

Confirm the active tenant and subscription so the command targets the intended Azure boundary.
Know the resource group, region, and related resource names before inspecting Deployment stack.
Run read-only list or show commands first, then review any mutating command with the owning team.
Choose JSON, table, or TSV output based on whether humans or automation will consume the result.

What the output tells you

Whether Azure can resolve Deployment stack at the expected scope and return current configuration.
Which identifiers, names, locations, states, and relationship fields are available for follow-up checks.
Whether the issue appears to be missing configuration, access denial, provider support, or dependency drift.
Which adjacent resource or command should be checked next before changing production behavior.

Mapped commands

Deployment stack operational checks

direct

az stack group list --resource-group <resource-group> --output table

az stack groupdiscoverManagement and Governance

az stack group show --name <stack-name> --resource-group <resource-group>

az stack groupdiscoverManagement and Governance

az stack group validate --name <stack-name> --resource-group <resource-group> --template-file <template-file> --deny-settings-mode <mode> --action-on-unmanage <action>

az stack groupdiscoverManagement and Governance

az stack group create --name <stack-name> --resource-group <resource-group> --template-file <template-file> --deny-settings-mode <mode> --action-on-unmanage <action>

az stack groupsecureManagement and Governance

Architecture context

Deployment stack belongs to Management and Governance architecture decisions where identity, deployment scope, monitoring, cost ownership, reliability, and production support need shared evidence.

Security: Security for Deployment stack starts with least privilege, change traceability, and evidence that deployment authority matches workload risk. Review deny settings, stack built-in roles, excluded principals, and RBAC scope before approving production use. A common failure is assuming that a successful release, reachable endpoint, completed template, or blocked action proves access is appropriate. Use Microsoft Entra groups, managed identities, RBAC, private connectivity, source-control approval, deployment records, and audit logs where applicable. Keep exceptions ticketed, time-bounded, and tied to a named owner. For regulated workloads, align the configuration with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale publish profiles, unreviewed contributors, and undocumented exception paths before Deployment stack becomes an incident path.
Cost: Cost for Deployment stack appears through compute runtime, storage retention, deployment scripts, staging slots, failed retries, protected resources, diagnostic retention, and the human effort required to recover from bad releases. Review orphaned resource cleanup, retained unmanaged resources, failed stack updates, and protected resource overhead before expanding production use. Some costs are direct, such as extra App Service plan capacity, deployment script execution, or retained resources; others are indirect, such as failed releases, emergency restores, duplicated troubleshooting, and support escalation. Tag related resources, monitor usage, and separate exploratory work from production. A cost review should connect spend to a real owner and measurable release value.
Reliability: Reliability for Deployment stack depends on repeatable configuration, tested dependencies, and clear failure signals. Watch managed resource tracking, out-of-sync detection, safe deletion behavior, and template drift because drift often appears later as failed releases, unavailable apps, unexpected deletes, blocked stack updates, or confusing history records. Use lower environments, source-controlled definitions where possible, deployment validation, monitoring, and rollback notes before changing production. Operators should know which app, slot, template, script, identity, stack, resource group, or downstream system fails first and which log or metric proves the failure. The goal is predictable recovery: detect Deployment stack drift, preserve service, restore safely, and explain the incident without guessing.
Performance: Performance for Deployment stack depends on deployment timing, app warm-up, slot readiness, template complexity, script duration, resource-provider latency, network path, and the monitoring path used to confirm success. Review stack validation time, deployment duration, provider operation latency, and resource count scale before increasing capacity or retrying blindly. The better fix might be pre-warming a slot, simplifying templates, reducing script work, validating dependencies, sequencing stack changes, or capturing clearer operation output. Measure with representative production conditions, not a tiny test that hides real behavior. Operators should connect symptoms to evidence: latency, failed operations, cold starts, queueing, deployment duration, or error records.
Operations: Operations for Deployment stack should focus on ownership, observability, and safe repeatability. Standardize naming, tags, owner groups, environment labels, diagnostic destinations, runbook links, approval records, and change windows so support teams do not reverse-engineer deployments during incidents. Use read-only CLI, API, deployment history, activity log, or portal checks first, then compare live state with intended configuration. For production, connect alerts, audit events, cost records, graph links, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and rollback before changing Deployment stack in a production environment.

Common mistakes

Treating Deployment stack as a label instead of checking the resource scope, owner, and dependency chain.
Running a mutating command before collecting read-only evidence and confirming the target subscription.
Copying configuration between environments without checking region, policy, identity, and service support.
Forgetting that governance, monitoring, cost, and recovery behavior may depend on adjacent Azure resources.