6.1.5. Environment Gates and Trustworthy Actions
💡 First Principle: Some risks aren't solvable by configuration alone, so the last line of defense is deliberate friction — a human approval before credentials are released, and a vetting process before a new dependency enters the organization.
Environment protection rules (2.3.3) are the friction mechanism, and their power comes from the ordering: a job targeting a protected environment waits, and its environment secrets are not delivered until the rules pass. Three rules compose: required reviewers (up to six, any one of whom approves; the run waits up to 30 days), a wait timer (a forced delay, useful as a cancellation window for automated deploys), and deployment branch policies (only main, only tags matching v*, or a named ruleset may deploy here). Pair them with an OIDC trust policy keyed on the environment claim (6.1.3) and cloud access itself becomes gated on approval — configuration and cloud policy enforcing the same rule from both sides.
Vetting third-party actions is the process half. The signals to weigh: is the publisher a verified creator; how many repositories depend on it; is the source readable and small enough to review; does it bundle a dist/ you can't diff meaningfully; what permissions does it ask the workflow to grant; is it actively maintained. The strongest posture for anything sensitive is to fork the action into the organization, review it, and consume the fork — accepting the maintenance cost in exchange for controlling the bytes. Where that's too heavy, SHA-pin and let Dependabot surface updates for review.
The overall shape: policies decide what may run, pinning decides what does run, permissions decide what it can do, and environment gates decide whether a human agreed. Layered, they mean no single failure is catastrophic.
⚠️ Exam Trap: Environments are a release gate for secrets and deployments, not an access control on the repository. They don't stop someone from editing the workflow file — branch protection and rulesets do that. A question about "preventing unauthorized changes to the deploy pipeline" is asking about branch protection or CODEOWNERS, not environments.
Reflection Question: Required reviewers on the production environment protect the deployment. Name the separate control that protects the workflow file defining that deployment, and explain why the two must be used together.
