A logistics company manages around 400 mixed Amazon EC2 instances and on-premises servers from AWS Systems Manager across several accounts. The security team requires a recurring patch cycle that scans every managed node weekly, installs approved operating-system patches only inside a defined maintenance window to avoid business-hours disruption, and tags hosts by environment so production patches one week after the lower environments have proven stable. They want this driven natively by Systems Manager without scripting their own orchestration. Which approach BEST automates this scheduled, environment-staged patching?
- ADefine Patch Manager patch baselines with approval rules per environment, group nodes into patch groups by environment tag, and run the patch scan and install in Maintenance Windows scheduled a week apart so lower environments patch before production. Correct
- BSchedule a single Systems Manager Run Command invocation that runs the operating-system patch installation command on every managed instance at a fixed time each week, relying on each host operating system to defer the required reboot until its own configured quiet hours afterwards.
- CEnable AWS Config managed rules to detect instances missing required patches and configure an automatic remediation action that calls a patch document whenever a host is reported as non-compliant during the periodic Config evaluation.
- DUse AWS Backup to snapshot every instance weekly and write an AWS Lambda function that downloads and applies the latest vendor patches to each volume, restoring from the snapshot automatically if a patched host fails its post-install health check.
Why A is correct: Patch Manager baselines set which patches are approved per environment, patch groups map nodes by tag to those baselines, and Maintenance Windows execute the scan and install on controlled schedules, so configuring the production window a week after the lower environments delivers the staged, in-window, approved-only patching natively.
Why B is wrong: Run Command fires a single command at a set time with no patch baseline, approval rules, or maintenance-window scoping, so it cannot enforce approved-only patches, environment staging, or a controlled window, and depending on OS reboot deferral is unreliable across a mixed fleet.
Why C is wrong: Config evaluates compliance and can trigger remediation, but it offers no maintenance-window timing or week-apart environment staging, so patches could install during business hours and production would patch on the same cadence as test, missing the staged stability gate.
Why D is wrong: AWS Backup protects data and has no patching capability, and a custom Lambda that patches volumes is exactly the bespoke orchestration the team wants to avoid, while volume-level patching outside a running OS is impractical and unsupported for live servers.