GH-200 — GitHub Actions (GH-200) Exam Blueprint

How to Use This Exam Blueprint

Use this checklist to prepare for the GitHub Actions (GH-200) exam from GitHub. It translates the GitHub Actions skill areas into practical readiness tasks: what you should be able to configure, explain, troubleshoot, and choose in a scenario.

Because official weights can change, do not treat the order below as a scoring prediction. Treat it as a readiness map for final review.

A strong GH-200 candidate should be able to:

• Read and reason about workflow YAML.
• Select the right trigger, runner, action, environment, permission, or reuse pattern.
• Diagnose why a workflow did not run, skipped a job, failed a permission check, or exposed risk.
• Distinguish similar GitHub Actions features under scenario pressure.
• Apply security, governance, and operational controls without over-permissioning workflows.

Topic-Area Readiness Map

Workflow File Anatomy Checklist

You should be able to read a workflow and identify each major scope.

name: CI

on:
  pull_request:
    branches:
      - main

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Run tests
        run: npm test

Check that you can explain:

• Why workflow files live under .github/workflows/.
• The difference between a workflow, job, step, action, and runner.
• When to use run versus uses.
• How YAML indentation changes meaning.
• Where permissions, env, defaults, and concurrency can be declared.
• How workflow-level settings differ from job-level and step-level settings.
• How skipped jobs affect downstream jobs.
• How default shell behavior may differ by runner operating system.

Events and Trigger Readiness

Trigger Selection Table

Trigger Checklist

• Explain the difference between event name, activity type, branch filter, and path filter.
• Identify why a workflow does not run when both branch and path filters are present.
• Use workflow_dispatch inputs without assuming they are automatically safe.
• Distinguish pull_request and pull_request_target risk at a high level.
• Recognize when a workflow is skipped by filters rather than failing.
• Explain why a workflow triggered by one event may have different context values than another.
• Know when workflow_call is for reusable workflows, not manual dispatch.
• Recognize that cron-style schedules are not a substitute for deployment gates.

Jobs, Steps, and Execution Flow

Can You Do This?

• Predict the order of job execution when needs is present.
• Explain what happens when an upstream job fails.
• Use if: at the step and job level.
• Distinguish success(), failure(), cancelled(), and always() style conditions.
• Choose where to place env values based on scope.
• Explain how continue-on-error affects workflow status and downstream behavior.
• Use timeout-minutes appropriately without hiding root causes.
• Identify when a step runs in a shell versus using an action.
• Explain why a command works on Linux but fails on Windows or macOS runners.
• Use defaults.run for shell and working-directory consistency.

Execution Flow Example

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Build"

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: echo "Test"

  notify:
    needs: [build, test]
    if: always()
    runs-on: ubuntu-latest
    steps:
      - run: echo "Notify regardless of prior result"

Be ready to answer:

• Which jobs can start immediately?
• Which jobs wait?
• What happens if build fails?
• Why might notify still run?
• What context would you inspect to know upstream job results?

Contexts, Expressions, and Variables

Important Contexts to Recognize

Expression Readiness Checklist

• Use ${{ }} expressions in the correct places.
• Compare strings and booleans without assuming shell syntax.
• Use logical operators in if: conditions.
• Use functions such as checks, formatting, JSON conversion, or containment where appropriate.
• Distinguish GitHub expression evaluation from shell variable expansion.
• Avoid placing untrusted input directly into shell commands.
• Explain why a value may be empty because of scope, event type, or secret restrictions.

Example distinction:

steps:
  - name: GitHub expression
    run: echo "Branch is ${{ github.ref_name }}"

  - name: Shell variable
    env:
      BRANCH_NAME: ${{ github.ref_name }}
    run: echo "Branch is $BRANCH_NAME"

Environment Variables, Outputs, Artifacts, and Caches

Data-Sharing Decision Table

Outputs Checklist

• Give a step an id before referencing its outputs.
• Promote step outputs to job outputs when another job needs them.
• Reference downstream values through the needs context.
• Avoid using outputs for secrets unless you fully understand masking and exposure risks.
• Troubleshoot empty outputs caused by scope, conditionals, or skipped steps.

Example:

jobs:
  prepare:
    runs-on: ubuntu-latest
    outputs:
      version: ${{ steps.meta.outputs.version }}
    steps:
      - id: meta
        run: echo "version=1.2.3" >> "$GITHUB_OUTPUT"

  release:
    needs: prepare
    runs-on: ubuntu-latest
    steps:
      - run: echo "Releasing ${{ needs.prepare.outputs.version }}"

Artifact and Cache Readiness

• Explain the difference between artifacts and caches.
• Use cache keys that change when dependencies change.
• Recognize cache restore behavior and partial-match implications.
• Avoid storing secrets, credentials, or sensitive build outputs in caches.
• Use artifacts for logs, test reports, coverage reports, binaries, and deployment packages when appropriate.
• Know that artifact and cache behavior can be affected by repository settings and retention policies.

