Domain 1: Manage identity and access
- The enterprise account is the layer above organisations: it exists so policy, security settings and billing are configured once and inherited by every organisation beneath it. Repositories live in organisations, not in the enterprise itself.
- Configuring an identity provider at the enterprise gives one sign-in for every organisation underneath and one place to change it. Configuring the same provider per organisation produces the same experience with several times the maintenance, and the copies eventually drift.
- SAML single sign-on establishes who somebody is at the moment they sign in. It does nothing about accounts belonging to people who have left - that gap is closed by SCIM provisioning, not by SSO.
- SCIM provisioning creates, updates and deactivates membership automatically from the directory, so leavers lose access and team membership tracks people moving between roles. Both are failures of manual administration that persist quietly until an audit finds them.
- When SSO enforcement is switched on, every member must authenticate through the provider to link their account, and anyone who has not done so loses access until they do. The wave of identical reports immediately after enforcement is resolved by the user signing in, not by an administrator.
- An outside collaborator is granted access to named repositories rather than joining the organisation, which makes them the right mechanism for a contractor who should see one project and nothing else. They can hold write access on repositories they are granted, and they do consume a licence.
- Organisation members belong to the organisation; outside collaborators are scoped to specific repositories. Choosing between them is a scoping decision, not a permission-level one.
- Map directory groups to teams and let the directory be the source of truth. Team-based access makes the answer to "who can reach this repository" a list you can read rather than an audit you have to run.
- Team permissions flow downward from parent team to child team. A child inherits the parent's access and can add to it, so nesting is how you model an organisation without granting the same thing repeatedly.
- Grant from nothing upward rather than granting broadly and restricting afterwards. Starting from access and trimming leaves permissions nobody remembers granting.
- Personal access tokens outlive the account that created them in the sense that removing a person from the directory does not by itself invalidate credentials already issued - deprovisioning has to account for tokens as well as membership.
- Enterprise owners can undo the controls that make everything else safe, so the owner list is the shortest list worth reviewing regularly. An administrator nobody recognises is either stale privilege or a compromise.
- Enterprise Managed Users belong to the enterprise rather than to the person: the enterprise owns the identity, usernames are derived from the directory and carry a suffix rather than being chosen, and the account is confined to that enterprise.
- A managed account cannot participate in public GitHub - the restriction is on contributing publicly, not on consuming public code - and a member's existing personal account is untouched, because the managed account is a separate identity.
- Enterprise Managed Users depend entirely on provisioning: with no SCIM integration no accounts exist, because nothing else creates them.
Domain 2: Deploy and license GitHub Enterprise
- GitHub Enterprise Cloud is hosted and operated by GitHub; GitHub Enterprise Server runs on infrastructure the customer provides, maintains, backs up and upgrades. Nearly every other difference - cost shape, upgrade cadence, who is on call - follows from that one.
- The reason to accept the operational burden of self-hosting is an absolute requirement that source stays on controlled infrastructure, typically regulatory, contractual or classification-driven. Wanting the newest features favours the cloud, where they arrive first.
- Patching the instance and being able to restore it are the customer's responsibilities on Server, and both are ongoing obligations needing staffing and rehearsal rather than one-off setup.
- Data residency places an enterprise's data in a chosen geography. It answers a location question and nothing more: vendor access is governed by contractual terms and operational controls, not by where the bytes sit.
- Residency commitments apply to specified data and services, and the gaps are what catch people - check coverage against the feature set you actually intend to use before committing.
- Running both Cloud and Server means two control planes, and therefore two of everything governance depends on: two policy surfaces, two audit trails, two identity configurations.
- The usual driver for migrating from Server to Cloud is handing back the operations burden rather than acquiring a specific feature.
- In a migration, identity mapping determines how the result lands - who owns what afterwards is decided by how accounts are matched, not by the repository transfer itself.
- Code and most history move cleanly in a migration; the losses are at the edges - integrations, webhooks, some metadata and anything depending on instance-specific configuration.
- Licensing counts the person, once, across the whole enterprise, no matter how many organisations they belong to.
- Outside collaborators consume licences, which is where the billing surprise usually comes from. A seat is released only when the person no longer holds any access anywhere in the enterprise.
- Suspending a user stops their access but does not necessarily stop the charge - access need is the only criterion that produces the right licensing answer.
- GitHub Advanced Security is a separate purchase counted against active committers on the repositories where it is enabled, so blanket enablement counts committers on repositories that never warranted it.
- Seats count people; consumption counts what those people ran. Actions minutes and Packages storage are metered, while organisations, teams and repositories are structure and are not.
- Moving Actions to self-hosted runners stops the per-minute charge and starts paying for infrastructure you run and maintain - the cost does not disappear, it changes shape.
- Unused seats are committed money buying nothing, and are usually the largest single recoverable line in an enterprise bill.
Domain 3: Secure the enterprise
- A ruleset is defined once at organisation level and targeted at many repositories by name or pattern. That is what makes consistent protection achievable across hundreds of repositories rather than something configured individually and forgotten.
- Multiple applicable rulesets combine rather than compete: a branch covered by one requiring two reviews and another requiring signed commits must satisfy both. The strictest requirement from each wins, and recency does not determine precedence.
- Enterprise-level and organisation-level rules both apply, and a push must satisfy every rule from either. Rules configured above the repository are not visible from inside it, which is a common source of confusion for repository administrators.
- Evaluate (dry run) mode records what a ruleset would have blocked while letting the work proceed, turning a risky enterprise-wide rollout into a short list of teams to contact first.
- Roll out by evaluating first, because the surprises are in the repositories nobody thought about - typically release automation and migration tooling that has to do something the rules forbid.
- Give release tooling and migrations a named, documented bypass entry rather than weakening the rule for everybody. Exceptions are acceptable when they are visible and revisited.
- Exempting administrators or owners from merge and review requirements removes the control where it matters most: those accounts could already change almost anything, and they are exactly what an attacker targets.
- Target rulesets with a pattern rather than an explicit repository list, or repositories created after the rollout arrive unprotected.
- Release branches ship code to users and frequently carry no protection at all, which makes them worth checking specifically when scoping a ruleset.
- Going straight to enforcement without an evaluation pass typically stops release automation the same afternoon - the breakage list exists either way, and a dry run produces it before the breakage.
- A required review records an approval; it cannot compel attention. It is a process control, not a guarantee that anybody read the diff.
- An approval applies to the diff that was approved. Pushing further changes invalidates it, because an approval of one diff does not cover a different one.
- CODEOWNERS routes review to whoever answers for that part of the codebase, which is how review requirements survive a growing repository.
- A required status check must be able to fail, and it must test what will actually merge. A check nobody trusts is worse than no check, because it still looks like one.
- Requiring linear history forces a straight line of commits, which keeps the history readable and auditable at the cost of some merge flexibility.
- Requiring a review from someone other than the author gives two people per change, which is the separation-of-duties control auditors look for.
Domain 4: Govern GitHub Actions
- The allowed-actions policy governs which external actions a workflow may call. Every action runs with access to the job's context and secrets, so an unrestricted policy means arbitrary third-party code executes inside your build.
- Referencing an action by tag or branch means the maintainer can change what that reference points at, so code you never reviewed runs with access to your secrets. Pinning to an immutable commit SHA is what removes that.
- The two enterprise-level exposures are the third-party code your pipelines execute and the untrusted trigger that causes them to run - restrict both. Which languages a workflow builds is not a security control.
- Anyone can fork a public repository and open a pull request, and if that triggers a workflow their code runs on your runners. Fork owners gain no write access, but they do gain execution.
- A self-hosted runner sits on infrastructure you control, often with network access to internal systems, so a fork pull request triggering a workflow on one gives an outsider code execution inside the perimeter. The combination is specifically discouraged.
- A runner group binds a set of runners to named repositories or organisations, which is how you stop a low-trust repository scheduling work onto runners that can reach production networks. The isolation is the point.
- Making runners universally available means the least trusted repository can reach the most privileged infrastructure.
- Self-hosted runners should be ephemeral - destroyed between jobs - because anything one workflow leaves on disk is there for the workflow that follows it.
- Anybody who can register a runner can attach infrastructure to your estate, so registration rights are a privileged permission rather than a convenience.
- Self-host when a job genuinely needs something hosted runners lack - specific hardware, licensed software, or private network access - not by default.
- Restricting actions buys safety and costs agility. The honest framing is that a request-and-review process must be fast enough that people use it rather than route around it.
- Set the default GITHUB_TOKEN permissions to read-only at the organisation level and let workflows request what they need. One setting applies least privilege across every pipeline at once.
- Elevate the single workflow that needs write access rather than raising the default for everything.
- An action inherits whatever the job's token can do, so reducing what the job holds reduces what a compromised action can reach.
- Tightening default permissions surfaces undeclared dependencies as failures, which is the point - but run the change in a low-risk scope first to find the workflows that will break before breaking them.
- A workflow authenticating as a person ends up acting as somebody who may no longer be there; a dedicated identity with scoped permissions is the durable alternative.
Domain 5: Monitor usage and cost
- The audit log records administrative and access events - a member added, a setting changed, a repository made public, a token created - with the actor and timestamp attached. Open vulnerabilities live in the security views, not here.
- An account active across several organisations leaves a trail scattered across each of their logs; the enterprise-level audit view assembles it into one sequence, which is what makes investigating lateral movement practical.
- The events worth reading individually are the ones that expand exposure or authority: a repository becoming public, a new enterprise owner, a change to authentication settings. Pull requests being opened is ordinary traffic in enormous volume.
- The audit log records the act, not the justification or the consequence - it tells you what happened and who did it, and nothing about whether it was appropriate.
- Audit log streaming forwards events to a log platform, where they can be retained for whatever period policy demands and correlated with identity, network and endpoint telemetry. That correlation is where a partial signal becomes a detection.
- Streaming does not extend what the GitHub interface shows; it moves the events somewhere with a longer retention policy.
- The platform's own retention window is finite, so an investigation reaching back over a year depends entirely on whether those events were forwarded - which is the practical reason streaming is configured before it is needed, not after.
- Streaming without alerting rules is storage rather than security: somebody must be told, and the history must still exist when they look.
- Configuration drift accumulates whether or not anything has gone wrong, which is why periodic review of settings and ownership is a standing task rather than an incident response.
- Licences are charged per person; Actions minutes and Packages storage are metered by consumption. Nobody approves a runaway schedule, but the invoice arrives anyway.
- To attribute Actions spend, combine per-repository consumption figures with an ownership map - the number alone tells a team nothing they can act on.
- A spending limit stops the work when reached; an alert only warns. A single shared ceiling means one team's mistake stops everybody, and a ceiling set too low turns a busy week into an outage.
- Project spend by trend per unit rather than from a single month, because one month contains whatever happened to run that month.
- Default artefact retention applied across thousands of repositories adds up unseen; reducing it stops you keeping what nobody fetches and nothing references.
- Optimising something that costs nothing achieves nothing - start from the repositories that actually produced the number.
- A scheduled export is the only version of a usage report that stays current; a manual download is stale the day after it is taken.
- A runaway bill is usually a trigger firing on everything - a schedule that is too frequent, or a workflow running on every push to every branch.
GitHub Enterprise Administrator exam tips
- Read every scenario for the LAYER it is asking about. A control configured at the enterprise applies to every organisation beneath it and is invisible from inside a repository, and a large share of GH-100 questions turn on that distinction alone.
- When a question separates authentication from lifecycle, SAML SSO answers "who is this person signing in" and SCIM answers "should this account exist at all". Leavers, drift and team membership are always provisioning answers.
- For rollout questions, the safe answer is nearly always evaluate first, then enforce, with a named bypass for automation. Blanket administrator exemption is a trap: it removes the control from exactly the accounts worth controlling.
- In Actions governance, prefer the answer that reduces what a job can do over the one that adds monitoring - read-only default token permissions, pinned action SHAs, and runner groups are controls; dashboards are not.
- Cost questions distinguish seats from consumption. Licences count people once across the enterprise and are released only when all access is removed; minutes and storage are metered and need attribution before optimisation.
Study guide FAQ
How is the GH-100 exam scored and structured?
A score of 700 or greater on a scaled 1-1000 range is required to pass per the official study guide. The exam runs 100 minutes with about 75 multiple-choice and multiple-select questions, and may include interactive components. It is proctored and delivered through Microsoft's certification platform, where the skills-measured breakdown is published.
Which domain should I focus on most?
Secure the enterprise is the largest domain and Govern GitHub Actions is close behind, so rulesets and Actions security together account for a substantial share of the exam. Manage identity and access is the domain most likely to appear inside other questions, because SSO, SCIM and Enterprise Managed Users underpin scenarios in every other area.
Do I need hands-on GitHub Enterprise experience to pass?
It helps considerably. The questions are scenario-shaped - a control has been rolled out and something broke, or a bill has grown and you have to attribute it - and they reward having seen the administrative surfaces rather than only read about them. A GitHub Enterprise Cloud trial covers most of the identity, ruleset and Actions governance material.
Has the exam changed recently?
Yes. GitHub significantly restructured the GH-100 skills-measured breakdown in July 2026 into the current five domains: identity and access, deployment and licensing, securing the enterprise, governing Actions, and monitoring usage and cost. Study material written against the older split will not map cleanly, so check any resource against the current exam guide.