GuardDuty reports cryptocurrency mining activity on a county EC2 instance. Leadership wants an architecture that can automatically start containment when that finding type appears. Which design best supports detection-to-response automation?
Select an answer to reveal the explanation.
Short Explanation
When GuardDuty yells “miner on that box,” you want a tripwire that already knows what to do—EventBridge catches the finding and kicks off isolate-and-notify. Waiting on invoices or binders lets the miner keep digging.
Full Explanation
GuardDuty cryptocurrency-mining findings on a county EC2 instance call for detection-to-response automation, not ticket theater. Amazon EventBridge can match GuardDuty finding types and invoke containment playbooks—Lambda or Systems Manager actions that isolate the instance by swapping to a forensic security group (deny inbound, tightly controlled outbound), snapshot volumes for investigation, tag the resource, and notify operators through SNS or the ITSM integration. That architecture turns a high-fidelity finding into minutes-scale containment while humans still review for false positives.
Turning GuardDuty off and waiting for a CPU spike on the monthly invoice fails detection timing and accountability—cost anomalies are a poor substitute for threat intel. Forwarding findings only to a printed binder with a 30-day change board fails containment speed; miners continue consuming resources and possibly pivoting while paperwork moves. Deleting CloudWatch metrics so mining cannot be graphed fails observability and does nothing to stop the compromise.
Exam caveat: automate isolation carefully so you do not brick shared services; prefer instance-specific SG swaps and preserve evidence volumes rather than immediate terminate-without-snapshot. Operational check: inject or simulate a GuardDuty mining finding in a lab account, confirm EventBridge fires, verify the instance SG changes and operators receive notification, and document the rollback path for false positives.