Author and Maintain Workflows
This domain tests your ability to write, read, debug, and maintain GitHub Actions workflow YAML files for CI/CD pipelines and automation tasks. It is the heaviest-weighted domain at 40% of the exam, meaning roughly 20 out of 50 questions will require you to understand workflow syntax, event triggers, job coordination, secrets handling, artifact management, and debugging techniques with enough precision to distinguish between near-identical YAML configurations.
Workflow YAML Structure
Every workflow file lives in .github/workflows/ and must be valid YAML. The four required top-level keys are:
| Key | Purpose | Required |
|---|---|---|
name | Display name in the Actions UI | No (defaults to filename) |
on | Event(s) that trigger the workflow | Yes |
jobs | Map of one or more jobs to run | Yes |
steps | List of steps within each job | Yes (per job) |
A job must have a runs-on key. Steps can use uses (an action) or run (a shell command), never both in the same step.
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: echo "Hello"
Common traps
- Putting
stepsat the workflow level instead of inside a job. - Using both
usesandrunin the same step — this is invalid. - Omitting
runs-onfrom a job — the workflow will fail to parse. - Confusing
jobs.<id>.name(display name) with the job ID (the YAML key).
Event Triggers
Bold keywords: on, push, pull_request, schedule, workflow_dispatch, repository_dispatch
| Trigger | Who/What fires it | Key sub-keys |
|---|---|---|
push | A commit pushed to matching branches/tags | branches, tags, paths |
pull_request | PR opened, synchronised, or reopened | branches, types, paths |
schedule | POSIX cron on UTC clock | cron |
workflow_dispatch | Manual trigger from UI or API | inputs |
repository_dispatch | External HTTP POST to GitHub API | types |
Cron syntax: five fields — minute, hour, day-of-month, month, day-of-week. Example: '0 8 * * 1' = every Monday at 08:00 UTC. The minimum schedule interval is every 5 minutes.
workflow_dispatch inputs support types: string, boolean, choice, environment. Default values can be set. Inputs are accessed via ${{ inputs.input_name }}.
repository_dispatch requires a client_payload in the POST body and a matching types filter. It can only be triggered on the default branch.
Common traps
pull_requestdefault activity types areopened,synchronize,reopened— not all PR events.scheduleruns only on the default branch of the repository.workflow_dispatchinputs are optional by default unlessrequired: trueis set.- Paths filter uses glob patterns;
paths-ignoreandpathscannot both be set for the same event. repository_dispatchonly fires on the default branch, regardless of the branch specified in the API call.
Sign in free to read the full guide
17 more sections (about 2,757 words) continue below. The first domain's study guide is free for every GH-200 learner with a free account.