GH-100 GitHub Enterprise Administrator: A Practical Beta Study Guide

What GH-100 measures

GH-100 targets administrators with experience operating GitHub Enterprise environments. The role is broader than repository administration. It connects workforce identity, organization structure, enterprise policies, secure development, Actions, runners, integrations, audit, licensing, support, and cost. The official audience profile includes both GitHub Enterprise Cloud and GitHub Enterprise Server and expects collaboration with development, security, and operations teams.

The July 2026 guide assigns the largest weight to secure software development and compliance, followed by GitHub Actions. Identity and access remains foundational because every policy, repository, runner, app, and audit event depends on an accountable identity. Enterprise deployment and monitoring have smaller percentages, but weak performance in either area can still affect the result and, more importantly, cause real operational failures.

The five-phase GH-100 roadmap converts those domains into an operational sequence. Build with invented organizations, repositories, users, findings, secrets, and events. Do not practice identity cutovers, security feature rollout, or runner policy changes against a production enterprise without formal change control.

Domain 1: manage GitHub identities and access

Enterprise Managed Users versus personal accounts

Enterprise Managed Users gives an external identity management system responsibility for the lifecycle and authentication of managed user accounts. The IdP provisions accounts, and the enterprise can control usernames, profile information, organization membership, and repository access through supported identity and GitHub administration patterns. Managed users authenticate through the IdP and cannot create public content or collaborate outside the enterprise. Those restrictions are valuable for controlled workforce environments but can conflict with open-source contribution or collaboration requirements.

An enterprise that uses personal accounts has a different boundary. Individuals own their GitHub.com accounts and can use them beyond the enterprise. SAML SSO can govern access to enterprise resources, but it does not replace the ordinary GitHub sign-in. A linked SAML identity proves enterprise authentication; it does not make the account enterprise-owned. Do not choose EMU merely because it sounds more secure. Compare ownership, lifecycle, collaboration, migration, recovery, supported IdP architecture, and data-residency needs.

SAML, OIDC, SCIM, and team management

Authentication and provisioning solve different problems. SAML SSO authenticates access through an IdP. For EMU, OIDC authentication is supported with Microsoft Entra ID according to current documentation. SCIM manages the lifecycle of users and groups. Authorization remains a GitHub concern: enterprise roles, organization roles, teams, repository roles, app permissions, and resource policies determine what an authenticated identity may do.

GitHub recommends a single partner IdP application for both authentication and provisioning where possible. Mixed or untested systems can fall outside support, and the combination of Okta and Entra ID for SSO and SCIM in either order is explicitly unsupported. For a custom SCIM integration, the identity system should be the only source of write operations. Ad hoc writes alongside a partner IdP can break later synchronization. A narrowly scoped provisioning token, matching unique identifiers, audit logging, rate-limit planning, and an isolated test environment are important controls.

With EMU, SCIM groups can be connected to GitHub teams. Membership changes come from the IdP, and GitHub reconciliation updates team and organization membership. Repository access assigned to those teams is still managed on GitHub. Connected teams cannot participate in parent-child nesting, and membership cannot be edited directly on GitHub. In Entra ID, use supported security groups; nested membership and Microsoft 365 groups are not supported for this connection.

Least privilege and access reviews

Enterprise owner is not a general-purpose troubleshooting role. Use built-in and custom roles to separate identity administration, organization administration, repository access, audit review, billing, security, Actions policy, runner management, and support. Shared owner tokens destroy attribution. An effective-access review should follow the identity through enterprise membership, organization membership, base permissions, teams, direct repository roles, outside-collaborator state, SSO authorization, app policy, and resource-specific restrictions.

Domain 2: administer the GitHub Enterprise environment

Choose a deployment deliberately

The blueprint expects comparison of GitHub Enterprise Cloud with EMU, GitHub Enterprise Cloud with data residency and EMU, GitHub Enterprise Cloud with personal accounts, and GitHub Enterprise Server. Cloud reduces customer responsibility for platform infrastructure and upgrades. Data residency supports specified regional requirements on a dedicated GHE.com subdomain, subject to current regional and feature details. GHES supports self-hosted control but makes the customer responsible for infrastructure, networking, availability, backup, monitoring, capacity, upgrades, and supported maintenance.

