What's changed: New GH-100 Chapter 4 (governance & runners = distribute reusable components, org Actions policy [allow list/require SHA/fork-PR approval], runner groups/hosted-vs-self-hosted, IP allow lists/Azure private networking, performance monitoring [label mismatch/auto-scaling]; encrypted secrets = org/repo/environment scope and precedence, org-level central management, REST API automation, third-party vault integration (OIDC runtime fetch))
4.1Actions Governance and Runner Management
Understand configuring reusable actions/workflows to enterprise repositories, applying org policies for GitHub Actions, managing runner groups and GitHub-hosted/self-hosted runners, IP allow lists and networking (including Azure private networking), and monitoring/troubleshooting runner performance—from an admin’s view.
GitHub Actions is powerful but, ungoverned, becomes a security/cost/supply-chain risk. Admins govern which actions/workflows can run (policy), where they run (runners), and how secrets are handled (next section) org-wide. GH-100 tests this large-scale management (workflow authoring detail is GH-200; here it’s admin-view governance).
4.1.1Reusable components and policies
Admins distribute reusable workflows, composite actions, and starter workflows (GH-200) across the enterprise/organization to roll out internal standard pipelines. Org policies for Actions choose the allowed action scope—disable all / allow all / GitHub-authored only / GitHub + verified / allow list—and can require SHA pinning for external actions. Requiring approval for fork-PR runs and restricting the default GITHUB_TOKEN to read curb external-code and supply-chain risk. Enterprise policy cascades to member orgs.
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.