GitHub Certifications

Almost every platform on earth begins in the same place: a repository, and the pipeline that fires when somebody pushes to it. For a very large share of the industry that repository lives on GitHub, and GitHub sells certifications for it — but the programme you may remember is gone. GitHub moved its whole exam family onto Microsoft Learn with delivery through Pearson VUE, gave every exam a Microsoft-style GH- code, and then rebuilt the content of every single one during 2026. This page covers what each exam really tests, the slice a platform engineer actually needs (reusable workflows, runner-group governance, OIDC federation, attestations), how that hands off to the pull-based world in GitOps, and — honestly — when to spend the money somewhere else. GitLab’s competing programme has its own page.

What this credential is and where it sits

☺ Like you’re 10: One company, about six quizzes about its own product. It moved all of them to a new home and rewrote nearly all of them this year.

None of these is a CNCF credential and none of them is neutral. They are vendor certifications about one hosted product, the way Amazon certifies you on AWS. That is not an insult — the source-control and CI layer is where a platform’s delivery story starts, and the concepts you learn (declarative pipelines, reusable units, ephemeral credentials, provenance) transfer even when the YAML does not. It just means you should know which parts you are renting.

The structural change matters more than any single exam. Per GitHub’s own community announcement, from 1 July 2025 all GitHub certification exams are delivered exclusively through Pearson VUE, in partnership with Microsoft Learn; the previous PSI-based flow is gone. Certifications earned through PSI before that date stay visible on the GitHub Learn profile, and everything earned on or after it appears on your Microsoft Learn profile. Each exam page now carries the line: “This exam is provided by Microsoft, but the exam and associated certification are maintained by GitHub.” The badge is a Microsoft Learn credential, not a Credly one.

The five live exams

GitHub’s own documentation, About GitHub Certifications, names five certifications: Foundations, Actions, Advanced Security, Administration and Copilot. Those are the five generally available exams, and each has a live page on Microsoft Learn carrying its code, duration, languages and skills-measured domains.

The number has changed: there is now a sixth code

Earlier passes of this site recorded five GitHub exam codes. That is still the right number of generally available exams and the five codes are unchanged — but it is no longer the whole picture. Microsoft Learn now also publishes GitHub Certified: Agentic AI Developer (beta), exam code GH-600, 120 minutes, English only, six domains, aimed at people who “operate, integrate, supervise and govern AI agents” with GitHub as the control plane. As of writing the certification page still carries (beta) in its own title and warns that “you will not receive your results immediately” because scores are released roughly eight weeks after the beta period ends. Third-party reporting says the beta ran to 31 May 2026 with general availability targeted for July 2026; treat that as reporting, not vendor publication, and check the page for the word beta before you assume it is a finished credential.

Two honest observations about GH-600. First, GitHub’s own docs page still lists five certifications and does not mention it — nor Pearson VUE, nor Microsoft Learn — so GitHub’s documentation currently lags GitHub’s own certification programme, which is a useful reminder about where the authoritative page really is. Second, its domains are genuinely interesting for this audience: tool permissions and MCP allow-lists, agent scope confined to one repository, agents invoked from a CI workflow, guardrails, least-privilege execution contexts and human-in-the-loop authorisation for irreversible changes. That is platform-engineering vocabulary applied to a new kind of workload — the same instinct as AI/ML platforms and Governance & Compliance, pointed at agents.

Why a platform engineer takes one — and when to skip

☺ Like you’re 10: Worth it if you build pipelines for other people. Not worth it if you already do that every day, or if your company uses the other vendor.

The case for is narrow but real. On this site, CI is the half of delivery that pushes — it builds, tests, signs and publishes — and CD is the half that pulls (see GitOps Workflows). Most platform teams own the push half as a product: golden pipeline templates, a runner fleet, org-wide policy about which third-party actions are allowed at all. GH-200 is the only structured curriculum that covers that as a platform concern rather than as “here is how to write a build script.” It devotes a whole 20–25% domain to managing Actions for the enterprise — runner groups, org use policies, IP allow lists, secret scoping across org, repo and environment — which is precisely the work. GH-500 earns its place too if supply-chain security is genuinely yours, because it is the closest thing GitHub publishes to a shift-left security curriculum.

