Q: 9
A company uses an organization in AWS Organizations to manage multiple AWS accounts. The
company needs to send specific events from all the accounts in the organization to a new receiver
account, where an AWS Lambda function will process the events.
A CloudOps engineer configures Amazon EventBridge to route events to a target event bus in the us-
west-2 Region in the receiver account. The CloudOps engineer creates rules in both the sender and
receiver accounts that match the specified events. The rules do not specify an account parameter in
the event pattern. IAM roles are created in the sender accounts to allow PutEvents actions on the
target event bus.
However, the first test events from the us-east-1 Region are not processed by the Lambda function in
the receiving account.
What is the likely reason the events are not processed?
Options
Discussion
Pretty common on practice tests, it's C. Check the official AWS documentation if you want to see the permissions model.
C , official guide and lab practice cover cross-account EventBridge details like this.
B is wrong, C, . The region trap gets folks but it's the event bus policy that's critical for cross-account puts.
I think it's B here. EventBridge can't invoke a Lambda in a different region directly, so events from us-east-1 wouldn't trigger the us-west-2 Lambda. Someone correct me if that's off?
C or D. I think it's the event pattern in D since without specifying accounts, events might not match. What do you think?
Nah, not D. It's C since the missing event bus permissions block cross-account events, not the event pattern filter.
C, Not about event pattern, this is a permissions thing on the event bus. See this tripping up on org accounts a lot, but let me know if you think otherwise.
Its C here. You actually need a resource-based policy on the target event bus to allow PutEvents from other accounts, otherwise cross-account sends just get dropped. D is a trap since account filter only impacts matching, not permissions. Correct me if I'm missing anything!
Probably C, since EventBridge needs that resource-based policy on the event bus for cross-account PutEvents to actually go through. Without it, sender accounts can't deliver events even if their IAM roles allow it. Pretty sure from the official AWS doc and a similar practice test. Official guide explains this gotcha pretty well, worth reviewing.
Its D for me. Since the rule in the receiving account doesn't mention the sender account ID, maybe that's why the Lambda isn't triggered-event pattern could be filtering them out. In cross-account EventBridge, I thought specifying accounts in the rule can matter for matching events correctly. I'm not 100% positive, but feels like a matching issue over permissions here. Disagree?
Be respectful. No spam.
