CLF-C02 Cloud Technology and Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Amazon SQS

  Why it's wrong here

  Amazon SQS is a fully managed message queueing service, but it interacts via AWS-proprietary REST/Query APIs rather than industry-standard wire protocols such as AMQP, MQTT, OpenWire, or STOMP. A legacy on-premises application that uses the JMS interface with ActiveMQ or RabbitMQ cannot simply point its client at SQS because the connection library and messaging semantics are entirely different. Only by rewriting the application (or using an adapter) could it function, whereas Amazon MQ offers drop-in protocol compatibility.

• ✗

  Amazon SNS

  Why it's wrong here

  Amazon SNS is a pub/sub notification service that pushes messages to subscribers via HTTP/S, email, SMS, or AWS services like SQS and Lambda, not a protocol-compatible replacement for messaging brokers. Its API is AWS-specific and it does not implement the wire-level handshakes and frames that ActiveMQ or RabbitMQ clients use, so a Java Message Service (JMS) application would fail to connect. The service also provides no support for broker features such as exchanges/queues, routing keys, or message acknowledgment semantics used in RabbitMQ.

• ✓

  Amazon MQ

  Why this is correct

  Amazon MQ is a managed message broker service that provisions either Apache ActiveMQ or RabbitMQ clusters, giving you the exact endpoints (e.g., OpenWire, AMQP, MQTT, STOMP, or WebSocket) those engines expose. Because it natively speaks the same wire protocols and supports JMS, ActiveMQ artifacts, and RabbitMQ client libraries, an existing on-premises messaging workload can be lifted and shifted to AWS without rewriting application producer/consumer code. The service also provides automatic provisioning, failover via paired brokers, and durable storage, offloading operations while preserving compatibility.

• ✗

  Amazon Kinesis Data Streams

  Why it's wrong here

  Amazon Kinesis Data Streams is a massively scalable streaming ingestion service designed for real-time data analytics and big data pipelines, not for enterprise message brokering. Its API, through PutRecord and GetRecords actions, is AWS-proprietary and has no knowledge of ActiveMQ or RabbitMQ wire protocols, so a JMS/AMQP client cannot connect to it. Even architecturally it is different: consumers share the shard data and records expire after 24 hours (or up to 365 days with extended retention), whereas a message broker delivers an acknowledged message to a specific consumer.

Go deeper

Related to this question