GH-200 — GitHub Actions Cheat Sheet

The exam mindset is practical: know how a workflow is triggered, how jobs and steps execute, how data moves between jobs, how permissions and secrets are controlled, and which GitHub Actions feature solves a specific automation problem.

Workflow file elements

Workflow File Anatomy

A workflow is a YAML file placed under .github/workflows/. It normally includes an event trigger and at least one job.

Workflow Structure Traps

Trigger filtering patterns

on:
  pull_request:
    types: [opened, synchronize, reopened]
    branches:
      - main
      - "release/**"
    paths:
      - "src/**"
      - "!src/experimental/**"

Trigger decision table

Events and Triggers

The on key defines when a workflow runs. Be comfortable with simple triggers, filtered triggers, manual triggers, reusable workflow triggers, and security-sensitive pull request triggers.

Trigger Filters

High-yield filter rules:

• If both branch filters and path filters are configured, the workflow runs only when both conditions match.
• Negative patterns using ! are order-sensitive.
• You cannot use branches and branches-ignore together for the same event.
• You cannot use paths and paths-ignore together for the same event.
• Path filters are not evaluated for tag pushes.
• Workflows skipped by branch, path, or commit-message filters can leave required checks pending, which may block merging if that check is required.
• Events created by the default GITHUB_TOKEN generally do not trigger new workflow runs, which helps prevent accidental recursion. Use a suitable GitHub App token or personal access token only when workflow chaining is intentionally required.

Pull Request Trigger Decision Point

The key exam trap: pull_request_target is powerful but dangerous. It runs in the context of the base repository. If you check out and execute code from an untrusted fork in that context, secrets or write permissions may be exposed.

Status functions

- name: Upload logs on failure
  if: ${{ failure() }}
  uses: actions/upload-artifact@v4
  with:
    name: logs
    path: logs/

Expression functions and operators

Environment variable precedence

env:
  APP_ENV: test

jobs:
  example:
    runs-on: ubuntu-latest
    env:
      APP_ENV: ci
    steps:
      - run: echo "$APP_ENV"
        env:
          APP_ENV: step

Passing data between steps and jobs

steps:
  - id: version
    run: echo "value=1.2.3" >> "$GITHUB_OUTPUT"

  - name: Use step output
    run: echo "Version is ${{ steps.version.outputs.value }}"

Contexts, Variables, and Expressions

Contexts expose workflow data. The correct context depends on where the expression is evaluated.

Variables and Secrets

Environment variable precedence generally becomes more specific as scope narrows: step-level env overrides job-level env, which overrides workflow-level env.

Workflow Command Files

Expression Traps

Useful expression functions to recognize:

Matrix Strategy

A matrix expands one job definition into multiple job runs.

High-yield matrix rules:

• Matrix jobs are separate job runs.
• Matrix variables are accessed with the matrix context.
• Use include for special combinations or extra variables.
• Use exclude to remove invalid combinations.
• Use fail-fast: false when you want all matrix combinations to finish even if one fails.
• Use max-parallel when runner capacity, rate limits, or deployment constraints matter.
• Dynamic matrices often use a previous job output plus fromJSON.

Composite action pattern

action.yml:

name: "Setup and lint"
description: "Install dependencies and run lint"
runs:
  using: "composite"
  steps:
    - run: npm ci
      shell: bash
    - run: npm run lint
      shell: bash

Called from a workflow:

steps:
  - uses: actions/checkout@v4
  - uses: ./.github/actions/setup-and-lint

Reusable workflow pattern

Reusable workflow:

name: Reusable Deploy

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    secrets:
      deploy-token:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    steps:
      - run: echo "Deploying to ${{ inputs.environment }}"

Caller workflow:

jobs:
  deploy-prod:
    uses: org/platform/.github/workflows/deploy.yml@main
    with:
      environment: production
    secrets:
      deploy-token: ${{ secrets.PROD_DEPLOY_TOKEN }}

Reusable workflow traps

Actions

An action is a reusable unit invoked from a step with uses.

Security review for actions:

• Prefer trusted actions and review what they do.
• Pin actions to a full commit SHA when security and reproducibility matter most.
• Pinning to a major version tag is common but less strict than SHA pinning.
• Avoid using unreviewed actions with secrets or write permissions.
• Use organization or enterprise policies where available to restrict allowed actions.

Composite Action vs Reusable Workflow

Decision rule:

• Use a composite action when you want to reuse a set of steps inside a job.
• Use a reusable workflow when you want to reuse an entire job or multi-job process.
• Use a workflow template when you want a starter workflow pattern for repositories, not runtime reuse.

Reusable Workflow Calling Patterns

Reusable workflows are triggered by workflow_call and called from another workflow at the job level.

Reusable workflow traps:

• A reusable workflow is called as a job, not as a step.
• The called workflow must define on: workflow_call.
• The caller does not define the internal steps of the called workflow.
• Permissions and secrets should be explicitly considered across the call boundary.
• Pinning reusable workflows by SHA improves reproducibility and security.

jobs:
  build:
    runs-on: [self-hosted, linux, x64, gpu]
    steps:
      - run: ./build.sh

Job containers and service containers

