GH-200 — GitHub Actions Quick Review

Quick Review Focus

This independent Quick Review is for candidates preparing for GitHub’s GitHub Actions (GH-200) exam. Use it to refresh the highest-yield concepts before moving into topic drills, mock exams, original practice questions, and detailed explanations.

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.

Core Mental Model

GitHub Actions automation usually follows this path:

1. An event occurs, such as push, pull_request, workflow_dispatch, or schedule.
2. GitHub finds a matching workflow file in .github/workflows/.
3. The workflow creates one or more jobs.
4. Each job runs on a runner.
5. Each job executes steps, which either run shell commands with run or invoke actions with uses.
6. Logs, outputs, artifacts, caches, checks, deployments, and summaries are produced.

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

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.

Jobs, Steps, and Control Flow

Jobs

A job is the main execution unit in a workflow. Each job gets a runner and runs its steps in order.

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.

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.

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.

Actions, Composite Actions, and Reusable Workflows

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.

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:

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.

Artifacts, Caches, Outputs, and Data Passing

Different data-sharing mechanisms solve different problems.

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.

Concurrency

Concurrency prevents overlapping workflow runs or jobs from interfering with each other.

Review points:

• concurrency can be set at workflow or job level.
• A concurrency group allows at most one running and one pending run/job in that group.
• cancel-in-progress: true cancels the currently running item in the group.
• Group names are case-insensitive.
• Ordering of queued items is not guaranteed.

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.

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.

Self-Hosted Runner Security

Self-hosted runners are powerful because they can access internal tools and networks, but that also increases risk.

Exam decision rule: if a scenario involves private infrastructure, custom hardware, or special internal dependencies, a self-hosted runner may be the answer. If the scenario involves untrusted public contributions, self-hosted runners are often the risk to avoid.

Debugging and Observability

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:

YAML and Syntax Gotchas

GitHub Actions workflows are YAML, so small syntax mistakes can change meaning.

High-Yield Decision Rules

Use these as quick “if the question says X, think Y” rules.

Common Candidate Mistakes

Confusing Reuse Mechanisms

Misusing Security Features

Misunderstanding Data Flow

Quick Concept Check

Practice Connection

After this Quick Review, use IT Mastery practice to test whether you can choose the right GitHub Actions feature under exam-style pressure. A strong GH-200 study sequence is:

1. Start with topic drills on workflow syntax, triggers, jobs, steps, and runners.
2. Add security drills on GITHUB_TOKEN, permissions, secrets, OIDC, and pull request threat models.
3. Practice data-flow questions covering outputs, artifacts, caches, matrix jobs, and reusable workflows.
4. Use mock exams to build speed and identify weak areas.
5. Review detailed explanations for every missed or guessed question, especially when two choices seem plausible.

Next step: move into a GH-200 question bank with original practice questions, topic drills, mock exams, and detailed explanations so you can apply these rules in realistic scenarios.

Continue in IT Mastery

Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official GitHub questions, copied live-exam content, or exam dumps.