GH-100 tests whether you can run a GitHub Enterprise organization, not just use one — so the fastest way to diagnose a weak area is to work through a scenario with several interlocking requirements, the way the real exam presents case-study-style questions. The 5 blocks below map to Microsoft's 5 official GH-100 domains: identities & access, the enterprise environment, security & compliance, GitHub Actions, and usage monitoring.
Click any question to reveal the answer, the reasoning, and why each wrong option is wrong.
Want the full domain breakdown first? See the GH-100 study guide, or jump straight to the GH-100 task-based cheat sheet.
Scenario 1: Contoso Consolidates Identity
Contoso, a 2,400-employee company, is moving all GitHub work into a single GitHub Enterprise Cloud account. Security requires every account to be tied 1:1 to Contoso's Entra ID directory: accounts must be created automatically the moment someone joins the "Engineering" security group, removed automatically the moment they leave the company, and there must be no possibility of an employee accessing client repos through a personal, non-corporate GitHub account.
1Which identity model guarantees that no Contoso engineer can access the client repos through a personal, non-corporate GitHub account?Tap to see the four answer choices and the correct answer →
Enterprise Managed Users accounts are provisioned and owned entirely by the enterprise — they cannot exist outside it and cannot be a person's pre-existing personal account. That structurally rules out the "personal account with client access" scenario Contoso wants to eliminate.
A: SAML SSO enforces authentication through Contoso's IdP, but the underlying GitHub account can still be a personal account that a person owns independent of Contoso — SSO alone doesn't prevent that.
C: 2FA is an authentication-strength control, unrelated to who owns the underlying account.
D: Repository visibility controls who can see a repo, not what kind of identity a member authenticates with.
2Which feature automatically creates and removes GitHub accounts as membership in Contoso's "Engineering" Entra ID group changes?Tap to see the four answer choices and the correct answer →
SCIM (System for Cross-domain Identity Management) synchronizes account and team membership state from the identity provider's directory automatically — creating accounts when someone is added to the mapped group and removing access when they're removed, without manual intervention.
A: SAML SSO handles authentication at sign-in; it does not, by itself, create or remove accounts as directory groups change.
B: CODEOWNERS assigns automatic PR reviewers based on file paths — unrelated to account lifecycle.
D: Branch protection rules govern how changes merge into a branch, not account provisioning.
Scenario 2: Northwind Chooses a Deployment Model
Northwind Trading is EU-regulated and must keep its source code data within an EU boundary at rest, but wants to stay on GitHub's cloud infrastructure rather than self-host. Separately, its infra lead needs to justify a license renewal to finance with an accurate count of unique users consuming a seat across the company's 6 organizations, and later hits a storage anomaly self-service docs can't resolve.
3Northwind must keep source code data within an EU boundary at rest, wants every identity enterprise-owned, and wants to stay on GitHub-hosted cloud infrastructure. Which deployment model fits all three requirements?Tap to see the four answer choices and the correct answer →
GHEC with Data Residency pins data to a declared regional boundary while remaining on GitHub's cloud infrastructure; layering EMU on top makes every identity enterprise-owned. Only this combination satisfies the EU-boundary requirement, the identity requirement, and the "stay on the cloud" requirement together.
A: GHES is self-hosted infrastructure — it satisfies data control but contradicts the explicit requirement to stay on GitHub-hosted cloud infrastructure.
B: Standard GHEC has no data-residency guarantee and allows personal accounts, failing both the boundary and identity-ownership requirements.
D: EMU alone enforces enterprise-owned identity but does nothing to pin data to a geographic boundary.
4Northwind's infra lead needs a license-utilization figure for finance, counted correctly across the company's 6 organizations inside one enterprise. How should a single person who belongs to 3 of those organizations be counted?Tap to see the four answer choices and the correct answer →
GitHub Enterprise licenses are consumed per unique user across the entire enterprise account, not per organization and not per repository. A person in 3 organizations under one enterprise still consumes exactly one seat.
A: This would overcount seats and is a common mistake when organizations were historically billed independently — it doesn't reflect how enterprise-level licensing counts users.
C: Organization membership under an enterprise does consume a license; it isn't free just because it spans multiple orgs.
D: License consumption is tied to unique enterprise membership, not the number of repositories a person can reach.
5The infra lead spends two hours investigating an unusual repository storage issue using self-service docs with no resolution. What should they do before contacting GitHub Support?Tap to see the four answer choices and the correct answer →
Generating a support bundle and diagnostics before escalating gives GitHub Support the technical detail they'll ask for anyway, and reflects the domain objective of knowing which issues are admin-resolvable versus which need Support — with the evidence prepared either way.
A: Skipping diagnostics usually means Support asks for the same bundle later, adding a round trip.
C: Recreating a repository risks data loss and doesn't diagnose the underlying cause.
D: Billing plan is unrelated to a storage/technical anomaly on one repository.
Scenario 3: Fabrikam Investigates a Leak
Fabrikam's security team is alerted that a valid-looking cloud API key was detected in a commit pushed to a public repo about 10 minutes earlier. Separately, Fabrikam wants automatic pull requests whenever a used npm package gets a published CVE, and wants an internal migration tool's nightly Actions automation to keep running with least-privilege, read-only access to Issues even after the engineer who built it leaves.
6A valid-looking cloud API key was detected in a commit that was pushed to a public Fabrikam repo; the alert fired about 10 minutes after the push. Which feature most likely generated this alert?Tap to see the four answer choices and the correct answer →
Because the commit was already pushed and the alert arrived afterward, this is secret scanning's standard detection flow, which scans committed content and flags matches after the fact. Push protection, by contrast, blocks the push before it completes — it wouldn't have let the secret land in the first place.
B: Push protection prevents the push from succeeding at all when it detects a matching pattern — the scenario describes a secret that was already pushed, ruling this out.
C: Dependabot flags known vulnerabilities in third-party dependencies, not credentials exposed in your own commits.
D: CodeQL performs static analysis of code logic for exploitable flaws — it doesn't pattern-match for exposed secrets.
7Fabrikam wants an automatic pull request opened whenever an npm package they use gets a published CVE, without a human retriggering anything. What should they enable?Tap to see the four answer choices and the correct answer →
Dependabot alerts notify Fabrikam that a vulnerability exists; Dependabot security updates is the separate setting that automatically opens a pull request upgrading the dependency to a patched version. Fabrikam explicitly wants the PR to appear automatically, which requires security updates enabled, not just alerts.
A: Alerts alone only notify — they don't open a PR by themselves.
C: Secret scanning addresses exposed credentials, not dependency vulnerabilities.
D: CodeQL analyzes Fabrikam's own source code, not third-party package vulnerabilities.
8Fabrikam wants their internal migration tool's nightly Actions automation to keep running with least-privilege, read-only access to Issues, even after the engineer who built it leaves the company. What identity should the automation use?Tap to see the four answer choices and the correct answer →
A GitHub App has its own identity independent of any individual user and can be scoped to exactly the permissions it needs — read-only Issues, in this case. It keeps working regardless of which employees come or go, satisfying both the least-privilege and continuity requirements.
A: A personal access token is tied to one person's identity and typically stops working (or becomes an orphaned credential risk) once that person leaves.
B: Sharing personal credentials across a team is a security anti-pattern and still ties the automation to an individual's account.
D: A full-repo-scope classic PAT violates least privilege and is still bound to whichever user generated it.
Scenario 4: Tailwind Traders Scales Its Pipelines
Tailwind Traders runs GitHub Actions across 80 repos. A new deploy job must reach an internal payment-processing database with no public IP and no plan to ever expose one. Separately, Tailwind wants a DEPLOY_KEY readable by a deploy job only after a release manager manually approves that run, and wants to stop storing long-lived AWS access keys as secrets for every AWS deploy job.
9Tailwind Traders' deploy job needs to reach an internal payment-processing database with no public IP address and no plan to ever expose one. What runner configuration is required?Tap to see the four answer choices and the correct answer →
GitHub-hosted runners always originate from GitHub's public IP ranges and cannot reach non-internet-routable, private-network resources. Reaching an internal database with no public IP requires self-hosted runners placed with actual network access to that resource, optionally combined with IP allow lists or private networking (including Azure private networking).
A: Auto-scaling has no bearing on network reachability — GitHub-hosted runners still can't reach a non-routable private resource.
B: There is no such "static IP add-on" for GitHub-hosted runners that grants private network access.
D: A VPN action inside a GitHub-hosted runner job doesn't solve the underlying reachability problem the same way a properly network-placed self-hosted runner does, and isn't the standard/recommended approach the exam tests.
10Tailwind wants `DEPLOY_KEY` readable by the deploy job only after a release manager manually approves that specific run. Where should this secret be configured?Tap to see the four answer choices and the correct answer →
Environment secrets are the only secret scope that can be gated behind required reviewers — the job must target the environment, and the run pauses for approval before the environment's secrets become readable. Organization- and repository-level secrets have no built-in manual-approval gate.
A: Organization secrets are available broadly (unless restricted to a repo list) with no per-run approval gate.
B: Repository secrets are readable by any workflow in that repo with no approval step.
D: Actions cache stores build artifacts/dependencies for reuse — it isn't a mechanism for storing or gating secrets at all.
11Tailwind wants to stop storing long-lived AWS access keys as secrets for every AWS deploy job. What should replace them?Tap to see the four answer choices and the correct answer →
OIDC federation lets a workflow request short-lived, per-run cloud credentials directly from AWS using a signed token, eliminating the need to store any long-lived AWS access key as a GitHub secret at all — which is exactly what Tailwind asked to stop doing.
A: More frequent rotation reduces risk but doesn't eliminate the long-lived-secret storage Tailwind wants gone.
C: Changing the secret's scope doesn't change the fact that it's still a long-lived static credential.
D: Encrypting the key before storing it as a GitHub secret still leaves a long-lived credential in the pipeline — GitHub secrets are already encrypted at rest regardless.
Scenario 5: Contoso Finance Reviews the Bill
Back at Contoso, a quarterly review shows GitHub Advanced Security costs rose sharply. Finance wants to know which team's repositories drove the increase, and separately wants to know whether the design team's 15 GitHub Copilot Business seats are actually being used.
12Contoso's finance team sees GitHub Advanced Security costs rise sharply this quarter and wants to know which team's repositories drove the increase. Where should the admin look first?Tap to see the four answer choices and the correct answer →
Interpreting usage reports for metered products is the exam objective that directly covers attributing a cost change to specific consumption — Advanced Security features like secret scanning and code scanning are billed per active committer, and the usage report breaks that down by repository/team.
A: READMEs document a project; they carry no billing or usage data.
C: A membership list shows who belongs to the org, not which repos consumed metered security features.
D: Popularity metrics like stars and forks have no relationship to Advanced Security billing.
13Finance also asks whether the design team's 15 GitHub Copilot Business seats are actually being used. What should the admin check?Tap to see the four answer choices and the correct answer →
Evaluating enterprise usage patterns to identify underutilized features means tying a license or seat cost back to real activity data — Copilot usage/insights reporting shows which assigned seats are actually generating suggestions or chat activity versus sitting idle, which is what a "reassign this seat" recommendation should be based on.
A: Assignment age says nothing about whether the seat is actually used.
C: Repository count reflects the team's project footprint, not individual Copilot activity.
D: 2FA status is a security control unrelated to feature usage or license optimization.
Distractor Patterns to Watch For
The wrong answers above weren't random — they follow a handful of repeatable patterns worth recognizing on exam day.
| Pattern | What it looks like |
|---|---|
| Detection vs. prevention | Picking "push protection" for an already-completed push, or "secret scanning" for a blocked one — read whether the bad thing already happened. |
| Person-bound vs. app-bound identity | Picking a personal PAT for automation that must outlive one employee — the exam rewards recognizing when a GitHub App is required. |
| Cloud-hosted vs. self-hosted | Picking a GHEC variant when the scenario demands zero internet egress or full infrastructure control, which only GHES satisfies. |
| Notify vs. auto-remediate | Assuming "alerts" alone deliver an automatic fix — alerts and automated PRs are separate settings (e.g. Dependabot alerts vs. security updates). |
| Secret scope creep | Defaulting to an organization- or repository-level secret when the scenario specifically needs a manual-approval gate, which only environment secrets provide. |
How to use this: if you missed more than 3 of these 13, revisit the matching domain in the GH-100 study guide before scheduling — the real exam leans on scenario recognition across interlocking requirements, not isolated definitions.
Go Beyond 13 Questions
MSCertQuiz has a growing GH-100 question bank covering identity federation, deployment models, security scanning, runner and secrets configuration, and usage monitoring — with the same reveal-as-you-go, rationale-for-every-option format.
MSCertQuiz sells practice-exam access for GH-100 and other GitHub and Microsoft certifications; these questions are written by the same team that builds those question banks, matched to Microsoft's official GH-100 study guide and certification page, checked September 2026.