A small municipal IT shop runs a custom ticket-binder service on self-managed servers and spends too much time patching the queue layer. What change best reduces infrastructure provisioning and patching overhead?
Select an answer to reveal the explanation.
Short Explanation
If you are patching the queue instead of fixing tickets, you own the wrong problem. Hand the binder to a managed queue like SQS and spend the hours on civic work, not broker babysitting.
Full Explanation
Small municipal IT teams often inherit custom ticket-binder services that run on self-managed brokers, which forces ongoing OS patching, clustering care, and capacity babysitting unrelated to citizen outcomes. Migrating that binder to a managed queue such as Amazon SQS transfers undifferentiated infrastructure work to the cloud provider so staff can focus on application logic, permissions, and dead-letter handling instead of broker patching. Adding more self-managed EC2 brokers increases capacity while preserving the same operational burden. Rewriting the binder as a desktop Access database on one workstation destroys availability, multi-user scale, and recoverability for a civic workflow. Exposing self-managed brokers on the public internet to simplify networking expands attack surface without reducing patching overhead. Exam caveat: managed queues change semantics—ordering guarantees, exactly-once expectations, and poison-message handling must be redesigned rather than lifted unchanged from a bespoke broker. Operational check: pilot a producer/consumer path through SQS with IAM least privilege, validate DLQ alarms, compare weekly patch hours before and after cutover, and confirm ticket throughput meets service-desk SLAs.