Q54 — AWS SAA-C03 Ch.17

Question 54 of 89 | ← Chapter 17

Q1354. A media publishing company is building an application on AWS to give users the ability to print their own books. The application frontend runs on a Docker container.The amount of incoming orders varies significantly. The incoming orders can temporarily exceed the throughput of the company's book printing machines. Order-processing payloads are up to 4 MB in size.The company needs to develop a solution that can scale to handle incoming orders.Which solution will meet this requirement?

Correct Answer: C. Use Amazon SQS to queue incoming orders. Create an AWS Lambda function to process orders.Deploy the frontend application on Amazon ECS with the AWS Fargate launch type.

Explanation

The correct answer is C. Use Amazon SQS to queue incoming orders. Create an AWS Lambda function to process orders. Deploy the frontend application on Amazon ECS with the AWS Fargate launch type.Explanation:The requirements are:Handle variable incoming orders (scalable solution).Process orders that may exceed printing machine throughput (decouple order intake from processing). Order payloads up to 4 MB (message size limitation consideration). Frontend runs in a Docker container (container-based deployment).Why Option C is correct:Amazon SQS (Standard Queue):Decouples order intake from processing: Orders are queued when demand exceeds printing capacity. Handles variable load: Automatically scales with incoming traffic. Supports up to 256 KB per message natively (but can use SQS Extended Client for larger payloads up to 2 GB).Alternative for 4 MB payloads: Store the payload in S3 and send the S3 URL in the SQS message.AWS Lambda for order processing:Serverless scaling: Automatically scales to process orders from the queue.Cost-efficient: Pays only for compute used.Frontend on Amazon ECS with AWS Fargate:Docker container support: ECS + Fargate is a fully managed container orchestration service. Scalable: No need to manage EC2 instances; Fargate handles scaling.Why the other options are incorrect:A. Use SQS + Lambda@Edge + Amazon EKSIncorrect:Lambda@Edge is for edge computing (CloudFront CDN), not order processing. Amazon EKS is Kubernetes-based, which is overkill for this use case (Fargate is simpler).B. Use SQS + Lambda + AWS Fargate (without ECS)Incorrect:AWS Fargate requires ECS or EKS to run containers--it cannot directly process SQS messages. Lambda processes SQS, but the frontend must be deployed via ECS/EKS + Fargate.D. Use SNS + Lambda@Edge + Amazon EC2Incorrect:SNS is a pub/sub service, not a queue--orders could be lost if no subscribers are ready.Lambda@Edge is not suitable for order processing.EC2 requires manual scaling, which contradicts the requirement for a scalable solution.Key Considerations:SQS vs. SNS:SQS is a queue (decouples producers/consumers, ensures message persistence). SNS is a pub/sub system (broadcasts messages to multiple subscribers, no queueing). Since orders must be processed sequentially (or at least not lost), SQS is the right choice.Handling large payloads (4 MB):SQS has a 256 KB limit per message, but:Store the payload in S3 and send the S3 URL in the SQS message. Use the SQS Extended Client library to handle larger payloads.Frontend deployment:ECS + Fargate is the best choice for Docker containers without managing servers.EKS is unnecessary unless Kubernetes features are needed.EC2 requires manual scaling, which is not ideal for variable workloads.Correct Architecture (Option C):Frontend (Docker container) Amazon ECS + Fargate (scalable, serverless containers).Orders Amazon SQS (queued for processing).SQS triggers AWS Lambda Processes orders (scales automatically). If payload > 256 KB: Store in S3, send S3 URL in SQS message.Conclusion:Option C is the only solution that meets all requirements:SQS for decoupling and scalability.Lambda for serverless order processing.ECS + Fargate for scalable Docker frontend.The other options either misuse services (Lambda@Edge, SNS) or lack proper scaling (EC2).