GH-100: Administering GitHub Enterprise Securely

GH-100, GitHub Enterprise Administrator, focuses on running GitHub at organizational scale rather than merely contributing code to a repository. Microsoft's July 2026 study guide emphasizes identity and access, enterprise administration, secure software development, GitHub Actions governance, and usage monitoring. These concerns touch GitHub Enterprise Cloud and GitHub Enterprise Server, but their deployment, identity, network, licensing, and feature-management characteristics are not identical. A GitHub administrator works with development, security, operations, and compliance teams to make collaboration reliable without granting broader permissions than necessary. The core challenge is to design guardrails that developers can understand and use, then produce evidence those controls are operating across a complex estate.

Choose identity models before configuring repository roles

GitHub Enterprise Cloud organizations can use different enterprise identity arrangements, including managed-user models and configurations in which users retain their personal GitHub accounts. This decision influences onboarding, external collaboration, offboarding, identity provider integration, and policy enforcement. SAML single sign-on, two-factor authentication, SCIM provisioning, and team synchronization address related but distinct aspects of the problem. Successful sign-in does not automatically imply that an account belongs to the correct enterprise team or has suitable repository access. Conversely, deprovisioning a user in the identity provider may need verification that privileged tokens, automation integrations, and other access paths were actually revoked.

Roles should reflect what a person needs to do, not simply their seniority. Enterprise owners, organization owners, security managers, repository administrators, maintainers, and contributors can have different responsibilities. A platform administrator may be authorized to set policy while not needing write access to every product's source code. Access reviews should find stale team memberships, outside collaborators, broad automation tokens, and repositories whose inherited permissions no longer fit their sensitivity. The objective is a reproducible authorization model: a new employee gets the correct access through approved membership, and their departure removes it promptly without relying on someone to remember individual repository grants.

Standardize repositories without blocking useful workflows

Enterprise settings, organization defaults, repository rulesets, branch protections, and contribution policies influence how code is changed and reviewed. A pull request policy can require status checks, signed commits in selected contexts, and reviews before protected branches are updated. Yet an indiscriminate rule can interfere with emergency response or repositories with different release practices. Administrators should identify which controls are universal and which require bounded exceptions. Reusable repository templates and standards can reduce drift, but the policy must still account for products that use distinct languages, deployment models, and risk classifications.

A mature governance process includes ownership. Every important repository should have a responsible team, documented review expectations, and a clear way to request policy changes. Rulesets with bypass roles need auditability: an exception exercised by an unauthorized person is a security problem, while an exception that can never be used during a genuine outage may become an operational problem. A baseline that cannot be explained to the people following it tends to generate workarounds. The best enterprise configuration creates a consistent minimum while making higher-sensitivity controls visible and enforceable where they are needed.

Select deployment and licensing arrangements deliberately

GitHub Enterprise Cloud and Enterprise Server differ in infrastructure responsibility, data residency choices, network connectivity, support workflows, maintenance, and integration options. A business must evaluate legal constraints, latency, identity management, release requirements, and whether it can reliably operate a self-managed service. Enterprise Managed Users may bring different collaboration and identity restrictions from personal account models. Licensing also involves people, products, and metered services. Administrators should understand usage reports and billing boundaries rather than assuming that every tool is included with the same seat entitlement.

Operational support requires a documented division of responsibilities between administrators and GitHub Support. Troubleshooting may depend on audit events, organization settings, connectivity, runner health, and service status. Self-managed deployments introduce backup, upgrade, appliance or infrastructure, and capacity obligations. Cloud deployments still require policy maintenance, user management, integration review, and resilience procedures for dependent delivery workflows. Teams should know what happens if they temporarily lose access to their primary identity provider or an organizational administrator leaves unexpectedly. Administrative continuity is itself a security requirement.

Manage tokens, applications, and enterprise integrations

GitHub Apps and OAuth apps use different authorization models and lifecycle arrangements. Fine-grained or classic personal access tokens create their own operational risk when permissions are too broad, expiration is absent, or ownership is unclear. A privileged token stored in a developer laptop or public build log can compromise repositories even when interactive authentication is well protected. Integrations should use the narrowest practical permissions, rotate secrets when needed, and have owners who review continued necessity. Requests to install an application should be assessed against its requested scopes and what data it could read or change across the organization.

