ExamFinch.com My Study

Study guide

8.1 Actions Purpose, Workflows, and Events

Practice this exam

GitHub Foundations GH-900

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Domains, Scoring, and Candidate Profile 1.3 Official Resources and Hands-On Prep

2 Version Control Fundamentals

2.1 Purpose and Benefits of Version Control 2.2 Git vs GitHub 2.3 Repositories, Commits, and History 2.4 Branches, HEAD, and the Default Branch

3 Working with GitHub

3.1 Accounts, Organizations, and Enterprise Options 3.2 GitHub Flow 3.3 Markdown for Issues and Pull Requests 3.4 GitHub Desktop and GitHub Mobile

4 Repository Structure and Key Files

4.1 Repository Structure and Community Health Files 4.2 Creating Repositories with Templates and Branches 4.3 Adding and Managing Files

5 Repository Insights and Maintenance

5.1 Insights, Stars, Dashboards, and Dependency Insights 5.2 Repository Maintenance and Collaboration Best Practices

6 Issues and Pull Requests

6.1 Issues 6.2 Pull Requests 6.3 Linking PRs, Templates, Filters, and Assignments

7 Discussions, Notifications, and Documentation

7.1 Discussions 7.2 Notifications and Workflow Management 7.3 Gists, Wikis, and GitHub Pages

8 GitHub Actions

8.1 Actions Purpose, Workflows, and Events 8.2 Jobs, Steps, Runners, Secrets, and Reusable Actions

9 GitHub Copilot

9.1 Copilot Suggestions, Agents, Agent Mode, and Multi-Model Support 9.2 Copilot for Individuals, Business, and Enterprise

10 Codespaces and github.dev

10.1 Codespaces, Customization, and Dev Containers 10.2 github.dev vs Codespaces

11 Manage Projects with GitHub

11.1 GitHub Projects and Layout Options 11.2 Configuring Projects, Labels, Milestones, and Workflows 11.3 Saved Replies and Assignees 11.4 Project Insights

12 Account Security and Access

12.1 Two-Factor Authentication and Passkeys 12.2 Access Permissions and Roles 12.3 Enterprise Managed Users and Copilot Policy

13 Privacy, Branch Protection, and Organization Admin

13.1 Privacy, Visibility, and Branch Protection 13.2 Organization Settings, Teams, and Roles

14 Open Source, Sponsors, and InnerSource

14.1 Open Source Benefits and GitHub Sponsors 14.2 How GitHub Supports Open-Source Projects 14.3 InnerSource

15 Marketplace, Discovery, and Collaboration Models

15.1 Following Users and Organizations 15.2 GitHub Marketplace 15.3 Forks, Templates, and Discoverable Repositories

8.1 Actions Purpose, Workflows, and Events

Key Takeaways Explain This Topic AI

GitHub Actions is GitHub's CI/CD platform and a repository automation engine: it can build, test, and deploy code and also label issues or run other GitHub tasks when events fire.

Workflows are YAML files committed to .github/workflows ; a repository can contain multiple independent workflows, each with its own triggers and jobs.

An event—such as push, pull_request, schedule (POSIX cron in UTC), workflow_dispatch, or issues—starts a workflow run; the on key lists those triggers.

workflow_dispatch starts a run from the repository Actions tab (optional inputs); schedule runs without a code change; issues workflows for labeling must exist on the default branch.

GitHub-hosted runners cover Ubuntu Linux, Windows, and macOS; you can also attach self-hosted runners in your own datacenter or cloud.

Last updated: August 2026

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:

  • Workflow file Typical on trigger What it does
  • ci.yml push , pull_request Build and test the proposed change
  • deploy.yml push to the default branch Deploy after merge
  • triage.yml issues with types: [opened] Label or assign the new issue
  • nightly.yml schedule cron Dependency audit or stale cleanup
  • manual.yml workflow_dispatch Operator-started one-off

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.

Loading diagram... Event starts a workflow run

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.

  • Event Fires when Exam cue
  • push Commits (or tags) land on a branch "Every commit to main should run tests"

pull_request Pull request activity; default types are opened , synchronize , and reopened "Test the proposed merge before review"

schedule POSIX cron in UTC "Every Monday at 06:00, no one pushed code"

workflow_dispatch A person clicks Run workflow on the Actions tab, or an API call "Start this by hand, optionally with inputs"

issues Issue activity; filter with types such as opened or labeled "When someone opens an issue, add a label"

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.