A municipal permit queue grows because an SQS-triggered Lambda’s batch size and visibility timeout do not match how long each batch takes to process. What is the most likely integration problem?
Select an answer to reveal the explanation.
Short Explanation
Picture a ticket window that locks tickets for two minutes while clerks need five—the line explodes. Same story when SQS visibility timeout and Lambda batch size do not match real processing time.
Full Explanation
If a municipal permit queue grows because an SQS-triggered Lambda's batch size and visibility timeout do not match how long each batch takes to process, the likely integration problem is a misconfigured event-source mapping relative to processing time. Visibility timeout must exceed the time needed to process a batch; otherwise messages reappear and appear as backlog growth or duplicate processing risk. Oversized batches that always time out similarly stall drainage of citizen permit messages waiting in SQS.
CloudFront origin shield sits in front of HTTP origins; it does not drop SQS messages before Lambda. Cognito user-pool MFA settings do not block SQS delivery to functions. An unused Kinesis data stream is not a prerequisite for SQS event-source mappings to drain a permit queue.
Exam caveat: for SQS plus Lambda, align batch size, visibility timeout, function timeout, and partial-batch-failure settings—this is a frequent integration troubleshooting theme on DVA-C02.
Operational check: measure p99 batch processing duration for permit messages, set visibility timeout and function timeout with margin, tune batch size downward if batches cannot finish, enable appropriate failure handling, and watch queue depth and age metrics recover.