GH-200 cheat sheet

Exam at a glance

Domain weightings

How much of the exam each domain covers. Spend your study time in proportion — the heavier the domain, the more questions you'll see.

Key terms

Workflow

A workflow is a configurable automated process defined in a YAML file under .github/workflows that runs one or more jobs. Workflows are triggered by events such as pushes, pull requests, schedules, or manual dispatch, and are the top-level unit of automation in GitHub Actions.

Job

A job is a set of steps in a workflow that execute on the same runner. Jobs run in parallel by default but can be sequenced with the needs keyword to express dependencies, and each job runs in a fresh runner environment.

Runner

A runner is a server that executes the jobs in a workflow. GitHub offers hosted runners on Linux, Windows, and macOS images, and organizations can register self-hosted runners for custom hardware, software, or network access.

Reusable workflow

A reusable workflow is a workflow invoked by another workflow through the workflow_call trigger, letting teams define automation once and call it from many repositories. Inputs and secrets are passed explicitly, and it is versioned centrally rather than copied.

Composite action

A composite action is a custom action that bundles multiple workflow steps into a single reusable action defined in an action.yml file. It encapsulates step logic so it can be shared, distinct from a reusable workflow, which invokes an entire workflow.

Matrix strategy

A matrix strategy uses the strategy.matrix key to generate multiple job variations from combinations of variables such as operating system and runtime version. It supports include and exclude, fail-fast, and max-parallel to control how the variations run.

GITHUB_TOKEN

GITHUB_TOKEN is an ephemeral, automatically generated secret that GitHub Actions provisions for each workflow run to authenticate against the repository. It is scoped to the run, expires when the job finishes, and its permissions can be narrowed with the permissions key.

OIDC

OIDC (OpenID Connect) lets a GitHub Actions workflow request a short-lived identity token to federate with a cloud provider, eliminating long-lived stored cloud secrets. Enabling it requires the id-token: write permission and a trust relationship configured on the cloud side.

Artifact

An artifact is a file or set of files produced by a workflow run and stored by GitHub for later download or use by other jobs. Artifacts have configurable retention periods and are distinct from caches, which speed up repeated runs.

Immutable actions

Immutable actions are published action releases that cannot be altered after publication, so a specific released version resolves to the same code every time. Moving major/minor tags can still be advanced to new releases, which is why pinning to a full commit SHA remains the strongest supply-chain practice.

workflow_dispatch

workflow_dispatch is an event that enables manually triggering a workflow from the GitHub UI or API. It supports typed inputs with required flags and defaults, which are then available to the workflow through the inputs context.

Runner group

A runner group is a collection of self-hosted or larger hosted runners managed together with shared access policies at the organization or enterprise level. It controls which repositories and workflows may use those runners.

Context

A context is a collection of workflow and runtime data accessed with the ${{ }} expression syntax, such as github, runner, env, secrets, matrix, and needs. Contexts let steps read metadata about the run, repository, and environment.

Artifact attestation

An artifact attestation is signed provenance metadata that records how a build artifact was produced, supporting frameworks such as SLSA. It lets downstream consumers verify that an artifact came from a trusted workflow before deploying it.

Environment

An environment is a named deployment target in GitHub Actions that can require protection rules such as required reviewers, wait timers, and branch restrictions before a job proceeds. Environment-scoped secrets and variables are only exposed to jobs that reference the environment.