Updated GitHub Actions GH-200 Free Practice Questions | 2026

GH-200 Practice Test

Preparing for the Microsoft GH-200 exam is easier when you combine hands-on GitHub Actions experience with realistic questions that show where your knowledge is strong and where it needs work. A well-designed GH-200 practice test should cover workflow creation, troubleshooting, custom actions, enterprise management, security, and performance—not just definitions. You can View all available practice exams to organize your certification study and then use this guide to build a clear, student-friendly plan for the GitHub Actions exam.

Quick Answer: What Is the Microsoft GH-200 Exam?

GH-200 is the exam for the GitHub Actions certification. It measures whether you can create, use, troubleshoot, secure, and manage GitHub Actions automation. The current exam is aimed at people with intermediate GitHub Actions experience, including students, developers, DevOps engineers, IT professionals, administrators, and solution architects.

According to the current Microsoft Learn GitHub Actions certification page, candidates receive 100 minutes for the proctored exam. It is scheduled through Pearson VUE and is available in English, Spanish, Portuguese (Brazil), Korean, and Japanese. The price depends on the country or region where the exam is proctored.

The official GH-200 study guide says a score of 700 or higher is required to pass. It also shows that the exam blueprint changed significantly in January 2026. Students should therefore use current practice questions that match the five-domain blueprint rather than older materials based on the previous four-domain outline.

What Does a GH-200 Practice Test Help You Learn?

A GH-200 practice test is a study and readiness tool. It should help you do four things:

1. Recall important concepts. You should recognize workflows, events, jobs, steps, actions, runners, contexts, variables, secrets, artifacts, caches, environments, and reusable automation.
2. Apply the right feature to a scenario. The exam may describe a goal or problem and ask for the most secure, maintainable, or efficient solution.
3. Read workflow configuration. You should be comfortable interpreting YAML, conditions, dependencies, matrix jobs, permissions, inputs, outputs, and references to reusable components.
4. Find weak areas. A score is useful only when it directs your next study session.

Good practice questions do not simply ask, “What is a runner?” They may show a situation in which a workflow needs a particular operating system, access to an internal network, or a controlled runner group. Your task is to choose the runner approach that meets the stated requirements.

Practice tests are most effective when paired with a small GitHub repository where you can try each topic. Reading may help you recognize an answer, but building and repairing workflows teaches you why the answer works.

Who Should Take the GH-200 Exam?

GH-200 is a good fit if you already understand basic Git and GitHub concepts and want to prove that you can automate software work with GitHub Actions. The official certification page describes the target candidate as someone with intermediate experience in workflow creation, automation, and CI/CD pipeline management.

The exam is especially relevant for:

• Students learning DevOps or software delivery
• Software developers who maintain build and test pipelines
• DevOps and platform engineers who standardize automation
• IT professionals who manage runners, secrets, and access
• Administrators who apply organization or enterprise policies
• Solution architects who design secure automation patterns

You do not need to be an expert in every programming language. However, you should be able to read YAML, understand common shell commands, follow logs, and reason about permissions and data flow. You should also know the purpose of continuous integration and continuous delivery.

If you are planning more than one credential, Browse all Microsoft exams and compare the expected skills before deciding which certification matches your current role.

Prerequisite Knowledge for GH-200

The certification does not list a required prerequisite exam. That does not mean a complete beginner should schedule GH-200 immediately. Before taking full practice tests, make sure you can:

• Create and clone a GitHub repository
• Work with branches, commits, pull requests, and releases
• Explain the difference between continuous integration and continuous delivery
• Read a basic YAML file
• Navigate the Actions tab and open workflow logs
• Explain why credentials must be protected
• Identify a build, test, package, and deployment stage
• Understand that third-party actions execute code in the workflow context

If several of these ideas are new, spend a few days on GitHub fundamentals before studying the exam blueprint. This prevents you from memorizing isolated terms without understanding the workflow around them.

Current Microsoft GH-200 Exam Domains and Weights

The official study guide lists five skill areas for the blueprint effective January 2026:

The percentages are ranges, so students should not try to predict an exact number of questions from each domain. Use them to set study priorities. “Author and manage workflows” and “Manage GitHub Actions for the enterprise” carry the highest stated ranges, but all five domains can affect the result.

