GitHub GH-100: Governing GitHub Enterprise Securely

GH-100 validates the ability to administer GitHub Enterprise as a shared engineering platform. Microsoft's July 2026 study guide covers identity and access, enterprise configuration, secure software development and compliance, GitHub Actions administration, and monitoring cost and usage. This is different from knowing how to commit code to a repository. An enterprise administrator sets the rules under which thousands of developers can collaborate, publish artifacts and run automation without violating security or operational requirements.

The most effective perspective is to treat GitHub as an enterprise service with users, trusted integrations, lifecycle events and audit responsibilities. Security teams may ask for strong identity controls; developers need repositories and automated builds; finance needs visibility into metered resources. An administrator succeeds by designing policies that satisfy those legitimate needs rather than imposing blanket restrictions that force work into ungoverned alternatives. The foundational GH-900 covers ordinary collaboration, while GH-100 focuses on platform-wide decisions and consequences.

Establish an identity and repository boundary

An enterprise must determine who can join organizations, how authentication works, how teams receive repository access and what occurs when staff leave. Single sign-on, identity provisioning, organization membership and repository permissions interact but do not mean the same thing. A person may authenticate successfully yet have no access to a restricted repository. Equally, an administrator account should not inherit broad development privileges unnecessarily. Design role assignments around operational duties, including who can change enterprise policies and who can approve sensitive exceptions.

Repository visibility is a data-handling choice. Private repositories can still expose secrets through workflows, logs, package distribution or careless exports. Establish which teams may create repositories, what naming and ownership information is required, how abandoned repositories are handled, and when archiving is preferable to deletion. Forking and external collaboration need explicit policy because they can create additional copies of source content with distinct access boundaries.

For example, an acquired subsidiary may need to join the same enterprise while preserving an initial separation of intellectual property. Creating a common identity directory does not automatically justify broad access to every organization's repositories. Map the business sharing requirements first, then implement teams, repositories and policies that permit the approved relationships. Verify access with test identities and examine audit events rather than assuming the UI arrangement enforces the intended model.

Govern secure software development without blocking delivery

GitHub security configuration spans code scanning, secret scanning, dependency visibility, branch or ruleset protection and approval requirements. These capabilities provide different safeguards. Secret scanning alerts on exposed credentials, while code analysis can detect potential vulnerabilities in source patterns. Dependency alerts help address known component risks, but no single tool proves an application is safe. Decide which controls apply to critical repositories, how results are triaged and who can accept documented risk.

Protected branches and repository rulesets help enforce review and status checks before changes reach release branches. The policy must account for emergency remediation: an organization may need an authorized break-glass route with auditability rather than a permanent administrator bypass. Identify which team owns the policy and how exceptions expire. Integrate checks into the review process so a blocked merge reports a specific actionable failure rather than a mysterious red status.

A security team may demand that all source code changes receive two approvals. For generated dependency updates, this can cause significant queue delays unless ownership and automation are considered. A risk-based solution can still enforce protected default branches while differentiating release-critical code, generated files and low-risk documentation. Administrators must evaluate both control effectiveness and developer workflow because a policy that is consistently bypassed is not strong governance.

Manage Actions runners as privileged compute

GitHub Actions can execute build and deployment code using hosted or self-hosted runners. An Actions administrator must assess runner trust, network reachability, isolation and access to secrets. A self-hosted runner attached to production networks is not merely another CI server; untrusted workflow code may execute on it if repository and runner-group boundaries are too broad. Limit assignment of runner groups and prefer short-lived, isolated execution environments for sensitive workloads where feasible.

Workflow secrets, environment protections and permissions need careful scoping. A build that compiles a pull request from an untrusted contributor should not inherit deployment secrets. Require environment approval for releases where appropriate and use cloud workload identity federation rather than long-lived service credentials whenever supported. The GH-200 exam deepens workflow authoring and runner troubleshooting; GH-100 asks how to govern those capabilities across organizations consistently.

Analyze a scenario where an engineering group moves from hosted runners to self-hosted hardware for performance. Before approving the change, examine patching, ephemeral state, egress routes, container escape risk, logging and whether another team's workflow could land on the same runner. A savings estimate that ignores the operating cost of securing and maintaining that host is incomplete. Measure reliability and incident response obligations alongside throughput.

