2.1.1.2. Design for Environment Provisioning: Deployment Stacks and Template Specs
2.1.1.2. Design for Environment Provisioning: Deployment Stacks and Template Specs
💡 First Principle: Provisioning a governed environment repeatably means shipping the resources AND the governance around them as one versioned unit — and then keeping what you shipped from drifting.
Scenario: Your organization needs to rapidly provision new development environments that consistently include specific Virtual Networks, Network Security Groups, monitoring policies, and a set of predefined RBAC role assignments. These environments must be compliant from day one, and must not be quietly modified afterwards.
⚠️ Azure Blueprints is deprecated. For years this was the Blueprints answer, and you will still meet Blueprints in existing estates. Microsoft has deprecated it in favour of Template Specs and Deployment Stacks, and it does not appear anywhere in the current AZ-305 exam objectives. Learn it well enough to recognise it in a legacy environment; do not choose it for a new design.
The two services that replaced it, and the split between them:
| Service | What it is | Use it for |
|---|---|---|
| Template Specs | An ARM/Bicep template stored as a first-class, versioned resource in the tenant, shareable by RBAC | Publishing a reviewed environment definition that teams deploy from, without passing template files around |
| Deployment Stacks | A deployment managed as a single lifecycle unit — the resources it created are tracked as its managed resources | Deploying an environment that must be updated, deleted and PROTECTED as one thing |
Deny settings are the part that replaces locked artifacts. A deployment stack can apply
denySettings to everything it manages, so the resources it created cannot be modified or
deleted out from under it — which is the capability Blueprints provided through locked
artifacts, and the reason a stack beats a plain template deployment when drift is the concern.
Role assignments are template resources too. With Blueprints gone there is no
separate "RBAC artifact": Microsoft.Authorization/roleAssignments is declared in the
template like any other resource, so an environment's access control ships in the same
definition as the environment and is tracked by the same stack — created with it,
updated with it, torn down with it. That is what makes "compliant from day one" true
without a follow-up manual grant.
The enforcement mechanism is a deny assignment, and deny assignments are evaluated
ahead of role assignments — so a subscription Owner is blocked by one too. Two things
follow. The deny assignment is visible in Access control (IAM) so you can see why an
action was refused, but it is read-only there; and the protection is lifted through the
stack that created it — set the deny setting mode to none, or remove the resource from
the template, at which point actionOnUnmanage decides whether it is detached or
deleted. A subscription owner cannot self-approve removing the control.
Choosing between them and the alternatives:
| Requirement | Answer |
|---|---|
| Deploy resources repeatably | ARM/Bicep template, published as a Template Spec if it is shared |
| Deploy AND protect the deployed resources from modification | Deployment Stack with deny settings |
| Apply a rule to resources that already exist, and to future ones | Azure Policy (with DeployIfNotExists to remediate) |
| Have every NEW subscription pick up a standard configuration automatically | Azure Policy at a management group — inheritance is what makes it automatic |
⚠️ Common Pitfall: reaching for a deployment stack when a plain template would do. The stack earns its extra machinery only when the deployed set genuinely needs managing or protecting as one unit; for a one-off deployment a template or Template Spec is simpler.
Key Trade-Offs:
- Templates vs. Stacks: a template deploys resources and then forgets them. A stack remembers what it created, which is what enables coordinated update, clean deletion, and deny settings — at the cost of a lifecycle object to manage.
- Stacks vs. Policy: a stack governs what IT deployed. Policy governs everything in scope, including resources it never created. They are complementary, and most landing zones use both.
Reflection Question: How does packaging an environment as a versioned Template Spec and deploying it as a Deployment Stack with deny settings deliver the consistency, compliance and drift protection that Blueprints was built for — and why does policy assigned at a management group remain the mechanism for reaching subscriptions that do not exist yet?