Matrix Strategy Checklist

Matrix jobs are common exam material because they combine YAML, expressions, and execution behavior.

strategy:
  fail-fast: false
  matrix:
    os: [ubuntu-latest, windows-latest]
    node: [18, 20]
    include:
      - os: ubuntu-latest
        node: 20
        coverage: true

Be ready to:

• Predict how many jobs a matrix creates.
• Explain how include adds or augments matrix combinations.
• Explain how exclude removes combinations.
• Use matrix values in runs-on, names, commands, and conditions.
• Explain fail-fast behavior conceptually.
• Limit parallelism when resource use or external systems require control.
• Debug a matrix job that fails only on one OS, language version, or dependency version.

Scenario cues:

Reusable Workflows vs Composite Actions vs Custom Actions

Feature Selection Table

Reusable Workflow Checklist

• Use workflow_call for reusable workflows.
• Define expected inputs and secrets explicitly.
• Know how caller workflows pass inputs and secrets.
• Explain how called workflow permissions are handled conceptually.
• Return outputs from a reusable workflow when the caller needs results.
• Version reusable workflow references to avoid unexpected changes.
• Avoid designing reusable workflows that require unnecessary broad permissions.

Example caller pattern:

jobs:
  call-ci:
    uses: org/shared-workflows/.github/workflows/ci.yml@main
    with:
      node-version: "20"
    secrets: inherit

Be prepared to discuss when secrets: inherit is convenient versus when explicit secret passing is safer.

Custom Action Checklist

For action authoring, review the shape and purpose of action.yml or action.yaml.

name: "Example Composite Action"
description: "Runs shared setup"
inputs:
  node-version:
    required: true
    description: "Node.js version"
runs:
  using: "composite"
  steps:
    - run: echo "Using Node ${{ inputs.node-version }}"
      shell: bash

You should be able to:

• Identify metadata fields: name, description, inputs, outputs, and runs.
• Distinguish composite, JavaScript, and Docker action execution models.
• Explain where action inputs are referenced.
• Explain how an action can set outputs.
• Recognize why action versioning matters.
• Describe risk considerations for publishing or consuming actions.
• Understand that custom action code should avoid logging secrets or trusting unsafe input.

Security and Permissions Readiness

Least-Privilege Checklist

• Set permissions explicitly when a workflow needs the GITHUB_TOKEN.
• Grant only required scopes for each workflow or job.
• Prefer job-level permissions when different jobs need different access.
• Recognize when default token permissions are too broad for the task.
• Avoid using personal access tokens when GITHUB_TOKEN or OIDC is more appropriate.
• Store sensitive values in secrets, not plain workflow YAML.
• Avoid echoing secrets or placing them in artifacts, caches, logs, or outputs.
• Treat third-party actions as code you are executing in your workflow.
• Pin actions to stable references appropriate for your risk model.
• Review workflows triggered from forks or untrusted contributions with extra caution.

Permission Scenario Table

OIDC Readiness

OpenID Connect is a common secure deployment pattern because it can reduce reliance on long-lived cloud credentials.

Be able to explain:

• What problem OIDC solves in CI/CD.
• Why short-lived federated credentials are safer than storing long-lived keys.
• That the workflow must have appropriate token permissions for OIDC.
• That the cloud or external identity provider must trust specific GitHub token claims.
• Why branch, environment, repository, or workflow conditions may be part of trust policy.
• How OIDC interacts with environment protection and deployment approvals.

Environments, Deployments, and Concurrency

Environment Checklist

• Use environments to represent targets such as development, staging, or production.
• Know that environments can have secrets and protection rules.
• Explain how required reviewers or approvals affect job execution.
• Use branch or tag conditions to control deployment eligibility.
• Keep deployment secrets scoped to the environment that needs them.
• Understand why production deployment jobs usually need stricter permissions than build jobs.

Example:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      id-token: write
    steps:
      - run: echo "Deploying"

Concurrency Checklist

Use concurrency when overlapping runs could waste resources, corrupt deployment state, or produce confusing results.

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true

Be ready to:

• Explain what a concurrency group does.
• Decide whether to cancel in-progress runs.
• Prevent multiple production deployments from running at the same time.
• Avoid concurrency group names that accidentally block unrelated workflows.
• Combine concurrency with environments for safer deployment workflows.

Runner Readiness

Runner Selection Table

Self-Hosted Runner Checklist

• Explain when self-hosted runners are appropriate.
• Understand label-based job routing.
• Recognize why self-hosted runners can retain state unless cleaned.
• Avoid running untrusted pull request code on sensitive self-hosted runners.
• Know that runner availability affects queued jobs.
• Consider network access, credentials, patching, and isolation.
• Use runner groups or repository access controls where appropriate.

Marketplace and Third-Party Action Readiness

Before using an action, ask:

• Who maintains it?
• Is the repository active and reviewed?
• What permissions or secrets does it need?
• Does it run arbitrary code in your workflow?
• Is it pinned to a version, tag, or commit appropriate for the risk?
• Could a built-in command or first-party action meet the need?
• Does it run before or after secrets are available?
• Does it process untrusted input?

