Operators need the same request identifier in API Gateway access logs, Lambda logs, and X-Ray traces for a single citizen complaint. What practice enables that correlation?
Select an answer to reveal the explanation.
Short Explanation
Chasing one citizen ticket across three tools without a shared id is like hunting a library book with three different call numbers. Carry one request or correlation id through API Gateway, Lambda logs, and X-Ray. Then one complaint becomes one story.
Full Explanation
Operators who need the same request identifier in API Gateway access logs, Lambda logs, and X-Ray traces for a single citizen complaint must propagate one correlation or request ID across those layers. Consistent IDs turn three observability systems into one investigation story. Generating new random IDs at each hop breaks the narrative municipal support depends on.
Generating a new random id in every layer and never passing it downstream prevents cross-signal correlation.
Logging only the Lambda memory size cannot reconstruct a request identity across systems.
Disabling API Gateway access logs to reduce identifier noise removes a critical piece of the correlation chain.
Exam caveat: Propagate request/correlation IDs end-to-end; align log fields with X-Ray annotations/trace IDs where possible.
Operational check: Pass API Gateway requestId into Lambda logs and X-Ray annotations, reproduce a complaint scenario, query all three systems by that ID, and confirm support runbooks use the same key. Keep the civic/municipal context in mind: one citizen complaint should not require three disconnected forensic hunts across gateway, function, and traces. Document the finding in the municipal incident ticket so the next on-call engineer inherits evidence rather than folklore.