Microsoft GH-100: Governing GitHub Enterprise Access and Policy

The GH-100 GitHub Enterprise Administrator examination assesses how organizations govern identities, repositories, security capabilities and automation at enterprise scale. Microsoft's July 2026 objectives encompass identity and access, enterprise environment administration, secure software development, GitHub Actions and monitoring usage. This is not simply a test of creating repositories. An administrator must reconcile developer autonomy with access accountability, organizational policy and the operational consequences of configuration changes. In the broader range of Microsoft certifications, GH-100 sits alongside GH-200 and GH-500 while focusing on the enterprise control plane rather than one workflow or security scanner.

A growing engineering organization accumulates repositories, teams, automation tokens, external collaborators and compliance requirements. A permissive configuration may enable quick onboarding but make access reviews difficult; a restrictive one may cause teams to build unsanctioned workarounds. Good administration defines minimum standards and safe exceptions, then measures how they operate. GH-100's real-world challenge is to make governance durable through reorganizations, acquisitions and staff turnover. The best policy is not the one with the most prohibitions. It is the one that reduces material risk while remaining understandable and auditable to users.

Model identities and organizational ownership

GitHub Enterprise identity options can involve personal accounts, enterprise-managed users, identity-provider integrations and team membership. Those approaches differ in account lifecycle and administrative responsibility. An enterprise-managed user model places identity provisioning under organizational control, while other configurations may involve individual user accounts associated with an organization. The design should follow how staff join, change roles and leave. If offboarding only disables an internal HR account while an external collaborator's repository permission remains active, identity governance is incomplete. Track which system is authoritative for each access state.

Teams and organizations organize access but should not become arbitrary substitutes for role design. A developer might need write permission to two services, read permission to a shared library and limited access to security-sensitive repositories. Giving every engineer organization-owner rights is easier to administer until a compromised account can change policies for thousands of projects. Use team nesting and repository roles thoughtfully, document ownership of exceptional permissions and review activity. Administrators should know how to determine effective access and identify where a grant came from rather than searching only the visible repository member list.

Authentication assurance matters at the enterprise boundary. SAML SSO, multifactor authentication and related features can enforce stronger sign-in policies, but access tokens and application integrations require additional review. A human user's SSO session does not automatically restrict the scopes granted to a third-party application. OAuth apps, GitHub Apps, fine-grained personal access tokens and classic tokens have different permission models and lifecycle considerations. Prefer narrowly scoped integrations, reduce unnecessary standing credentials and plan how credentials will be rotated and revoked. A policy that addresses only interactive user login leaves a significant portion of the platform's access surface uncovered.

Repository ownership should survive departures. A project maintained by one engineer who controls the only deployment secret or branch policy is vulnerable to an ordinary personnel change. Define code-owner teams, repository administrators and escalation procedures so maintainers can recover or transfer responsibility. Administrative reports should flag abandoned repositories, stale collaborators and unexpected permission escalation. For regulated organizations, periodic access reviews need durable evidence of approval and removal. A spreadsheet of users is less valuable than a process that compares intended access with actual effective permissions and corrects drift.

Establish enterprise policy with room for safe exceptions

Enterprise and organization policies can govern repository creation, forking, visibility, Actions use, integrations and other settings. The hierarchy matters. A repository owner may not be able to override an enterprise restriction, and an organization policy may interact with a default setting in ways that surprise maintainers. Before applying an enterprise-wide change, document its intended control and test how common development workflows behave. A policy that blocks all outside collaborators may protect one class of repositories but break legitimate open-source coordination if introduced without an exception process.

Internal, private and public repository visibility carry different sharing implications. Internal visibility is not the same as private access limited to one team, and transferring or forking repositories can change where code is available. Treat visibility as part of a data classification decision, not merely a convenience setting. A repository containing deployment configuration may reveal infrastructure topology or credentials accidentally committed in history. Restricting visibility after exposure does not remove every copy. Governance should combine visibility policy, secret detection, audit evidence and developer training on what should never be committed.

Branch protection and repository rulesets reduce the risk of unreviewed changes, but their value depends on branch strategy and release process. Require appropriate reviews, status checks and protections for critical branches; ensure there is a documented emergency method for restoring production when normal approvers are unavailable. Avoid exceptions that silently bypass every check. An administrator should understand how rulesets apply across repositories and how changing a required check name can unexpectedly block merges. Rules are part of the release contract, so their rollout deserves compatibility testing just like a code change.