Domain 1: Author and Manage Workflows (20–25%)

A workflow is an automated process stored as a YAML file in the .github/workflows directory of a repository. GitHub can start it after a repository event, on a schedule, manually, or through another supported trigger. Each workflow contains one or more jobs, and each job contains steps.

The GitHub Actions overview is a useful foundation: an event triggers a workflow; jobs run on runners; and steps run scripts or reusable actions.

Workflow triggers and events

Know how to choose a trigger that matches the requirement:

• push for selected branch or tag updates
• pull_request for pull request activity
• workflow_dispatch for a manual run
• schedule for time-based automation
• repository_dispatch for a custom external event
• workflow_call when another workflow calls a reusable workflow

For manual workflows, study how to define inputs, mark them as required, assign defaults, and select input types. Also understand how a calling workflow passes inputs and secrets to a reusable workflow.

Jobs, steps, dependencies, and conditions

Jobs run in parallel unless you create a dependency. The needs keyword makes one job wait for another. Conditions allow a workflow, job, or step to run only when an expression is true.

Practice reading scenarios such as:

• Run deployment only after tests succeed.
• Run cleanup even if an earlier step fails.
• Skip a job unless the branch is main.
• Use an output from a build job in a later job.

Do not confuse a job with a step. A job runs on a runner and contains ordered steps. Separate jobs normally use separate runner environments, so data does not automatically appear in the next job.

Matrix strategies

A matrix runs variations of the same job. For example, a test workflow can cover several operating systems and language versions. Learn how include and exclude modify combinations, how fail-fast changes failure behavior, and how max-parallel limits simultaneous jobs.

The current blueprint also expects students to think about cost and performance. A 20-combination matrix may provide wide coverage, but it can waste time if many combinations are unnecessary. Practice questions may ask you to keep required coverage while reducing duplicate runs.

Contexts, expressions, and environment files

Contexts provide workflow information. Common examples include:

• github for event and repository information
• runner for the runner environment
• env for environment variables
• vars for configuration variables
• secrets for protected values
• matrix for the current matrix combination
• needs for data from dependent jobs
• steps for step outcomes and outputs
• inputs for reusable or manually triggered workflow inputs

Expressions use the ${{ … }} syntax. Understand when a value is available and whether it is evaluated while GitHub processes the workflow or while a job is running. This matters in both troubleshooting and security questions.

The current guide also names GITHUB_ENV, GITHUB_OUTPUT, and GITHUB_STEP_SUMMARY. In simple terms:

• Write to GITHUB_ENV to make an environment variable available to later steps in the same job.
• Write to GITHUB_OUTPUT to define a step output.
• Write Markdown to GITHUB_STEP_SUMMARY to create a readable summary for the job.

Service containers, artifacts, and caching

Service containers give a job access to a dependent service such as a database or message queue. Study ports, health checks, and container options.

Artifacts and caches solve different problems. GitHub’s dependency caching guidance gives a clear distinction:

• Use a cache for dependencies or files that can be regenerated but are expensive to download or rebuild.
• Use an artifact for files created by a job that people or later jobs need, such as a test report or compiled package.

Never put credentials in a cache. A workflow should also be able to continue after a cache miss.

YAML anchors and editor tooling

The January 2026 outline includes YAML anchors, aliases, and merge keys for reusing repeated mappings inside one workflow file. You do not need to turn every workflow into an advanced YAML exercise, but you should recognize what &, *, and << are doing when they appear.

Microsoft also lists editor tooling, including the GitHub Actions extension for Visual Studio Code, YAML schema completion, IntelliSense, and validation. Use validation while practicing so you learn to separate syntax errors from runtime problems.

Domain 2: Consume and Troubleshoot Workflows (15–20%)

This domain focuses on understanding automation written by someone else and finding why it did not behave as expected.

Read the run before changing the file

Use the workflow run history and logs to answer:

• Did the expected event trigger a run?
• Which job failed?
• Was a job skipped because of a condition or dependency?
• Which matrix combination failed?
• Did an action receive the expected input?
• Was the required secret or variable available at that scope?
• Did a file path or runner operating system cause the error?

