A developer connects a Lambda function to an Amazon SQS standard queue using an event source mapping. The function occasionally fails when a downstream API is briefly unavailable, and those failed batches are retried so often that good messages are delayed. The developer wants messages that repeatedly fail to be set aside automatically for later inspection without losing them. What should the developer configure?
- AEnable Lambda provisioned concurrency on the function so failing batches are processed faster and stop blocking the rest of the queue.
- BLower the function timeout so failing invocations end quickly and SQS can return the messages to the queue for a faster overall retry cycle.
- CConfigure a redrive policy on the source queue with a dead-letter queue and a maxReceiveCount so repeatedly failed messages move there. Correct
- DSet a Lambda on-failure destination pointing at the dead-letter queue, because event source mapping batch failures are delivered through destinations.
Why A is wrong: Provisioned concurrency reduces cold-start latency but does nothing about poison messages, so the same batches keep failing and there is still no place to set them aside.
Why B is wrong: A shorter timeout only makes each failed attempt end sooner, so the poison messages keep returning to the queue and are never moved aside for inspection.
Why C is correct: The SQS redrive policy moves a message to the dead-letter queue once its receive count exceeds maxReceiveCount, isolating poison messages so good ones flow while the failures are kept for inspection.
Why D is wrong: On-failure destinations apply to asynchronous invocations, not to SQS event source mapping batches, so for an SQS source the queue's own redrive policy is the correct mechanism.