GitHub GH-100: Governing Enterprise Repositories at Scale

A developer can understand GitHub perfectly at repository level and still be unprepared to administer thousands of repositories across a regulated organization. GH-100, the GitHub Enterprise Administrator exam, tests decisions about identity, governance, enterprise features, automation, security and usage. Its July 2026 objectives reflect the difference between configuring a single project and establishing policies that remain workable as teams, acquisitions and development platforms change. The task is not to restrict everyone; it is to make legitimate development possible without losing accountability.

Unlike the introductory GitHub Foundations exam, GH-100 assumes administrative responsibility. A repository owner can adjust a local setting, but an enterprise administrator must consider its effect on multiple organizations, role boundaries, billing and compliance. Microsoft publishes the GH-100 exam objectives alongside GitHub's role-based learning tracks. Administrators should use that first-party scope to distinguish enterprise-wide policy responsibilities from settings controlled by individual repository owners.

Decide who owns identities and where trust begins

Enterprise identity architecture starts with the relationship between an employee's corporate identity and the account used on GitHub. Enterprise Managed Users and personally held GitHub accounts represent different governance models with different migration and operating implications. SAML single sign-on, SCIM provisioning, team synchronization and two-factor authentication each solve a specific part of the problem. Authentication says who signed in; authorization says what that identity can access. Provisioning controls lifecycle, but it is not a substitute for auditing effective permissions.

A company acquires a software studio that already has a large GitHub organization. Leadership wants development to continue uninterrupted while requiring centralized offboarding. Simply switching every repository to a new enterprise overnight risks breaking integrations, workflow tokens and account mappings. Map existing owners, identity sources, third-party applications and external collaborators first. Establish how departing workers lose access and how exceptional service accounts are governed without hiding behind a shared human login.

GitHub teams, organizations and repository roles form overlapping access boundaries. A team may need write access to one project and triage privileges in another. The principle of least privilege is more useful than giving every senior engineer organization-owner rights. Periodic access reviews should ask who can change protections, publish packages, administer secrets and approve deployment environments, not only who can see source code.

Choose Enterprise Cloud, Server and managed-user models deliberately

GitHub Enterprise Cloud and Enterprise Server support different deployment and operational constraints. A regulated organization might evaluate data location, connectivity, identity handling, feature availability and upgrade responsibilities rather than select an option based solely on a generic 'cloud versus on-premises' preference. Enterprise Cloud with managed users, personal accounts and data-residency configurations are not interchangeable. Each needs a documented lifecycle and access architecture.

An isolated environment with strict network requirements may favor certain hosting controls, but those controls create their own obligations for capacity, upgrades, high availability and incident response. A cloud-hosted solution may reduce server maintenance but still require enterprise administrators to own policy configuration, role management and third-party integration risk. The deployment model does not absolve the organization of governance obligations.

Plan support boundaries explicitly. Which failures belong to an organization's enterprise admins, which require its network or identity team, and which need GitHub Support? Good administrators collect relevant diagnostic evidence and know the effect of support bundles on confidentiality. If developers cannot push after a policy rollout, the first action is to investigate scope and recent changes, not remove protections everywhere.

Create repository standards that survive real teams

Enterprise policies can set boundaries for repository creation, visibility, forking, sharing, code review and automation. Organization policies translate those principles into a workable local practice, while repository rulesets protect sensitive branches or tags. CODEOWNERS can designate reviewers based on paths. Neither a ruleset nor a file of owners replaces the cultural requirement to review high-risk changes thoughtfully.

Consider an application handling customer payment data. Its release branches need stable protection, reviewed changes and a controlled deployment identity. Yet an internal documentation repository has very different risks. Imposing the same heavyweight process on both can frustrate contributors without adding proportional protection. Define enterprise minimums and let teams adopt tighter controls where the asset and threat model justify them.

Emergency access is where governance is tested. If a production patch is urgent, who may bypass protections and how is that action recorded? A sound procedure specifies the accountable role, temporary elevation mechanism, compensating review and post-incident assessment. A permanent administrator bypass with no trail is not a recovery plan; it is an unmonitored exception that becomes normal behavior.

