DVA-C02 Troubleshooting and Optimization 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.

• ✗

  Increase memory to 10 GB only

  Why it's wrong here

  Increasing a Lambda function's memory allocation primarily enhances its computational capacity and allows it to process larger datasets in memory or execute more complex logic faster. While this might prevent timeouts or out-of-memory errors for a healthy batch, it does not directly address the problem of repeated failures caused by specific malformed records within a Kinesis stream batch. It lacks a mechanism to identify, isolate, and reprocess or discard problematic individual records, leading to continued processing issues if a bad record persists.

• ✗

  Disable batch processing

  Why it's wrong here

  Disabling batch processing for a Kinesis event source by setting the batch size to 1 would indeed ensure that each record is processed individually. While this isolates failures to a single record, it drastically increases the number of Lambda invocations, leading to higher operational costs and potentially reduced throughput. Furthermore, processing one record at a time does not inherently provide a mechanism to handle the *failure* of that single record; the function would still fail, and the problematic record would continue to block progress without a dedicated error destination.

• ✓

  Configure failure handling with bisect batch on error and an on-failure destination where supported

  Why this is correct

  Configuring `ReportBatchItemFailures` (often referred to as "bisect batch on error" in the console) for a Kinesis event source allows the Lambda function to return a partial success, indicating which specific records within a batch failed. Lambda then automatically retries only the failed records, potentially splitting the batch further to isolate the problematic items. Combining this with an on-failure destination, such as an SQS queue or SNS topic, ensures that records that ultimately cannot be processed are sent to a dead-letter queue for analysis and manual intervention, preventing them from indefinitely blocking the stream processing.

• ✗

  Convert the stream to an S3 bucket

  Why it's wrong here

  Converting a Kinesis Data Stream to an S3 bucket represents a fundamental architectural change, shifting from a real-time streaming paradigm to an object storage model. While Kinesis data can be delivered to S3 via Kinesis Firehose for archival or batch processing, replacing the stream entirely with S3 would eliminate the real-time, low-latency processing capabilities inherent to Kinesis. This option does not address the problem of handling individual record failures within a streaming context; instead, it redefines the entire data ingestion and processing pipeline, which is not what the question implies.