A Lambda that calls a slow legacy mainframe still uses the default 3-second timeout and fails mid-transaction even though the business allows 45 seconds. What should the developer do?
Select an answer to reveal the explanation.
Short Explanation
If the mainframe needs up to 45 seconds on the phone, don't hang up at three. Align the Lambda timeout with the real SLA—and don't blindly max every function at 15 minutes or fake success. Retries on a too-short timeout just restart the same mid-transaction failure.
Full Explanation
A Lambda that calls a slow legacy mainframe still using the default 3-second timeout will fail mid-transaction even when the business allows 45 seconds. Set the function timeout to match the workload SLA (for example 45 seconds) without exceeding downstream limits needlessly. Timeouts should reflect real municipal integration latency, not leftover defaults. Align API Gateway/integration timeouts as well so the edge does not cut the function first.
Leaving the default 3-second timeout and adding more asynchronous retries that restart the same transaction risks duplicate mainframe side effects without fixing the too-short sync budget. Setting every function to the 15-minute maximum hides hung work and complicates incident response. Removing the mainframe call and returning a static success payload falsifies outcomes clerks rely on.
Exam caveat: longer timeouts consume concurrency longer on slow calls—pair with correct IAM, idempotency keys, and maybe async patterns if waiting is not required on the citizen path. Nested service timeouts (Gateway, ALB, Step Functions) must be consistent.
Operational check: measure mainframe p95/p99 latency; set Lambda timeout slightly above SLA needs; align upstream timeouts; make posts idempotent; and alarm on duration approaching the timeout ceiling.