Secure developer workflows, secrets and integrations

GH-100 includes enabling secure software development at enterprise scale. Organization-wide policies can govern security scanning, secret handling, reusable workflows and repository compliance. GitHub App permissions and fine-grained tokens deserve scrutiny because third-party automation can access many repositories without appearing as a human team member. GitHub Advanced Security examines code scanning, dependency risk and secret-protection workflows; enterprise administrators must know which controls they can mandate and who follows alerts through to remediation.

Suppose an external build service requests broad write permissions to every repository so it can publish release tags. Ask whether it genuinely needs this scope, whether a GitHub App or more narrowly scoped credential is appropriate and how access can be rotated or revoked. Administrative review should examine the service's maintenance, token lifetime, access grants and audit trail, not just whether a demonstration workflow ran successfully.

Encrypted secrets have scopes and access decisions. Store environment-specific deployment credentials where their use can be constrained by approval, branch or repository policies. A single enterprise-wide secret used by unrelated production applications increases the consequences of compromise. Integrations with external secret stores can reduce duplication but create additional network, availability and identity dependencies that require testing.

Govern GitHub Actions infrastructure without blocking delivery

Enterprise administrators control which workflows can run, what external actions are permitted and how hosted or self-hosted runners are allocated. Runners execute code and often handle secrets; their isolation is a security boundary. An untrusted pull request should not be able to reuse a powerful deployment runner with access to internal systems. Runner groups and policies help separate workloads with different trust levels.

Imagine that a repository uses a public third-party action without pinning its version. The development team appreciates quick updates, but security wants repeatable supply-chain behavior. A balanced rule can require pinned actions or approved sources for sensitive pipelines while maintaining an exception process for legitimate experimentation. GitHub Actions covers authoring and troubleshooting the workflows in greater depth; GH-100 emphasizes the policies and infrastructure by which many teams can use them safely.

Workflow failures can also signal capacity or billing problems rather than code defects. Monitor queue time, runner utilization, failure rates and use of expensive resources. If self-hosted runners suddenly become unavailable, identify whether the cause is registration, network access, runner group policy or an infrastructure incident before expanding privileges to make jobs pass.

Use audit evidence and usage data to steer policy

Audit logs, API activity and enterprise usage reports can reveal suspicious access, bottlenecks and licensing waste. The challenge is interpretation. A surge in failed authentication may follow a legitimate identity migration, or it may indicate an attack. A rarely used licensed feature could represent true overspend, or it could belong to a critical but intermittent incident-response team. Ask what decision the metric should support before treating it as a target.

Build a simple governance dashboard with meaningful questions: are required branch controls enforced on sensitive repositories; do organizations have accountable owners; how quickly are privileges removed after departure; which workflows have excessive permissions; and how much build capacity sits idle? Numbers alone do not fix the issue, but they reveal where to investigate. Use audit evidence to identify repeated exceptions that deserve a policy redesign.

When organizational policies change, communicate impact in a way that enables developers to adapt. A policy saying 'third-party actions prohibited' offers less useful direction than clear criteria, supported alternatives and a place to request review. Explain not only the risk but also how the compliant path supports delivery. Enterprise adoption improves when controls are predictable and their rationale is visible.

Rehearse administration as a sequence of controlled changes

A practical GH-100 exercise is to design the onboarding of a newly acquired team. Specify identity choices, migration sequencing, repository ownership, team permissions, runner access, security policy and measurable acceptance criteria. Then simulate an offboarding event, compromised integration and emergency deployment. What should an admin change first, and how will they know legitimate workflows still function afterward?

Review role and policy boundaries by reading hypothetical failures: a developer cannot access a repository; a workflow cannot retrieve an environment secret; an organization unexpectedly permits public repositories; a licensing report conflicts with expected usage. Each has multiple plausible causes. The best response follows evidence through identity, authorization, enterprise configuration and local settings rather than guessing from an error message.

The goal is an enterprise where developers know how to collaborate, administrators can explain effective access and security teams can investigate a change after the fact. GH-100 tests the judgement required to keep those qualities intact across many repositories and stakeholders. That is what makes it an administrative credential rather than a longer version of repository basics.