SAA-C03 Practice Question 64: Amazon MQ Broker Migration
AWS Certified Solutions Architect – Associate (SAA-C03) · Test 7 · question 4 of 10
A logistics company is moving a Java application to AWS on a tight schedule. The application talks to a self-managed Apache ActiveMQ broker over JMS and relies on topics with durable subscriptions and on message selectors. The company wants to stop patching and operating broker servers, and the migration budget does not allow the messaging layer to be rewritten.
What should the solutions architect recommend?
Show answer and explanation
Answer:
Amazon MQ is a managed message broker service for Apache ActiveMQ and RabbitMQ that handles setup, operation, maintenance windows and version upgrades. Because it runs the actual broker software and speaks the industry-standard protocols, an existing application can be migrated without rewriting messaging code; the JMS client, the durable subscriptions and the message selectors all continue to work against the managed endpoint. That satisfies both constraints at once: no broker servers to operate and no messaging rewrite.
Option A is the right destination for a greenfield design but the wrong one here. SQS and SNS expose AWS-native APIs rather than JMS, and features such as JMS message selectors have no direct equivalent, so the messaging layer would have to be rewritten, which the budget rules out.
Option C keeps the JMS compatibility and throws away the operational benefit: the company still patches ActiveMQ, manages broker state and handles failover itself. Fronting brokers with a load balancer also does not give an ActiveMQ cluster its high availability, which comes from the broker's own failover configuration.
Option D swaps a message broker for a streaming service with different semantics: ordered, replayable shards rather than queues, topics and per-consumer acknowledgement, and requires exactly the rewrite that was excluded.
Reference: What is Amazon MQ?