There is a second, quieter benefit. These exams force you to learn the enterprise surface of a product you probably only use at repository scale. Most engineers can write a workflow. Far fewer can say what happens when a runner group is scoped to one organisation but the reusable workflow lives in another, or what a delegated bypass on a push-protection rule actually delegates. That gap is where platform teams get hurt.

The honest case against

Four situations where you should not take these. You already author workflows weekly — this is a recall exam about a product you use all day, and your colleagues can read your workflow files, which is better evidence than a badge. Your platform standardised on the other vendor, or on Tekton / Argo Workflows running in-cluster — then this is vendor-locked knowledge with a low transfer rate, and there are better ways to spend a weekend. You are choosing between this and a CNCF exam — the CNPA and the performance-based CNPE map onto the whole discipline rather than one company’s YAML dialect, and a hands-on exam proves something a multiple-choice paper cannot. You want GH-900 to “get started” — if you are reading a platform-engineering site you are already past it.

One more calibration. GH-200 is a proctored exam with a real pass mark, which makes it a stronger market signal than an unproctored vendor quiz — but it is still recognition, not construction. Nothing on it requires you to build a working pipeline under time pressure. Weigh it against the CNCF performance-based exams accordingly, and read the verdict at the bottom of this page before you spend anything.

What GH-200 actually tests — the official domains

☺ Like you’re 10: GitHub tells you how much of the quiz each topic is worth — as a range, not an exact number.

These are the five skills-measured domains from the official GH-200 study guide, whose “skills measured” block is dated January 2026 and whose change log records that the exam “changed significantly” that month. Note that the weights are ranges, in the Microsoft house style — they do not sum to a tidy 100, and any course quoting exact single percentages for GH-200 invented them. Bars below are drawn to the midpoint of each range, relative to the largest:

Read those two 20–25% domains together, because they are the shape of the exam. Roughly half the paper is authoring and consuming workflows, which you can learn free from the docs; the other half is governance, distribution and security, which is the part that is genuinely hard to pick up by osmosis. If you are already fluent in the first half, the exam is a two-week job. If you are not, it is a decent syllabus.

The other exams, in one glance

All weights below are the vendor’s own, transcribed from the official study guides. GH-500 and GH-100 are dated July 2026; GH-900 is dated January 2026; all three record a “changed significantly” entry on those dates. GH-300 and GH-600 are listed for completeness, not because this site recommends them for delivery work.

Two things worth noticing in that table. GH-100 is not really an identity exam — its largest domain by some distance is secure software development and compliance at 25–30%, and Actions administration takes another 20–25%, so nearly half of an “administration” exam is security and pipeline governance. And GH-500 spreads evenly: no domain exceeds 20%, which tells you it is a breadth exam across the whole security suite rather than a deep CodeQL exam. Code Security is in fact the smallest domain at 10–15%, which surprises most candidates who assumed CodeQL was the point.

What the 2026 refreshes changed

Three shifts run through the rebuilt objectives, and all three are worth knowing whether or not you sit an exam. First, the security vocabulary moved: GitHub split what used to be sold as one “Advanced Security” bundle into separately-named suites, and the exam objectives now say Secret Protection, supply chain security and Code Security, each with a “formerly” in brackets. Anything you read that talks only about “GHAS” as a single SKU is describing an older product shape. Second, immutable actions arrived: actions can be published as OCI packages whose version tags cannot be overwritten once published, and GH-200 now expects you to understand that behaviour and its effect on version pinning. It does not make SHA pinning obsolete — the study guide still asks you to “pin third-party actions to full commit SHAs” and to avoid floating @main or @v* without justification. Third, agents entered the blueprint: GH-900 now asks about Copilot agents and Agent Mode, and GH-600 exists at all.

The substance you actually need

☺ Like you’re 10: Write the recipe once, let everyone call it, never hand out a permanent key, and sign what you bake.

Strip away the product trivia and the exam rewards four instincts: do not repeat yourself (reusable workflows and composite actions), do not hold long-lived credentials (OIDC), do not trust code you did not pin (SHA pinning and allow-lists), and prove what you built (attestations). Here is a caller that does all four.

name: build-and-publish
on:
  push:
    branches: [ main ]

permissions:                  # least privilege at the top; jobs may narrow further
  contents: read

env:
  IMAGE: ghcr.io/acme/api     # define it once; used as $IMAGE and env.IMAGE below

