GitHub Actions Certification (GH-200): What the 2026 Exam Actually Tests
The GitHub Actions certification (GH-200) is not a YAML trivia quiz. Since the January 2026 objectives update it is a practical test of whether you can author, troubleshoot, secure, and govern automation at scale. If you study on: push examples and stop there, you will lose points on reusable workflows, enterprise policies, runner groups, OIDC federation, artifact attestations, matrix behavior, caching, and the safe use of third-party actions.
Two shifts trip up most candidates, and both are recent enough that a lot of the advice still circulating is wrong.
- Delivery moved. GitHub certifications were administered by PSI until June 30, 2025. Exams taken on or after July 1, 2025 run through Pearson VUE, are scheduled with a Microsoft Learn account, and appear in your Microsoft Learn profile instead of Credly. Registration walkthroughs written before that date describe a system that no longer exists.
- The blueprint changed. GH-200 went from four skill areas to five in January 2026, and every objective was reworded. Several guides that still rank for this query print the retired four-domain weights.
This guide is built only from current official sources: the GitHub Actions certification page (last updated August 7, 2026), the GH-200 study guide (article date February 4, 2026), and the GitHub Learn credentials FAQ, which is where GitHub publishes price, format, retake, and renewal rules.
100 free GitHub Actions practice questionsPractice questions with detailed explanations
GH-200 Exam Snapshot
| Item | Verified 2026 detail |
|---|---|
| Certification | GitHub Actions |
| Exam code | GH-200 |
| Level | Intermediate |
| Roles | Administrator, Developer, DevOps Engineer, Solution Architect, Student |
| Exam duration | 100 minutes |
| Format | 60 scored multiple-choice questions plus roughly 10 to 15 unscored pretest items |
| Open or closed book | Closed book; Microsoft Learn access is not available on GitHub exams |
| Passing score | 700 or greater on a 1 to 1,000 scale |
| Price | $99 USD, with regional pricing in some countries |
| Delivery | Proctored by Pearson VUE at a test center or online through OnVUE |
| Languages | English, Spanish, Portuguese (Brazil), Korean, Japanese |
| Prerequisites | None |
| Validity | 2 years |
| Retakes | 24-hour hold before the first retake, 14 days between later retakes, 5 attempts per year |
| Skills measured as of | January 2026 |
A few of these deserve a sentence of explanation, because they are the ones candidates get wrong.
700 is a scaled score, not 70% correct. Microsoft reports technical exam scores on a 1 to 1,000 scale and states plainly that a passing score "may not equal 70% of the points." The cut is set by subject-matter review of question difficulty, so an easier form needs more points and a harder form needs fewer. There is no penalty for guessing, so answer every item.
100 minutes is answering time, not appointment time. Check-in, the candidate agreement, the instruction screens, and the optional post-exam comment period all sit outside the 100 minutes. Book the block on your calendar as if the appointment runs about two hours. This is also where the widely repeated "120-minute GH-200 exam" claim comes from: it is seat time for an exam of this length, not the exam clock.
The item count is published by GitHub, not by Microsoft. The Microsoft exam page does not state a question count. GitHub's credentials FAQ does: 60 scored multiple-choice questions plus approximately 10 to 15 pretest items that vary by exam. You will not be told which items are unscored.
The Retired Blueprint, and Why So Many Guides Are Wrong
If a page tells you GH-200 has four domains weighted 40%, 20%, 25%, and 15%, it is describing the pre-2026 exam. That structure was: Author and maintain workflows (40%), Consume workflows (20%), Author and maintain actions (25%), and Manage GitHub Actions for the enterprise (15%). It is retired.
The current official study guide opens its change log with a blunt note: the exam "has changed significantly (e.g., new objectives were added, some were removed, existing objectives may have moved to different functional groups, and all were reworded) on January, 2026."
Here is the mapping, so you can convert old study notes rather than throwing them away.
| Pre-2026 domain | Current domain | Current weight |
|---|---|---|
| Author and maintain workflows (40%) | Author and manage workflows | 20-25% |
| Consume workflows (20%) | Consume and troubleshoot workflows | 15-20% |
| Author and maintain actions (25%) | Author and maintain actions | 15-20% |
| Manage GitHub Actions for the enterprise (15%) | Manage GitHub Actions for the enterprise | 20-25% |
| (no equivalent) | Secure and optimize automation | 10-15% |
The two structural consequences matter more than the percentages themselves.
First, enterprise management roughly doubled in weight, from 15% to a 20-25% range. It is now tied with workflow authoring as the largest area. Developers who have only ever worked in a single repository are systematically underprepared for this exam.
Second, security became its own scored domain. Secrets, GITHUB_TOKEN scoping, OIDC, SHA pinning, and artifact attestations used to be scattered through other objectives. They now have a dedicated 10-15% band, and the security mindset still shows up inside workflow, action, and enterprise questions on top of that.
The Five Domains, Objective by Objective
The official study guide lists the skill areas below. The bullets under each are the actual published objectives, condensed, with a note on what a question tends to look like.
1. Author and manage workflows (20-25%)
Triggers and events. Scheduled, manual, webhook, and repository events. Choosing the right scope, permissions, and event for a given automation. Defining and validating workflow_dispatch inputs (types, required, defaults) and passing inputs to reusable workflows through workflow_call with input and secret mapping.
Workflow structure. Jobs, steps, conditional logic, and job dependencies. Workflow commands and environment variables. Service containers via services: with ports, health checks, and container options. strategy and matrix to generate job variations, including include, exclude, fail-fast, and max-parallel, plus sizing a matrix for cost. YAML anchors, aliases, and merge keys (&, *, <<) for reuse inside one file. The predefined contexts (github, runner, env, vars, secrets, inputs, matrix, needs, strategy, job, steps, github.event, github.ref). Expression evaluation in double-brace syntax, and the distinction between static evaluation at workflow parse time and runtime evaluation.
Execution and outputs. Caching and artifact management, with retention policies applied through the REST API at organization and repository level. Passing data between jobs and steps using artifacts, outputs, GITHUB_ENV, GITHUB_OUTPUT, and reusable workflow outputs. Job summaries written to GITHUB_STEP_SUMMARY. Status badges and environment protections.
Two objectives here are easy to skip and appear in the current guide: runner image changes (the Ubuntu 20.04 deprecation and the Windows Server 2025 migration behind windows-latest) and immutable actions behavior with version pinning. Both are named explicitly in the official objectives.
Lab to run: build one workflow that has a matrix with include and exclude, a service container with a health check, a cache, a job output consumed by a dependent job, and a Markdown job summary. Then break the matrix and read the run graph.
2. Consume and troubleshoot workflows (15-20%)
Identify what triggered a run from configuration and logs. Diagnose failed runs from logs and run history. Expand and interpret YAML anchors and merged mappings when reading someone else's workflow. Interpret matrix expansions, correlate job names to matrix axes, analyze failures across variants, and rerun individual matrix jobs selectively. Locate workflows, logs, and artifacts in the UI and through the API, and download and manage artifacts.
The template objectives in this domain are where candidates lose easy points. You need to distinguish starter workflows (a scaffold that is copied into a repository and becomes independent), reusable workflows (a central versioned definition invoked through workflow_call), and composite actions (encapsulated step logic). You also need to know how consuming non-public organization workflow templates works, and how disabling a workflow differs from deleting it.
Lab to run: break one workflow three ways on purpose. Invalid YAML, a secret that is not in scope for the triggering event, and a service container that never passes its health check. Fix each one from the logs alone, without looking at your own diff.
3. Author and maintain actions (15-20%)
Identify and implement the three action types: JavaScript, Docker container, and composite. Understand the immutable actions rollout on hosted runners and what it implies for version pinning and registry sources. Troubleshoot action execution and errors. Specify the required files, directory structure, and metadata in action.yml. Implement workflow commands inside actions. Choose a distribution model (public, private, Marketplace), publish to the GitHub Marketplace, and apply versioning and release strategies.
Lab to run: write a small composite action, tag it, publish it privately, then pin it in a workflow by full commit SHA. Compare that behavior with calling the same action by a moving major-version tag, and explain what an immutable actions policy changes.
4. Manage GitHub Actions for the enterprise (20-25%)
Governance. Define and manage reusable components and templates. Control access to actions and workflows within the enterprise. Configure organizational use policies, including allow and deny lists.
Runners at scale. Configure and monitor GitHub-hosted and self-hosted runners. Apply IP allow lists and networking settings. Manage runner groups and troubleshoot runner problems. Identify preinstalled software and tool versions on hosted runners using the image release notes and the toolcache, and install additional software at runtime through setup-* actions, package managers, caching, container images, or a custom self-hosted image.
Secrets and variables. Define and scope encrypted secrets and variables at organization, repository, and environment level. Access them in workflows and actions, and manage them programmatically through the REST API.
This is the domain that separates candidates. If you have never configured a runner group or an organization action policy, you are guessing on roughly a fifth of the exam.
Lab to run: write out how the same deployment workflow would be governed in a personal repository, an organization repository with an action allow list, and an enterprise with runner groups and required reviewers. Name the specific control at each level.
5. Secure and optimize automation (10-15%)
Security. Environment protections and approval gates. Identifying trustworthy Marketplace actions. Mitigating script injection by sanitizing and validating inputs, applying least privilege, keeping untrusted data out of run:, quoting shells properly, and preferring vetted actions over inline scripts. The GITHUB_TOKEN lifecycle (ephemeral and scoped), granular permissions, and how it contrasts with a personal access token. OIDC with the id-token permission for cloud federation, so long-lived cloud secrets can be removed entirely. Pinning third-party actions to full commit SHAs rather than floating @main or @v*. Enforcing action usage policies with allow and deny lists and required reviewers for unverified actions. Generating and verifying artifact attestations and provenance, and wiring that into deployment verification.
Optimization. Caching and artifact retention for efficiency, retention policies applied through the REST API, and strategies for scaling workflows.
Lab to run: take a workflow that authenticates to a cloud provider with a long-lived secret and redesign it with OIDC, an explicit least-privilege permissions block, SHA-pinned third-party actions, and an environment approval gate. Then generate an artifact attestation and verify it.
How to Register for GH-200
- Create or sign in to a Microsoft Learn profile. GitHub certification scheduling now runs through Microsoft Learn, not through the old GitHub registration portal.
examregistration.github.comredirects to GitHub Learn. - Use a personal Microsoft account, not a work or school account. Microsoft warns on the certification page that exam records tied to an organizational account are lost and unrecoverable if you leave that organization. This is the single most expensive registration mistake you can make.
- Schedule through Pearson VUE from the certification page. Choose a test center or OnVUE online proctoring. Online delivery requires the secure browser and a stable connection, so run the Pearson VUE system test in advance.
- Pay $99 USD, subject to regional pricing. GitHub publishes this figure in its credentials FAQ; the Microsoft page only says price varies by the country or region where the exam is proctored.
- Request accommodations before you book if you need them. Pearson VUE reviews most accommodation requests within 20 business days. If GH-200 is not offered in your native language, you can submit the English as a Second Language request form for extra time; the study guide notes an additional 30 minutes is available in that case.
- Rescheduling and cancellation are handled from Upcoming Appointments in your exam program homepage, and you must confirm on the final screen for the change to save.
One thing not to count on: the free GitHub Student Developer Pack certification voucher, earned through the DataCamp learning path, can only be applied to GitHub Foundations (GH-900) or GitHub Copilot (GH-300). It does not cover GH-200.
Free Official Preparation Worth Using
- The GH-200 practice assessment on Microsoft Learn. Free, and linked from the certification page. It exists to show you the style, wording, and difficulty of real items. Note the inconsistency here: GitHub's own credentials FAQ still says practice assessments are "coming soon," while a GH-200 practice assessment is already live on the Microsoft Learn certification page. Use the Microsoft Learn one.
- The GitHub exam sandbox at aka.ms/GHExamDemo-enu. This is the GitHub-specific demo, not the generic Microsoft sandbox. It walks you through the same interface, instruction screens, and candidate agreement you will see on exam day. Twenty minutes here removes most of the first-ten-minutes friction.
- The Microsoft Learn path "Automate your workflow with GitHub Actions." The official study guide names it as the recommended training, along with the "Manage GitHub Actions for the enterprise" module for the domain most candidates are weakest in.
- The GitHub Actions documentation, especially the workflow syntax reference and the "creating actions" and "releasing and maintaining actions" sections, which the study guide links objective by objective.
- Our GitHub Actions study guide for a domain-by-domain walkthrough with YAML examples, and 100 free practice questions for timed drilling.
What none of these give you is a real repository with an organization policy, a runner group, and an environment gate. Build that yourself. A free organization on github.com is enough for most of the governance objectives.
What GH-200 Questions Actually Look Like
Items are multiple choice and multiple select, and the exam may include interactive components. They are overwhelmingly scenario-shaped: a snippet plus a constraint, where more than one option is technically valid and only one satisfies the constraint. Two representative shapes:
Shape 1: the snippet with a scope trap. You are shown a workflow triggered by pull_request_target that references a repository secret and checks out the head ref of the pull request. The question asks what to change. Three options are real GitHub Actions features. The correct one addresses the fact that this pattern runs untrusted code with access to secrets. The tell is the trigger, not the syntax.
Shape 2: the governance constraint. An organization needs every team to use one hardened deployment workflow, centrally updated, with no copy drift. The distractors offer a starter workflow, a composite action, and a required status check. The answer is a reusable workflow called through workflow_call, because "centrally updated with no drift" is the constraint that only reusable workflows satisfy. A starter workflow is a copy and diverges the moment it is created.
Train the habit of reading the constraint before the code. In practice that means, for every item: identify the desired end state, underline the constraint (least privilege, no drift, no downtime, auditability, cost), then eliminate options that solve the wrong layer. Many wrong answers are perfectly real features aimed at the wrong problem.
A 4-Week GH-200 Study Plan
Week 1: workflow authoring. Read the current study guide end to end and build five workflows from scratch: push and pull request, scheduled, workflow_dispatch with typed inputs, a matrix, and one that calls a reusable workflow. Explain every context and expression you use out loud. Finish the week by writing a job summary to GITHUB_STEP_SUMMARY.
Week 2: actions, reuse, and troubleshooting. Build one composite action and one reusable workflow with mapped inputs and secrets. Then troubleshoot deliberately broken runs from logs, artifacts, and selective matrix reruns. Drill the starter workflow versus reusable workflow versus composite action distinction until it is instant, because it is worth points in two domains.
Week 3: enterprise and runners. Organization policies, action allow and deny lists, runner groups, self-hosted runners, hosted runner images and the toolcache, IP allow lists, and secrets and variables at all three scopes. Manage a secret and a variable through the REST API so the API objectives are muscle memory rather than trivia. This is 20-25% of the exam and the weakest area for most developers.
Week 4: security, optimization, and timed sets. OIDC, permissions blocks, script injection, SHA pinning, immutable actions, artifact attestations, caching, and retention. Take the Microsoft Learn practice assessment, then timed question sets. Tag every miss by failure type: concept, service boundary, syntax, sequence, or speed. Concept misses need documentation. Boundary misses need a comparison table. Syntax misses need a hands-on drill. Speed misses need smaller timed sets, not more reading.
If you already run GitHub Actions daily at organization scale, two weeks of focused work on the enterprise and security domains is usually enough.
Exam Day: Rules, Timing, and Tactics
It is closed book. Microsoft's exam experience page is explicit that Learn access is not available on Fundamentals exams or GitHub exams. Whatever you can look up at work, you cannot look up here.
Breaks run on the exam clock. Five minutes of break time is built into the exam duration, but the clock keeps running while you are away, and you cannot return to any question you have already seen before the break, even one you left unanswered or marked for review. Answer and review before you start a break, or skip breaks entirely on a 100-minute exam.
Budget by item, not by feel. Roughly 70 to 75 items in 100 minutes is about 80 seconds each. Flag anything that takes more than two minutes and move on.
Read snippets in a fixed order: trigger, then permissions, then secret and variable scope, then the if condition, then the step itself. Most trap items are decided before you reach the step.
Use elimination. Wrong answers on this exam cluster into recognizable shapes. They overgrant permissions, expose secrets to untrusted events, reach for a personal access token where GITHUB_TOKEN or OIDC is safer, swap composite actions for reusable workflows, or treat a copied starter workflow as if it were centrally managed.
Log in 15 minutes early for an OnVUE appointment so check-in does not eat into your start.
After the Exam: Score, Certificate, and Renewal
Results arrive within minutes for exams without labs, and land in your Learn profile within 24 hours. The score report gives you a numeric score, pass or fail, and a bar chart of performance by skill area. The bars cannot be converted into a number of questions answered correctly, and Microsoft does not disclose which specific items you missed.
If you fail, there is a 24-hour hold before the first retake and a 14-day hold before each subsequent one, with a maximum of five attempts in a 12-month period. Study the weak bars, not the whole blueprint again.
Passing earns a downloadable Microsoft Learn certificate. Credly badges were discontinued for new GitHub certifications on July 1, 2025; badges earned before that date remain valid in Credly, and certifications earned through PSI before that date stay visible in your GitHub Learn profile.
GitHub certifications are valid for two years. GitHub is moving to Microsoft's recertification process so credentials can be maintained without retaking the full exam, and it has said that any GitHub certification expiring before that process is available will be extended by six months on request to the certification team. If yours has already lapsed, GitHub's FAQ says it will issue a voucher to retest at no cost. GH-900 GitHub Foundations is the one exception in the program: as a fundamentals credential it does not expire.
Official Sources
- GitHub Actions certification page (Microsoft Learn): https://learn.microsoft.com/en-us/credentials/certifications/github-actions/
- Study guide for Exam GH-200: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/gh-200
- GitHub Learn credentials and FAQ (price, format, retakes, renewal): https://learn.github.com/credentials
- Exam scoring and score reports: https://learn.microsoft.com/en-us/credentials/certifications/exam-scoring-reports
- Exam duration and exam experience: https://learn.microsoft.com/en-us/credentials/support/exam-duration-exam-experience
- GitHub Actions documentation: https://docs.github.com/en/actions
