Exercise 2: Why a 45-Minute Job Doesn't Fit Lambda — Possible Solution
====================================================================

Every Lambda function has a real, hard maximum execution timeout of
15 minutes -- this is not a soft default that can be raised with a
configuration change or a bigger budget; it's an absolute architectural
ceiling on how long any single invocation is allowed to run, no
matter what.

A job that reliably takes about 45 minutes to complete is three times
longer than Lambda's own real maximum. AWS would forcibly terminate
the function partway through, every single time it ran, regardless of
how much is spent on it or how the function itself is configured.

ANSWER: Lambda is a poor fit here specifically because of its real,
fixed 15-minute execution ceiling -- a 45-minute job simply cannot
complete within a single Lambda invocation, full stop. This isn't a
cost or efficiency concern that a different pricing tier could fix;
it's a hard architectural limit that rules Lambda out entirely for
this specific job. An EC2 instance (Chapter 3), which has no such
ceiling on how long a process may run, would be the correct fit
instead.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the reason as a hard, non-negotiable
architectural limit rather than a cost or performance tradeoff --
directly matching the chapter's own warn-box framing that some
workloads "don't fit Lambda's own execution model at all," not merely
"cost more on Lambda than elsewhere."