Build a repeatable troubleshooting order:

1. Confirm the event and branch or tag filters.
2. Check the workflow file and YAML validation.
3. Review job dependencies and conditions.
4. Open the first meaningful failure in the logs.
5. Check inputs, contexts, permissions, and file paths.
6. Compare successful and failed matrix combinations.
7. Make one targeted change and run again.

This is more reliable than changing several lines at once.

Workflow templates, reusable workflows, and composite actions

These features sound similar but are not interchangeable:

The current GitHub guidance on reusing workflow configurations explains that a starter workflow becomes independent after it is copied, while a reusable workflow remains a called, versioned definition.

Also know the operational difference between disabling and deleting a workflow. Disabling stops new runs but keeps the workflow file and history available. Deleting the file removes its definition from the branch.

Domain 3: Author and Maintain Actions (15–20%)

An action is reusable automation that a workflow can run as a step. You can use an action from the GitHub Marketplace, reference an action from another repository, or create your own.

The three custom action types

For each type, learn the required files and metadata. Custom actions commonly use an action.yml or action.yaml metadata file to define a name, description, inputs, outputs, and how the action runs.

Troubleshooting and maintenance

Practice identifying problems such as:

• An input name in the workflow does not match the metadata.
• The action expects a file that was not included in the release.
• A Docker action is selected for a runner environment it cannot support.
• A JavaScript action was not packaged with the required dependencies.
• An output is defined incorrectly.
• The workflow references a branch or tag that moved.

Versioning matters because other repositories depend on the reference you publish. Understand the trade-off between a full commit SHA, a version tag, a branch, and a release. For third-party actions, security guidance strongly favors a full commit SHA because it identifies an exact revision.

Distribution

The exam can cover public, private, and Marketplace distribution. Think about who needs the action, where the source should live, and which policies allow the organization to use it. Publishing to the Marketplace requires more than writing working code; the action also needs suitable metadata, documentation, branding, and a release approach.

Domain 4: Manage GitHub Actions for the Enterprise (20–25%)

This is one of the two largest blueprint areas. It expands the focus from one repository to many repositories, organizations, teams, and controlled execution environments.

Governance and reusable automation

At scale, organizations need consistent workflows without copying and manually updating the same logic everywhere. Reusable workflows, custom actions, workflow templates, and access policies help create that consistency.

Practice scenarios that ask you to:

• Provide an approved deployment workflow to many repositories.
• Restrict which external actions teams may use.
• Share a private action within an organization.
• Maintain one central workflow while allowing controlled inputs.
• Determine why a repository cannot access a reusable workflow.

The best answer usually balances maintainability, access, and security. A solution that works in one repository may be difficult to govern across hundreds of repositories.

GitHub-hosted and self-hosted runners

GitHub-hosted runners are managed runner environments that start clean for jobs. Self-hosted runners are systems that your organization manages.

Study runner groups, labels, access, monitoring, networking, and troubleshooting. Also know that GitHub-hosted runner images change. The current blueprint specifically expects candidates to find preinstalled tool versions in image release notes or the tool cache and to install additional software through setup actions, package managers, containers, or custom images.

Self-hosted does not automatically mean better or cheaper. Your organization becomes responsible for patching, isolation, availability, scaling, access, and cleanup.

Secrets and variables at the right scope

Secrets protect sensitive values. Variables store non-sensitive configuration. Both can be defined at different scopes, including organization, repository, and environment.

Choose the narrowest practical scope:

• A value used by one repository normally belongs at repository scope.
• A shared value for approved repositories may belong at organization scope with access controls.
• A production credential usually belongs to a protected environment, where approval rules can restrict access.

Practice using the secrets and vars contexts and deciding when an environment should add branch rules or reviewers. The blueprint also includes managing secrets and variables programmatically through REST APIs.

Domain 5: Secure and Optimize Automation (10–15%)

This is the smallest percentage range, but it contains high-value concepts that also appear in workflow, action, and enterprise scenarios.

Least privilege and GITHUB_TOKEN

GITHUB_TOKEN is created for a workflow run and is scoped to the repository. Configure only the permissions the workflow needs. If a test job only needs to read repository contents, broad write permissions create unnecessary risk.

