Examkin

Question

Difficulty: HardServerless Development with AWS Lambda

A developer is implementing a serverless data processing application where an Amazon Kinesis data stream triggers an AWS Lambda function via an event source mapping. During high-traffic periods, temporary downstream database connection failures cause the Lambda function to fail when processing certain batches. This results in the entire batch of records being repeatedly retried, causing head-of-line blocking and redundant processing of valid records. The developer wants to isolate the failing records, avoid processing duplicates where possible, and capture failed records for offline analysis without stalling stream ingestion.

Which two configurations should the developer apply to the Lambda event source mapping to meet these requirements? (Select two.)

  1. Set BisectBatchOnFunctionError to true in the event source mapping configuration.Answer
  2. Configure an on-failure destination (DestinationConfig) in the event source mapping to route discarded record metadata to an Amazon SQS queue.Answer
  3. C
    Configure the DeadLetterConfig property of the Lambda function to send failed execution payloads directly to an Amazon SQS queue.
  4. D
    Increase the Lambda function's timeout configuration to match the retention period of the Kinesis data stream.
  5. E
    Modify the Kinesis stream partition key logic to route failed records to a single static key to isolate them in a dedicated shard.

Answer

The correct configurations are to enable BisectBatchOnFunctionError in the event source mapping and configure an on-failure destination on the mapping to route metadata of discarded records to an Amazon SQS queue.
To prevent head-of-line blocking in Kinesis event source mappings, the developer must set BisectBatchOnFunctionError to true. This splits the failed batch into two halves and retries them separately, narrowing down the failure to the specific failing record. To capture failed records without stalling ingestion, the developer should configure an on-failure destination on the event source mapping itself. When a batch reaches its maximum retry limit or maximum record age, Lambda discards the batch and sends metadata (including shard ID and sequence number) to the destination.

Step-by-Step Solution

1
Analyze the event source mapping behavior for stream-based sources.
Identify that by default, a single failed record in a batch causes the entire batch to be retried repeatedly, leading to head-of-line blocking.
This helps locate where the logic for splitting batches and routing failures resides.
2
Select the correct mechanism to isolate failing records within a batch.
Enable BisectBatchOnFunctionError so that Lambda splits the failing batch in half and retries each half independently.
This isolates the problematic record and allows successful records in the original batch to proceed.
3
Select the correct mechanism to capture permanently failing records without blocking the stream.
Configure an on-failure destination on the event source mapping.
Since the stream is polled synchronously by Lambda, standard function-level DLQs do not apply. An on-failure destination ensures that record metadata is captured once retry limits are exhausted.

Key Concept

Error handling configurations for AWS Lambda event source mappings integrated with Amazon Kinesis Data Streams.
Rate this question

Topics

Serverless Development with AWS Lambda

More questions from this topic