Audit logs help explain administrative actions after the fact. Monitor sensitive changes such as adding owners, altering SSO policy, modifying Actions permissions or granting application access. Retention and export mechanisms should meet the organization's investigation needs. Logs alone do not enforce security, and collecting them without a response process can produce little value. Establish which changes generate alerts, who receives them and what evidence is needed for investigation. An unusual configuration change is not necessarily malicious; context and change approvals help distinguish authorized maintenance from compromise.

Administer Actions and security at scale

GitHub Actions introduces compute and credential risks across the enterprise. Runners execute workflow code that may come from multiple repositories or trusted and untrusted contributors. Hosted runners, self-hosted runners and runner groups have distinct isolation, scaling and maintenance considerations. A self-hosted runner with broad network access and persistent state can become a lateral-movement pathway if it processes untrusted workflow code. Design runner assignments around trust boundaries and clean execution environments, not only around the desire to reduce build latency or cost.

Workflow permissions should follow least privilege. The default token in a job may need to read source but not write repository contents or access production deployment credentials. Third-party actions should be reviewed and appropriately version-pinned; an untrusted action can compromise a pipeline before its tests even run. The security of reusable GitHub Actions workflows depends on understanding caller and callee permissions: reuse can centralize controls while still allowing privilege leakage. Enterprise administration must account for where credentials cross workflow, repository and organization boundaries.

GitHub Advanced Security controls can include secret protection, code scanning and dependency-related features. Turning them on is a beginning, not a response strategy. A secret alert requires a process for revocation and investigation, while a dependency vulnerability needs assessment of exploitability, supported versions and deployment exposure. GH-500 focuses more deeply on those technical security operations. GH-100 candidates should understand administration and policy placement: who is permitted to enable features, how repositories inherit settings and how compliance evidence is gathered without drowning every project in duplicate alerts.

Supply-chain risk also involves identities that publish artifacts, approve changes and access package registries. Protecting only the default branch is insufficient if a deployment workflow can download a mutable dependency or use a broadly privileged service connection. Administrators should collaborate with security and delivery teams on artifact provenance, branch rules, package policies and emergency remediation. One compromise of an enterprise-wide automation integration may affect many products. Evaluate blast radius, not merely the number of repositories displaying a compliance check mark.

Make platform operation measurable and recoverable

License and feature management influence both cost and user experience. An enterprise may purchase advanced capabilities but fail to configure them for the repositories that carry the highest risk; another may enable expensive features without understanding usage. Report allocation, adoption and exceptions transparently. Administrators should know how to identify unused accounts, abandoned runner infrastructure and teams that cannot access needed services. Efficient governance requires feedback from developers as well as policy enforcement. High compliance with a workflow that developers routinely avoid is a warning, not a triumph.

Operational changes should use staging or controlled pilot groups when the platform supports them. Before enabling a new SSO requirement, test access for administrators, service integrations and emergency users. Before changing Actions permissions, run representative builds and deployments in affected repositories. Document rollback possibilities and any irreversible effects. Administrative errors at enterprise scope can stop many development teams simultaneously, so a change that looks small in the user interface can have a large operational impact. A review process proportional to blast radius is justified.

A realistic GH-100 practice scenario might create a test enterprise with two organizations, several teams and repositories of different sensitivity. Configure identity membership, repository visibility, branch rules and a restricted Actions runner group. Introduce an unauthorized collaborator and determine which audit event or effective permission reveals the problem. Test a workflow that requests more privileges than necessary, then narrow its permissions while preserving function. Finally, simulate removal of a repository owner and demonstrate continuity of administration. The point is to connect policy decisions to observed developer behavior.

GH-100 preparation should follow Microsoft's effective July 2026 skills outline and use current platform documentation for product-specific features. The durable competence is understanding ownership, effective access, platform-wide policy, secure automation and investigative evidence. An excellent GitHub Enterprise administrator keeps developers productive while making permissions and configuration changes explainable. The strongest design assumes teams and technologies will change and builds governance that can adapt without losing control of the software delivery system.