Do not assume every regulated workload requires GHES. Translate requirements into residency, control, connectivity, availability, maintenance, identity, integration, and collaboration criteria. Conversely, do not select Cloud if a validated requirement needs self-hosting or disconnected operation that only GHES can satisfy.

Standards, licensing, and support

Enterprise administrators define standards for workflow ownership, branching, reviews, releases, repository creation, app approval, security response, audit retention, and delegated administration. A standard should identify scope, owner, enforcement mechanism, exception process, evidence, review date, and rollback—not just state an aspiration in a README.

GitHub Enterprise user licensing is conceptually based on unique users. Correct license synchronization and identity matching can deduplicate a person across combined Cloud and Server deployments. That does not mean all products use the same measurement. Actions, storage, Copilot, GitHub Secret Protection, GitHub Code Security, and legacy or combined Advanced Security arrangements can have separate usage models. Use current billing pages and contract terms rather than a remembered formula.

Before contacting GitHub Support, check GitHub Status and perform documented administrator checks. A useful ticket includes impact, timeline, version, topology, reproduction, relevant audit events, diagnostic results, and changes already attempted. GHES incidents can require diagnostic information or a support bundle, which must be handled as sensitive. External IdP configuration, third-party CI/CD, cloud networking, custom scripts, and some preview features can be outside GitHub Support scope. Route those issues to the appropriate vendor or internal owner.

Domain 3: implement secure software development and compliance

Policies and rulesets

Enterprise policies bound what organizations can configure. Organization and repository settings then implement more specific controls where delegation is allowed. Understand inheritance before changing a setting: a permissive repository option cannot override a restrictive enterprise policy.

Rulesets apply named rules to branches, tags, or pushes. They can require pull requests, reviews, status checks, signed commits, linear history, or restrictions appropriate to supported rule types. Organization and enterprise rulesets can target repository cohorts. Use Evaluate mode to observe what would pass or fail before enforcement. Rule insights show passed, failed, and bypassed activity. Multiple applicable rulesets and branch protection rules layer together; where the same rule differs, the most restrictive form applies.

Bypass is part of governance, not an escape hatch. Keep lists narrow, prefer accountable requests and review, record reason and evidence, and monitor repeated bypass. Push rulesets can also govern file paths, extensions, path length, and file size across a private or internal repository's fork network according to current plan support.

Security features and response

A secure baseline combines eligible secret scanning and push protection, code scanning, dependency graph, Dependabot alerts, dependency review, updates, and security advisories. These capabilities are complementary. Enabling a feature is not proof of healthy coverage. Administrators should monitor eligible repositories, configuration state, scan execution, alert age, dismissals, remediation, exceptions, and recurring failures.

When a real credential is exposed, revoke or rotate it first. Deleting a file or rewriting Git history does not invalidate a value already copied. Then investigate use, replace the insecure handling pattern, remove the value from source and history under policy, and document resolution without placing the secret in issues, screenshots, or logs. For code and dependency alerts, confirm applicability and exposure, prioritize, fix through reviewed changes, test, deploy, and verify closure.

CodeQL default setup lowers administration for supported repositories, while advanced setup provides workflow-level control for specialized builds, languages, query suites, or configuration. The exam is more likely to test choosing and operating the correct pattern than memorizing every YAML key.

Apps, PATs, and audit evidence

GitHub Apps are generally preferred for durable automation because they have explicit permissions, selected-repository installations, independent identity, auditable attribution, and short-lived installation tokens. OAuth Apps act with user-delegated authority and require scope and owner review. Fine-grained PATs can narrow resource owner, repository, permission, and expiration, but they remain personal credentials and are not always the best automation identity. Govern approval, exception, rotation, and removal for every integration type.

The enterprise audit log supports investigations and compliance with actor, action, resource, identity, authentication, time, and other event context. GitHub documents 180-day retention for most enterprise audit events and seven days for Git events; the default UI view can show a shorter period unless a date query is supplied. For durable centralized analysis, configure audit-log streaming to a supported destination and monitor stream health, credentials, access, retention, and gaps. Webhooks can be more efficient than polling for event-driven use cases.

Domain 4: manage GitHub Actions

Enterprise workflow policy and reuse

Enterprise Actions policy can enable Actions for all, selected, or no organizations and restrict which actions and reusable workflows may run. Allowing only enterprise content blocks even GitHub-authored actions unless they are separately allowed. A selected policy can permit GitHub-authored actions, verified creators, and explicit patterns. Requiring full-length commit SHA pinning reduces action supply-chain drift; current documentation distinguishes this rule from reusable workflow references.

