Actions Foundations

What GitHub Actions is

GitHub Actions is GitHub's built-in automation platform. You describe automation as YAML workflow files committed to the repository, and GitHub runs them on runners in response to events — a push, a pull request, a schedule, a button press, an API call or almost any activity on GitHub. CI/CD is the obvious use, but the same machinery labels issues, publishes packages, rotates dependencies, deploys Pages sites and answers webhooks from other systems.

Because workflows live in the repository, they are versioned, reviewed and branched like code. That is the root of many exam answers: a workflow change goes through a pull request, a workflow on a branch runs that branch's version of the file, and protecting .github/workflows/ with CODEOWNERS is how you control who may change automation.

The building blocks

flowchart LR
  EV["Event"] --> WF["Workflow run"]
  WF --> J1["Job A"]
  WF --> J2["Job B"]
  J1 --> R1["Runner<br/>fresh VM or container"]
  J2 --> R2["Runner<br/>fresh VM or container"]
  R1 --> S1["Steps<br/>run: scripts · uses: actions"]
  R2 --> S2["Steps<br/>run: scripts · uses: actions"]

Anatomy of a workflow

Every workflow you meet on the exam is some arrangement of the same few top-level keys. Learn to read them in this order: when does it run (on), with what power (permissions), how many at once (concurrency), and then the jobs and their dependencies.

name: CI                                  # shown in the Actions tab
run-name: CI for ${{ github.ref_name }} by @${{ github.actor }}

on:                                       # 1 · the events that start a run
  push:
    branches: [main]
  pull_request:
    paths: ['src/**', 'package*.json']
  workflow_dispatch:                      # adds a "Run workflow" button

permissions:                              # 2 · the GITHUB_TOKEN's scopes
  contents: read

concurrency:                              # 3 · one run per branch at a time
  group: ci-${{ github.ref }}
  cancel-in-progress: true

env:                                      # 4 · variables for every job
  NODE_ENV: test

jobs:
  test:                                   # 5 · a job: one runner, many steps
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7         # an action
      - uses: actions/setup-node@v7
        with:
          node-version-file: .nvmrc
          cache: npm
      - run: npm ci                       # a script, in the default shell
      - run: npm test

  build:
    needs: test                           # 6 · waits for test to succeed
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v7
        with:
          name: dist
          path: dist/

The highlighted ${{ … }} spans are expressions: GitHub evaluates them before the text reaches the runner. Everything else in a run: line is handed to the shell as-is. Keeping that boundary in mind is half of the security skill — an expression that injects untrusted text into a script is the classic script-injection bug.

Where files live

When each part is evaluated

Many questions reduce to timing. A workflow is not one script run top to bottom: different parts are read at different moments, by different components, and some contexts simply do not exist yet when a key is evaluated.

flowchart LR
  A["Event fires<br/>workflow file read<br/>from its commit"] --> B["Run queued<br/>repo and org<br/>secrets read"]
  B --> C["Job starts<br/>environment rules,<br/>environment secrets,<br/>GITHUB_TOKEN minted"]
  C --> D["Job ends<br/>token revoked"]

The Syntax reference has the full table of which contexts each key can see.

The Actions tab

The exam expects you to know where things are in the UI, not just in YAML. The Actions tab of a repository lists workflows on the left and their runs on the right, filterable by event, status, branch and actor. Opening a run shows its summary: the trigger, status, duration, a graph of jobs, annotations, job summaries and artifacts. Opening a job shows its steps and their logs.

A job's log is grouped by step. Here is the start of a checkout step as the log viewer shows it:

Each step's output is folded into groups, secrets are replaced by ***, and annotations such as ::notice:: are lifted into the run summary. Skill 2 covers reading logs, re-running and downloading them in depth.

Runners in brief

The current GitHub-hosted labels, checked on 5 November 2026: ubuntu-latest is moving from Ubuntu 24.04 to Ubuntu 26.04 in a gradual rollout between 19 October and 19 November 2026; windows-latest is Windows Server 2025; macos-latest is macOS 26 on Arm64. Skill 4 covers runner management in full.

Renames and retired syntax

Older Learn units, blog posts, forum answers and practice questions are full of names and commands that have moved. The exam follows the current product, but you will read both.