The best solution is to create an Amazon Simple Queue Service (Amazon SQS) queue, update the data-producing services to send messages to the queue, and configure the consumer services to process messages from the queue. SQS decouples producers and consumers, enabling horizontal scaling of each independently. It also guarantees at-least-once delivery and supports reliable, asynchronous processingideal for workloads where the order of processing results does not matter.

Why the other options are incorrect:

Using Amazon SNS is better suited for fan-out scenarios where a message is broadcast to multiple subscribers simultaneously. It lacks built-in queuing and message persistence, making it less reliable for decoupled, asynchronous microservice communication in this context.

Using AWS Lambda as a message-passing layer is not a scalable or maintainable architectural choice. Lambda is designed for event-driven compute, not for managing message queues or acting as a relay between microservices. This also introduces unnecessary latency and complexity.

Using DynamoDB with DynamoDB Streams is intended for data change capture and replication use cases, not for inter-service communication. It would unnecessarily tie microservices to a shared data store and would not provide message queue semantics like visibility timeouts, retries, or dead-letter queues.

Why this question matters: This scenario tests knowledge of asynchronous messaging, service decoupling, and appropriate AWS service selection for building scalable, modern microservices architectures. Choosing the right mechanism for inter-service communication is critical for performance and maintainability.

Exam tip: If the question mentions microservices, decoupling, asynchronous processing, or scaling producers and consumers independently, Amazon SQS is often the right choice. Be cautious about using SNS or Streams unless broadcasting or data-change tracking is specifically mentioned.

Full AWS Practitioner Certification Question