Q13 — AWS SAA-C03 Ch.16

Question 13 of 100 | ← Chapter 16

Q1213. A company is building a serverless application that processes large volumes of data from a mobile app.The application uses an AWS Lambda function to process the data and store the data in an Amazon DynamoDB table.The company needs to ensure that the application can recover from failures and continue processing data without losing any records.Which solution will meet these requirements?

Correct Answer: A. Configure the Lambda function to use a dead-letter queue with an Amazon Simple Queue Service (Amazon SQS) queue. Configure Lambda to retry failed records from the dead-letter queue. Use a retry mechanism by implementing an exponential backoff algorithm.

Explanation

To ensure that the serverless application can recover from failures and continue processing data without losing any records, the most suitable solution is:A. Configure the Lambda function to use a dead-letter queue with an Amazon Simple Queue Service (Amazon SQS) queue. Configure Lambda to retry failed records from the dead-letter queue. Use a retry mechanism by implementing an exponential backoff algorithm.Analysis:Dead-Letter Queue (DLQ) with Amazon SQS:Failure Handling: When a Lambda function fails to process a record, the record can be sent to a dead-letter queue (DLQ). Amazon SQS is a fully managed message queuing service that can be used as a DLQ to store these failed records.Message Retention: SQS retains messages for a configurable period (up to 14 days), allowing you to retry processing these records at a later time.Retry Mechanism with Exponential Backoff:Exponential Backoff: Implementing an exponential backoff algorithm for retries helps to avoid overwhelming the system with repeated attempts in quick succession. This approach increases the delay between retries exponentially, giving the system time to recover from transient failures. Reliability: By combining a DLQ with SQS and an exponential backoff retry mechanism, you can ensure that the application can recover from failures and continue processing data without losing any records.Why Other Options Are Not Suitable:B. Configure the Lambda function to read records from Amazon Data Firehose and replay records in case of failures:Firehose Design: Amazon Kinesis Data Firehose is designed for delivering streaming data to destinations like Amazon S3, Amazon Redshift, or Amazon Elasticsearch Service. It is not intended for replaying records in case of processing failures within a Lambda function. Lack of Direct Retry Mechanism: Firehose does not provide a built-in mechanism for retrying failed records within a Lambda processing context.C. Use Amazon OpenSearch Service to store failed records and retry from there:Inappropriate Use Case: Amazon OpenSearch Service (formerly Elasticsearch) is primarily used for search and analytics, not for storing and retrying failed records from a Lambda function. Complexity: Implementing a retry mechanism using OpenSearch would add unnecessary complexity to the solution and is not the intended use case for this service. D. Use Amazon Simple Notification Service (Amazon SNS) to store failed records and retry from an SNS topic:SNS Design: Amazon SNS is a fully managed messaging service for both application-to-application (A2A) and application-to-person (A2P) communication. It is not designed for storing and retrying failed records from a Lambda function.Lack of Message Retention for Retries: SNS topics do not retain messages for retry purposes; they are designed for immediate delivery to subscribers.In summary, option A provides a robust and reliable solution for handling failures in a serverless application by using a dead-letter queue with Amazon SQS and implementing an exponential backoff retry mechanism.