What's changed: New GH-200 Chapter 4 (governance = use policies disable/all/GitHub/verified/allow-list, require SHA pinning, reusable-component access settings, fork-PR approval, cascade; runners at scale = GitHub-hosted/self-hosted, runner groups, IP allow lists, preinstalled/toolcache/setup-*, troubleshooting; encrypted secrets & variables = org/repo/environment scope and precedence, secrets/vars, masking, REST API management)
4.1Governing Actions and Workflows
Understand how an enterprise/organization defines and manages reusable components and templates, controls which actions/workflows may run (allow/deny lists, allow only verified actions, required reviewers for unverified actions), and configures organizational use policies.
To run GitHub Actions safely at scale, an organization needs governance over "who can use which actions/workflows, and how." Settings cascade across the enterprise, organization, and repository levels; a restriction set higher (enterprise) flows down to lower levels (org, repo). GH-200 centers on use policies, access control, and managing reusable components.
4.1.1Action use policies
In Settings → Actions policies you choose the allowed scope of actions in tiers—disable all, allow all, allow only GitHub-authored actions, allow GitHub-authored + verified-creator actions, and an allow list of specific actions (with patterns like owner/*). Under least privilege, the safe approach is to permit only the needed actions via the allow list. You can also require pinning external actions to a commit SHA, raising supply-chain safety org-wide.
| Policy | Meaning |
|---|---|
| Disable all | No Actions run at all |
| Allow all | Allow any action (loosest) |
| GitHub-authored only | Only official like actions/* |
| GitHub + verified | Also allow verified-creator actions |
| Allow list | Only enumerated actions (recommended) |
4.1.2Access control and reusable components
Reusable workflows, composite actions, and starter workflows built inside the org are governed by access (sharing) settings that control "which repos may reference them." Sharing a component in a private repo with other repos requires explicit permission, so you can distribute internal standards while preventing references from unrelated repos. Organizations centrally manage starter workflows (workflow-templates) in the .github repo to give teams a standard CI/CD scaffold.
4.1.3Approving unverified actions and fork-PR policy
When external contributions execute, risk management matters. An organization can require approval before Actions run on a fork PR for the first time, so maintainers review before execution—preventing outsiders from abusing workflows or secrets. Combine this with org defaults such as not exposing org secrets to fork PRs and restricting the default GITHUB_TOKEN permissions to read, erring on the safe side.
Common: (1) Action use policy = disable all / allow all / GitHub-authored only / GitHub + verified / allow list (least privilege = allow list). (2) You can require SHA pinning for external actions. (3) Sharing reusable components is governed by access settings. (4) Org standard scaffolds live in .github workflow-templates. (5) Require approval for fork PRs + no secret exposure + default GITHUB_TOKEN to read. (6) Higher-level (enterprise) restrictions cascade down.
Watch out: (1) "GitHub-authored only" vs "GitHub + verified" are different tiers—whether to include verified creators. (2) Allow lists support patterns (owner/*) but over-broadening weakens control. (3) Sharing reusable components ≠ making public—you can share privately via access settings. (4) Removing fork-PR approval lets external code run unreviewed. (5) Enterprise restrictions can’t be loosened at the org (mind the cascade direction).
4.1.4Section summary
- Use policy = disable/all/GitHub/GitHub+verified/allow list (least privilege = allow list); can require SHA pinning
- Sharing reusable components via access settings; standard scaffolds in .github workflow-templates
- Require approval for fork PRs; no secret exposure; default GITHUB_TOKEN to read
- Enterprise restrictions cascade to org/repo (cannot be loosened below)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. The security team requires that workflows use only specifically approved actions. Which policy setting is most appropriate?
Q2. You want to prevent first-time, unreviewed Actions runs on PRs from forks. What should the org configure?
Q3. You want a reusable workflow in a private org repo to be referenceable only by certain internal repos, without making it public. How?
Q4. At the enterprise level you set "allow only GitHub-authored and verified-creator actions." How can a downstream org admin treat this?
Q5. Which policy would you enforce org-wide to make external action references resistant to tampering?
Q6. You want to give teams a standardized "starting scaffold" for CI workflows. Where do you manage these centrally?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.