Inspection events land in an SQS dead-letter queue. Opening the poison messages shows a newer JSON schema the consumer does not understand yet. What should analysis conclude?
Select an answer to reveal the explanation.
Short Explanation
Dead-letter queues are the trash drawer with receipts. Open those poison messages and you often find a schema the consumer never learned yet.
Full Explanation
Inspection events landing in an SQS dead-letter queue with poison payloads showing a newer JSON schema the consumer cannot parse indicate a producer/consumer contract break. DLQ inspection is doing its job: repeated processing failures for schema-mismatched messages move them aside so the municipal inspection pipeline can analyze and version consumers without endlessly retrying poison. Conclude schema mismatch first, then plan coordinated rollout or tolerant readers.
DLQ depth does not always mean the producer used the wrong Region spelling; Region issues usually appear as endpoint/permission errors earlier.
A full VPC redesign is unnecessary for message schema failures; networking theater will not parse new JSON fields.
CloudTrail management events record control-plane API calls; they do not replace opening the DLQ payload to see schema fields.
Exam caveat: Always inspect DLQ message bodies for poison root causes—schema, permissions inside the handler, or bad data—before redesigning infrastructure.
Operational check: Sample DLQ messages, document the schema delta, ship a backward-compatible consumer or dual-write producer plan, replay or quarantine deliberately, and alarm on DLQ age/depth for the inspection queue. Keep the civic/municipal context in mind: city inspection systems evolve forms often; contract tests between producers and consumers prevent silent DLQ pileups.