A poison record in a Kinesis batch causes the water-quality Lambda to fail the entire batch and stall shard iterator progress. What should the developer apply?
Select an answer to reveal the explanation.
Short Explanation
One bad water-quality blip should not freeze the whole stream like a jammed conveyor. Bisect-on-error (and similar tactics) isolates the poison pill so the shard can keep moving. Deleting the stream is using a sledgehammer on a sticky label.
Full Explanation
When a poison record in a Kinesis batch causes the water-quality Lambda to fail the entire batch and stall shard iterator progress, apply bisect-on-error or related partial-failure strategies so one bad record does not permanently stall the shard. Bisect splits the failing batch, isolates the poison record, and lets good measurements continue advancing the iterator. Water-quality monitoring cannot afford a single malformed payload freezing an entire shard’s worth of sensor truth.
Increasing the batch window indefinitely and never surfacing errors hides data-quality problems while delaying detection. Deleting the Kinesis stream after the first failure and recreating it empty destroys history and operational continuity. Disabling CloudWatch metrics for IteratorAge so stalls go unnoticed removes the primary lag signal operators need.
Exam caveat: configure bisect-on-error on the event source mapping and still send true poison to a DLQ or quarantine bucket after isolation. Idempotent writes remain necessary because bisect reprocesses subsets. Monitor IteratorAge religiously for public-health data paths.
Operational check: enable bisect-on-error; inject a poison record in non-prod; confirm the shard continues and the bad record is quarantined; alarm on IteratorAge; and document how analysts fix and replay quarantined payloads.