Design policy for secrets, tokens and integrations

Enterprise administration extends beyond human users. Fine-grained tokens, GitHub Apps and workflow permissions authorize software operations. A machine identity may need to publish packages but should not receive organization administration rights. Review token lifetime, scoping, revocation and audit evidence. Secrets stored in repositories, organizations or environments have different eligibility rules; understand which workflows can read them, not just where the UI lists them.

Integrations can become critical dependencies. An organization that routes approvals through a third-party system must determine what happens during that provider's outage and what data the app can access. Keep an inventory of authorized GitHub Apps, periodically review granted permissions and define who can install new integrations. A tool that requests access to every repository when it only needs one team deserves additional scrutiny. The objective is the smallest practical trust boundary.

For credential exposure, the first step is not simply deleting the line from Git history. Revoke or rotate the compromised secret, inspect access and usage, evaluate downstream systems, and address how it entered the repository. If the same token appeared in a build artifact or log, source cleanup alone leaves other exposures. A useful enterprise policy standardizes this response so security and engineering teams can act quickly.

Monitor activity, compliance and total ownership cost

Audit logs, usage reporting and API consumption reveal both risk and platform health. Track ownership gaps, privileged-role changes, new integrations and unusual automation usage. Interpret events in context: a large number of repository reads may be an approved code migration rather than exfiltration, but it still warrants evidence of authorization. Set retention and access controls for audit data appropriate to the organization's obligations, and ensure investigations can correlate GitHub events with identity-provider and cloud activity.

Costs include seats, metered Actions minutes, storage, runner infrastructure and management overhead. Review which teams use licensed features and which workloads cause repeatable unnecessary build activity. A workflow that runs a large test suite on every trivial documentation edit may waste resources; a path-based trigger could reduce that load without weakening required release tests. Cost optimization should preserve security gates and reproducibility, not simply disable expensive checks.

Enterprise changes benefit from a staged rollout. Before changing a rule across hundreds of repositories, test it on representative teams and record rejected workflows or merge failures. Communicate the reason for the policy, offer a migration window where appropriate and provide an accountable path for resolving exceptions. A central policy is only effective if it is both enforceable and operationally usable.

A useful GitHub Enterprise exercise is to analyze a departing contractor who maintained a release workflow. The contractor's personal access should be removed, but the service might also depend on a personal token or a deployment key that nobody inventoried. Review integrations, automation identities, repository ownership and emergency access before the departure date. Replace fragile person-dependent credentials with managed application identities where appropriate. Offboarding becomes a platform-resilience test rather than a checkbox in an identity system.

Another case is a centralized security rollout that blocks an unapproved action used in hundreds of repositories. Simply relaxing the enterprise rule restores builds but also restores the supply-chain risk. Identify the exact action and version, evaluate a permitted replacement, communicate the migration steps, and preserve a temporary, time-bound exception for essential releases when approved. Audit those exceptions and remove them after teams migrate. This approach respects both security and production continuity.

Finally, evaluate the enterprise as a product. Administrators should know which teams experience slow builds, confusing permissions and repeated repository setup work. Gather representative support cases and usage data, then prioritize platform improvements that reduce friction while preserving controls. A published policy with no adoption feedback tends to accumulate exceptions and workarounds. Mature GitHub governance has measurable outcomes: fewer unmanaged credentials, faster approved delivery, clear ownership and evidence that critical rules are actually enforced.

Verify the GH-100 skill set in an administration lab

Build a controlled organization with test repositories, teams, a GitHub App, a workflow and distinct admin/developer identities. Configure repository policies and validate them through permitted and prohibited actions. Create a simulated secret leak, verify alert routing and token revocation, then inspect the audit trail. Set up hosted and isolated runner configurations where your environment allows and document how workflow authorization differs between trusted branches and pull requests.

The July 2026 Microsoft study guide is the reference for current exam domains and release changes. Focus on explaining decisions: why a permission is too broad, what an audit record proves, how a runner could expose a workload, and how to enforce policy without breaking normal development. Those are the durable responsibilities of a GitHub Enterprise administrator, regardless of the navigation layout of an individual settings page.