A retailer manages several thousand Amazon EC2 instances across many accounts in its organisation from AWS Systems Manager. The platform team must roll out a single multi-step configuration change to every instance: pull a new agent package, edit a config file, restart a service, and then run a verification check that must pass before the host is considered done. The rollout must process instances in controlled concurrency, halt automatically once a defined number of hosts report a failure so a bad change cannot cascade across the fleet, and produce a per-step execution record for audit. The team wants this driven natively by Systems Manager without building its own orchestration engine. Which approach BEST meets these requirements?
- ARun the multi-step change as a Systems Manager Automation runbook executed across the fleet by tag targets, configuring a concurrency rate and an error threshold so the rollout limits how many instances run at once and stops automatically once the failure count reaches the defined limit. Correct
- BIssue a single Systems Manager Run Command document that scripts all four steps inline and target the whole fleet at once, capturing the command output per instance so the team can review which hosts succeeded after the command has finished executing everywhere.
- CAssociate the change with Systems Manager State Manager so the document reapplies the four steps on a recurring schedule, relying on the periodic reconciliation to converge every instance onto the new configuration and report compliance across the fleet over successive intervals.
- DBuild an AWS Step Functions state machine that invokes a Lambda function for each step and iterates over the instance list, adding retry and failure-count logic in the workflow definition so the rollout pauses when too many instances fail the verification check.
Why A is correct: An Automation runbook expresses the ordered steps including the verification gate, runs across targeted instances with a concurrency rate that controls how many process at once, and stops the rollout when the configured error threshold is reached, while recording each step's outcome for audit, meeting every requirement natively.
Why B is wrong: Run Command can carry a multi-step script and supports concurrency and error controls, but it lacks the structured per-step automation flow with branching verification gates, and targeting the whole fleet at once without an enforced step-by-step stop risks the cascade the team needs to prevent.
Why C is wrong: State Manager is built for continuous desired-state reconciliation on a schedule rather than a one-time controlled rollout, and it offers no error-threshold halt that stops a bad change mid-fleet, so a faulty document would be reapplied everywhere instead of being stopped early.
Why D is wrong: Step Functions with Lambda can express the orchestration, but writing the per-step invocation, instance iteration, and failure-count logic is exactly the custom orchestration engine the team wants to avoid, and it duplicates capabilities Systems Manager Automation already provides natively.