Management and Governance ARM deployments

Deployment stack action on unmanage

Deployment stack action on unmanage is the setting that defines what Azure does with resources that are no longer managed after a deployment stack is updated or deleted, such as detaching or deleting them.

Source: Microsoft Learn - Microsoft.Resources/deploymentStacks template reference Reviewed 2026-05-13

Exam trap: Changing production before checking the exact deployment scope, owner, correlation ID, slot settings, and rollback path.
Production check: Can you name the Azure scope, resource owner, deployment name, and rollback action without guessing?

Practice this topic Microsoft Learn

Article details and learning context

Aliases: actionOnUnmanage, deployment stack unmanage action, stack unmanaged resource action, deployment stack cleanup behavior
Difficulty: intermediate
CLI mappings: 4
Last verified: 2026-05-13

Related context No curated learning path mapped yet; use the category trail.

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Deployment stack action on unmanage is the deployment stack setting that controls what happens when resources become unmanaged after stack updates or deletion. In Azure, it helps teams make cleanup and retention behavior explicit when a resource is removed from a template or a stack is deleted. 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 action on unmanage 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.

Technical context

Technically, Deployment stack action on unmanage appears in deployment stack properties, Bicep stack commands, actionOnUnmanage parameters, stack update workflows, managed-resource lists, and delete or detach release decisions and interacts with Azure Resource Manager, Bicep, and ARM templates. Configuration is reviewed through delete resources action, detach action, and delete all behavior, while operators validate live state through unmanaged resource list, actionOnUnmanage value, and deleted resources. Scope defines which permissions, logs, CLI commands, deployment records, and downstream dependencies are relevant before production change.

Exam context

Compare with

Complete deployment mode Resource lock Deny assignment

Where it is used

Where you see it

In deployment stack commands, action on unmanage appears as the parameter that decides whether unmanaged resources are deleted or detached during release review before production promotion.
In release design, it appears when removing a resource from a Bicep file could either clean it up or leave it running during release review.
In cost review, it appears when detached resources remain billable after a stack update or deletion during release review before production promotion when support engineers collect evidence.

Common situations

Detach shared resources when a deployment stack is deleted.
Delete obsolete resources removed from a nonproduction stack template.
Document cleanup behavior before updating infrastructure-as-code definitions.

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 action on unmanage in action for equipment leasing SaaS Scenario, objectives, solution, measured impact, and takeaway.

Scenario

MercuryLease, a equipment leasing SaaS organization, needed to address retired test environments continued running because removed template resources were detached without owner review. The architecture team used Deployment stack action on unmanage as the control point for a measurable production improvement.

Goals

Delete obsolete nonproduction resources automatically
Avoid deleting shared production dependencies
Reduce monthly orphaned-resource spend

Approach using Deployment stack action on unmanage

The platform team separated nonproduction and production deployment stacks. Nonproduction stacks used action-on-unmanage behavior that deleted resources removed from templates, while production stacks used detach for shared dependencies after approval. Release notes documented the expected unmanaged resources before stack update. The team validated Deployment stack action on unmanage 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 action on unmanage in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes

Nonproduction orphaned spend fell 44 percent
No shared production dependency was deleted
Cleanup decisions became visible before deployment approval

What to learn

Action on unmanage makes the resource cleanup decision explicit before a deployment stack changes ownership.

Scenario 02 Deployment stack action on unmanage in action for medical imaging services Scenario, objectives, solution, measured impact, and takeaway.

Scenario

LumaCare Imaging, a medical imaging services organization, needed to address an imaging archive migration required removing storage accounts from one stack without deleting retained clinical data. The architecture team used Deployment stack action on unmanage as the control point for a measurable production improvement.

Goals

Detach archive storage from the old stack safely
Keep regulated data available during migration
Prove ownership transfer in the change record

Approach using Deployment stack action on unmanage

Architects configured the deployment stack action on unmanage to detach resources during the migration update. The storage accounts were removed from the old Bicep template, verified as detached rather than deleted, and then onboarded into a new governance model with updated RBAC and monitoring. The team validated Deployment stack action on unmanage 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 action on unmanage in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes

Archive data stayed available throughout migration
Ownership transfer evidence satisfied compliance review
No emergency restore was needed

What to learn

Action on unmanage is critical when resources must leave a stack without being destroyed.

Scenario 03 Deployment stack action on unmanage in action for rail operations technology Scenario, objectives, solution, measured impact, and takeaway.

Scenario

VectorRail Systems, a rail operations technology organization, needed to address regional test stacks accumulated retired networking and compute resources after frequent template experiments. The architecture team used Deployment stack action on unmanage as the control point for a measurable production improvement.

Goals

Clean removed resources during test-stack updates
Keep production behavior more conservative
Reduce manual cleanup tickets for platform engineers

Approach using Deployment stack action on unmanage

The team standardized action-on-unmanage values by environment. Test stacks deleted resources removed from Bicep files, while production stacks required explicit detach review. CLI validation showed the chosen action before each stack update, and Activity Log evidence was attached to cleanup tickets. The team validated Deployment stack action on unmanage 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 action on unmanage in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes

Manual cleanup tickets dropped 68 percent
Test environment spend decreased within one billing cycle
Production deletion risk stayed under formal approval

What to learn

Deployment stack action-on-unmanage settings should vary by environment and risk, not by habit.

Azure CLI

CLI checks for Deployment stack action on unmanage 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

Detach shared resources when a deployment stack is deleted.
Delete obsolete resources removed from a nonproduction stack template.
Document cleanup behavior before updating infrastructure-as-code definitions.

Before you run a command

Run az account show, confirm tenant and subscription, and verify the operator identity has approved read access for the exact Azure scope.
Confirm resource group, application name, deployment name, slot, stack, template file, and environment before collecting evidence or changing production.
Prefer read-only commands first; review any command that swaps slots, deletes unmanaged resources, changes deny settings, or creates deployment history.

What the output tells you

Whether the deployment, app, slot, stack, script, correlation ID, or history record exists at the expected Azure scope.
Which provisioning state, timestamp, identity, source control setting, deny mode, action-on-unmanage behavior, or operation error is visible to the operator.
Whether the issue is wrong scope, stale history, a failed deployment operation, slot configuration drift, denied control-plane action, or release pipeline mismatch.

Mapped commands

Deployment stack action on unmanage 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 action on unmanage 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 action on unmanage starts with least privilege, change traceability, and evidence that deployment authority matches workload risk. Review cleanup approval, shared resource exceptions, RBAC for stack updates, and deny settings interaction 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.
Cost: Cost for Deployment stack action on unmanage 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 retention, cleanup automation, deleted obsolete resources, and manual review effort 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 action on unmanage depends on repeatable configuration, tested dependencies, and clear failure signals. Watch safe detach behavior, accidental delete prevention, dependency mapping, and stack update validation 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 action on unmanage drift, preserve service, restore safely, and explain the incident without guessing.
Performance: Performance for Deployment stack action on unmanage 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 update duration, delete operation timing, dependency sequencing, and validation speed 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 action on unmanage 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 action on unmanage in a production environment.

Common mistakes

Changing production before checking the exact deployment scope, owner, correlation ID, slot settings, and rollback path.
Treating a portal screenshot as sufficient evidence when CLI output, activity logs, deployment operations, and source-controlled templates are repeatable.
Assuming App Service deployment, ARM deployment, and deployment stack behavior use the same permissions, history, and cleanup semantics.