Exercise 2: Hardcoded Keys vs. an IAM Role — Possible Solution
====================================================================

The real, standard alternative is to attach an IAM role directly to
the EC2 instance itself, rather than embedding a long-term access key
in the application's own code. AWS automatically issues temporary
credentials to any process running on that instance through the
role, and automatically rotates those credentials on a real, ongoing
basis -- the application's own code never needs to store, reference,
or even see a long-term secret at all.

This avoids the specific risk in the scenario entirely because there
is no long-term credential embedded in the code in the first place.
Even if that exact same code were accidentally committed to a public
repository, there would be nothing sensitive in it to leak -- no
access key, no secret, nothing an attacker could extract and reuse.

ANSWER: Using an IAM role instead of a hardcoded access key removes
the vulnerability at its root, rather than just making it harder to
exploit: the application never possesses a long-term credential that
could be accidentally exposed, so a public code leak -- exactly the
scenario described -- causes no real credential compromise at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies that the fix isn't "be more careful with
the key" (better secrets management, environment variables, etc.) but
a structurally different approach that removes the long-term
credential from the picture entirely -- matching the chapter's own
explicit tip-box guidance that roles are the real default for AWS
services, not merely one option among several.