jobs:
  test:
    uses: acme/platform-workflows/.github/workflows/go-test.yml@v3   # reusable workflow
    with:
      go-version: "1.24"
    secrets: inherit          # or map explicitly: secrets: { TOKEN: ${{ secrets.TOKEN }} }

  publish:
    needs: test
    runs-on:                  # a runner *group* is selected with group:, not a label
      group: platform-runners
      labels: [ self-hosted, linux, x64 ]
    environment: production   # approval gate + environment-scoped secrets
    permissions:
      contents: read
      packages: write
      id-token: write         # OIDC — no long-lived cloud keys anywhere
      attestations: write     # provenance for what we just built
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1   # v7.0.1 — full SHA
      - uses: aws-actions/configure-aws-credentials@v6   # third party: pin this to a SHA too
        with:
          role-to-assume: arn:aws:iam::123456789012:role/ci-publisher     # federated
          aws-region: eu-west-1
      - name: Build image
        id: build
        run: |
          docker build -t "$IMAGE:$GITHUB_SHA" .
          docker push "$IMAGE:$GITHUB_SHA"
          # RepoDigests gives "repo@sha256:..."; attest wants just the sha256: part
          digest="$(docker inspect --format='{{index .RepoDigests 0}}' "$IMAGE:$GITHUB_SHA" | cut -d@ -f2)"
          echo "digest=$digest" >> "$GITHUB_OUTPUT"
      - uses: actions/attest-build-provenance@v4      # signed provenance, SLSA-style
        with:
          subject-name: ${{ env.IMAGE }}
          subject-digest: ${{ steps.build.outputs.digest }}

Six things the exam — and production — care about in that file.

• uses: at job level calls a reusable workflow; uses: at step level calls an action. A starter workflow is neither: it is a scaffold you copy once and then own outright. That three-way distinction is explicitly in the objectives and is the single most reliably-asked idea on the paper.
• GITHUB_TOKEN is ephemeral and scoped per run, which is exactly why a narrow permissions: block beats handing out a personal access token that lives forever and belongs to a human.
• id-token: write is what makes OIDC federation possible, and it is the highest-value line on this page: it deletes your long-lived cloud secrets entirely. See Secrets Management.
• Actions are pinned to a full 40-character commit SHA, not @main and not a floating major tag. The version comment beside the SHA is for humans; it plays no part in resolution. Immutable actions raise the floor here, but they do not replace SHA pinning.
• A runner group is selected with the group: key under runs-on:, optionally combined with labels: — and when you combine them the runner must satisfy both. A label that merely says “group” is still just a label. That distinction is exam-shaped and production-shaped at once.
• environment: is where approval gates and environment-scoped secrets live — the same gate idea as a progressive delivery promotion. (actions/attest-build-provenance is on v4 and is now a thin wrapper over actions/attest, which its own README recommends for new implementations.)

Runners: the domain platform teams live in

If you own the Actions estate, this is your half of the exam and your half of the job. Know that GitHub-hosted runners are ephemeral VMs with a documented preinstalled toolcache — the objectives explicitly want you to identify what is already on the image and install the rest at runtime via setup-* actions, package managers or a container. Know that self-hosted runners are agents you register, scale, patch and pay for, that they should never be attached to a public repository, and that runner groups are the governance boundary: which organisations and which repositories may target this pool at all.

Two consequences follow that the exam only gestures at and that this site treats as first-class. A self-hosted fleet is a scaling and scheduling problem — on a Kubernetes substrate a runner is a pod, and idle capacity is a real bill, which makes it a FinOps question and often a Karpenter one. And a self-hosted runner is a trust boundary: a job that can reach your cluster network is a job that can be used to reach your cluster network. That is why the pipeline gets an artifact registry and a config repo, not a kubeconfig.

Where CI stops and CD begins

The exam will happily let you believe the pipeline should deploy. On this site it does not. CI pushes; CD pulls. Your workflow builds, scans, signs and publishes an image, then makes one small commit to the config repo — and a reconciler inside the cluster, Argo CD or Flux, notices and converges. The pipeline never holds cluster credentials, so a compromised action cannot become a compromised cluster. Everything GH-200 teaches about attestations feeds this: the thing the reconciler pulls should be a thing whose provenance you can verify (Sigstore & Cosign), and admission policy in the cluster is where you enforce that (Kyverno, OPA Gatekeeper).

How it maps onto the CNPE and this site

