Manage GitHub Actions for the Enterprise Study Guide — GH-200

Manage GitHub Actions for the Enterprise

This domain tests your ability to configure, govern, and troubleshoot GitHub Actions at the enterprise and organization scale. It covers policy controls, runner infrastructure, billing, secrets management, audit logging, and cross-repository governance features. Weighted at 15% of the exam, this domain typically produces 6–9 questions and rewards students who know exact defaults, tier restrictions, and the hierarchy of policy enforcement.

Actions Policies: Allowed Actions, Disabling at Org Level

Concepts

GitHub Actions can be controlled at three levels: enterprise, organization, and repository. Policies set at a higher level restrict what lower levels can configure — an enterprise admin can lock down options so org admins cannot override them.

Policy options for which actions are allowed to run:

When using Allow select actions, you can additionally check:

• Allow actions created by GitHub — allows actions/* namespace automatically
• Allow actions by Marketplace verified creators — allows badge-verified publishers
• Allow specified actions and reusable workflows — explicit patterns like owner/repo@* or owner/repo@v2

Policy hierarchy:

The most restrictive policy in the hierarchy always wins. If the enterprise allows only local actions, an org admin cannot expand that to allow all actions.

Common Traps

• Confusing "local actions" (same repo only) with "actions in the same organization" — local means same repo, not same org.
• Thinking org admins can override enterprise policy — they cannot; enterprise is always ceiling.
• Forgetting that disabling GitHub Actions at org level stops ALL workflows, including those that were previously allowed.
• The Allow actions created by GitHub checkbox does not appear unless you first choose "Allow select actions."

Worked Scenario

Requirement: A security team wants to allow only actions/checkout, actions/setup-node, and any internally-built actions, but block all third-party marketplace actions.

Reasoning: Set policy to Allow select actions, check Allow actions created by GitHub (covers actions/checkout, actions/setup-node), and add the internal org pattern (e.g., my-company/*@*) to the explicit list. Do NOT check "Allow actions by Marketplace verified creators."

Self-Hosted Runner Groups: Assigning Runners to Orgs/Repos

Concepts

Runner groups are the primary access-control mechanism for self-hosted runners. Every self-hosted runner belongs to exactly one runner group.

Key rules:

• A runner can only belong to one group at a time.
• Moving a runner to a different group removes it from the previous group.
• Enterprise-level groups are managed at https://github.com/enterprises/<name>/settings/actions/runner-groups.
• GitHub-hosted runners cannot be placed into custom runner groups (runner groups are self-hosted only at the org level, but enterprise runner groups can include GitHub-hosted runners in some plans).
• When an enterprise runner group is assigned to an org, the org admin can further restrict which repos in that org can use it.

Common Traps

• Confusing enterprise runner groups (control org access) with org runner groups (control repo access) — they operate at different levels.
• Assuming newly registered runners land in a named group — they land in the Default group.
• Thinking a runner can be in multiple groups simultaneously — it cannot.
• Forgetting that org admins cannot see enterprise-managed runner groups in their settings unless the enterprise admin shares the group with their org.