Decision matrix for choosing an approach

The criteria that actually matter

Based on the previous modules, four criteria drive most of the decision — not fashion or habit:

Criterion	Why it matters
Repo visibility and plan	Public + Free = GitHub Environment fully available. Private + Free = protection rules silently ignored (module 4) — a real trap if not anticipated.
Need for traceable human approval	If compliance or a real stake requires a designated person to validate a deployment, required reviewers (module 3) answer that need directly — few native GitHub alternatives are this simple.
Where deployment already lives	If a hosting platform already manages its own environments/previews (module 5), duplicating that governance in GitHub Actions adds complexity with no net benefit, unless there's a specific need the platform doesn't cover.
The environment's real stakes	A low-stakes environment (disposable dev, a prototype with no users) usually justifies no protection rules at all — the friction cost would exceed the avoided risk (module 4's principle).

The matrix

Situation	Recommendation	Why
Public repo, need for traceable approval before deployment	Native GitHub Environment, with required reviewers and branch restriction	The feature is fully available (no plan constraint), and directly answers the approval need.
Private repo, Free plan, deployment driven by a third-party platform with its own environments	Rely on the third-party platform, not GitHub Environment	GitHub's protection rules would be ignored on this plan (module 4) — avoid the false sense of security.
Private repo, genuine need for traceable approval, budget available	Native GitHub Environment, after upgrading to a Pro/Team plan	The governance need justifies the paid plan's cost, once the plan prerequisite is known and anticipated.
Experimental project, no real users, fast iteration is the only priority	No formalized environment	The configuration and friction cost isn't justified by any matching risk.
Multiple teams deploy on the same repo, with different stakes per target (dev/staging/prod)	Separate Environments with differentiated protection rules (none on dev, required reviewers on prod only)	Friction should be proportional to each target's stakes, not applied uniformly (module 4).

Hands-on step — apply the matrix

For each of the following three cases, work out the recommendation before checking your answer against the principles above (don't read the matrix before answering):

1. A non-profit, public repo, a single maintainer, no budget, wants to prevent an accidental production deployment from an unreviewed branch.
2. A 15-person startup, private repo, already subscribed to a Team plan for other reasons, with a contractual obligation to approve every deployment before it reaches customers.
3. A 48-hour hackathon, a public repo created for the occasion, no intention of maintaining the project afterward.

Expected answers: (1) Native GitHub Environment with a branch restriction — public repo so it's available for free, real need despite the lack of budget. (2) Native GitHub Environment with required reviewers — the Team plan already removes the cost constraint, and the contractual obligation fully justifies the friction. (3) No formalized environment — zero stakes, project lifespan too short to justify the configuration.

What you've accomplished in this course

You started from a common confusion between two meanings of "environment," worked with the GitHub feature until you observed its real effects (scoping, approval blocking, branch restriction), learned its least visible plan constraint, stepped back to see deployment strategy in the broader sense, and can now decide with a set of criteria instead of a reflex. Next time someone asks "should we put this behind a protected environment?", you have something better than intuition to answer with.