GitHub Actions Certification Exam - Learning Resources

GitHub Actions Certification Exam (GH-200) is designed for DevOps engineers, software developers, and IT professionals with intermediate-level experience in GitHub Actions, including workflow creation, automation, and CI/CD pipeline management.

This exam covers:

• Streamlining workflows
• Automating tasks
• Optimizing software pipelines

Study Notes:

• MS Learn - Automate your workflow with GitHub Actions
• GitHub Actions: Beginner to Pro

From the video "GitHub Actions: Beginner to Pro" course notes

Practice tests:

• MS Learn Practice assessment
• GHCertified (127 questions)

Video Tutorials:

5-part series, Jan 2026

Instructor: Rob Foulkrod

1. Course Introduction
2. Introduction to Actions 
3. Pipelines in GitHub Actions
4. Extending Workflows
5. Organization and Enterprise Configurations

Instructor - Sid Palas, 24 Sept 2025

Duration - 3h 42m 

Instructor - Andrew Brown, 7 May 2024

Duration - 3h 10m 

AZ-400: Design and Implement Microsoft DevOps solutions, March 2026

Instructor: Andrew Conniff

Notes

1. GitHub Actions is a CI/CD (Continuous Integration/Continuous Deployment) platform built into GitHub
2. A workflow is an automated process you define
3. An action is a reusable unit of work (like a building block) that can be used inside workflows
4. Actions can be created by GitHub, third parties, or yourself.
5. GitHub Actions offers a low barrier of entry for GitHub-hosted code: Pipelines live alongside your code; creating a workflow is as simple as committing a YAML file under .github/workflows/
6. The action.yml file is the metadata file that defines an action. It is the required configuration file that every action must have at its root directory. action.yml is the "contract" or "interface" of an action.
7. Actions’ YAML syntax is simple by design, but complex workflows can become repetitive without reusable abstractions.
8. A GitHub Actions workflow starts in response to a configured event—such as a push, pull_request, or manual workflow_dispatch.
9. name: The action's display name
10. description: What the action does
11. branding: Icon and color for the GitHub Marketplace
12. using: Defines the runtime environment
13. uses: keyword combined with workflow_call is used for sharing workflows across repositories within an organization without duplication or manual processes.
14. jobs: defines the units of work in your workflow. Each job can optionally reference an environment
15. environment:   When a job specifies an environment, GitHub checks the protection rules of that environment before running the job. If a required reviewer hasn't approved → the job pauses and waits. GitHub Environments are logical constructs for workflow protection
16. env: keyword at the top/root level of your workflow YAML file is the correct way to declare custom environment variables that are accessible across ALL jobs and ALL steps within a single workflow run.
17. runs-on is a workflow keyword that specifies which runner should execute your job.
18. runs: keyword defines how and where the action executes (Docker, Node.js, composite). 
19. run: keyword executes shell commands. The exit code of the last command in run determines if the step passed or failed. Exit codes (also called return codes or status codes) are numbers that programs return when they finish executing. 
20. inputs: keyword defines what parameters can be passed INTO the action. Think of it like function arguments in programming
21. outputs: keyword defines what data the action sends back after running. Think of it like a function's return value. Best for passing simple values like version numbers, status flags, etc.
22. main: Specifies the primary entry point file
23. pre: Specifies a script to run before the main entry point
24. continue-on-error:  keyword tells GitHub Actions what to do AFTER a step fails 
25. defaults: - set default values for properties like run
26. Workflow commands are special instructions you can write in your shell steps that GitHub Actions intercepts and processes — rather than just printing them as plain text. These commands follow a specific syntax pattern: ::command-name::command-value
27. Debug messages only appear when debug logging is explicitly enabled. To see debug messages in your workflow runs, you need to enable debug logging by setting repository secrets.
28. Contexts are special objects that contain information about workflow runs, variables, runner environments, jobs, and steps. The github.event context contains the complete webhook event payload that triggered the workflow. 
29. When something happens on GitHub (like a comment on a PR), GitHub sends a JSON package of data describing that event. This package is called the event payload. It contains ALL the details about what happened.
30. github.event contains the full event payload as an object. It is the in-memory, parsed JSON object of the event. You can directly access nested properties using dot notation -
• github.event.comment.body → The comment text
• github.event.issue.number → The pull request number
31. GitHub Actions schedules run in UTC timezone and may have delays of up to 15 minutes during high-demand periods on GitHub's servers.
32. GitHub Actions allows you to define environment variables at three different levels using the env: keyword in your YAML file: Workflow, Job & Step
33. Default environment variables are available to every step in your workflow without any configuration needed. Examples -
• GITHUB_ACTOR - Username of the person who triggered the workflow
• GITHUB_REPOSITORY - Owner and repo name (e.g., octocat/Hello-World)
• GITHUB_SHA - The commit hash that triggered the workflow
• GITHUB_WORKFLOW - Name of the workflow
• GITHUB_WORKSPACE - Path to the workspace directory
• GITHUB_EVENT_NAME - Event that triggered the workflow (e.g., push, pull_request)
• GITHUB_REF - Full ref (branch/tag) that triggered the workflow
34. GITHUB_TOKEN is a special authentication token automatically created by GitHub for each workflow run. It is temporary and expires when the workflow job completes
35. Use GITHUB_TOKEN when your workflow needs to "talk to GitHub" through its API - creating, reading, updating, or deleting GitHub resources like issues, PRs, releases, or repository content.
36. GITHUB_TOKEN is available as ${{ secrets.GITHUB_TOKEN }} or ${{ github.token }}
37. A runner is a server/machine that executes the jobs defined in your GitHub Actions workflow.
38. Two types of runners can execute GitHub Actions workflows: GitHub-hosted runners or self-hosted runners.
39. Use GitHub-hosted runners for general workflows and automation.
40. Use self-hosted runners for private repositories, enterprise workloads, performance-intensive tasks, custom environments, large workloads, or security-sensitive applications.
41. GitHub-hosted runners are available for Windows, Linux, and macOS. 
42. GitHub-hosted runners run in isolated virtual machines that reset after each job, minimizing attack surfaces.
43. Self-hosted runners persist across jobs, meaning a compromised runner can be exploited across multiple workflow runs.
44. Self-hosted runners can be configured for custom hardware, on-premises, or cloud infrastructure to supports persistent states between jobs, allowing better caching and custom dependencies.
45. You can configure self-hosted runners at the organization level. Once configured, they're automatically available to ALL repositories in the organization. Repositories can reference them using labels in their workflows. This centralizes infrastructure management.
46. GitHub-hosted runners fully support Docker. Docker comes pre-installed on Ubuntu and Windows runners
47. GitHub-hosted runners have fixed specifications:
• 2-core CPU
• 7 GB RAM
• 14 GB SSD space
48. GitHub-hosted runners support: 
• - Free tier:    20 concurrent jobs, 5 for private repos 
• - Team:         60 concurrent jobs 
• - Enterprise:  180 concurrent jobs
49. GitHub-hosted runners operate within specific IP address ranges. GitHub provides a meta API endpoint https://api.github.com/meta that lists all current IP address ranges used by GitHub services
50. An IP Allow List is a security feature in GitHub Organizations that restricts access to organization resources only from specified IP addresses. 
51. Automating the dynamically changing IP address range review process by scripting the retrieval of IP ranges from GitHub's meta API can help ensure your allowlists remain current without manual intervention.
52. Runner Labels are tags/identifiers attached to runners that help workflows find the right runner. Think of them like name tags on people at a conference.
53. Custom labels are the mechanism by which workflows identify specific runners. Labels help organize and route jobs to specific self-hosted runners based on OS, hardware, or project requirements. Think of labels like "keywords" that describe the runner
54. The 'linux' label is AUTOMATICALLY added when you register    a runner on a Linux machine - You don't need to manually add it - It's already there by default!
55. Runner groups are organizational containers for runners, primarily used for access control (which repos/workflows can use which runners). 
56. By setting the ACTIONS_STEP_DEBUG runner diagnostic variable to true, the runner provides verbose output in your workflow logs. 
57. Repository Variable like ACTIONS_STEP_DEBUG are similar to secrets, these are stored in your GitHub repository settings, but they are not encrypted. 
58. To enable runner diagnostic logs, set: ACTIONS_RUNNER_DEBUG=true
59. In GitHub Actions, environments are deployment targets (like production, staging, or development) where your code runs. Environment protection rules are safety mechanisms that control when and how deployments to these environments can happen.
60. Wait Timer creates a mandatory waiting period before a deployment can proceed. You can set a delay from 0 to 43,200 minutes (30 days).
61. The environment protection rule Required Reviewers requires specific people or teams to manually approve a deployment. You can specify up to 6 reviewers (at least one must approve). Deployment pauses until approval is given.
62. An artifact is a file or collection of files produced during a workflow run that you want to share between jobs or keep after the workflow finishes. Artifact Storage is a feature for storing build outputs (compiled code, test results, logs). 
63. GitHub Marketplace is an official catalog of pre-built Actions that you can plug directly into your workflows. A GitHub Action must live in a PUBLIC repository to be listed on GitHub Marketplace. 
64. Actions published directly by cloud providers (like AWS, Azure, Google Cloud) have a "verified creator" badge.
65. Reusable workflows allow you to call an entire workflow from another workflow, similar to calling a function in programming
66. GitHub Actions uses pre/pre-if  for defining conditional pre-execution scripts in custom action metadata files.
67. A custom action is a reusable unit of code that can be shared across workflows. The metadata file (typically action.yml or action.metadata) defines how the action behaves. They can be JavaScript actions, Docker actions, or composite actions.
68. GitHub Actions Toolkit Node.js is a collection of Node.js packages that allows you to quickly build JavaScript actions with more consistency.
69. JavaScript Action files - action.yml, index.js, node_modules, package.json, package-lock.json, and README.md.
70. GitHub Enterprise Cloud allows private actions to be shared across the organization. You can reference private actions from any repo in the same organization. Syntax: {organization}/{repository}@{ref}
71. While you CAN store Docker images in GitHub Container Registry (GHCR), they're not directly reusable as actions. The Docker image alone isn't an action—it's just a container. Docker containers package the environment with the GitHub Actions code.
72. Docker container Action files: action.yml, entrypoint.sh, Dockerfile, and README.md.
73. Composite run steps actions allow you to reuse actions by using shell scripts. You can even mix multiple shell languages within the same action. 
74. Packaged composite actions bundle multiple steps into a reusable unit. These actions are defined in a repository and can be referenced in workflows across different repositories. Packaging a composite action simplifies workflows, reduces duplication, and improves maintainability.
75. Workflow templates are pre-configured workflow files that appear as starter options in the "Actions" tab when creating new workflows. Organization admins can create templates in a public .github repository. These templates appear for ALL repositories in the organization. Helps standardize CI/CD practices across teams and simplifies onboarding and maintains consistency.
76. GitHub Secrets are encrypted environment variables stored in your repository settings. They're automatically encrypted and can only be accessed during workflow runs. Perfect for storing sensitive data like passwords, API keys, and encryption keys
77. Organization secrets must be explicitly configured with access policies. They are not directly reusable across ALL repositories by default.
78. Encrypted Secrets can store a maximum of 64 KB of data. 
79. The act CLI tool simulates the GitHub Actions environment & GitHub workflows on your local machine.