An aggregate status is not a delivery list
For a StackSets rollout, retain each account and Region result. SUCCEEDED at operation level means the failure tolerance was not exceeded; it can coexist with failed instances. In the exercise, 18 targets updated and two failed within tolerance. The project requirement still calls for all 20. Report 18/20, identify the two targets, and assign correction and validation. Do not rename technical tolerance as business risk acceptance. Tolerance controls whether the operation continues; acceptance has separate criteria and authority. Keep IDs, previous and intended versions, errors, owners, and next steps. This lets the next shift distinguish a known failure from a new regression.
Limit impact and understand scope
Define Region order, concurrency, and stopping criteria before starting. In Strict Failure Tolerance, initial effective concurrency is bounded by tolerance plus one as well as the configured maximum; failures can reduce it. Percentage failure tolerances round down. These are operational limits, not exact duration estimates. With service-managed permissions, the management account does not receive stacks even when the entire organization is selected. Documentation also gives the StackSets delegated administrator broad organizational scope; selecting one OU for a rollout does not itself create a delegation boundary. Separate authorized scope from the current execution target, and prepare the management-account baseline through a separate process.
Guided exercise: deciding after partial delivery
The fictional requirement calls for monitoring agent v7 in four accounts before closing. Results show A and B at v7, C with a quota error, and D canceled. The PM should neither declare completion nor blindly repeat the operation. Confirm each stack’s current state, correct C’s condition, and prepare an observed update for pending targets. If returning is necessary, assess v7 already active in A and B and use an approved procedure. Failure at another target does not establish automatic rollback across the organization. For APS, the transition record should show the mixed population, expected alerts, and who decides to continue or return before cut-off.
Coverage and integrity answer different questions
A management-event trail does not guarantee GetObject or PutObject records for reconciliation files. Data events need explicit selection and incur additional charges. Specify resources, operations, and read/write requirements before optimizing volume. In the exercise, the requirement includes access and changes; a write-only selector leaves a gap. For integrity, enabling the validation feature allows digest generation but does not run file validation. Retain the verification result, interval, and limitations. Even successful validation does not recover events never collected. Separate four decisions in the report: what to collect, how to confirm delivery, how to validate integrity, and who monitors cost and deviations. This prevents a technical receipt from being confused with complete evidence of the requirement.
Rollout worksheet (fictional)
A / eu-west-1: v7 / SUCCEEDED
B / eu-west-1: v7 / SUCCEEDED
C / eu-west-1: v6 / FAILED (quota)
D / eu-west-1: v6 / CANCELLED
Business acceptance: v7 validated on A, B, C, D
Current acceptance: incomplete; preserve mixed-version inventoryThe dashboard shows success, but two accounts retain the old baseline and file reads are unlogged. These are two separate acceptance conditions.
Common pitfalls
Confusing tolerance with approval; assuming global rollback; forgetting the management account; counting digests as completed validation; cutting costs by removing required events.
Related topics: Governance boundaries across accounts
Accept observed results per target and evidence suited to the question you need to answer.
Reference: StackSets concepts · SAP-C02