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

Consume organisation-level reusable workflows and starter workflows, including non-public templates, and customise them for a repository.

Consume organisation-level reusable workflows via workflow_call and apply starter workflows - including non-public templates - as the starting point for a repository's automation. Customise inherited templates without breaking their intended contract.

reusable workflowsstarter workflowsnon-public templatesworkflow_call

Practice question for this objective

Free sampleConsume and troubleshoot workflowsmedium

A platform engineer is comparing a starter workflow against a reusable workflow before standardising how teams share continuous integration logic. They want to record only the statements that correctly describe a starter workflow as GitHub implements it. Which TWO statements about a starter workflow are accurate? Select TWO.

  • AWhen a user creates a workflow from a starter workflow, GitHub copies the template into that repository once, and the repository then owns and may freely edit the copied file. Correct
  • BA repository consumes a starter workflow at run time by referencing it from a job-level uses key, so later edits to the template propagate to every consuming repository on the next run.
  • CStarter workflow template files live under the workflow-templates directory of the organisation's .github repository, paired with a JSON metadata file describing the template. Correct
  • DA starter workflow bundles several run steps so a single job can invoke the whole group through one step, accepting parameters through a with block at call time.
Recognise a starter workflow as a one-time template, copied from the .github repository's workflow-templates folder, that the consuming repository then owns. A starter workflow is a template stored under workflow-templates in an organisation's .github repository alongside a properties JSON file, and GitHub copies it into a repository once when a user creates a workflow from it, so the copy is owned and editable locally and never stays linked to the template. Referencing logic at run time with a job-level uses key describes a reusable workflow, and bundling steps for single-step invocation with a with block describes a composite action.

Why A is correct: Correct because a starter workflow is a scaffold that GitHub copies into the chosen repository at creation time, after which the new file belongs to and can be edited by that repository independently of the template.

Why B is wrong: Tempting because job-level uses is how reusable workflows are consumed, but a starter workflow is never referenced with uses and does not stay linked, so template edits do not propagate to repositories that already copied it.

Why C is correct: Correct because GitHub reads starter workflow templates from the workflow-templates folder in the organisation's .github repository, where each template YAML is accompanied by a properties JSON file that supplies its name and description.

Why D is wrong: Tempting because bundling steps for one-step invocation sounds reusable, but that describes a composite action, whereas a starter workflow scaffolds an entire workflow file rather than a step-level unit invoked with with.

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.

  • octo-org/platform-ci@v1, because a reusable workflow is referenced by repository and ref alone and GitHub resolves the workflow file from the repository root automatically.

    Why it is wrong: Tempting because that short owner/repo@ref shape is how a published action is referenced, but a reusable workflow needs the explicit path to the file under .github/workflows, so this form fails to resolve.

  • Fork the shared-ci repository into the caller's account and reference the workflow from the fork, because a private reusable workflow can only be consumed from a copy owned by the calling repository.

    Why it is wrong: Tempting because forking removes the cross-repository boundary, but it duplicates the shared logic and defeats reuse. Access can be granted in settings without copying the workflow into the caller's account.

  • A reusable workflow referenced through the uses key at job level, because each repository points at the central workflow and applies its own customisations through with and secrets at call time.

    Why it is wrong: Tempting because reusable workflows are the standard way to share workflow logic, but the caller never owns a local copy. The central file remains the source of truth and is not freely edited per repository.

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