Free AWS SOA-C03 Actual Exam Questions - Question 5 Discussion
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?
This seems like it’s about permissions on the event bus itself, so I’m thinking option C. Just having IAM roles isn’t enough; the target event bus needs a resource policy that specifically allows those sender accounts to put events. Without that explicit permission, the events get blocked, even if everything else looks set up right.
B/C? Cross-region routing isn’t automatic, and bus needs explicit permission.
Probably C. Even if IAM roles allow PutEvents, the event bus itself needs a resource policy explicitly permitting those sender accounts. Without that, the events won’t be accepted by the receiver’s event bus.
Maybe B makes sense since EventBridge doesn’t natively support cross-region event routing. The events generated in us-east-1 wouldn’t automatically reach the event bus in us-west-2 unless you set up something like EventBridge Replication or a custom solution. Also, the question mentions the test events are from us-east-1 but the receiver is in us-west-2, which seems to be the core issue here rather than permissions or policies. So the Lambda function never sees those events because they just don’t arrive across regions.
Option C could be the problem here. Even if the IAM roles allow PutEvents, the event bus in the receiver account needs a resource-based policy explicitly allowing those sender accounts to put events. Without that, the events won’t be accepted, so the Lambda won’t get triggered. The question doesn’t mention any resource policy changes, so that might be the missing piece. Cross-region issues are valid, but EventBridge does support cross-region event buses if configured properly, and the question says rules exist in both accounts.
Cross-region event routing isn’t supported natively, so B.
The key issue sounds like cross-region event delivery isn’t supported natively, so the Lambda in us-west-2 won’t get events directly from us-east-1. That points to option B.
Actually, I think B makes the most sense here. EventBridge doesn’t support sending events directly across different regions, so events created in us-east-1 won’t get to the event bus in us-west-2. The question states the test events are from us-east-1 but the target is in us-west-2, so the cross-region limitation is probably why the Lambda isn’t triggered. Even if permissions and resource policies are set right, that regional boundary stops the events from flowing.
Probably C. Even with IAM roles set, if the event bus in the receiver account lacks a resource policy allowing PutEvents from sender accounts, events won’t be accepted or processed.
The main issue seems to be with option B. EventBridge doesn’t support sending events directly across different regions. Since the events originate in us-east-1 but the target event bus and Lambda are in us-west-2, the events won’t get routed properly no matter the permissions. Even if the resource policy on the event bus allows PutEvents, cross-region delivery of events isn’t supported by default. So, the problem isn’t just permissions but the fundamental limitation of EventBridge with cross-region event routing.
C/D? The question mentions IAM roles in sender accounts that allow PutEvents, but it doesn’t say if the event bus’s resource policy in the receiver account explicitly allows those sender accounts. Without that permission, PutEvents calls would fail. Also, the receiver’s rule not specifying account IDs might cause it to miss filtering correctly. Still, the bigger issue might actually be the cross-region sending; EventBridge can’t directly route events across regions without some workaround, which is why events from us-east-1 aren’t processed in us-west-2. So the problem could be both missing pe
Maybe B here. EventBridge doesn’t let you send events directly across regions, so the events generated in us-east-1 won’t reach the us-west-2 event bus. Even with correct permissions, this cross-region limitation would prevent the Lambda from seeing those events. The question says the events come from us-east-1 but the receiver is in us-west-2, which is likely the core issue. The setup might need to use a different approach like replicating events or setting up regional bridges instead of assuming cross-region event delivery works out of the box.
EventBridge doesn’t support sending events directly across regions, so events from us-east-1 won’t reach the us-west-2 event bus. Could the cross-region limitation be the real blocker here?
C The resource-based policy on the target event bus likely doesn’t allow PutEvents from the sender accounts, which is needed for cross-account event routing to work properly.
Good point, the resource policy on the event bus definitely needs to allow PutEvents from sender accounts, so C.
D The rules not specifying the account parameter could be the key here. Without explicitly filtering for the sender account IDs in the receiving account’s rule, those events might get ignored, especially in cross-account setups. Even if events arrive, the Lambda won’t trigger if the pattern doesn’t match. So, adding {"account": ["sender-account-id"]} makes sure the receiver only processes events from the intended sources, which is critical in multi-account architectures like this.
Option D could be the problem because if the receiving account’s rule doesn’t explicitly include the sender account ID in its event pattern, it might simply ignore those events. Even if events reach the receiver’s event bus, the Lambda won’t trigger without a matching rule. Since the question says the rules don’t specify an account parameter, the receiver’s rule might be too broad and filtering out events unintentionally. Adding the sender account ID to the event pattern ensures only relevant events get processed. This seems like a common oversight with cross-account event routing.
Maybe C. Even with IAM roles set up, if the receiver event bus lacks a resource-based policy allowing PutEvents from sender accounts, the event won't go through. That policy is essential for cross-account event delivery.
Maybe D is it. The receiving account’s rule might need to filter specifically by sender account IDs to catch those events. Without that, events from other accounts could get ignored.
Events won’t be processed if the event bus policy in the receiver account doesn’t explicitly allow PutEvents from the sender accounts. Without this, the calls get denied despite IAM roles being set up, so C makes sense here.