Audit logs and API access reports can help investigate suspicious changes, but their retention and availability depend on platform choices and configuration. An administrator needs to distinguish a legitimate automation deployment from a token being used outside its expected environment. Revoking one token may interrupt critical automation; incident response should identify dependent workflows before choosing containment steps. Where possible, federation and short-lived credentials can reduce persistent secret exposure. The team's inventory should connect each important integration to its identity, allowed repositories, business purpose, support contact, and recovery procedure.

Govern Actions and runner infrastructure at scale

GitHub Actions can execute privileged build and deployment workflows, so enterprise administrators must control which actions can be used, where runners operate, and how secrets enter jobs. GitHub-hosted and self-hosted runners have different maintenance and isolation considerations. A self-hosted runner may provide specialized networking or hardware access but can expose sensitive internal resources to workflow code. Untrusted pull-request changes require careful separation from deployment credentials and privileged runner pools. Organization policies can restrict action sources and guide version pinning, while reusable workflows can centralize approved deployment behavior.

An enterprise runner strategy also needs concurrency, capacity, diagnostics, patching, and cost controls. Queued jobs may result from runner scarcity rather than broken workflow YAML. Failed deployment runs might involve an expired token or blocked network path rather than faulty application code. Reusable GitHub Actions workflows illustrate a useful governance pattern, but administrators must know the difference between an organization-level template and a centrally versioned reusable workflow. Common configuration is valuable only when changes are reviewed, backward compatibility is considered, and emergency rollbacks remain possible.

Implement security suites as part of development governance

Enterprise administrators may enable secret scanning, push protection, dependency analysis, and code scanning within the organization's licensed capabilities. These tools detect different classes of problems. A vulnerable dependency advisory does not mean a secret has leaked, and a CodeQL alert does not automatically prove exploitability in the application as deployed. Policies should assign alert ownership, define triage timeframes, and distinguish dismissed findings from accepted residual risks. Security reviews should also consider protections around default branches, deployments, and external contributors. Cloud application security and DevSecOps provide broader context for integrating preventive controls into normal engineering work.

An effective rollout uses a pilot group to measure false positives, performance impact, and developer behavior before enforcing controls across all repositories. Security teams should prioritize accessible, actionable findings rather than flooding developers with unranked reports. Administrative access to alerts and settings must also be limited. Policies should explain how developers request exceptions and how security teams investigate repeated bypasses. The point is to improve outcomes: fewer leaked credentials, faster vulnerability remediation, and stronger release provenance—not merely a higher number of enabled product features on a dashboard.

Monitor usage, cost, and auditability as ongoing operations

Usage reports can show seat consumption, automation minutes, storage, and adoption patterns, depending on product configuration. A low feature-adoption rate may indicate training needs or a rollout defect rather than lack of value. Conversely, rapidly rising workflow usage might be legitimate growth or a loop repeatedly executing unnecessary jobs. Administrators should establish baseline behavior and review anomalies with the relevant team. Usage optimization should not remove required security scanning or reliability checks simply to reduce billed minutes. Cost and risk must be evaluated together.

A practical GH-100 exercise is to plan onboarding for a newly acquired development team. Decide whether existing identities and repository structures can be integrated, how external contractors are restricted, which actions and security features are enforced, where runners operate, and how administrators will audit access changes. Simulate departure of a privileged user and failure of a runner pool. Record whether access was truly revoked, whether build pipelines recovered, and which administrative events prove the outcome. This is the enterprise capability behind the certification: preserving secure, scalable collaboration while handling ordinary organizational change and exceptional failures.

A second enterprise scenario concerns a leaked automation credential. The administrator must identify the token's effective permissions, repositories it could reach, recent API usage, and the workflows that will stop after revocation. Emergency containment should happen promptly, but recovery may require replacing the credential with a GitHub App or supported short-lived identity rather than simply recreating an equally powerful token. The organization should review whether repository rules were bypassed, whether secrets were exposed in logs, and whether any dependent deployment artifact was altered. A written post-incident review can then recommend narrower permissions, automated expiration, or a different runner boundary.

Another practical consideration is delegated administration during acquisitions or departmental restructuring. Teams may want local control of repositories while the central platform group enforces enterprise security requirements. Define which settings can be overridden, how conflicts are escalated, and what evidence shows that minimum controls remain active after a repository transfers to a new organization. A migration that preserves commits but loses reviewer ownership, required checks, or security alerts is not operationally complete. Administrators should rehearse these transfers on representative repositories before moving a large engineering group.