Common exam-style distinction:

Troubleshooting Checklist

Common Symptoms and Likely Causes

Log and Debug Readiness

• Locate failed job and failed step in the workflow run.
• Expand logs and identify the first meaningful error.
• Distinguish command failure from action failure.
• Use annotations and summaries to find test or lint failures.
• Rerun failed jobs when appropriate.
• Know when debug logging may help, and why secrets must still be protected.
• Add temporary diagnostic steps without leaking sensitive values.
• Remove noisy debug output after resolving the issue.

Organization and Enterprise Governance Topics

For GH-200, be prepared for scenarios where GitHub Actions is used across teams, repositories, or an enterprise environment.

Governance Readiness Table

Admin-Style Can You Do This?

• Recommend whether a control belongs at repository, organization, or enterprise level.
• Explain how to restrict which actions can run.
• Design a secret strategy for repository, organization, and environment use.
• Explain why production secrets should not be available to every workflow.
• Choose between organization-level reusable workflows and copied workflow files.
• Identify risks of self-hosted runners shared across repositories.
• Explain how governance can improve both security and maintainability.

Scenario and Decision-Point Checks

Use these prompts to test whether you can apply features rather than just define them.

Scenario 1: Secure Pull Request Validation

A repository accepts pull requests from outside contributors. The workflow should run tests but must not expose deployment credentials.

Can you decide?

• Which event is appropriate for validation?
• Whether secrets should be available.
• Whether write permissions are needed.
• Whether third-party actions are safe before secrets are used.
• Whether the workflow should deploy from a PR run.

Scenario 2: Production Deployment

A team wants deployments only from the main branch, with approval, no overlapping production releases, and no long-lived cloud keys.

Can you design?

• Branch or ref condition.
• Production environment.
• Required review or approval concept.
• Concurrency group.
• OIDC-based authentication pattern.
• Minimal permissions for build versus deploy jobs.

Scenario 3: Shared CI Across Repositories

Multiple repositories use the same build, test, and scan process.

Can you choose?

• Reusable workflow versus composite action.
• Required inputs.
• Secret-passing model.
• Versioning strategy.
• Repository or organization governance controls.
• How to roll out updates safely.

Scenario 4: Multi-Version Testing

A project must test multiple operating systems and language versions, but deployment should happen once.

Can you configure?

• Matrix dimensions.
• OS-specific steps.
• Fail-fast behavior.
• Artifact upload per matrix leg if needed.
• A separate deployment job that depends on all test jobs.
• A condition that prevents deployment from non-release refs.

Common Weak Areas and Traps

Final-Week Review Checklist

Workflow Authoring

• Write a basic workflow from memory.
• Add branch and path filters correctly.
• Add a manual trigger with inputs.
• Use job dependencies with needs.
• Use job-level and step-level if conditions.
• Create and consume step and job outputs.
• Upload an artifact and explain when it is preferable to a cache.
• Configure a matrix and predict job expansion.
• Use concurrency for deployment safety.

Security

• Set explicit permissions.
• Explain GITHUB_TOKEN least privilege.
• Distinguish secrets, variables, and environment secrets.
• Explain OIDC at a practical level.
• Identify risks of third-party actions.
• Explain forked pull request risk.
• Choose safer action pinning strategies.
• Avoid leaking secrets through logs, outputs, artifacts, and caches.

Reuse and Action Authoring

• Define when to use workflow_call.
• Pass inputs and secrets to a reusable workflow.
• Explain reusable workflow outputs.
• Read an action.yml file.
• Distinguish composite, JavaScript, and Docker actions.
• Explain action inputs and outputs.
• Version shared workflows and actions intentionally.

Operations and Governance

• Select GitHub-hosted versus self-hosted runners.
• Troubleshoot queued jobs.
• Explain runner labels and groups conceptually.
• Use environments for gated deployments.
• Recommend organization-level policies for Actions use.
• Design a secret and variable strategy across repositories.
• Diagnose common workflow failures from logs and symptoms.

Quick “Ready or Not” Self-Test

You are likely ready for this topic area when you can answer these without notes:

• Why did this workflow not trigger?
• Which job runs first, and which jobs are skipped after a failure?
• Where should this variable, secret, or output be stored?
• Should this automation be a reusable workflow, composite action, or custom action?
• What permissions does this job actually need?
• Is this third-party action reference safe enough for the scenario?
• How would you deploy without storing long-lived cloud credentials?
• Why is this self-hosted runner job queued or risky?
• How would you prevent two production deployments from overlapping?
• What is the first log or configuration area you would inspect for this failure?

Practical Next Step

After reviewing this checklist, practice with mixed GH-200 scenarios rather than isolated definitions. For each practice question or lab, force yourself to identify the trigger, permissions, data flow, runner choice, security boundary, and likely troubleshooting path before checking the answer.