Protection rules and governance

The available protection rules

On an Environment's page (Settings > Environments > <name>):

• Required reviewers — up to 6 people/teams; a single approval unblocks the job.
• Wait timer — a delay in minutes before the job continues automatically, with no human action.
• Deployment branches and tags — restricts which branches/tags can reference this Environment (and therefore access its secrets).
• Prevent administrators from bypassing configured protection rules — disables the default admin bypass.

Hands-on step — configure a required reviewer and watch the block

1. On the demo Environment created in the previous module, enable Required reviewers and add yourself (or another account if you have one handy).
2. Go back to the Actions tab and re-run the Environment demo workflow (Run workflow).
3. This time, the run stays in Waiting status at the say-hello job — it doesn't run immediately. Open the run: a banner indicates a review is needed, with a Review deployments button.
4. Click it, select the Environment in question, approve. The job resumes and runs normally.

You just turned an automatic deployment into a governed one — without changing a single line of the workflow itself, only the configuration of the Environment it references.

Hands-on step — restrict deployment branches

1. On the same demo Environment, enable Deployment branches and tags and choose Selected branches and tags, allowing only main.
2. Create a feature/test-env branch and push a trivial change to it (a comment added to the workflow, for example).
3. From that branch, try to trigger the Environment demo workflow via workflow_dispatch, selecting feature/test-env as the ref.
4. Observe: the job fails to start, with a message stating that the branch is not allowed to deploy to this Environment.

If you plan to reuse this demo Environment for something else afterward, remove the branch restriction and/or the required reviewer now — the following modules don't reuse them, but there's no reason to leave your repo more locked down than necessary without remembering it.

Why this governance matters

Without a protection rule, an Environment is just a namespace for secrets — useful for scoping (module 2), but with no guardrail. With required reviewers and a branch restriction, you get a real control gate: nobody deploys to production from an unvetted branch, or without a designated person explicitly approving it. This mechanism, more than secret scoping, is what justifies most of the value of Environments — and their real configuration cost (next module).

What you just did

You configured and observed, with real runs blocked then unblocked, the two most commonly used governance mechanisms: required human approval and branch restriction. The next module steps back to objectively weigh all of this against its complexity and real cost.