Know the difference between:

• GITHUB_TOKEN: an automatically created, short-lived token for the workflow
• Personal access token (PAT): a credential associated with a user or account and manually scoped
• OIDC token: a token used to establish identity with an external provider and obtain short-lived access

Do not choose a PAT merely because it feels familiar. Start with GITHUB_TOKEN when its scope and permissions meet the requirement. Use another credential only when the scenario requires capabilities it cannot provide.

OpenID Connect

OpenID Connect, or OIDC, lets a workflow obtain short-lived cloud access without storing a long-lived cloud credential as a GitHub secret. GitHub’s OIDC configuration guide explains that a workflow needs id-token: write to request the OIDC token. That permission does not itself grant write access to cloud resources; the external provider evaluates the token and its trust rules.

For exam scenarios, look for requirements such as:

• Remove long-lived cloud secrets.
• Limit deployment identity to one repository, branch, tag, or environment.
• Use short-lived credentials for a job.

OIDC is often the best answer when the cloud provider supports it and trust is configured correctly.

Script injection and untrusted input

Repository data can be attacker-controlled. A pull request title, issue body, branch name, or commit message should not be inserted carelessly into a shell command.

The GitHub secure use reference recommends least privilege and careful treatment of secrets and untrusted input. Safe patterns include validating input, using an intermediate environment variable, quoting values correctly, and preferring a well-reviewed action over risky inline scripting.

Third-party actions and supply-chain safety

A workflow that uses a third-party action is executing someone else’s code. Review the source, publisher, maintenance, release history, and permissions. Pin important third-party actions to a full commit SHA. Apply organization or repository policies that allow approved actions and block untrusted choices.

The current blueprint also includes artifact attestations and provenance. At a student-friendly level, remember that provenance provides verifiable information about where and how a build artifact was produced. It supports stronger software supply-chain decisions.

Performance and cost

Optimization is not simply “make everything parallel.” The right answer may involve:

• Caching dependencies with a reliable key
• Reducing an oversized matrix
• Canceling older runs for the same branch with concurrency controls
• Reusing a built artifact instead of rebuilding it
• Selecting the right runner size
• Limiting artifact retention
• Avoiding duplicate triggers
• Keeping logs and outputs useful for troubleshooting

Always preserve correctness and security while reducing time or cost.

High-Value GH-200 Comparisons to Memorize

How to Use a Microsoft GH-200 Practice Test

Step 1: Take a short diagnostic

Begin with 20 to 30 mixed questions. Do not look up answers during this first attempt. The aim is to measure your current knowledge, not produce an impressive score.

Step 2: Label every mistake

Use four categories:

• Knowledge gap: You did not know the feature.
• Reading error: You missed a requirement such as “least privilege” or “centrally maintained.”
• Syntax gap: You understood the idea but could not read the YAML.
• Experience gap: The concept made sense only after you tried it.

This classification makes review faster. A knowledge gap may need documentation; a syntax gap needs workflow reading; an experience gap needs a lab.

Step 3: Verify with official documentation

Read the official page connected to the missed objective. Do not memorize an explanation from a questionable answer dump. GitHub Actions changes, and old questions may use obsolete behavior or an outdated blueprint.

Step 4: Reproduce the concept

Create a tiny workflow that proves the answer. If the question involves outputs, pass a value between steps and then between jobs. If it involves OIDC, map the trust flow even if you do not have a cloud lab. If it involves a matrix, inspect the expanded jobs.

Step 5: Retake by domain

Use a focused set for the weakest domain. Require yourself to explain why the correct option works and why each alternative fails.

Step 6: Finish with timed mixed tests

When your domain scores are steady, take complete mixed practice sessions. Use the same pace you plan for the real 100-minute exam. Start Practicing Today with a diagnostic, then review every explanation before taking another full set.

A Six-Week GH-200 Study Plan

Week 1: Core workflow structure

• Learn events, workflows, jobs, steps, actions, and runners.
• Create workflows for push, pull_request, and workflow_dispatch.
• Practice branch and path filters.
• Use conditions and needs.
• Take a short Domain 1 quiz.

Week 2: Data flow and workflow features

