Exercise 3: Why the Split Shifts Between EC2 and Lambda — Possible Solution
====================================================================

The shared responsibility model isn't a single fixed line -- it moves
depending on how much of the stack a given service manages for you.
EC2 sits at the "unmanaged" end: AWS provides only the virtualized
hardware and networking, leaving the customer responsible for the
entire guest operating system, its runtime, its patching, and
everything installed on top of it.

Lambda sits much further toward the "fully managed" end. AWS doesn't
just provide hardware -- it provides and maintains the entire
operating system, the language runtime (Node.js, Python, etc.), and
the execution environment your function code runs inside. The
customer's own responsibility narrows down to their own function code
itself, the permissions (IAM role) that code runs with, and how it
handles the data it's given.

ANSWER: The split is genuinely different because Lambda's own
"managed" layer extends much further up the stack than EC2's does.
One concrete responsibility that shifts from customer to AWS between
the two: operating-system patching. On EC2, the customer must patch
the guest OS themselves (as in Exercise 2); on Lambda, AWS patches and
maintains the underlying OS and language runtime automatically, and
the customer never has direct access to, or responsibility for, that
layer at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies a specific, concrete responsibility (OS patching) that
demonstrably moves from one side of the line to the other between the
two services, rather than just asserting "Lambda is more managed" in
the abstract -- and it directly ties back to Exercise 2's own real
EC2 patching scenario as the contrasting case.