A protected internal repository for reusable workflows centralizes CI and deployment logic. Define caller access, require review, test changes, pin caller references according to policy, and publish versioning and deprecation expectations. Reusable workflows do not automatically receive every caller secret. Pass explicit inputs and supported secrets and keep deployment authorization separate from workflow source.

Set the default GITHUB_TOKEN to least privilege and declare job permissions explicitly. Fork policies need special care. Untrusted pull requests should not receive write tokens or secrets. The pull_request_target event executes the base-branch workflow in a privileged context and requires careful design; do not check out and execute untrusted pull-request code in that context.

Runner groups and network trust

GitHub-hosted runners are the simplest starting point for supported standard workloads because GitHub maintains the images and jobs receive clean environments. Self-hosted runners are useful for specialized hardware, software, networking, compliance, or control, but the customer owns patching, isolation, capacity, credentials, cleanup, monitoring, and incident response.

Runner groups restrict which organizations, repositories, or selected workflows can route jobs to runners. Organization-owned groups cannot provide cross-organization workflow access; use an enterprise-owned group for enterprise scope. If workflow access is restricted, specify full workflow paths and governed references. Labels and group access both affect routing. Duplicate group names create ambiguity, so use unique names or explicit enterprise and organization prefixes.

Self-hosted runners should generally serve private repositories and trusted workflows. Public fork pull requests can execute attacker-controlled code and compromise persistent runner state, network access, GITHUB_TOKEN, or secrets. Prefer ephemeral or freshly isolated runners for higher-risk jobs. Restrict repository-level runner registration, segment networks, minimize runner identity, and monitor application version, online state, updates, queue time, capacity, proxy, DNS, firewall, and GitHub connectivity.

Secrets, OIDC, and external vaults

Choose the narrowest secret scope. Repository secrets are local. Organization secrets can be restricted to all, private, or selected repositories. Environment secrets can add deployment reviewers and branch controls. Enterprise-level capabilities depend on the current product and feature. A secret's existence does not prove that every event can use it: forked workflows and Dependabot events have important restrictions, and reusable workflows require deliberate passing.

Prefer OIDC federation for a cloud provider that supports it. A workflow requests an identity token and exchanges it for short-lived cloud credentials. The external trust policy must constrain repository, ref, environment, or reusable-workflow claims; otherwise removal of a long-lived key merely replaces one broad trust path with another. For secrets that cannot use OIDC, integrate a supported external vault, authenticate narrowly, retrieve at runtime, rotate, avoid logs, and define outage behavior.

Domain 5: monitor and optimize GitHub usage

Monitoring should answer three questions: Is the enterprise healthy? Are controls effective? Are paid capabilities used responsibly? Audit and API signals show administrative changes and integration behavior. Adoption signals can include active users, repositories, pull requests, Actions, ruleset outcomes, security feature coverage, and support trends. Use stable scope and aggregate reporting. A licensed seat is entitlement, not evidence of use, and commit count alone is a poor and potentially harmful measure of individual performance.

Actions optimization begins with measurement: minutes, workflow duration, queue time, runner use, redundant schedules, matrix size, cache behavior, artifact and log retention, storage, and superseded runs. Remove waste without removing required security scans, deployment safeguards, or evidence. Enterprise policy can set maximum artifact, log, and cache retention according to current platform limits.

Advanced Security licensing has evolved into product SKUs including GitHub Secret Protection and GitHub Code Security, while some customers may have combined GitHub Advanced Security licensing. Current documentation measures private or internal usage through unique active committers in enabled repositories and uses a rolling activity window. A user contributing to multiple enabled repositories is deduplicated within the relevant account scope. Review current billing mode, limits, budgets, usage delays, public-repository availability, and contract terms before recommending enablement or removal.

API collectors should use an appropriate GitHub App, minimum permissions, pagination, caching or conditional requests, rate-limit headers, reduced duplication, and bounded backoff. Rotating through shared user tokens to evade limits weakens attribution and does not repair an inefficient collector.

Two hands-on projects

The first GH-100 project is an enterprise identity and governance design for the invented Octoforge Research Group. It compares EMU and personal accounts, selects a supported SSO and SCIM path, models lifecycle events, maps IdP groups to teams, designs least-privilege roles, pilots rulesets, streams audit events to a synthetic SIEM design, reviews license usage, and creates a support escalation playbook.

