GH-100: Governing GitHub Enterprise at Organization Scale

A small engineering team can agree informally on who can merge code and which automation may run. At enterprise scale, those assumptions turn into security, continuity, and compliance risks. A former employee may retain a personal access token, a team may unknowingly expose a sensitive repository, or an ungoverned runner may process code from an untrusted pull request. GH-100, GitHub Enterprise Administrator, focuses on operating GitHub as a managed enterprise service: identity, policy, secure development, Actions administration, and usage oversight. The relevant question is not whether an administrator knows where each setting lives, but whether the controls work together.

Microsoft's GH-100 study guide reflects a July 2026 objective revision and describes administration of GitHub Enterprise Cloud and Server environments. Cloud, managed-user, and self-hosted deployment models have meaningful differences; features, availability, and licensing should be verified for the actual enterprise plan. A sound enterprise design begins with a known identity boundary, clear ownership of settings, and a repeatable process for exceptions.

Map enterprise identity to the correct GitHub access model

GitHub users can participate through personal accounts or through enterprise-managed identities, depending on the organization's setup. Enterprise Managed Users change account provisioning, authentication, and external collaboration assumptions. A system designed for individually owned accounts should not be copied uncritically into a managed-user enterprise. Document what the identity provider controls and what remains configured within GitHub, including team membership, organization roles, and repository authorization.

Single sign-on is an authentication boundary, not a complete authorization policy. SAML integration can establish identity, while SCIM and team synchronization can support lifecycle management. An employee might authenticate successfully but still have inappropriate repository access because team inheritance or repository-role assignment is excessive. Regularly examine effective access, external collaborators, service accounts, and administrative privileges, especially after reorganizations or acquisitions.

Enterprise-scale identity and access management provides useful conceptual language for this work: least privilege, lifecycle changes, recertification, and separation of duties. In GitHub, apply it to organization owners, repository administrators, teams, branch maintainers, automation credentials, and emergency access. A permission review that examines only human accounts will miss workflows and bots that can read or modify code.

Plan onboarding and departure as auditable transactions. A joiner receives an identity, the correct organization membership, and access appropriate to a team. A leaver must lose interactive access and have tokens, machine integrations, and owned automations reviewed. An identity sync failure can become a security event if offboarding stops working. Test those edge cases before treating successful single sign-on as evidence that enterprise governance is complete.

Define a consistent boundary for repository administration

Organizations should decide which settings are centrally enforced and which teams may choose locally. Repository visibility, rulesets, approved actions, code ownership, merge requirements, branch protections, and outside collaboration policies can be distributed across enterprise, organization, and repository levels. An apparent conflict between policies may confuse developers unless administrators explain effective enforcement and permissible exceptions.

A branch protection and pull request governance model helps connect review expectations to real risk. A sensitive deployment repository might require multiple approvals, signed commits, and passing checks, while a low-risk documentation repository can use lighter controls. The requirement should be proportional to the asset, clearly documented, and measurable. Blanket strictness with frequent informal bypasses is not a reliable security posture.

Rulesets can standardize protections, but ownership still matters. Decide who may approve policy exceptions, how long a temporary bypass lasts, and which audit trail records it. Teams need a safe path for urgent incident fixes without normalizing direct unreviewed changes to production branches. If controls are impossible to operate during an outage, people may find unsupported workarounds that weaken long-term governance.

Repository templates and default files help communicate project expectations. A README clarifies purpose and setup; CODEOWNERS can route reviews; SECURITY describes vulnerability reporting; CONTRIBUTING gives contributors a predictable workflow. These are not substitutes for technical controls, but they reduce ambiguity and help new teams adopt good practices without reinventing policy language in every repository.

Manage secure development features as an integrated program

Enterprise administrators commonly coordinate code scanning, secret scanning, dependency alerts, security advisories, and remediation workflows. These features detect different risk classes. A hard-coded credential needs revocation and rotation; an outdated dependency needs impact assessment and an upgrade path; a code analysis finding needs review in the context of the application's reachable execution paths. A single undifferentiated queue of findings produces noise and poor accountability.

GitHub Advanced Security is a closely related specialist area, but GH-100 examines governance and deployment of the capabilities at scale rather than the deeper technical treatment of every vulnerability. Decide which repositories must participate, who owns alert triage, and what level of central visibility is required. Document why a risk is dismissed or deferred, and ensure the exception can be revisited when dependencies or exposure change.

