A municipal payments topic carries fee and refund events that many microservices can see on the shared bus. What security basic should the platform enforce?
Select an answer to reveal the explanation.
Short Explanation
The payments bus is not a bulletin board for every city app. Lock who can write and who can read that topic—like badge access to a cash room. Shared messaging still needs authorization, not open-mic publishing.
Full Explanation
Municipal payments topics on a shared bus must enforce least-privilege publish and subscribe rights so only authorized services may produce or consume fee and refund events. Topic-level authorization limits blast radius when many microservices share infrastructure and keeps payment streams from becoming an open bulletin board. Pairing ACLs with encryption and audit where policy requires is part of ingestion security, not an optional afterthought.
Allowing any authenticated city service to publish or subscribe to every topic by default violates least privilege and invites accidental or malicious payment-event exposure. Relying only on network firewalls while leaving topic ACLs unused ignores application-layer identity and the reality that many services already share the messaging network. Publishing payment payloads in clear text for troubleshooting convenience undermines confidentiality and complicates compliance even when network controls look tidy.
Exam caveat: authorization on the bus does not replace payload protection, key management, or application authentication of the business transaction itself—defense in depth still applies. Operational check: attempt a subscribe and a publish from a non-authorized service account in a non-production payments topic and confirm both are denied, then verify authorized producers and consumers still succeed and leave audit evidence.