Protect secrets and cloud access

Production deployment obtains a short-lived cloud credential through OIDC only after the protected environment is approved. That contrast gives us something useful to test instead of a rule to memorize.

Secret masking is not a permission boundary, and a secret exposed to a process can often be exfiltrated by that process. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can store one permanent administrator key as a repository secret and expose it to every job and still get one successful demo. Push past the demo. use environment scoping, least privilege, short-lived identity, rotation, and no secret access for untrusted code, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Reduce workflow authority and prevent untrusted repository input from becoming privileged code execution. Save the before-and-after evidence now; it will make the final project review much more honest.

Inventory every secret and replace one long-lived deployment credential with an identity-based flow or a narrower alternative. Save the evidence, then explain which requirement would force you to choose a different design.