The second project administers a synthetic software-delivery organization. It applies rulesets and eligible security features, governs apps and PATs, publishes protected reusable workflows, restricts Actions policy, creates a nonproduction runner group, replaces a dummy cloud key with OIDC, exercises safe security response, troubleshoots a queued job, analyzes Advanced Security and Actions usage, and removes every runner, credential, trust relationship, and repository created for the lab.

Both projects are intentionally synthetic. Do not create fake security alerts that notify real partners, commit realistic credential formats to public repositories, connect a lab runner to production networks, or use employee identities. Where a feature or license is unavailable, produce a documented architecture and test plan rather than bypassing controls.

A six-to-eight-week plan

1. Week 1: Read the official guide. Compare EMU and personal accounts. Diagram SAML or supported OIDC, SCIM, groups, teams, roles, and effective access.
2. Week 2: Compare GHEC, data residency, and GHES. Study user licensing, product usage, administrator standards, GitHub Status, diagnostics, support bundles, and support scope.
3. Weeks 3-4: Build rulesets in Evaluate mode. Study code scanning, secret scanning, push protection, Dependabot, security advisories, apps, PATs, audit search, streaming, and response plans.
4. Weeks 5-6: Build protected reusable workflows, action allowlists, token permissions, runner groups, queued-job troubleshooting, environment protection, OIDC, and a vault design.
5. Week 7: Analyze adoption, audit, APIs, Actions, storage, active-committer usage, seats, support, and cost. Complete both synthetic projects and cleanup.
6. Week 8: Use original GH-100 questions and GH-100 flashcards. Explain every distractor, revisit weak objectives, and verify beta status and result timing.

Common preparation mistakes

• Equating SSO with authorization. Authentication does not grant repository write access.
• Treating SCIM and team synchronization as identical. User lifecycle, group lifecycle, team membership, and repository access have distinct responsibilities.
• Assuming EMU is always best. Its enterprise-only collaboration restrictions can conflict with legitimate open-source work.
• Activating rulesets everywhere without evaluation. Use Evaluate mode, insights, narrow bypass, staged rollout, and rollback.
• Calling enabled security features complete coverage. Measure eligibility, execution, findings, dismissals, remediation, and exceptions.
• Using persistent self-hosted runners for untrusted code. Isolate, restrict, patch, monitor, and prefer ephemeral execution where required.
• Moving a long-lived key into a broader secret. Prefer constrained OIDC or a runtime vault and remove the old key.
• Optimizing cost by removing required controls. Reduce duplication, retention, oversizing, and stale access without weakening policy.
• Expecting an immediate beta score. Results remain delayed until the exam completes beta and goes live.
• Using dumps or pass guarantees. Recalled content undermines exam integrity and does not build administrator judgment.

Certification and evidence

GH-100 can structure enterprise administration knowledge and provide a recognizable signal. It cannot guarantee a passing result, interview, job, promotion, or salary. Stronger evidence combines the credential with an IAM decision record, access matrix, ruleset rollout report, security response runbook, reusable workflow design, runner threat model, OIDC trust policy, audit-stream health plan, usage dashboard, support checklist, and verified cleanup record.

Describe sandbox work honestly. A documentation-only design is not a production migration. A synthetic runner exercise is not experience operating a regulated fleet. Use the PrepKloud jobs explorer to compare evidence with administrator, platform engineering, DevSecOps, and security roles, and continue through the PrepKloud blog for related guidance.

Official Microsoft and GitHub references

• Study guide for Exam GH-100: GitHub Enterprise Administrator
• GitHub Administration certification page
• About beta Certification exams
• Exam scoring and score reports
• About Enterprise Managed Users
• Provisioning users and groups with SCIM
• Managing organization rulesets
• Enterprise code security and analysis policies
• Enterprise GitHub Actions policies
• Managing access to self-hosted runners with groups
• Using secrets in GitHub Actions
• Audit log for an enterprise
• GitHub Advanced Security license billing
• About GitHub Support

Continue GH-100 preparation

• GH-100 five-phase roadmap
• GH-100 original practice questions
• GH-100 flashcards
• GH-100 hands-on projects
• GH-500 GitHub Advanced Security guide
• Cloud, platform, DevOps, and security jobs
• PrepKloud editorial policy

Frequently asked questions