Security findings raised in member accounts must trigger automated response runbooks that run only in the central security account. Which event architecture supports that pattern?
Select an answer to reveal the explanation.
Short Explanation
Findings are like smoke alarms in every building that need to ring the firehouse, not just the hallway. Cross-account EventBridge carries the signal into the security account where the response automation lives.
Full Explanation
Security findings raised in member accounts should trigger automated response runbooks that execute in the central security account via cross-account EventBridge delivery. Member accounts emit findings or custom events to a security-account event bus; rules there invoke Lambda, Step Functions, or Systems Manager automation with security-account privileges. That pattern keeps remediation blast radius, secrets, and approval gates in the security tooling account rather than scattering powerful credentials across every department account.
Copying findings into email and hoping analysts paste them into tickets is manual, lossy, and too slow for containment after phishing or crypto-mining detections. Disabling findings in members and relying on weekly spreadsheets abandons continuous detection and response. Running all remediation Lambda functions with root keys stored in each member account embeds the worst credential anti-pattern into the automation meant to improve security.
Exam caveat: EventBridge cross-account buses plus a security tooling account form the automated response backbone; pair with Security Hub custom actions where useful. Operational check: route a sandbox finding to the security bus, invoke a read-only enrichment runbook first, confirm least-privilege execution roles, and expand to containment actions only after documented approval gates.