GH-200 - Consume and troubleshoot workflows (18% of the exam) - Section 2.6

Distinguish starter workflows, reusable workflows and composite actions, and contrast disabling with deleting a workflow.

Distinguish starter workflows (project scaffolds), reusable workflows (called via workflow_call), and composite actions (step-level reuse). Contrast disabling a workflow - which preserves its file and history - with deleting it.

starter versus reusablecomposite actionsdisable workflowdelete workflow

Practice question for this objective

Free sampleConsume and troubleshoot workflowsmedium

A maintainer is deciding between disabling and deleting an existing workflow and wants to record only the statements that correctly describe what GitHub does in each case. Which TWO statements accurately contrast disabling a workflow with deleting its file? Select TWO.

ADisabling a workflow from the Actions tab stops it triggering on every event, including its schedule, while keeping the workflow file and its past run history so it can later be re-enabled. Correct
BDeleting the workflow file and committing the removal stops the workflow running and removes it from the Actions tab, with its definition recoverable only from the repository's git history. Correct
CA disabled workflow disappears entirely from the Actions tab and cannot be brought back without recommitting its file, exactly as deleting the file would behave.
DDeleting the workflow file only suspends its triggers temporarily, and GitHub automatically restores the file and resumes runs once the next scheduled time arrives.

Contrast disabling, which suspends triggers while keeping the file and history, with deleting, which permanently removes the workflow from the Actions tab. Disabling a workflow halts all of its triggers, including a schedule, but leaves the file in the repository and its run history intact and visible in the Actions tab, so it can be re-enabled later. Deleting the workflow file and committing the change permanently retires it so it no longer triggers or appears in the Actions tab, and its definition survives only in git history until someone recommits it; GitHub never auto-restores a deleted workflow.

Why A is correct: Correct because disabling suspends all of a workflow's triggers without removing the file or its run history, so the maintainer can re-enable it later and resume runs from the same definition.

Why B is correct: Correct because removing and committing the workflow file retires the workflow so it no longer triggers or appears in the Actions tab, leaving its definition available only through git history.

Why C is wrong: Tempting because both stop runs, but a disabled workflow still appears in the Actions tab marked as disabled and is re-enabled from there, so it does not vanish or require recommitting the file.

Why D is wrong: Tempting because it sounds like a reversible pause, but deletion is permanent until someone recommits the file, and GitHub never restores a deleted workflow or resumes its schedule on its own.

See more GH-200 practice questions, answers explained.

Exam traps in Consume and troubleshoot workflows

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-200 bank for this domain.

A composite action is invoked at the job level with a uses key and runs as a separate job, so callers pass inputs to it under a secrets block rather than a with block.
Why it is wrong: Tempting because job-level uses and a secrets block both belong to reusable workflows, but a composite action runs as a step inside a job and receives inputs through with, not as a separate job taking secrets.
Disable the workflow from the Actions tab, because disabling stops it running permanently and removes it from the list of workflows shown in the Actions tab.
Why it is wrong: Tempting because disabling does stop a workflow from running, but a disabled workflow still appears in the Actions tab marked as disabled and can be re-enabled, so it does not retire the workflow or remove it from the list.
Publish the build logic as a starter workflow in the organisation's .github repository, so every repository inherits the same definition and stays updated as the starter workflow changes.
Why it is wrong: Tempting because starter workflows centralise a template in the .github repository, but a starter workflow is only a one-time scaffold copied into a repository when a user creates a workflow, so later edits to the template do not propagate to the copies already in the fifteen repositories.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.