Exercise 2: Why an IAM Role Beats a Hardcoded Access Key — Possible Solution
====================================================================

Why a role is the correct pattern:

Per the chapter, a role has NO PERMANENT CREDENTIALS of its own -- it
generates short-lived, automatically-expiring credentials only when
it's actually assumed. An application running on a VM can assume a
role scoped with exactly the permissions it needs (e.g., read access
to one specific storage bucket, per the chapter's least-privilege
scoping material) for exactly as long as it's running, with no secret
value that ever needs to be written down, stored, or embedded
anywhere at all.

The real-world risk of hardcoded credentials:

Embedding a permanent access key directly in application code or a
configuration file creates a long-lived secret that has to be
protected everywhere that code exists -- on every developer's laptop,
in every deployment, and critically, in the project's SOURCE CONTROL
HISTORY if it's ever accidentally committed. Per the chapter's own
cross-reference, this site's `pipelines1-5` states plainly that "a
committed credential is compromised forever" -- version history
retains it indefinitely even after the file is later fixed or deleted,
because the credential still exists in every earlier commit. An
attacker who finds that key gains PERMANENT access using it, with no
natural expiration, until someone notices and manually revokes it --
which could be a long time after the initial exposure.

Comparing the two directly: a leaked role-based credential is
short-lived and expires on its own, limiting the exposure window even
in a worst case. A leaked hardcoded permanent key has no such natural
limit -- it remains valid indefinitely until someone actively
revokes it, which is exactly the risk profile `crypto1-11`'s key
management chapter also warns about for any long-lived secret.

WHY THIS WORKS AS AN ANSWER
------------------------------
This connects the chapter's own two explicit cross-references
(`pipelines1-5` and `crypto1-11`) directly to the specific mechanism
that makes roles safer -- not just "roles are best practice" as an
unexplained rule, but the concrete difference between a
short-lived, automatically-expiring credential and a permanent one
that has no natural limit on how long a leak stays dangerous.