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.
4.1.2Managing runners
Job runtimes are runners: GitHub-hosted (ephemeral, clean) and self-hosted (internal network/special environments). Group self-hosted runners into runner groups to control "which orgs/repos may use them" (restrict sensitive runners to specific repos). Self-hosted runners on public repos are risky (external PR code runs on your machine). Orgs restrict sources via IP allow lists, and on Azure use Azure private networking to connect GitHub-hosted runners to your VNet for safe access to internal resources.
4.1.3Runner performance monitoring and troubleshooting
Admins monitor runner status and performance—job queue wait, self-hosted online/offline, resource limits. "Jobs not starting" is typically a label mismatch (no idle runner matching runs-on), a stopped runner app, or network/auth issues. For performance, look at concurrency capacity, runner size (larger runners), caching, and reducing wait. At scale, consider auto-scaling self-hosted runners to match demand.
Common: (1) Admins distribute reusable workflows/composites/starters and set org Actions policy (disable/all/GitHub/verified/allow-list, require SHA pinning, fork-PR approval). (2) Runners = GitHub-hosted/self-hosted; govern self-hosted via runner groups; public repos are risky. (3) Restrict source via IP allow lists; on Azure use private networking to reach internal resources. (4) Jobs not starting = suspect label mismatch / no idle runner.
Watch out: (1) Self-hosted runners retain state and risk external-code execution on public repos—use GitHub-hosted/ephemeral or runner groups for sensitive use. (2) "GitHub-authored only" vs "GitHub + verified" are different tiers. (3) Azure private networking connects hosted runners to your internal network—a different approach from self-hosted. (4) Don’t assume "jobs not starting = outage"—check labels/availability.
4.1.4Section summary
- Distribute reusable components; govern via org Actions policy (allow list/require SHA/fork-PR approval)
- Runners = hosted/self-hosted; govern self-hosted via runner groups (risky on public repos)
- Restrict source via IP allow lists; on Azure use private networking for internal resources
- Performance: jobs not starting = label mismatch/no idle runner; consider auto-scaling at scale
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to limit usable actions to "only specifically approved ones." Which org Actions policy?
Q2. You want only limited repos to use a self-hosted runner for production deploys. What do you use?
Q3. On Azure, you want GitHub-hosted runners connected to your VNet for safe access to internal resources. Which mechanism?
Q4. Why is using self-hosted runners on public repos generally discouraged?
Q5. Jobs sent to a self-hosted runner stay queued. What to suspect first?
Q6. You want to distribute internal standard CI/CD pipelines across the enterprise/org. What does an admin use?
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.