Examworthyexamworthy.comGitHub Actions (GH-200) cheat sheet
GitHub
Free to share. Examworthy is not affiliated with or endorsed by GitHub; GH-200 and related marks belong to their respective owners.
At a glance
Format: Multiple choice and multiple response, at a Pearson VUE testing center or online proctored
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
GH-200 is a pick-the-right-mechanism exam: almost every question is a CI/CD scenario with a stated need, and the right answer is the trigger, workflow structure, context, runner, secret scope, caching or artifact mechanism, action type, or security control built for it - and an insecure design can be wrong even when it works.
Spot the trap
Tempting wrong answers, and why they failTempting but wrong
workflow_dispatch can fire a job automatically every night because its cron expression sets a default run time.
Why it fails
workflow_dispatch only adds a manual Run workflow button and accepts no cron field, so it cannot fire automatically on a timetable. Recurring time-based runs come from the schedule event with a cron expression.
Author and manage workflows
Tempting but wrong
A starter workflow can govern shared logic centrally because every repository runs an identical copy of the seeded security checks.
Why it fails
Wrong. Selecting a starter workflow copies the file into the repository, so a later central fix never reaches copies already created. Starter workflows standardise how new repositories begin, but they do not stay a single shared definition. Use a reusable workflow when fixes must propagate to all consumers.
Manage GitHub Actions for the enterprise
Tempting but wrong
A push run can appear in history with a commit to main but with the pushing actor omitted from the interface.
Why it fails
A push run always references a head commit and names the pusher as the actor. If a run shows no commit and no actor, push cannot be the cause, because both fields are always populated for a push event.
Consume and troubleshoot workflows
Tempting but wrong
A JavaScript action can package plain shell run steps once they are rewritten as a Node.js entry point.
Why it fails
This misses the goal. A JavaScript action does run on the runner, but it requires the logic to be rewritten as a Node entry point. To bundle existing shell run steps unchanged, use a composite action with using: composite and a steps list.
Author and maintain actions
Tempting but wrong
Naming required reviewers on an environment inserts a fixed countdown delay during which a queued deployment can be cancelled.
Why it fails
Required reviewers does pause a run, but it waits for a named person to approve rather than counting down a clock. It provides no automatic timed window. To get a fixed unattended delay you use the wait timer protection rule.
Secure and optimize automation
Tempting but wrong
repository_dispatch listens for a timed webhook GitHub emits internally to drive cron-based recurring runs.
Why it fails
repository_dispatch fires only when an external system posts a custom event to the REST API, not on any internal timer, so it ignores a cron field. Recurring time-based runs need the schedule event.
Author and manage workflows
Tempting but wrong
A composite action stored in a shared repository can govern an end-to-end shared workflow as a single source of truth.
Why it fails
Wrong. A composite action bundles a sequence of steps that slot inside a job's steps; it does not define whole jobs. It cannot govern an end-to-end shared workflow on its own. A reusable workflow, referenced through uses at job level, is what centralises a full shareable workflow.
Manage GitHub Actions for the enterprise
Tempting but wrong
A workflow_dispatch run anonymises the actor to protect the operator who clicked Run workflow.
Why it fails
GitHub does not anonymise manual runs. A workflow_dispatch run always records the person who clicked Run workflow as the actor, so an unnamed operator rules this trigger out rather than supporting it.
Consume and troubleshoot workflows
Key terms
Exam-day rules
- Read the scenario for its constraint first. The need named in the question - recurring with no commit, one central definition, a value that survives between steps, a token scoped to least privilege - is what picks the answer, so find it before you judge the options.
- Treat broad GITHUB_TOKEN permissions as a wrong answer. When a job needs only a scope or two, a top-level permissions block that sets every unlisted scope to none is almost always the fit; an option leaving the default read-write or scoping only one job is the trap.
- Reach for OpenID Connect whenever cloud credentials are needed without a stored secret. If an option proposes a long-lived cloud key in a GitHub secret and another proposes OIDC federation, the federation answer is the secure one the exam wants.
- Pin third-party actions to a full commit SHA, not a tag. Any option pinning to a mutable tag like v3 for a third-party action is the weaker, exploitable choice even though it works.
- Let the data-passing requirement pick the mechanism. Same-job environment variable means GITHUB_ENV, a named step output means GITHUB_OUTPUT, files across jobs means artifacts, and a value back to a reusable workflow's caller means on.workflow_call.outputs read via needs.
Revision schedule
- Day 1Map the reweighted blueprint and book a date
- Week 1Build the core decision trees
- Weeks 1 to 3Go deep on authoring and enterprise management (Domains 1 and 4)
- Weeks 3 to 4Drill consuming, troubleshooting and action authoring (Domains 2 and 3)
- Week 4Cover security and optimisation and its traps (Domain 5)