☺ Like you’re 10: Almost every quiz topic is already a page here, just written with a different vendor’s words.

Against the CNPE blueprint, domain by domain

Here is the uncomfortable arithmetic. The CNPE publishes five domains: GitOps & Continuous Delivery 25%, Platform APIs & Self-Service 25%, Observability & Operations 20%, Platform Architecture & Infrastructure 15%, Security & Policy Enforcement 15%. Lay GH-200 over that and the overlap is real but lopsided:

Read that as a recommendation, not a criticism. GH-200 is an excellent second or third credential for someone whose delivery layer runs on GitHub, and its security domain is the most portable thing in the whole family. It is a poor substitute for the CNCF ladder, because three of the five CNPE domains barely appear.

Exam logistics — verify before you book

☺ Like you’re 10: 100 minutes, someone watches, you need 700 out of 1000, and the price depends on which country you sit it in.

All of this comes from the official Microsoft Learn certification pages and study guides as of writing. Numbers move quietly — confirm at checkout.

Registration starts at GitHub’s own credentials page, which hands off to Microsoft Learn and then to Pearson VUE for scheduling. One practical warning that Microsoft repeats on every page and that people ignore: register with a personal Microsoft account, not a work or school account — if you register with an organisational account, your exam records are lost and unrecoverable when you leave that organisation. Accommodations are requested through Microsoft’s accommodations process, not GitHub’s.

GitHub or GitLab?

☺ Like you’re 10: Take the one your company actually uses. Taking both is mostly a waste.

If you are choosing between programmes rather than between exams, read the GitLab certifications page alongside this one — the two vendors have made almost opposite choices, and the differences change what a badge is worth. GitHub’s exams are proctored, scored on a 700-point scale, delivered by a third party, and priced by region without a published figure. GitLab’s are self-service, unproctored and flat-priced. The content rhymes — reusable workflow and CI/CD component are the same instinct, runner group and group runner are the same governance problem — but the vocabulary does not transfer, and a hiring manager who has run both will tell you the proctored badge carries more weight while neither proves you can build.

The practical rule: take one vendor exam, and only for the vendor your employer actually runs. Then spend the real money on something performance-based.

Verdict — where it fits in a realistic order

☺ Like you’re 10: Take GH-200 second or third, take it only if you live in GitHub, and never let it stand in for a hands-on exam.

A defensible order for a platform engineer: get genuinely comfortable with Kubernetes first, because every other page here assumes it. Then take GH-200 if your delivery layer is GitHub Actions and you own it for other people — it is the strongest exam in this family for this audience, and its enterprise and security domains are real work rather than trivia. Add GH-500 only if supply-chain security is genuinely your responsibility, and GH-100 only if you actually administer GitHub Enterprise. Then spend the serious effort and money on the performance-based CNPE, which asks you to build rather than to recognise. Skip GH-900. Treat GH-300 as an AI-assistant credential rather than a delivery one, and treat GH-600 as a thing to watch until its page stops saying beta.

Two calibrations to close on. First, these are recall exams about a hosted product — a structured reading list with a badge attached. A hiring manager who reads GH-200 as proof you can operate a runner fleet is making a mistake, and so is a candidate who lets them. Second, the ground under these exams keeps moving: GitHub relocated its entire programme mid-2025, rewrote GH-900 and GH-200 in January 2026, rewrote GH-500 and GH-100 in July 2026, renamed GH-500’s subject matter along with the product, has another GH-200 and GH-300 refresh dated 7 August 2026, and has added a sixth exam that its own documentation does not yet mention. Learn the concepts — reuse, least privilege, ephemeral credentials, provenance, and the push/pull split — because those survive every rename. Rent the badge, which does not. Then head back to the certifications hub to see how this sits beside GitLab, Terraform, the cloud DevOps exams and the SRE-practice credentials.

Official sources verified for this page: GitHub’s About GitHub Certifications and its credentials registration page; the community announcement GitHub Certifications Are Moving to Pearson VUE and the follow-up on Microsoft Learn integration; the certification pages for GH-200, GH-500, GH-100, GH-900, GH-300 and GH-600 (beta); and the study guides for GH-200, GH-500, GH-100, GH-900 and GH-600, which are the authority on domains, weights and change logs. Runner-group syntax checked against GitHub’s runner documentation. Last re-verified July 2026.