GH-200 — GitHub Actions (GH-200) Exam Study Plan
A practical 7-day, 14-day, 30-day, and 60/90-day study plan for the GitHub Actions (GH-200) exam.
How to use this Study Plan
This Study Plan is for candidates preparing for the GitHub GitHub Actions (GH-200) exam, code GH-200. It is built around practical workflow knowledge: reading YAML, predicting workflow behavior, choosing triggers, securing automation, troubleshooting failed runs, and understanding how GitHub Actions fits into CI/CD.
Use the plan that matches your available time. If you are close to exam day, prioritize diagnostic practice, weak-area review, and timed mocks. If you are starting earlier, build a small practice repository and test the concepts instead of only reading about them.
Which plan should you use?
| Time until exam | Best plan | Use it if | Main goal |
|---|---|---|---|
| 7 days | Final review sprint | You already studied and need structure | Close gaps, review missed questions, run timed practice |
| 14 days | Focused plan | You know basic GitHub Actions but are inconsistent | Cover high-yield areas and practice scenarios daily |
| 30 days | Balanced plan | You can study most days | Learn, lab, drill, review, and mock under time pressure |
| 60 days | Full preparation path | You are starting from limited Actions experience | Build complete workflow fluency before exam review |
| 90 days | Extended path | You are new to CI/CD or study only a few times weekly | Learn slowly, repeat labs, and add more review cycles |
What to schedule for GH-200 preparation
The GH-200 exam is about GitHub Actions, so your study time should not be only memorization. You should be able to read workflow files, reason through event behavior, identify security risks, and troubleshoot failed automation.
| Skill area | What to practice | Evidence you are ready |
|---|---|---|
| Workflow structure | name, on, jobs, steps, uses, run, with, env | You can explain what a workflow will do before running it |
| Events and triggers | push, pull_request, workflow_dispatch, schedule, workflow_call, filters | You can predict when a workflow will or will not run |
| Jobs and runners | Job dependencies, needs, runner selection, GitHub-hosted and self-hosted runners | You can choose the right runner pattern for a scenario |
| Actions and reuse | Marketplace actions, pinned actions, reusable workflows, composite actions | You can decide when to reuse, compose, or write workflow logic |
| Expressions and contexts | ${{ }}, contexts, functions, conditions, job outputs | You can trace values across steps and jobs |
| Secrets and variables | Repository, organization, environment secrets and variables | You know what belongs in secrets, variables, and environment protection |
| Permissions and security | GITHUB_TOKEN, least privilege, OIDC, forked PR risk, action pinning | You can spot unsafe workflow patterns |
| Artifacts and caching | Upload/download artifacts, dependency caching, cache keys | You can choose between artifact storage and cache reuse |
| Deployment workflows | Environments, approvals, deployment jobs, release workflows | You can design a controlled deployment workflow |
| Troubleshooting | Logs, annotations, reruns, debug logging, YAML mistakes | You can identify the likely cause of a failed run |
| Administration and governance | Repository/org Actions settings, allowed actions, runner groups | You understand common policy and control scenarios |
Daily practice rhythm
Use the same rhythm regardless of your timeline. Adjust the length, not the sequence.
If you have 45 minutes
| Time | Activity |
|---|---|
| 5 min | Review yesterday’s missed-question log |
| 15 min | Drill one narrow topic, such as triggers or permissions |
| 15 min | Read or edit one workflow example |
| 10 min | Answer practice questions and record misses |
If you have 90 minutes
| Time | Activity |
|---|---|
| 10 min | Rework missed questions without looking at answers |
| 25 min | Study one objective cluster |
| 25 min | Hands-on workflow practice in a test repository |
| 20 min | Timed question set |
| 10 min | Update weak-area list |
If you have 2 hours or more
| Time | Activity |
|---|---|
| 15 min | Missed-question review |
| 35 min | Concept review |
| 35 min | Hands-on workflow build or troubleshooting lab |
| 25 min | Timed practice set |
| 10 min | Summarize rules, traps, and YAML patterns |
Missed-question review method
Do not only mark questions as right or wrong. For GH-200, the important step is finding why your mental model failed.
Use this review table after every practice session.
| Field | What to write |
|---|---|
| Topic | Example: reusable workflows, pull_request, environments, caching |
| Question type | Syntax, security, troubleshooting, scenario choice, trigger behavior |
| Why I missed it | Misread YAML, forgot context, confused artifact/cache, guessed |
| Correct rule | One sentence in your own words |
| Proof | Link to your lab result, notes, or corrected workflow example |
| Retest date | 2 to 4 days later |
Common missed-question causes:
| Cause | Fix |
|---|---|
| Memorized syntax but cannot trace execution | Draw job order and dependencies before answering |
| Confused similar features | Make compare tables: cache vs artifact, secret vs variable, composite vs reusable workflow |
| Ignored security context | Always check event type, token permissions, secrets exposure, and fork behavior |
| Overlooked conditions | Trace if, needs, job outputs, and matrix expansion |
| Read the answer too quickly | Explain why each wrong option is wrong |
Baseline diagnostic before you start
Before choosing daily topics, take a short diagnostic set or one small timed quiz.
Do not use the diagnostic to judge whether you are “ready.” Use it to decide where to spend time.
| Diagnostic result | What it means | First adjustment |
|---|---|---|
| Weak on YAML structure | You need workflow-reading practice | Build and annotate simple workflows |
| Weak on events | You need trigger scenario drills | Compare push, pull_request, manual, schedule, and reusable triggers |
| Weak on security | You need focused security review | Study permissions, secrets, OIDC, forks, and action pinning |
| Weak on troubleshooting | You need log and failure practice | Break workflows intentionally and fix them |
| Weak across all areas | Use the 30-day or 60/90-day path | Avoid rushing straight to full mocks |
7-day final review sprint
Use this plan if your exam is one week away. It assumes you have already studied GitHub Actions and now need structured review.
Stop adding large new topics after Day 5. Days 6 and 7 are for review, confidence, timing, and error reduction.
| Day | Focus | Study actions | Output |
|---|---|---|---|
| 1 | Diagnostic and triage | Take a timed diagnostic set. Review every missed question. Sort misses by topic. | Ranked weak-area list |
| 2 | Workflow syntax and triggers | Review on, filters, manual triggers, schedules, and reusable workflow triggers. Read several YAML examples. | Trigger comparison notes |
| 3 | Jobs, runners, matrices, and reuse | Drill needs, matrix strategy, job outputs, reusable workflows, and composite actions. | Job-flow diagrams |
| 4 | Security and permissions | Review GITHUB_TOKEN, permissions, secrets, variables, OIDC, environments, forked PR risks, and action pinning. | Security checklist |
| 5 | Troubleshooting, artifacts, cache, deployments | Practice logs, reruns, failed steps, cache/artifact decisions, environment protection, and deployment patterns. | Error-pattern list |
| 6 | Timed mock and deep review | Take a full timed mock or the longest available timed set. Spend longer reviewing than testing. | Final weak-area sprint list |
| 7 | Light final review | Rework missed questions. Review notes, compare tables, and high-risk YAML patterns. Stop heavy studying early. | Exam-day checklist |
7-day priority order
If time is very limited, study in this order:
- Security and permissions.
- Trigger behavior and workflow events.
- Jobs, dependencies, matrices, and reusable workflows.
- Secrets, variables, environments, and deployments.
- Artifacts, caching, and troubleshooting.
- Administration and governance scenarios.
14-day focused plan
Use this plan if you have two weeks and can study most days. The goal is to cover the core GH-200 skills, run targeted labs, and complete at least one timed mock review cycle.
| Day | Main topic | Practice task |
|---|---|---|
| 1 | Diagnostic | Take a baseline quiz. Create a weak-area tracker. |
| 2 | Workflow anatomy | Read and write workflows with on, jobs, steps, uses, run, with, and env. |
| 3 | Events and filters | Practice trigger scenarios: branch filters, path filters, manual runs, schedules, and PR events. |
| 4 | Jobs and dependencies | Practice needs, job-level conditions, step-level conditions, and job outputs. |
| 5 | Runners | Compare GitHub-hosted and self-hosted runner scenarios, labels, groups, and security implications. |
| 6 | Actions and reuse | Review marketplace actions, version pinning, composite actions, and reusable workflows. |
| 7 | Timed checkpoint | Take a timed set. Review misses fully. Do not skip explanations for correct guesses. |
| 8 | Contexts and expressions | Drill ${{ }}, contexts, functions, status checks, environment variables, and outputs. |
| 9 | Secrets, variables, and environments | Practice deciding where data belongs and how environment protection affects deployment. |
| 10 | Permissions and secure automation | Review permissions, GITHUB_TOKEN, OIDC, forked PRs, and safe third-party action use. |
| 11 | Artifacts, cache, and packages/release workflows | Compare artifact retention use cases, dependency caching, and build output movement. |
| 12 | Troubleshooting | Review logs, annotations, reruns, debug options, skipped jobs, and common YAML failures. |
| 13 | Full timed mock or long timed set | Simulate exam timing. Flag uncertain answers. Review by topic. |
| 14 | Final review | Rework all missed questions. Review checklists. Stop adding new material. |
30-day balanced plan
Use this plan if you have about one month. It gives you enough time to learn, lab, review, and improve timing.
Week 1: Build the foundation
| Day | Focus | Actions |
|---|---|---|
| 1 | Diagnostic | Take a baseline quiz and set up your missed-question log. |
| 2 | Workflow basics | Write simple workflows with multiple jobs and steps. |
| 3 | Events | Practice common triggers and filters. Predict whether workflows run. |
| 4 | YAML reading | Annotate workflows line by line. Identify job order and conditions. |
| 5 | Runners | Study GitHub-hosted vs self-hosted runners and runner selection. |
| 6 | Mini-lab | Build a workflow that tests, builds, and uploads an artifact. |
| 7 | Review | Timed quiz plus review of all misses from the week. |
Week 2: Control flow, reuse, and data movement
| Day | Focus | Actions |
|---|---|---|
| 8 | Dependencies | Practice needs, job outputs, and conditional jobs. |
| 9 | Matrix strategy | Build a matrix workflow and reason through expansion behavior. |
| 10 | Contexts | Drill GitHub, job, steps, runner, matrix, inputs, and secrets contexts. |
| 11 | Expressions | Practice if, status functions, string checks, and expression syntax. |
| 12 | Reusable workflows | Practice workflow_call, inputs, secrets, and outputs. |
| 13 | Composite actions | Compare composite actions with reusable workflows. |
| 14 | Checkpoint | Timed set and detailed review. Update weak-area ranking. |
Week 3: Security, deployments, and governance
| Day | Focus | Actions |
|---|---|---|
| 15 | Secrets and variables | Compare repository, organization, and environment-level data use. |
| 16 | Token permissions | Practice least-privilege permissions blocks and risky defaults. |
| 17 | OIDC and cloud auth concepts | Understand when OIDC is preferable to long-lived secrets. |
| 18 | Forks and PR security | Review pull_request, pull_request_target, secret exposure, and untrusted code. |
| 19 | Environments | Practice deployment jobs, required reviewers, and environment secrets. |
| 20 | Governance | Review allowed actions, policy settings, runner controls, and audit-style scenarios. |
| 21 | Mock exam 1 | Take a timed mock. Review every miss and every guess. |
Week 4: Troubleshooting and final readiness
| Day | Focus | Actions |
|---|---|---|
| 22 | Logs and reruns | Practice reading failed runs, rerunning jobs, and locating failure causes. |
| 23 | Artifacts and cache | Compare use cases, keys, restore behavior, and build output handling. |
| 24 | Deployment/release scenarios | Trace CI/CD workflows from commit to deployment. |
| 25 | Weak-area sprint 1 | Study your two weakest topics only. |
| 26 | Weak-area sprint 2 | Rework missed questions and rebuild failed labs. |
| 27 | Mock exam 2 | Take another timed mock or long timed set. |
| 28 | Mock review | Categorize misses and update final notes. |
| 29 | Final consolidation | Review compare tables, security checklist, and trigger behavior. |
| 30 | Light review | No large new topics. Rework misses and prepare exam-day routine. |
60/90-day full preparation path
Use this path if you are starting early, are new to GitHub Actions, or need more hands-on practice.
60-day version
| Phase | Days | Goal | What to do |
|---|---|---|---|
| Foundation | 1-10 | Understand workflow structure | Learn YAML anatomy, triggers, jobs, steps, and runners |
| Core workflow behavior | 11-20 | Predict execution | Practice events, filters, conditions, dependencies, matrix jobs, and outputs |
| Reuse and maintainability | 21-28 | Organize automation | Study marketplace actions, pinned versions, reusable workflows, and composite actions |
| Security and deployment | 29-40 | Secure CI/CD | Review permissions, secrets, variables, environments, OIDC, and forked PR risks |
| Troubleshooting and governance | 41-48 | Diagnose and administer | Practice logs, reruns, skipped jobs, policy settings, runner controls, artifacts, and cache |
| Exam practice | 49-56 | Convert knowledge into exam performance | Timed question sets, mock exam, missed-question review |
| Final review | 57-60 | Stabilize | Rework misses, review checklists, stop adding new material |
90-day version
For a 90-day schedule, stretch the 60-day path and add review loops.
| Added time | How to use it |
|---|---|
| Extra 10 days | Build more workflows from scratch instead of only reading examples |
| Extra 10 days | Repeat weak topics after a one-week delay to improve retention |
| Extra 5 days | Add troubleshooting labs by intentionally breaking workflows |
| Extra 5 days | Add an additional timed mock and review cycle |
A 90-day candidate should still use the final 14 days as a focused exam-prep block. Do not let the longer timeline delay timed practice.
Hands-on practice checklist
Create a small private practice repository and build workflows that cover the common GH-200 scenarios. Keep each lab short and write down what happened.
| Lab | What to build | What to learn |
|---|---|---|
| Basic CI workflow | Run tests on push and pull request | Workflow structure and trigger behavior |
| Branch/path filters | Trigger only for selected branches or changed paths | Event filtering and skipped workflow causes |
| Matrix build | Test across multiple versions or configurations | Matrix expansion and failure behavior |
| Job dependency workflow | Build, test, then deploy using needs | Job order, outputs, and conditions |
| Artifact workflow | Upload build output and download it in another job | Artifact use cases |
| Cache workflow | Cache dependencies with a sensible key | Cache vs artifact decisions |
| Reusable workflow | Call a workflow with inputs and secrets | workflow_call behavior |
| Composite action | Move repeated shell steps into an action | Composite action purpose and limitations |
| Deployment environment | Use an environment with secrets and protection | Controlled deployments |
| Least-privilege workflow | Set explicit permissions | Secure GITHUB_TOKEN usage |
| OIDC concept lab | Review token-based cloud authentication flow | Why short-lived credentials matter |
| Troubleshooting lab | Break YAML, permissions, cache, or dependencies | Log reading and failure isolation |
Compact workflow example to study
Use small examples like this to practice reading workflow behavior. Do not memorize this file; explain each line.
name: ci
on:
pull_request:
branches:
- main
workflow_dispatch:
permissions:
contents: read
concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [18, 20]
steps:
- uses: actions/checkout@v4
- name: Set up Node
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: npm
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
Questions to ask when reviewing any workflow:
- What event starts it?
- Are branch or path filters involved?
- What token permissions are granted?
- What jobs run in parallel?
- What jobs depend on other jobs?
- Which values come from contexts, inputs, variables, or secrets?
- Could this expose secrets to untrusted code?
- What artifact, cache, or deployment state is created?
- What would you check first if it failed?
High-yield comparison tables
Cache vs artifact
| Feature | Cache | Artifact |
|---|---|---|
| Primary purpose | Reuse dependencies or generated data between runs | Preserve and share files from a workflow run |
| Common use | Package manager dependencies | Build output, reports, logs |
| Key decision | Is this reusable acceleration data? | Is this an output someone or another job needs? |
| Exam trap | Treating cache as permanent storage | Using artifacts for dependency speedup |
Secret vs variable
| Feature | Secret | Variable |
|---|---|---|
| Use for | Sensitive values | Non-sensitive configuration |
| Example | Token, password, private key | Region name, feature flag, environment label |
| Exam trap | Putting sensitive data in variables | Using secrets for ordinary configuration |
Composite action vs reusable workflow
| Feature | Composite action | Reusable workflow |
|---|---|---|
| Best for | Reusing step logic | Reusing job or workflow patterns |
| Called with | uses as a step | workflow_call from a workflow |
| Scope | Steps | Jobs/workflow |
| Exam trap | Expecting a composite action to replace full workflow orchestration | Using reusable workflows for small repeated shell steps |
pull_request vs pull_request_target
| Event | Runs in context of | Security note |
|---|---|---|
pull_request | Pull request code and event context | Safer default for untrusted contributions, but secrets may be limited |
pull_request_target | Base repository context | Requires caution because it can access more privileged context |
For exam scenarios, always ask whether code is trusted before choosing an event or granting secrets.
Timed mock exam strategy
Timed practice should start earlier than the final week. Waiting too long hides pacing and question-reading problems.
| Timeline | When to use timed mocks | How to review |
|---|---|---|
| 7-day plan | Day 1 diagnostic and Day 6 mock | Spend more time reviewing than testing |
| 14-day plan | Day 7 checkpoint and Day 13 mock | Track misses by topic and cause |
| 30-day plan | Days 21 and 27, with shorter timed sets weekly | Compare first-mock and second-mock weak areas |
| 60/90-day plan | After core content, then weekly near the end | Use mocks to guide final sprints |
During a timed mock:
- Answer easier questions first if the platform allows navigation.
- Flag questions where two options seem plausible.
- Do not change answers unless you find a specific reason.
- After the mock, review:
- wrong answers,
- correct guesses,
- slow questions,
- questions missed because of wording.
Troubleshooting review checklist
GH-200 candidates should be comfortable diagnosing why a workflow did not behave as expected.
| Symptom | What to check |
|---|---|
| Workflow did not start | Event name, branch filters, path filters, workflow file location, disabled workflow |
| Job skipped | if condition, needs result, event context, matrix include/exclude |
| Step failed | Command exit code, missing dependency, working directory, permissions |
| Secret unavailable | Event type, fork behavior, environment protection, secret scope |
| Permission denied | permissions block, token scope, repository settings, organization policy |
| Cache miss | Cache key, restore keys, dependency file changes, OS differences |
| Artifact missing | Upload step result, artifact name, job boundary, retention assumptions |
| Reusable workflow failed | Inputs, secrets mapping, caller/callee permissions, output references |
| Deployment blocked | Environment rules, required reviewers, branch restrictions, secret availability |
Useful GitHub CLI commands for hands-on review, if you use the GitHub CLI:
gh workflow list
gh workflow run ci.yml
gh run list
gh run view --log
gh run rerun
Security review checklist
Security is a major practical theme in GitHub Actions preparation. Review it repeatedly.
| Area | Questions to ask |
|---|---|
| Token permissions | Is GITHUB_TOKEN limited to the permissions the job needs? |
| Third-party actions | Is the action from a trusted source and pinned appropriately? |
| Secrets | Are secrets only available to trusted workflows and environments? |
| Forked pull requests | Could untrusted code access sensitive data or privileged tokens? |
| OIDC | Could short-lived identity-based credentials replace stored cloud secrets? |
| Self-hosted runners | Could untrusted code persist or access sensitive resources on the runner? |
| Environments | Are approvals and environment-specific secrets used for deployments? |
| Logs | Could scripts accidentally print secrets or sensitive values? |
When to stop adding new material
| Time left | Rule |
|---|---|
| 14+ days | You can still add new topics, but test them with practice questions |
| 7 days | Add only high-yield topics tied to missed questions |
| 3 days | Stop broad new learning; focus on weak-area repair |
| 24 hours | Light review only; no full new labs or deep documentation dives |
The final days should improve accuracy, not create new confusion.
Final-week rules
Use these rules during the last week for any timeline.
- Review missed questions every day.
- Rework questions before reading the explanation.
- Keep a one-page list of:
- trigger rules,
- security traps,
- reusable workflow patterns,
- cache vs artifact differences,
- troubleshooting checks.
- Do at least one timed session under realistic conditions.
- Do not judge readiness only by raw score; inspect whether misses are repeated or isolated.
- Sleep and pacing matter. Avoid a late-night cram session before the exam.
Exam-readiness checks
You are in a good position for the GitHub Actions (GH-200) exam when you can do the following without relying on notes.
| Readiness check | Yes/No |
|---|---|
| I can read a workflow YAML file and predict when it runs. | |
I can explain job order, needs, conditions, and matrix behavior. | |
| I can compare artifacts, caches, variables, secrets, and environments. | |
| I can identify risky use of secrets, tokens, fork events, and third-party actions. | |
| I can choose between composite actions and reusable workflows. | |
| I can troubleshoot common workflow failures from logs and symptoms. | |
| I can answer timed scenario questions without rushing or rereading excessively. | |
| My missed-question log shows fewer repeated errors in my weakest topics. |
Practical next step
Choose the schedule that matches your exam date, take a diagnostic practice set, and build your weak-area list today. Then study in short daily cycles: review misses, practice one GitHub Actions topic, complete hands-on workflow work, and finish with timed questions.