Consume and Troubleshoot Workflows Study Guide — GH-200

Consume Workflows

This domain tests your ability to use, configure, and monitor existing GitHub Actions workflows rather than author them from scratch. It covers how workflows are triggered manually, how they interact with branch protection, how to inspect and rerun workflow history, how to skip or filter executions, how to call reusable workflows, how to gate deployments with environments, and how to surface workflow status and billing data. At 20% of the exam, this is one of the highest-weighted domains — expect 10–12 questions directly from these topics.

Manually Triggering Workflows: workflow_dispatch

workflow_dispatch allows a workflow to be triggered manually from the GitHub UI, the GitHub CLI, or the REST API. It must be defined on the default branch (or the branch being dispatched) to appear in the Actions UI.

Inputs

Inputs are declared under on.workflow_dispatch.inputs. Each input has a defined type, an optional default, a description, and a required flag.

Key rules:

• Maximum 10 inputs per workflow_dispatch trigger.
• Input values are accessed via ${{ inputs.<name> }}.
• required: true prevents dispatch without a value; the UI enforces this.
• default is used when the input is not supplied (e.g., via API dispatch).
• The environment type input does not enforce environment protection rules — it is just a string value that happens to be filtered to environment names.

Common traps

• Confusing the environment input type with an actual deployment environment — the input type does not trigger approval gates.
• Believing workflow_dispatch can appear on any branch in the UI — it only appears on branches that contain the workflow file with the trigger.
• Forgetting that number inputs are received as strings inside the workflow; fromJSON() or numeric comparison requires casting.
• Assuming more than 10 inputs are allowed — the exam may present a scenario with 11 inputs as a distractor.

Worked scenario

Requirement: A workflow should let an operator choose a deployment target from dev, staging, or prod and set a boolean flag to run smoke tests.
Correct config: Two inputs — one choice type with options: [dev, staging, prod], one boolean type. Accessing them via ${{ inputs.environment }} and ${{ inputs.run_smoke_tests }}.

Required Status Checks: Branch Protection

Branch protection rules (classic) and rulesets (newer, GA) both support required status checks — named checks that must pass before a pull request can be merged.

Required Status Checks behavior

• The check name must exactly match the job name (or the name reported by an external check) — it is case-sensitive.
• If the workflow that provides the check never runs (e.g., path filter excludes the changed files), the check is considered pending and the merge is blocked unless you use "Require branches to be up to date" with care, or configure the check as optional.
• Bypass actors can merge without the checks passing. Bypass can be granted to: repository roles (admin, maintain, write), teams, or GitHub Apps.
• With the "strict" option enabled, the branch must be up-to-date with the base branch before merging — not just passing checks.

Common traps

• Thinking admins automatically bypass required status checks — they do not unless explicitly added as bypass actors.
• Confusing the check name (job name in YAML) with the workflow file name — the check name is the job name, not the file name.
• Assuming a skipped check (via paths filter) counts as passing — it counts as not run / pending, which blocks merge unless the check is configured to allow skipping.
• Rulesets apply at org level; branch protection rules are repo-only.