Multiple municipal apps publish inspection.completed events; a single analytics consumer should not be wired into each publisher's code. Which EventBridge approach keeps publishers decoupled?
Select an answer to reveal the explanation.
Short Explanation
Put inspection.completed on a shared bulletin board — a custom EventBridge bus — instead of teaching every app the analytics team's phone number. Publishers post; rules deliver. Nobody rewires when a new consumer shows up.
Full Explanation
When multiple municipal apps publish inspection.completed events and a single analytics consumer must not be wired into each publisher’s code, use a custom EventBridge event bus and rules so publishers put events on the bus and consumers subscribe independently. Publishers know the bus and event shape; they do not know the analytics Lambda ARN. Rules route matching events to targets. Adding or replacing analytics sinks becomes a rule change, not a multi-app release train.
Hard-coding the analytics Lambda ARN inside every publisher and invoking synchronously recreates tight coupling and dual-write failure modes. Giving each publisher its own copy of analytics code duplicates logic and drifts schemas. Requiring publishers to write directly to the analytics team’s DynamoDB table exposes foreign schemas and IAM across team boundaries.
Exam caveat: default bus versus custom bus is an organization choice; custom buses help isolate municipal domains. Schema registries or careful versioning prevent breaking consumers. EventBridge is not a durable queue by itself—buffer with SQS if needed.
Operational check: define inspection.completed on a custom bus; publishers PutEvents only; analytics subscribes via rules; confirm a new publisher needs no analytics redeploy; and monitor failed invocations / DLQs on the consumer path.