• Practice contexts and expressions.
• Pass values through GITHUB_ENV and GITHUB_OUTPUT.
• Pass outputs between jobs.
• Upload and download an artifact.
• Add a dependency cache.
• Create a matrix with include and exclude.
• Add a job summary.

Week 3: Reuse and troubleshooting

• Read successful and failed logs.
• Build a reusable workflow with typed inputs.
• Create a simple composite action.
• Compare starter workflows, reusable workflows, composite actions, and YAML anchors.
• Practice rerunning one failed matrix job.
• Take a Domain 2 practice set.

Week 4: Custom actions and enterprise management

• Inspect action.yml from maintained public actions.
• Create a basic composite or JavaScript action.
• Learn action inputs, outputs, versioning, and releases.
• Compare GitHub-hosted and self-hosted runners.
• Review runner groups, labels, networking, and organization policies.
• Practice selecting secret and variable scopes.

Week 5: Security and optimization

• Reduce GITHUB_TOKEN permissions.
• Identify unsafe use of untrusted input.
• Pin a third-party action to a full SHA.
• Explain the OIDC trust flow.
• Apply an environment approval rule in a practice repository if available.
• Optimize a cache key and an oversized matrix.
• Review artifact retention and attestations.

Week 6: Mixed practice and final review

• Take two or three timed mixed practice tests on separate days.
• Review every incorrect and guessed answer.
• Rebuild the weakest workflow examples.
• Revisit the current official study guide.
• Use the official exam sandbox to learn the interface.
• Stop heavy study the night before the exam and prepare the testing space.

If you have only two weeks, combine Weeks 1–3 into the first week and Weeks 4–6 into the second. Keep at least half of your study time for hands-on practice and review.

Hands-On Labs That Improve GH-200 Readiness

Create one safe practice repository and complete these tasks:

1. Trigger a workflow on a pull request and manually.
2. Add branch and path filters.
3. Create build, test, and deploy jobs with dependencies.
4. Add a matrix for two operating systems and two runtime versions.
5. Pass a step output to another step.
6. Pass a job output to a dependent job.
7. Upload a test report as an artifact.
8. Cache package dependencies.
9. Add a service container for a test database.
10. Create and call a reusable workflow.
11. Create a composite action.
12. Limit GITHUB_TOKEN permissions.
13. Add an environment and approval protection.
14. Deliberately introduce a trigger, path, and expression error, then repair each from the logs.
15. Pin a third-party action to a full commit SHA.
16. Add a Markdown job summary.

Keep a short lab notebook with the problem, the fix, and the reason. Those explanations become valuable revision material.

How to Know When You Are Ready

Do not use one high practice score as the only signal. You are closer to exam readiness when you can:

• Score consistently across several mixed practice sets
• Stay within your planned time
• Explain each correct choice without memorized wording
• Explain why the wrong options do not meet the requirement
• Read an unfamiliar workflow without panic
• Find a failure in logs using a repeatable process
• Choose between a cache and an artifact
• Choose between a reusable workflow and a composite action
• Select a safe credential pattern
• Describe the responsibilities of self-hosted runner management
• Complete the hands-on labs without copying every step

A useful personal target is consistent performance comfortably above your minimum goal, especially in the two 20–25% domains. This is a study target, not an official prediction of the scaled exam score.

GH-200 Exam-Day Tips

Read the final requirement first

Scenario questions often include extra information. Identify whether the question asks for the most secure option, the least administrative effort, the centrally managed solution, or the fastest troubleshooting step.

Watch for scope words

“One repository,” “selected repositories,” “organization,” “enterprise,” and “production environment” point to different configuration scopes.

Prefer the option that meets every requirement

An answer may technically work but violate least privilege, require unnecessary maintenance, or fail to scale. Select the option that satisfies all stated conditions.

Manage the 100 minutes

Move past a difficult question and return if the interface permits. Do not spend excessive time trying to remember one small syntax detail. Keep enough time for review.

Do not plan to search Microsoft Learn

Microsoft’s exam-experience page specifically says Microsoft Learn access is not available during GitHub exams. Prepare to answer from your knowledge and reasoning.

Use the official sandbox before exam day

