8.1 Actions Purpose, Workflows, and Events

Why GH-900 tests GitHub Actions

Domain 4 of GitHub Foundations (GH-900)—Apply modern development practices, 10–15% of the exam—opens with describe the purpose and capabilities of GitHub Actions. The January 2026 outline does not ask you to debug a production matrix from memory. It asks whether you know that Actions is GitHub's built-in continuous integration and continuous delivery (CI/CD) system and a general automation engine for the rest of the repository: issues, pull requests, releases, and scheduled chores.

GitHub's Understanding GitHub Actions page is the product source. Actions lets you build, test, and deploy when people push commits or open pull requests. It also lets you run a workflow when other repository events fire. The official example is labeling a new issue automatically. If a question says "run tests on every pull request," the answer is Actions. If it says "add a needs-triage label when an issue is opened," the answer is still Actions—not a GitHub Project built-in workflow, not a Marketplace App you must buy, and not a webhook server you host yourself (those exist; GH-900 wants the in-repo YAML).

GH-900 sits below the dedicated GitHub Actions certification. You will not be asked to size ARM larger runners. You will be asked to name the chain: event → workflow → jobs → steps on a runner. Section 8.1 owns purpose, workflow files, and events. Section 8.2 owns jobs, steps, runners, secrets, reusable actions, and included minutes.

Purpose: CI/CD plus repository automation

Continuous integration (CI) is the habit of building and testing every change so defects show up before merge. Continuous delivery (CD) is the habit of packaging and deploying those changes once they pass. GitHub Actions implements both inside the same YAML files that already live with the code. A typical CI workflow checks out the repository on a runner, installs a toolchain, and runs the test command. A typical CD workflow waits until the default branch moves, then publishes a package or deploys to a host.

That pairing is the first trap. Actions is not "the GitHub version of Jenkins, period." GitHub's docs say Actions goes beyond DevOps and lets you run workflows when other events happen in your repository. Typical non-CI jobs:

• Apply labels or assignees when an issue is opened
• Comment on a pull request with a review checklist
• Welcome a first-time contributor
• Attach a release asset when a tag is pushed
• Close stale issues on a weekly schedule
• Sync labels from a template repository

If the scenario never compiles code, Actions can still be the right product because the trigger is a GitHub event. The capability GH-900 wants is: any repository activity GitHub exposes as an event can start automation that runs on a runner.

An action (lowercase, the reusable unit) is not the same thing as GitHub Actions (the product). An action is a pre-built step you uses: inside a workflow—checkout, setup-node, a Marketplace deploy action, or a custom action you wrote. The product is the whole event-driven engine. Mixing those two words is a common wrong answer: "install an action from Marketplace" is how you reuse a step; it is not how you turn on CI for the repository.

Workflows live as YAML under .github/workflows

A workflow is a configurable automated process that runs one or more jobs. You define it in a YAML file (.yml or .yaml) and commit that file to the repository. GitHub only auto-discovers workflows in .github/workflows/. A file at the repository root named ci.yml, a file in .github/CODEOWNERS, or a file in .github/actions/ is not a workflow. Custom actions you write can live elsewhere; workflows that GitHub runs must sit in that directory.

A repository can have multiple workflows. That is the intended design, not a workaround. Split by purpose so logs stay readable and a flaky deploy does not block issue triage:

Each file is independent. A failing CI run does not cancel an issue-label workflow. You can still list several events on one workflow when they should share the same jobs (for example push and pull_request on ci.yml). Filters such as branches and paths further narrow when that file fires.

The repository Actions tab lists workflow runs and their logs. You read failures there. You do not need a third-party dashboard for GH-900. Anyone with write access can run workflows; usage is billed to the repository owner, not to the person who clicked.

Here is a small, realistic workflow that GH-900-level candidates should be able to read. It does not invent a second product—it shows name, on, jobs, runs-on, steps, uses, and run in one file:

name: Continuous integration
on:
  push:
    branches: [main]
  pull_request:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

name is the title in the Actions tab. on is the event list. jobs.build is one job. runs-on: ubuntu-latest asks GitHub for a Linux hosted runner. The first step uses the official checkout action so the runner has your files; the second step runs a shell command. Section 8.2 unpacks jobs, needs, secrets, and with/env. For this section, memorize the location and the trigger.

Events: what actually starts a run

An event is a specific activity that triggers a workflow run. GitHub documents a long catalog; GH-900 concentrates on five you must recognize by name and by scenario.

You list them under on. One event: on: push. Several events: stack them as keys. Activity types narrow a noisy event:

on:
  issues:
    types: [opened]
  schedule:
    - cron: "0 6 * * 1"

push vs pull_request. A push workflow runs in the context of the branch that received the commits. A pull_request workflow is the CI check reviewers see on the pull request. By default it does not run on every PR activity (review requested, labeled, closed). Unless you add types, GitHub runs it when the pull request is opened, when new commits synchronize it, or when it is reopened. pull_request also will not start if the pull request has a merge conflict—fix the conflict first. Do not write on: pull_request and assume a comment on the PR retriggers CI; comments are issue_comment.

schedule. The value is a POSIX cron string, evaluated in UTC, not the repository owner's local time. 0 6 * * 1 is 06:00 UTC every Monday. GitHub may delay scheduled workflows under load, so treat cron as "about this time," not a hard SLA. Cron does not require a new commit; that is the point. A trap option is putting cron under push—cron belongs under schedule.

workflow_dispatch. This is the manual trigger. The Run workflow button appears on the Actions tab once the workflow file exists on the default branch. If you add workflow_dispatch only on a feature branch, the button is missing until that file reaches main (or whatever the default is). You can declare inputs so the operator picks an environment or a version. workflow_dispatch is not a timer; if the scenario is a clock, the event is schedule.

issues. This is the official "beyond CI/CD" example. types: [opened] runs when an issue is created. Pair it with an action that calls the Issues API (or gh) to add labels. The workflow file for issues (and most non-push events) must exist on the default branch, or GitHub never starts the run. issue_comment is a different event—comments on issues and pull requests. If the question is "new issue," use issues, not issue_comment.

You can also trigger workflows from the REST API (repository_dispatch) or by calling a reusable workflow. GH-900 will almost always name push, pull_request, schedule, workflow_dispatch, or issues. If a scenario says "outside GitHub, a monitoring tool should start the workflow," that is repository_dispatch—know it exists, do not spend Domain 4 memorizing the payload.

Exam scenarios and traps

• "Build and test every pull request" → Actions workflow on pull_request, not a gist and not github.dev.
• "Label issues as needs-triage when they are opened" → Actions on issues / types: [opened]. GitHub Projects can auto-add items; that is not the same as applying a repository label from a workflow.
• Workflow files belong in .github/workflows/. .github/workflows is not optional decoration. action.yml at a folder root describes a reusable action, not a workflow.
• Multiple workflows per repository are normal. You do not cram deploy, CI, and triage into one file unless they share jobs.
• workflow_dispatch is manual. schedule is cron. Do not swap them.
• Cron is UTC. "6 a.m. company time" is not automatically 0 6 * * *.
• An issues workflow sitting only on a feature branch will not run. Put it on the default branch.
• GitHub Actions the product ≠ one Marketplace action. Marketplace is where you find reusable steps; the workflow is what runs.

If you can read a one-line story and answer "which event, which file path, CI or repo automation?" you have Domain 4's purpose-and-capabilities skill. The next section puts jobs on runners and shows where secrets and minutes fit.