Unit 3 capstone — Consolidating a mixed compute estate
AZ-104 › Unit 3 › Capstone
Unit 3 capstone — Consolidating a mixed compute estate
Tailwind Traders rationalises its platform
- AZ104-U3
- 4
- 24
- 5
- 25 minutes
The brief
Tailwind Traders runs five small web applications, a nightly reconciliation job, and a pair of virtual machines carrying a legacy service. The region they are committed to for this financial year does not offer availability zones, and last quarter both machines rebooted together during Azure planned maintenance and the service went down. One of the five web apps is a customer-facing checkout that must not be affected when the internal apps get busy. Releases go out weekly and have twice needed reversing under pressure. Their infrastructure is deployed from a Bicep file, and the last person to change one setting in it discovered afterwards that three other settings had gone back to their defaults.
What they need
- Change one setting in the Bicep file without resetting the others.
- The two legacy machines survive planned maintenance without both going down, in a region with no zones, under an availability SLA.
- The nightly reconciliation job runs in a container, does its work, and stops.
- The checkout app is unaffected when the four internal apps get busy.
- A weekly release can be reversed in seconds.
Commit before you read on
Write down your answer to each of the 5 numbered requirements above — the mechanism, and the scope you would apply it at. Then open the working below and compare. Reading the reasoning beside the question is the one way to feel like you knew it without having known it.
▶Show the working
1. Change one setting without resetting the others
Specify every non-default value in the template, not just the one being changed.
This is the single most misunderstood behaviour in the unit, and it explains what happened to them. On redeploying in incremental mode, all properties are reapplied; the properties aren't incrementally added, and properties not included in the template are reset to their default values. A template is always the final state of a resource and cannot express a partial update. Switching to complete mode would make it worse — that deletes resources not in the template.
2. Survive planned maintenance, no zones, under an SLA
An availability set holding both machines.
Zones are unavailable, which removes the other candidate. Two or more VMs in an availability set meets the 99.95% SLA, and there is no extra cost for the set itself. The mechanism that solves their actual symptom is the update domain: only one update domain is restarted at a time, and a restarted one gets 30 minutes to recover first. ⚠ Plan it now — an availability set's 3 fault and 20 update domains cannot be changed after creation, and a VM cannot join one later.
3. A container job that runs and stops
Azure Container Instances with the restart policy set to OnFailure or Never.
The trap is the default. Always is the default restart policy applied when none is specified, so a run-once job left at the default restarts forever. OnFailure restarts only on a nonzero exit and runs the container at least once, which is what a nightly job wants. Container Apps would be over-specified for a task with no ingress and no revisions.
4. Checkout unaffected by the internal apps
Move the checkout app to its own App Service plan.
Not a bigger tier, not autoscale rules on the shared plan. All apps in an App Service plan scale together because they share the same VM instances, and apps in the same plan share those instances. Isolation between apps is a plan boundary, and there is no per-app setting that creates one.
5. Reverse a release in seconds
Deployment slots, and swap again to roll back.
Slots need Standard, Premium or Isolated — the tier gate is asked directly. The rollback mechanism is the part people miss: after a swap, the staging slot holds the previous production app, so swapping a second time restores it immediately. Redeploying from source is the slow wrong answer. Instances are warmed up before the swap, so the forward direction has no downtime either.
The reasoning this unit rewards
Check yourself
Where these figures come from
Every figure above was read from the raw documentation below on the day this sheet was written. The sha1 is git hash-object over the bytes as fetched, so a doc that changes underneath this sheet can be detected rather than assumed.
| Document | sha1 |
|---|---|
| Azure Resource Manager deployment modes | d10ae932c680 |
| Availability sets overview | 3d013cdadbc3 |
| Restart policy for run-once tasks | 7a520bfd1207 |
| Azure App Service plan overview | 031c5af27b95 |
| Set up staging environments in Azure App Service | 2d0b4578ba9a |