Cross-Account EC2 Lifecycle Events to One SQS Queue
A company is running Amazon EC2 instances in multiple AWS accounts. A developer needs to implement an application that collects all the lifecycle events of the EC2 instances. The application needs to store the lifecycle events in a single Amazon Simple Queue Service (Amazon SQS) queue in the company's main AWS account for further processing. Which solution will meet these requirements?
Community Insight
The question tests whether you know how EC2 state-change events reach EventBridge and how EventBridge shares events cross-account; the trap is assuming EC2 itself can be pointed at another account's bus, or that a Lambda polling sweep is an acceptable substitute for real-time events.
This DVA-C02 scenario asks how to aggregate EC2 instance lifecycle events from multiple AWS accounts into a single Amazon SQS queue in a main account. The correct pattern is cross-account Amazon EventBridge event buses: each workload account forwards its EC2 lifecycle events to the central account's event bus, where one rule matches them and targets the SQS queue.
Option B is the most tempting wrong-leaning choice: giving the SQS queue a resource policy so each account's EventBridge rule targets the queue directly does technically work, but it skips the centralized, permission-governed cross-account event bus pattern AWS recommends, spreading per-account targets and queue-policy exposure instead of one controlled ingress point.
Community Discussion (29 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option D follows the documented AWS cross-account EventBridge pattern: you add a resource-based policy on the main account's event bus that permits the source accounts to put events, create a rule in each account that matches EC2 instance lifecycle (state-change) events and forwards them to that central bus, then place one rule on the main bus whose target is the SQS queue. EC2 automatically emits state-change events to the default event bus of the account where the instance runs, so the only cross-account work is the bus-to-bus forwarding, which is exactly what D describes. This yields a single, auditable aggregation point where lifecycle events from every account land in one queue for downstream processing.
Why the Other Options Are Wrong
Option A is invalid because Amazon EC2 has no configuration to deliver its lifecycle events to a different account's event bus; state-change notifications always go to the local account's default bus, so the stated EC2 step cannot be performed. Option C replaces a real-time event stream with a Lambda function scheduled every minute that scans all EC2 instances across accounts, which introduces detection latency, extra cross-account polling permissions, and needless cost when EventBridge already delivers these events natively. Option B can technically function because an SQS queue policy can allow another account to send messages and EventBridge can target it, but it bypasses the centralized event bus, forcing every account's rule to point directly at a shared queue and scattering ingestion control; between the two working designs, the AWS-recommended and more governable answer is D.
Community Comment Notes
Untamables, the top-voted comment, backs D and cites the EC2 state-change monitoring guide plus the EventBridge cross-account event-bus documentation, which matches this analysis. KillThemWithKindness concedes that "Both B and D works, but D is more centralized," which is the deciding factor here. TeeTheMan argues for B on step count and questions "why would you want to pollute the event bus of the main account," but centralizing inbound events on one bus is precisely the intended, permission-controlled design. haaris786 and good_ favor A, which rests on the false premise that EC2 can be configured to deliver to another account's bus, and trieudo correctly discards A and C for the same maintenance and latency reasons.
Official Reference
Exam Strategy
On multi-account aggregation questions, look for the pattern that centralizes ingress with a resource-based policy on the receiving event bus, since cross-account EventBridge buses are the AWS-recommended design. Be skeptical of any option that claims EC2 can be reconfigured to emit to another account, or that proposes scheduled Lambda scanning of live resources.
Frequently Asked Questions
Can Amazon EC2 lifecycle events be configured to go straight to the main account's event bus?
No. EC2 state-change events are emitted to the default event bus of the account where the instance runs; cross-account delivery requires an EventBridge rule forwarding them to another account's bus.
Why not give the SQS queue a resource policy and target it directly from each account?
A cross-account rule can target a foreign SQS queue when the queue policy permits it, but that scatters ingestion control across accounts. Centralizing on one event bus gives a single governed entry point, which AWS recommends.
Related Analysis
Practice All DVA-C02 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DVA-C02 Practice Test →