A broadcast network is changing a StackSet that already has stack instances in several Regions. A bad template should affect one Region before any other. How should they deploy the change?
Select an answer to reveal the explanation.
Short Explanation
You taste one tray from the oven before you commit the whole bakery. The StackSet change should land in one Region, and you should confirm that Region before any other stack instance is updated. Sending every Region through the same operation turns a bad template into everyone's outage at once.
Full Explanation
A StackSet update can be limited to the stack instances in one Region. That Region is where a bad template shows up, including a failed stack instance, before any other Region is changed. Updating the instances in one Region first, and confirming that Region, is the rollout that matches the requirement. Updating every stack instance in every Region in the same operation removes that pause, so a bad template reaches the whole set together. Deleting the StackSet and creating every Regional stack again from the updated template replaces the running stacks everywhere in one pass, which is a rebuild, not a single-Region trial. Handing the template to each Regional team leaves the existing StackSet instances on the old version and splits the change outside the StackSet. Caveat: a clean result in the first Region does not remove a permission or quota failure that can still appear when the other Regions are updated. Operational check: run the first operation against one Region only, confirm that stack instance and a smoke test, and only then update the remaining Regions.