SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
GH-200 practice

Free GH-200 practice questions

Drill exam-realistic GitHub Actions questions by domain, with an explanation on every option — not just the right one. 5 fully worked examples are further down this page, answers included.

Question bank
379
across 5 domains
Free, no account
5/day
a free account allows 30 a day
Real exam
60 Qs
100 min · pass 700 / 1000
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across all domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

5 sample GH-200 questions, fully explained

Real questions from the GH-200 bank, with the answer key and the reasoning behind every option. Read them, then go back up the page and try the rest.

Question 1Author and manage workflows

A developer adds a nightly integration-test workflow with a valid cron expression to the branch feature/nightly and pushes it. A push-triggered workflow on the same branch runs normally, but after two days the nightly workflow has never started. The repository's default branch is main. What explains the missing runs?

Choose one.

  • a
    Scheduled runs use only the workflow files that exist on the default branch Correct

    Correct. GitHub evaluates schedule triggers only from workflow files on the default branch, so a cron defined only on feature/nightly is never picked up until it is merged to main.

  • b
    Scheduled runs start only after the workflow has been started once by hand

    There is no such prerequisite for schedules. A manual first run is never required; the cron starts working as soon as the file is on the default branch.

  • c
    Scheduled runs wait until a repository administrator approves the new cron entry

    Cron entries need no approval. Approval gates exist for environments and for some fork pull request runs, not for schedules.

  • d
    Scheduled runs need an open pull request from the branch into main

    An open pull request does not make a schedule fire. Only the copy of the workflow on the default branch is scheduled.

The concept

Scheduled workflows run only from the default branch.

Why that’s the answer

The schedule event reads the workflow file on the repository's default branch. A cron that exists only on a feature branch is ignored, even though push and pull_request triggers on that branch work normally. Merging the workflow to main makes the schedule active. Manual first runs, approvals and open pull requests have no effect on schedules.

How to reason it out
  1. Note which trigger works (push) and which does not (schedule).
  2. Recall where GitHub reads schedule triggers from: the default branch only.
  3. Check the branch the file was pushed to: a feature branch.
  4. Conclude the schedule is never registered until the file reaches main.

Exam tip: A cron trigger counts only when the workflow file is on the default branch.

GitHub Actions Triggers, Events, Caching, Artifacts and Outputs (GH-200) — the lesson that teaches this.

Question 2Consume and troubleshoot workflows

A repository has a workflow with this trigger:on: push: branches: [main] paths: ['src/**']Over one afternoon, four pushes happen. Which push starts a run of this workflow?

