An e-commerce platform sees GuardDuty EC2 malware findings at night and needs automatic isolation, forensic snapshot capture, and tagging for investigation without waiting for on-call approval. The workflow must be auditable and retry on API throttling. Which automated remediation design best contains the compromised EC2 incident?

The correct design is right because EventBridge natively matches GuardDuty EC2 malware findings and starts Step Functions without human intervention, enabling nighttime containment that revokes network access via Systems Manager, creates EBS snapshots for forensics, applies investigation tags, and preserves a visual auditable execution history with built-in error handling and exponential backoff for API throttling. The direct Lambda invocation approach automates isolation and snapshots correctly but fails the auditability and resilience requirement since a single function lacks orchestrated state tracking, centralized visual history, and declarative retry logic for throttled EC2 and SSM calls. The Systems Manager Automation with manual approval approach provides strong isolation and runbook control but violates the explicit no-wait constraint by inserting a human approval gate that delays nighttime containment and contradicts autonomy. The network detachment approach contains spread quickly by removing IAM role permissions and blocking traffic but omits forensic preservation and tagging, destroying volatile evidence needed for investigation and breaking chain of custody. On exams, distinguish orchestration with retry and audit from simple event-to-function automation and from approval-gated runbooks when immediate autonomy is stated. In practice, verify the EventBridge pattern filters the correct GuardDuty finding type, test least-privilege isolation roles, confirm snapshots are encrypted, tagged and locked from deletion, and rehearse throttling simulations to confirm retries succeed.