Audit logging should support questions that matter to incident response: who changed repository visibility, who relaxed a branch rule, when a privileged token was created, and which security policy was modified. Logs lose much of their value if they are not retained appropriately, searchable by authorized investigators, or correlated with identity events. Administrative oversight includes verifying that logs are actually collected and that the team can retrieve them during a realistic investigation.

Compliance controls should follow specific obligations rather than a vague goal to 'be secure.' A regulated enterprise may require retention of approval evidence, limited access from certain regions, or demonstrable change management. Document which GitHub features provide evidence and which control responsibilities belong to external identity, endpoint, network, and security systems. An enterprise admin should avoid claiming that enabling a security product automatically completes an audit requirement.

Govern Actions, runners, and reusable automation safely

GitHub Actions can build, test, and deploy code, making automation permissions a direct production security concern. Define policies for allowed actions, reusable workflows, secrets, environments, and token scopes. A workflow triggered by code from an external contributor should not receive credentials capable of deploying production systems. The difference between read-only build validation and privileged release automation needs to be explicit in the workflow architecture.

The GitHub Actions exam goes deeper into authoring and operating workflows, while enterprise administrators concentrate on organizational guardrails. Runner ownership matters: hosted and self-hosted runners have distinct networking, maintenance, isolation, and availability characteristics. Persistent self-hosted runners processing untrusted jobs can expose credentials or neighboring workloads if isolation and lifecycle practices are weak.

Use organization-level reusable components to reduce variation where that improves safety, but avoid turning every team request into a central bottleneck. Provide reviewed templates for common actions such as test execution or cloud deployment, specify how versions are pinned, and tell developers how to request improvements. Central policy can prohibit clearly unsafe patterns while still allowing teams to control legitimate application-specific work.

Secrets and federated identities should be short-lived or scoped when possible. Workflow permissions, environment approvals, and audit trails must be tested with realistic jobs. A configuration that looks correct in the UI can still grant more access than intended through inherited permissions, token reuse, or broad self-hosted runner access. Administrator exams reward understanding how separate controls interact rather than treating each setting as isolated.

Operate GitHub Enterprise as an accountable service

Enterprise administrators need operational visibility beyond security findings. License allocation, organization growth, runner utilization, workflow execution volumes, support tickets, billing changes, and platform incidents all affect service delivery. A license report can reveal unused seats, but reclaiming them without understanding access dependencies may disrupt critical automation. Changes should follow documented ownership and a safe communication process.

Cloud and Server deployments require different operational care. A self-managed installation involves infrastructure maintenance, upgrade planning, backups, and recovery procedures outside the responsibilities of a fully hosted service. Enterprise Cloud still needs configuration resilience, identity-provider availability, policy review, and vendor support coordination. A shared runbook should state where GitHub ends and the organization's own responsibilities begin.

Monitor signals that indicate the quality of governance: the age of privileged access grants, the proportion of protected critical repositories, exception expiration, security-alert time to action, and whether essential workflows have owners. Avoid metrics that reward superficial compliance, such as counting branch rules without checking whether they apply to valuable branches or counting alerts without measuring remediation.

Administrators should rehearse key failure scenarios. What happens when the identity provider is unavailable? Who can restore a mistakenly locked repository? How will teams recover a blocked production release after a false positive rule change? The goal is not to bypass controls by default; it is to ensure that well-defined emergency procedures exist, produce evidence, and receive post-incident review.

Practice with policy decisions rather than isolated configuration trivia

Design a fictional enterprise with three development organizations, an external vendor, and several production deployment repositories. Specify the identity mode and provisioning path, assign role boundaries, and draw the inheritance of enterprise versus organization settings. Then model a new employee, a departing contractor, and a support engineer requiring time-limited access to investigate an incident.

Add workflow governance next. Determine which actions are allowed, who can run self-hosted runners, how tokens are restricted, and which repositories need approval gates. Introduce a malicious pull request and demonstrate why build credentials cannot be used to reach production. Add a secret-scanning alert and describe how security and repository owners coordinate revocation, remediation, and communication.

Finally, test the audit and service-management story: where would you find policy-change evidence, who can approve an exception, what would a quarterly access review actually inspect, and how would you recover from an erroneous organization-wide rule? These questions connect the official GH-100 domains into an operating model that a real administrator could defend.

GitHub Foundations (GH-900) explains everyday platform collaboration; GH-100 is the administration and governance discipline needed when that collaboration scales. The most useful preparation is to understand not only which settings exist, but what risk each one controls, which tradeoff it creates, who owns the exception path, and how effectiveness is verified after deployment.