The certification page links to an exam sandbox that demonstrates the interface. Familiarity with navigation and review controls prevents avoidable stress.

Common GH-200 Preparation Mistakes

Studying the old blueprint

Materials that list only four domains or use older percentages may not reflect the significant January 2026 update. Compare every course and practice test with the current five-domain guide.

Memorizing YAML without running it

Workflow questions become easier after you see events, contexts, outputs, and matrices in actual runs.

Ignoring enterprise topics

Enterprise management carries 20–25%, the same highest range as workflow authoring. Do not focus only on writing repository-level workflows.

Treating every reusable feature as the same

Starter workflows, reusable workflows, composite actions, custom actions, and YAML anchors solve different reuse problems.

Choosing convenience over security

Broad permissions, long-lived credentials, floating third-party references, and unvalidated input may look quick, but secure alternatives are often the better exam answer.

Using answer dumps

Unauthorized exam content can be inaccurate, obsolete, and harmful to the value of the credential. Use original practice questions, official documentation, and hands-on labs.

Microsoft GH-200 Frequently Asked Questions

What certification do I earn by passing GH-200?

Passing GH-200 earns the GitHub Actions certification. GitHub says successful candidates receive a badge and certificate that can be used to verify the credential.

Is GH-200 a Microsoft exam or a GitHub exam?

GH-200 is the exam code for the GitHub Actions certification. Its exam and study-guide information is published on Microsoft Learn, and the current certification page schedules the exam through Pearson VUE.

Is GH-200 suitable for beginners?

It is labeled intermediate. A beginner can work toward it, but should first learn GitHub repositories, pull requests, basic Git, YAML, CI/CD, workflow navigation, and security basics.

Are there any required prerequisite exams?

The official certification page does not list a prerequisite certification exam. Practical GitHub Actions experience is still strongly recommended.

How long is the GH-200 exam?

The current Microsoft Learn certification page gives candidates 100 minutes to complete the assessment.

How many questions are on GH-200?

Microsoft does not publish a guaranteed fixed count for this exam. Its general guidance says exam question counts can change, so avoid relying on a third-party number.

Is GH-200 open book?

No. Microsoft states that Microsoft Learn access during an exam is not available for GitHub exams. Prepare to answer without browsing documentation.

How much does the GH-200 exam cost?

The official page says pricing depends on the country or region where the exam is proctored. Use the scheduling page for the current local price, taxes, and available offers.

Which languages are available?

The current exam page lists English, Spanish, Portuguese (Brazil), Korean, and Japanese.

Does the GH-200 blueprint still have four domains?

No. The skills measured as of January 2026 are organized into five domains. Microsoft says the exam changed significantly at that time.

What is the difference between an artifact and a cache?

Use an artifact for output you need to keep, inspect, or pass between jobs. Use a cache to speed later work with files that can be downloaded or regenerated.

What is the difference between a reusable workflow and a composite action?

A reusable workflow is called by another workflow and can organize one or more jobs. A composite action packages multiple steps and is used as a step inside a job.

Why is OIDC important for GH-200?

OIDC supports short-lived access to compatible cloud providers without storing long-lived cloud credentials in GitHub. It is an important secure-deployment pattern in the current blueprint.

Are self-hosted runners always better?

No. They provide control and private-network options, but the organization must manage security, patching, scaling, isolation, and availability. Choose them only when requirements justify those responsibilities.

How many practice tests should I take?

There is no official number. One diagnostic, several domain-focused sets, and two or three timed mixed tests are more useful than repeatedly taking the same questions.

What practice score means I am ready?

No practice-test percentage guarantees a pass because providers differ and the real exam uses scaled scoring. Look for consistent results, strong explanations, good timing, and successful hands-on work.

Can practice questions replace hands-on experience?

No. Practice questions diagnose and reinforce knowledge; labs build the operational judgment needed for workflow and troubleshooting scenarios.

What should I do if I fail GH-200?

Use the score report to identify weak skill areas and rebuild those topics in a practice repository. Under the current Microsoft exam retake policy, a candidate who fails the first attempt must wait 24 hours before retaking. A 14-day wait applies between later attempts, with additional limits stated in the policy. Check the current policy before booking again.