Choose one.

  • a
    A push to main whose commit changes src/app.js and docs/guide.md Correct

    The branch filter matches main and at least one changed file matches src/**, so both filters are satisfied.

  • b
    A push to main whose commit changes docs/guide.md and README.md

    The branch matches, but no changed file matches src/**, so the paths filter is not satisfied.

  • c
    A push of tag v2.0.0 that points at a commit changing src/app.js

    The trigger defines branches but no tags filter, so the workflow does not run for events affecting tags.

  • d
    A push to release/2.0 whose commit changes src/app.js and src/db.js

    The paths match, but release/2.0 is not in the branches list, and both filters must be satisfied.

The concept

When a push trigger defines both a branch filter and a paths filter, a push must satisfy both; a trigger that defines only branches does not run for tag pushes.

Why that’s the answer

GitHub runs the workflow only when both the branches and the paths filters are satisfied. A paths filter is satisfied when at least one changed file matches a pattern, so a commit touching src/app.js and docs/guide.md qualifies. The docs-only push fails the paths filter, the release/2.0 push fails the branch filter, and the tag push is excluded because the trigger defines branches but no tags filter, so events affecting tags are ignored.

How to reason it out
  1. Check the ref: only main passes the branch filter, and a tag is a different kind of ref.
  2. Check the files: at least one changed file must match src/**.
  3. Require both checks to pass for the same push.
  4. Pick the push that passes both.

Exam tip: branches + paths means both must match; a branches-only trigger ignores tag pushes.

Troubleshoot GitHub Actions Workflow Runs: Logs, Matrix Re-runs and Artifacts (GH-200) — the lesson that teaches this.

Question 3Author and maintain actions

A team is writing an action in TypeScript that calls the GitHub REST API through the Actions toolkit. Workflows will run it on Ubuntu, Windows and macOS runners. The action must start quickly and must not install anything when it runs. Which kind of action should the team build?

Choose one.

  • a
    A JavaScript action that runs the compiled, bundled code with Node.js Correct

    JavaScript actions run directly on the runner's Node.js on all three operating systems and start without building or pulling anything.

  • b
    A Docker container action built from a Dockerfile in the action's repository

    Docker container actions run only on Linux runners, and building the image adds start-up time.

  • c
    A Docker container action that pulls a prebuilt image from a public registry

    A prebuilt image saves the build, but container actions still run only on Linux runners.

  • d
    A composite action that runs setup-node, npm ci and the TypeScript compiler

    This works on all three systems, but it installs packages and compiles on every run, which the team ruled out.

The concept

GitHub supports three kinds of custom action: JavaScript, Docker container and composite.

Why that’s the answer

JavaScript actions execute directly on the runner, so they run on Linux, Windows and macOS and are the fastest to start. Docker container actions are limited to Linux runners and must build or pull an image first. A composite action that installs tools and compiles code would run everywhere, but it breaks the requirement to install nothing at run time.

How to reason it out
  1. List the runner operating systems the action must support.
  2. Rule out Docker container actions, which run only on Linux.
  3. Check which remaining option installs software on every run.
  4. Choose the JavaScript action with bundled code.

Exam tip: Cross-platform and fast start-up points to a JavaScript action; Docker container actions are Linux-only.

Create Custom GitHub Actions: JavaScript, Docker and Composite Actions (GH-200) — the lesson that teaches this.

Question 4Manage GitHub Actions for the enterprise

An owner of the contoso organization wants its workflows to run actions and reusable workflows stored in contoso repositories and the actions GitHub publishes, such as actions/checkout. Actions from every other publisher, including verified Marketplace creators, must be refused. Which allowed-actions configuration meets this?

Choose one.

  • a
    Allow contoso actions and reusable workflows, the most restrictive option, with no non-contoso sources selected

    The owner-only option also blocks actions authored by GitHub, so every workflow that uses actions/checkout would fail.

  • b
    Allow contoso, and select non-contoso, actions and reusable workflows, with GitHub and verified creators checked

    Checking "Allow Marketplace actions by verified creators" admits other publishers' actions, which the requirement forbids.

  • c
    Allow all actions and reusable workflows, combined with the requirement that actions are pinned to a full commit SHA

    SHA pinning controls how actions are referenced, not who publishes them; every publisher would still be allowed.

  • d
    Allow contoso, and select non-contoso, actions and reusable workflows, with only "Allow actions created by GitHub" checked Correct

    This policy always allows the organization's own actions and reusable workflows, and the one checked sub-option adds the actions in the actions and github organizations. Nothing else is allowed.

The concept

The allowed-actions policy has three levels: all, owner-only, and owner plus selected non-owner sources.

Why that’s the answer

Only the "select non-owner" policy can combine the organization's own actions with GitHub-authored ones. Its sub-options are independent: "Allow actions created by GitHub" admits the actions and github organizations, while "Allow Marketplace actions by verified creators" would admit other publishers. The owner-only option is a trap because it blocks actions/checkout too, and SHA pinning is about reference format, not source.

How to reason it out
  1. List the allowed sources: the organization and GitHub only.
  2. Rule out "allow all", which admits every publisher regardless of pinning.
  3. Rule out owner-only, which blocks GitHub-authored actions.
  4. Choose the select policy with only the GitHub sub-option checked.

Exam tip: Owner-only blocks actions/checkout; use "owner and select non-owner" plus "created by GitHub".

Govern GitHub Actions in the Enterprise: Policies, Templates, Secrets and Variables (GH-200) — the lesson that teaches this.

Question 5Secure and optimize automation

A deployment workflow signs in to AWS with an access key ID and secret access key stored as repository secrets. After a key leaked from another system, the security team wants no long-lived cloud credentials stored in GitHub at all, while the workflow keeps deploying to the same account. What should the team do?

Choose one.

  • a
    Grant id-token: write and have the job assume an IAM role that trusts GitHub's OIDC provider Correct

    The job exchanges a short-lived OIDC token for temporary role credentials, so no cloud key is stored in GitHub.

  • b
    Move the access keys to a production environment secret that requires a reviewer's approval

    Approval limits who can use the keys, but long-lived keys are still stored in GitHub.

  • c
    Add a scheduled workflow that rotates the access keys weekly and updates the repository secrets

    Rotation shortens exposure, but a long-lived key is still stored as a secret between rotations.

  • d
    Store the access keys as an organization secret with access limited to the deployment repository

    Narrowing secret access does not remove the stored long-lived credential the team wants gone.

The concept

OIDC federation replaces stored cloud keys with short-lived credentials issued per job.

Why that’s the answer

With id-token: write, the job can request a signed OIDC token from GitHub. The cloud provider trusts GitHub's issuer and exchanges the token for short-lived credentials for a specific role. Environment approval, rotation and narrower secret scopes all keep a long-lived key stored in GitHub, which the requirement rules out.

How to reason it out
  1. Note the requirement: no long-lived cloud credential stored in GitHub.
  2. Eliminate options that only restrict, rotate or rescope a stored key.
  3. Choose OIDC federation, which issues short-lived credentials per job.

Exam tip: To store no cloud keys in GitHub, federate with OIDC (id-token: write) and assume a role.

Secure and Optimize GitHub Actions: Permissions, OIDC, Pinning, Attestations and Caching (GH-200) — the lesson that teaches this.

The GH-200 question bank, by domain

The bank is built to the exam's own weighting, so the practice you get reflects the marks that are actually on offer — not whichever domain was easiest to write questions for.

Published GH-200 practice questions per exam domain
DomainExam weightTopicsQuestions
Author and manage workflows24%292
Consume and troubleshoot workflows19%271
Author and maintain actions18%271
Manage GitHub Actions for the enterprise24%292
Secure and optimize automation15%153
Total100%9379

Practise GH-200 one domain at a time

Domain 1: Author and manage workflows24% of the exam · 92 questions, with worked examples and a topic breakdown.Domain 2: Consume and troubleshoot workflows19% of the exam · 71 questions, with worked examples and a topic breakdown.Domain 3: Author and maintain actions18% of the exam · 71 questions, with worked examples and a topic breakdown.Domain 4: Manage GitHub Actions for the enterprise24% of the exam · 92 questions, with worked examples and a topic breakdown.

How GH-200 questions are worded

Most GH-200 questions are not asking whether you can recall a definition. They describe a situation and ask which option satisfies it — so the skill being tested is reading the requirement precisely and eliminating options that fail it.

Single-response vs multiple-response

A single-response question has exactly one right answer. A multiple-response question tells you how many to pick ("Choose TWO") and there is no partial credit — getting one of the two right scores nothing. Read that instruction before you read the options.

Read the last line first

The final sentence is the actual question; everything before it is scenario. Read it first, then read the scenario knowing what you are looking for. It stops you from building an answer in your head that the question never asked for.

Hunt for the qualifier

Most scenarios turn on one word — MOST cost-effective, LEAST operational overhead, with the LEAST latency, without changing application code. Two options are frequently both technically correct, and the qualifier is the only thing separating them.

Eliminate, then choose

Distractors are almost always real GitHub services doing a real job — just not this job. Rule out the ones that break a stated constraint before you compare what's left. On a question you truly don't know, eliminating two options turns a guess into a coin flip.

Practise GH-200 from your browser

The SaveMyCert Chrome extension opens a daily drill of 5 GH-200 questions in the side panel, with the full explanation behind every answer. No account needed.

Get the Chrome extension (opens in a new tab)

Beyond GH-200 practice

GH-200 revision notes9 lessons covering every domain — go back to the source when a question keeps catching you out.GH-200 cheat sheetEvery key fact on one page. Skim it the week of the exam.GH-200 flashcardsThe same key facts one at a time, answer hidden until you commit — recall practice rather than re-reading.GH-200 mock examsQuestions are practice; 60 of them in 100 minutes is the exam. Rehearse the real thing.GitHub Actions (GH-200) exam overviewExam facts, who it is for, cost and how it fits alongside the other certifications.

GH-200 practice questions: your questions

Yes. You can answer 5 questions a day with no account at all, and a free account raises that to 30 a day across the full 379-question GH-200 bank, with an explanation on every option. Pro removes the daily cap entirely.

Source

Exam structure, domain weights and scoring on this page come from the official GH-200 exam guide.