The fastest way to check GH-200 readiness isn't reading through five labeled domains again — it's seeing whether you can still pick the right mechanism when a scenario gets harder. These 15 questions ramp from basic workflow mechanics up to the enterprise-governance and security scenarios that trip up candidates who've only run GitHub Actions on solo projects.
Click any question to reveal the answer choices, then the full reasoning for the correct one and for every wrong one. MSCertQuiz sells 500-question GH-200 practice access; the same team wrote these 15 to Microsoft's published skills-measured objectives, checked September 7, 2026.
Want the domain-by-domain narrative first? See the GH-200 study guide, or jump straight to the GH-200 cheat sheet for the reference tables these questions draw on.
Easy: Core Workflow Mechanics
Questions 1-5 · inputs, matrix basics, service containers, and starter workflows
1workflow_dispatch Input TypesA workflow should let someone manually trigger a deployment and pick an environment name from a fixed set — staging or production — not type it freely.Which workflow_dispatch input type enforces this?Tap to see the four answer choices and the correct answer →
The choice input type restricts a workflow_dispatch input to an enumerated list, rendered as a dropdown in the manual-run UI — exactly what a fixed environment-name selector needs.
A: string accepts free text; a comment describing intent is not enforced by the workflow engine.
B: boolean only accepts true/false, not named environments.
D: number restricts to numeric values, not named options.
Key concept: workflow_dispatch input types: string, boolean, choice (with options:), number, environment (restricted to configured deployment environments). Pick the type that matches the real constraint, not just "something that looks close."
2GITHUB_STEP_SUMMARYA team wants a formatted Markdown report of test coverage visible directly on the Actions run page — no separate artifact download required.What should the workflow write the report to?Tap to see the four answer choices and the correct answer →
Writing Markdown to the GITHUB_STEP_SUMMARY environment file renders it directly in the Actions run UI as a job summary — built for exactly this use case.
A: GITHUB_ENV sets environment variables for later steps, not a rendered report.
B: GITHUB_OUTPUT defines step outputs consumed by other steps/jobs, not a human-facing summary.
D: An artifact requires a separate download and doesn't render inline on the run page.
Key concept: GITHUB_STEP_SUMMARY accepts Markdown and appends across steps — multiple steps can build one cumulative summary for a run.
3Matrix fail-fastA build matrix tests three Node.js versions. The team wants to see every variant's result even if one fails early, so they don't miss a second, unrelated bug.What should change in the strategy block?Tap to see the four answer choices and the correct answer →
fail-fast defaults to true, canceling all remaining matrix jobs the moment one fails. Setting it to false lets every matrix variant run to completion so failures don't hide each other.
A: continue-on-error affects whether one step's failure fails its own job — it does not stop fail-fast from canceling other matrix jobs.
C: max-parallel only limits how many jobs run concurrently; it doesn't stop cancellation on failure.
D: Manually splitting into separate jobs throws away the matrix's purpose and still doesn't address the fail-fast behavior directly.
Key concept: fail-fast: false + max-parallel together let you both see every result and cap resource usage — they solve different problems and are often used together.
4Service ContainersA CI job needs a live Postgres database running alongside the test steps to support integration tests.Which feature should the job use?Tap to see the four answer choices and the correct answer →
services: at the job level runs a container alongside the job for its full lifetime, reachable via localhost or the service name, with configurable ports and health checks — the built-in mechanism for job-scoped dependent services.
A: A dedicated runner adds infrastructure overhead the built-in feature already solves.
C: Composite actions bundle reusable steps; they don't define standalone service containers.
D: Starting Docker manually inside a step repeats setup work every run instead of using the job-level lifecycle GitHub already manages.
Key concept: Service containers are configured under jobs.<job_id>.services, with each service getting its own ports:, env:, and options: (e.g., health-cmd for readiness checks).
5Starter Workflow BasicsA developer creates a new repository and picks a "Node.js CI" template from the Actions tab to get a working pipeline quickly.What did the developer just add to the repo?Tap to see the four answer choices and the correct answer →
The Actions tab template gallery copies a starter workflow into the repo. From that point it is an ordinary file the repo owns — editing it doesn't affect the template, and updates to the template don't flow back into the repo.
A: A reusable workflow is invoked with workflow_call from another workflow file, not picked from the template gallery this way.
C: Composite actions are a distinct authoring concept, not what the template gallery inserts.
D: There is no ongoing live link between a copied starter workflow and its source template.
Key concept: Starter workflow = one-time copy, then independent. Reusable workflow = live, versioned, invoked repeatedly via workflow_call. The exam tests this distinction directly.
Medium: Reusable Workflows & Troubleshooting
Questions 6-10 · workflow_call at scale, fork PR security, retention policy, action types, runner images
6Reusable Workflows at ScaleA platform team wants one CI workflow definition maintained centrally and called from 12 different application repositories, each passing its own build target and its own deployment secret.Which approach correctly supports this?Tap to see the four answer choices and the correct answer →
A reusable workflow invoked through workflow_call is exactly this pattern: one centrally maintained source of truth, with each caller passing its own inputs and secrets explicitly.
A: 12 independent copies immediately defeats "centrally maintained" — every future change means editing 12 files.
C: Composite actions bundle steps, not full job/workflow structure, and don't accept a mapped secrets: block the way workflow_call does.
D: A shared org secret with no workflow_call neither centralizes the workflow logic nor lets each repo differ.
Key concept: workflow_call syntax: on: workflow_call: inputs: {...} and secrets: {...} in the called workflow; the caller passes them with uses: org/repo/.github/workflows/file.yml@ref plus with: and secrets:.
7pull_request vs pull_request_targetA public repository runs CI on pull_request from external contributors. A maintainer wants a step to comment on the PR using a token that needs write access — access currently withheld from fork-triggered runs by design.What is the security-conscious way to add this capability?Tap to see the four answer choices and the correct answer →
The standard safe pattern separates execution of untrusted fork code (no secrets, pull_request) from any step that needs elevated access (a separate, controlled workflow that never checks out and runs untrusted code with those secrets).
A: Running pull_request_target against untrusted fork code with full secrets exposed is one of the most commonly documented GitHub Actions security mistakes.
C: "secrets: inherit" is not valid syntax on a pull_request trigger, and pull_request from forks doesn't expose repo secrets by design.
D: Granting collaborator access is a far broader permission grant than the problem requires and isn't how PR comment automation is normally solved.
Key concept: pull_request (from a fork) = no secrets, safe to run untrusted code. pull_request_target = full secrets, runs against the target branch's workflow file — never check out and execute untrusted fork code inside it.
8Centralized Artifact RetentionAn org's compliance team wants workflow artifacts and logs automatically deleted after 14 days platform-wide, without depending on individual repo owners to remember to configure it themselves.What should enforce this centrally?Tap to see the four answer choices and the correct answer →
Organization-level retention policy management — configurable via the REST API across logs, artifacts, and workflow runs — is the built-in way to enforce a uniform rule without relying on per-repo compliance.
A: Manual per-repo configuration is fragile and exactly what a compliance requirement is trying to avoid.
C: Building a custom scheduled-deletion workflow per repo reinvents a feature GitHub already provides centrally.
D: Disabling artifacts entirely removes a capability teams need, an overcorrection for a retention requirement.
Key concept: Retention policies can be read and set programmatically at org/repo level via REST APIs for logs, artifacts, and workflow runs — useful for compliance automation beyond the UI.
9Choosing an Action TypeA team wants to publish a Marketplace action that must behave identically regardless of the runner's OS, bundling a very specific pinned compiler toolchain rather than depending on whatever the runner image happens to have installed.Which action type best fits this requirement?Tap to see the four answer choices and the correct answer →
A Docker container action packages its own environment via a Dockerfile, guaranteeing a consistent, pinned toolchain regardless of the underlying runner OS or image — the standard reason to choose it over the other action types.
A: JavaScript actions execute directly on the runner's own Node.js install — there's no way to bundle an unrelated pinned compiler toolchain inside the action itself.
C: Composite actions still execute against whatever is already on the host runner; there's no isolated environment.
D: Reusable workflows compose jobs across a pipeline; they don't solve single-action, portable-environment distribution.
Key concept: Action type decision: JavaScript = fast, cross-platform, runs on the host directly. Docker = full environment control, Linux runners only. Composite = bundles existing steps/actions, no isolation.
10Runner Image AssumptionsA workflow starts failing after GitHub deprecates an older Ubuntu runner image, because a specific tool version the team assumed was preinstalled is no longer present on the new default image.What is the most reliable long-term fix?Tap to see the four answer choices and the correct answer →
Hosted runner images change their preinstalled tool versions over time — the exam explicitly covers checking image release notes/toolcache and installing what you need at runtime rather than assuming defaults will stay fixed.
A: Self-hosting to dodge an image deprecation adds ongoing maintenance and infrastructure burden instead of fixing the underlying assumption.
C: GitHub does not offer indefinite image freezes on request for hosted runners.
D: Switching operating systems doesn't address the assumption problem and introduces new, unrelated compatibility issues.
Key concept: Treat GitHub-hosted runner image contents as a moving target — check the image's release notes/toolcache, and install anything version-specific explicitly rather than assuming.
Hard: Enterprise Governance & Security
Questions 11-15 · OIDC federation, runner groups, immutable actions, attestations, nested workflows
11OIDC Federation (AWS)A workflow currently deploys to AWS using a long-lived IAM user access key stored as a repository secret. The security team wants that stored key eliminated entirely, without breaking automated deployments.What should replace the stored access key?Tap to see the four answer choices and the correct answer →
Requesting an OIDC token (permissions: id-token: write) and exchanging it for temporary AWS credentials via a federated IAM role trust policy removes the need to store any long-lived cloud credential at all.
A: Frequent rotation shrinks the exposure window but the long-lived-credential model, and the need to store something, still exists.
C: Moving scope from repository to environment changes where it's stored, not the fundamental reliance on a stored long-lived credential.
D: Encrypting the key inside the repo still stores a durable secret — just obscured — and directly contradicts the "eliminate the stored credential" goal.
Key concept: OIDC federation works the same shape across clouds: request an id-token, exchange it via a pre-configured trust relationship (Azure federated credential, AWS IAM role trust policy, GCP workload identity federation) for a short-lived token.
12Runner Groups + IP Allow ListsA large enterprise wants only specific self-hosted runners — reachable exclusively from the corporate network's known IP ranges — usable by a defined subset of sensitive repositories, enforced centrally rather than left to each repo.Which combination of features achieves this?Tap to see the four answer choices and the correct answer →
Runner groups control exactly which repositories or organizations can use a given set of runners; an organization/enterprise-level IP allow list restricts where Actions traffic and API access are allowed to originate from — together, precisely this governance requirement.
A: Environment protection rules govern deployment approvals, not which physical or self-hosted runners are network-reachable.
C: CODEOWNERS affects who must review a pull request; it has no effect on runner access or network restriction.
D: Signed commits address commit authenticity, not which runners a repository can reach or use.
Key concept: Runner groups = access control over which repos can use which runners. IP allow lists = network-origin control. Enterprise governance questions often combine both rather than testing them in isolation.
13Immutable Actions + SHA PinningA security audit flags a workflow referencing a third-party action by a floating major-version tag (@v3). The team wants to align with the 2026 immutable-actions rollout while minimizing ongoing maintenance.What is the recommended remediation?Tap to see the four answer choices and the correct answer →
Immutable action releases lock a specific published version's content once released — but a floating tag like @v3 can still be repointed by the publisher to a different release. Pinning to a full commit SHA is the recommended way to guarantee exactly which code executes, paired with a deliberate process for reviewing and updating that pin.
B: Immutability protects a given release's content; it does not stop a maintainer from moving a major-version tag pointer to point at a different release — the tag itself is still floating.
C: @main is the most volatile reference possible — the opposite of the intended fix.
D: Forking and never updating trades one risk (a moved tag) for another (permanently missed security patches) and isn't what aligning with immutable-release practice is asking for.
Key concept: Immutable action releases ≠ "the tag is now safe to float." Immutability is about a specific release's content, not about tag mutability. SHA-pinning is still the exam's expected answer for "guarantee exactly what runs."
14Artifact AttestationsA regulated organization wants to cryptographically verify, at deployment time, that a container image was actually built by their official CI workflow and not tampered with or built somewhere else.What GitHub Actions capability directly supports this requirement?Tap to see the four answer choices and the correct answer →
Artifact attestations provide signed, verifiable provenance metadata (aligned with SLSA) proving what workflow produced a given artifact — the direct answer to a "cryptographically verify this came from our CI" requirement, and a named topic in GH-200's security domain.
A: A passing status check only proves a check ran; it's not cryptographic proof of build origin or artifact integrity.
C: CODEOWNERS controls PR review assignment, unrelated to verifying build provenance.
D: A manually stored digest isn't signed provenance, doesn't scale, and can't verify authenticity on its own.
Key concept: Artifact attestations tie an artifact to the exact workflow run and repository that produced it, verifiable independently of trusting whoever hands you the file — the modern answer to supply-chain provenance questions.
15Nested Reusable Workflow LimitsA team builds a reusable workflow (A) that itself calls a second reusable workflow (B) via workflow_call, which in turn tries to call a third reusable workflow (C) the same way — maximizing shared logic reuse across the chain.What should the team know about this design?Tap to see the four answer choices and the correct answer →
GH-200's own objectives explicitly name "nested reusable workflow limits" as an exam topic — chaining workflow_call invocations is supported, but only up to a defined depth, a real design constraint teams building layered shared workflows need to plan around.
A: This overstates support and is the opposite of the documented constraint.
C: Nesting doesn't auto-flatten — each call remains a distinct workflow_call invocation subject to the depth limit.
D: Reusable workflows calling other reusable workflows is supported up to the depth limit; the constraint is how deep, not whether it's possible at all.
Key concept: When a scenario chains three or more workflow_call invocations together, that's a deliberate signal pointing at the nesting-depth limit, not just a "reusable workflows are flexible" trivia question.
GH-200 Distractor Patterns Worth Recognizing
Five wrong-answer shapes that recur across the questions above — spotting the pattern is often faster than knowing the exact feature name.
| Pattern | What it looks like | Seen in |
|---|---|---|
| The floating-tag trap | A wrong answer keeps using @main or a bare version tag when the correct answer requires pinning to a full commit SHA. | Q13 |
| The bigger-hammer trap | A wrong answer solves the stated problem with an overly broad grant — pull_request_target on everything, a shared org secret, collaborator access — instead of the narrowly scoped correct mechanism. | Q7, Q11 |
| The manual-process trap | A wrong answer proposes a person or a custom script doing repeatedly, by hand, something the platform already automates natively. | Q8, Q10 |
| The right-feature-wrong-scope trap | A wrong answer names a real GitHub Actions feature but applies it at the wrong level — repo secret instead of environment secret, per-repo setting instead of org-level policy. | Q6, Q12 |
| The looks-secure-but-isn't trap | A wrong answer sounds security-conscious — encrypting a secret in the repo, storing a digest for later comparison — without actually eliminating or verifying the underlying risk. | Q11, Q14 |
Where Each Question Maps to the Real Exam Blueprint
Difficulty tiers don't map cleanly to domains — this table shows which of GH-200's five real domains each question above actually belongs to, so you can spot a weak domain even though the sections above aren't organized that way.
| # | Topic | Real GH-200 domain |
|---|---|---|
| 1 | workflow_dispatch input types | Author and manage workflows |
| 2 | GITHUB_STEP_SUMMARY | Author and manage workflows |
| 3 | Matrix fail-fast | Author and manage workflows |
| 4 | Service containers | Author and manage workflows |
| 5 | Starter workflow basics | Consume and troubleshoot workflows |
| 6 | Reusable workflows at scale | Author and manage workflows |
| 7 | pull_request vs pull_request_target | Secure and optimize automation |
| 8 | Centralized artifact retention | Manage GitHub Actions for the enterprise |
| 9 | Choosing an action type | Author and maintain actions |
| 10 | Runner image assumptions | Manage GitHub Actions for the enterprise |
| 11 | OIDC federation (AWS) | Secure and optimize automation |
| 12 | Runner groups + IP allow lists | Manage GitHub Actions for the enterprise |
| 13 | Immutable actions + SHA pinning | Secure and optimize automation |
| 14 | Artifact attestations | Secure and optimize automation |
| 15 | Nested reusable workflow limits | Consume and troubleshoot workflows |
How to use this: if you missed more than 2-3 of the Hard tier, spend your next study block entirely on the security and enterprise-governance domains (rows tagged "Secure and optimize automation" and "Manage GitHub Actions for the enterprise" above) before scheduling GH-200 — those two domains alone account for 30-40% of the real exam.
Go Beyond 15 Questions
MSCertQuiz has 500 GH-200 questions across all five domains — reusable workflow scenarios, matrix troubleshooting, OIDC and secret-scoping traps, and enterprise runner governance — in the same reveal-as-you-go format.
MSCertQuiz sells practice-exam access for GH-200 and other GitHub and Microsoft certifications; this page is written by the same team that maintains the question bank.