jobs:
  integration:
    runs-on: ubuntu-latest
    container: node:22

    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres

    steps:
      - run: npm test
        env:
          DATABASE_HOST: postgres

Runner security distinctions

Runners

A runner is the machine that executes a job.

Runner Selection

Runner traps:

• Each normal job runs on its own runner instance. Do not assume job filesystem state carries over.
• GitHub-hosted runners are ephemeral; self-hosted runners may persist files unless cleaned.
• Shell defaults differ by operating system.
• Container jobs and service containers are primarily Linux-runner features.
• Self-hosted runners in public repositories require special caution because untrusted code may execute on your infrastructure.
• If a self-hosted runner is offline, jobs can remain queued.

Secrets vs variables

High-yield rules:

• Do not hard-code secrets in workflow YAML, scripts, logs, or action inputs.
• Secrets are masked in logs, but masking is not a substitute for least privilege.
• Secrets are generally not available to workflows triggered from untrusted forks.
• Secrets cannot be directly used in some conditional expressions. A common pattern is to map to env and test the env value carefully.
• Prefer environment secrets for deployment targets with required reviewers or protection rules.
• Use separate secrets for separate environments instead of one broad credential.

OIDC federation pattern

Use OpenID Connect when a cloud or external identity provider trusts GitHub-issued tokens. This avoids long-lived cloud credentials in GitHub secrets.

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Authenticate with cloud provider using OIDC
        run: echo "Request short-lived credentials through provider action or CLI"

Secure action usage

Unsafe pattern:

- run: echo "${{ github.event.pull_request.title }}" | bash

Safer pattern:

- name: Use PR title as data, not code
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: |
    printf '%s\n' "$PR_TITLE"

Permissions, Tokens, and Security

Security is a major decision area for GitHub Actions. Know how to reduce privileges and prevent untrusted code from reaching secrets.

GITHUB_TOKEN

GitHub automatically creates a GITHUB_TOKEN for workflow runs. Its access is controlled with the permissions key.

Important nuance: when you explicitly configure permissions, unspecified permissions are generally not granted, aside from required metadata access. This is a common exam-style trap.

OIDC

OpenID Connect allows workflows to request short-lived tokens from a cloud provider or external system without storing long-lived cloud credentials as GitHub secrets.

OIDC trap: granting id-token: write does not automatically grant cloud access. The external provider must be configured to trust the workflow identity.

Secrets

Common secret mistakes:

• Printing secrets or derived credentials.
• Passing secrets to untrusted third-party actions.
• Using secrets in workflows triggered by untrusted code.
• Confusing vars and secrets.
• Assuming masking prevents all forms of leakage.
• Forgetting that generated sensitive values may need explicit masking with add-mask.

Environments and Deployments

GitHub Actions environments help control deployment jobs.

Deployment review rules:

• Use environments for deployment gates and environment-specific secrets.
• Use concurrency to prevent overlapping deployments.
• Build once, then deploy the same artifact through later stages when possible.
• Keep CI validation separate from privileged deployment jobs.
• Avoid exposing production secrets to PR validation workflows.
• Use least-privilege permissions for each deployment job.

Artifact pattern:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: mkdir -p dist && echo app > dist/app.txt
      - uses: actions/upload-artifact@v4
        with:
          name: app
          path: dist/

  consume:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: app
          path: dist/
      - run: ls dist

Cache pattern:

- name: Cache npm dependencies
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      npm-${{ runner.os }}-

Cache key guidance

Debugging techniques

- name: Debug selected contexts
  run: |
    echo "ref=${{ github.ref }}"
    echo "event=${{ github.event_name }}"
    echo "runner=${{ runner.os }}"

Use toJSON carefully:

- name: Debug event payload
  env:
    EVENT_JSON: ${{ toJSON(github.event) }}
  run: echo "$EVENT_JSON"

Avoid dumping secrets or full contexts that may contain sensitive data.

Steps

Steps run sequentially inside a job.

Status Functions

Common control-flow traps:

• A dependent job is skipped if a required job is skipped or fails, unless the condition explicitly handles it.
• Step-level if conditions are evaluated at runtime inside the job.
• Job-level if conditions are evaluated before matrix expansion.
• continue-on-error changes failure behavior but does not mean the command succeeded.
• Use needs.<job_id>.result when downstream jobs must react to upstream success, failure, cancellation, or skip states.

Outputs

Output traps:

• A step must have an id if later steps need its outputs.
• Job outputs are only available to jobs that declare needs.
• Outputs are strings unless converted.
• Outputs are not a safe place for secrets unless the flow is carefully controlled.

Artifacts vs Cache

Cache key best practices:

• Include operating system or platform.
• Include dependency lockfile hash with hashFiles.
• Use restore keys for fallback matches.
• Do not depend on cache for correctness.
• Do not put credentials, tokens, or secrets in cached paths.

Debug logging review:

• ACTIONS_STEP_DEBUG enables detailed step debug logging.
• ACTIONS_RUNNER_DEBUG enables additional runner diagnostic logging.
• Use debug logging carefully because logs may contain sensitive operational details.

Common failure patterns:

Misusing Security Features

Misunderstanding Data Flow