Account A must put events onto an EventBridge event bus in Account B for a multi-account city services mesh. What must be true?
Select an answer to reveal the explanation.
Short Explanation
Cross-account EventBridge is a two-sided handshake: the producer needs permission, and Account B’s bus policy has to welcome that principal. Matching detail-type text does not erase account walls. Public writable buses are not the pattern.
Full Explanation
Cross-account PutEvents onto an EventBridge event bus requires cooperation on both sides of the city services mesh. The producer in Account A needs identity permissions to call events:PutEvents, and Account B must attach an event bus resource policy that allows the cross-account principal. Omitting the bus policy leaves Account A unable to deliver events even when its identity policy looks correct.
Claiming only Account A’s identity policy matters is incomplete for cross-account EventBridge. Matching detail-type strings does not erase account boundaries. Making the event bus publicly writable from the internet without authenticated AWS principals is not the supported mesh pattern and is unsafe for municipal event fabrics.
Exam caveat: also review rule targets, KMS key policies if the bus uses customer managed keys, and any Organizations SCPs that might Deny events:PutEvents. Operational check: grant both identity and bus policy sides, PutEvents from Account A, and confirm Account B rules receive the event; remove the bus policy allow and confirm puts fail, proving the resource policy was required. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.