Exercise 3: Why Hardcoded Credentials in a Provider Block Are Dangerous — Possible Solution
====================================================================

Writing `access_key`/`secret_key` directly into a `.tf` file means the
real, working AWS credential now exists as plaintext inside a file that
-- per this course's own established workflow -- gets committed to git
alongside the rest of the configuration. Per the warn-box's own framing
(echoing `pipelines1-5` and `crypto1-11` directly), a committed
credential is compromised the moment it's pushed, PERMANENTLY, even if
it's later removed from the latest commit -- git retains the full
history, so the credential remains recoverable by anyone with read
access to the repository (or its history) indefinitely, regardless of
whether the file is edited or deleted afterward.

This is a materially worse exposure than a typical leaked secret,
because Terraform credentials specifically tend to carry broad
provisioning permissions (create/modify/delete real infrastructure) --
so a leaked key isn't just a data-exposure risk, it's a direct path to
an attacker creating or destroying real, billable cloud resources under
the account's own name.

What to do instead: read credentials from environment variables (e.g.
`AWS_ACCESS_KEY_ID`/`AWS_SECRET_ACCESS_KEY`, which the AWS provider
picks up automatically without any explicit block content) or from a
separate, git-ignored credentials file (e.g. `~/.aws/credentials`,
outside the project directory entirely). Either approach keeps the
credential itself out of any file that could ever be committed, while
the `provider "aws" {}` block in the actual configuration stays empty
of secrets and safe to share.

WHY THIS WORKS AS AN ANSWER
------------------------------
This applies the specific "committed forever, even after removal" logic
from `pipelines1-5`/`crypto1-11` to this exact scenario, adds the
Terraform-specific aggravating factor (broad provisioning permissions,
not just data exposure), and names concrete, currently-standard
alternatives (env vars, a git-ignored credentials file) rather than a
vague "use a secrets manager" gesture.