GH-200 - Manage GitHub Actions for the enterprise (24% of the exam) - Section 4.1

Define and manage reusable components and workflow templates so teams across the organisation share standardised automation.

Define reusable workflow components and workflow templates in the .github repository to give teams across the organisation a consistent, standardised automation starting point. Govern which templates are visible and how they are updated.

reusable componentsworkflow templatesorganisation templatesdot-github repository

Practice question for this objective

Free sampleManage GitHub Actions for the enterprisemedium

A consuming team references an organisation reusable workflow stored at octo-org/automation in the file .github/workflows/build.yml, but their calling job fails to resolve the workflow. They are calling it with uses from another repository in the organisation. Which uses value references a reusable workflow held in a separate repository correctly?

jobs:
  call-build:
    uses: <reference>

Auses: octo-org/automation@v1, naming only the owner and repository with a git ref, on the basis that GitHub locates the single reusable workflow file inside that repository automatically.
Buses: ./.github/workflows/build.yml@v1, using a path relative to the caller with a git ref, on the basis that the leading dot-slash points GitHub at the shared workflow in the other repository.
Cuses: octo-org/automation/.github/workflows/build.yml@v1, giving the owner, repository, full path to the workflow file under .github/workflows, and a git ref after the at sign. Correct
Duses: octo-org/automation/build.yml@v1, naming the owner, repository, and workflow file name with a git ref, omitting the .github/workflows segment because GitHub assumes that directory by default.

Reference a reusable workflow in another repository using owner/repo, the full .github/workflows file path, and a git ref after the at sign. A reusable workflow in a separate repository is called with the owner and repository, the complete path to the file under .github/workflows, and a git ref after the at sign, as in octo-org/automation/.github/workflows/build.yml@v1. Action-style references that stop at the repository do not name the file, a leading dot-slash only reaches a workflow in the same repository, and omitting the .github/workflows segment leaves the path unresolved.

Why A is wrong: Tempting because action references stop at owner and repository, but a reusable workflow reference must include the full path to the specific YAML file under .github/workflows, so this resolves nothing.

Why B is wrong: Tempting because a leading dot-slash does call a reusable workflow in the same repository, but it cannot reach another repository and a local reference must not carry a git ref after the path.

Why C is correct: Calling a reusable workflow in another repository requires the owner and repository, the full path to the file under .github/workflows, and a git ref after the at sign, which this reference supplies exactly.

Why D is wrong: Tempting because the .github/workflows location feels implied, but a cross-repository reusable workflow reference must spell out the full .github/workflows path, so dropping that segment fails to resolve.

See more GH-200 practice questions, answers explained.

Exam traps in Manage GitHub Actions for the enterprise

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.

In the calling repository's Actions settings, add the reusable workflow's repository to an allow list of permitted actions so the policy stops blocking the private workflow when uses references it.
Why it is wrong: Tempting because allow lists govern which actions a repository may run, but the block here is the host repository denying access; the permission must be granted on the reusable workflow's repository, not the caller's allow list.
A repository named .github-private owned by the organisation, because private starter workflows are sourced from that dedicated repository rather than from the standard public organisation profile repository.
Why it is wrong: Tempting because .github-private exists for private profile READMEs, but starter workflows are not sourced from it; the workflow-templates directory must live in the organisation's .github repository.
A branch protection rule on the default branch of the .github repository, because only repositories that satisfy the configured protections are permitted to list and select the published template.
Why it is wrong: Tempting because branch protection governs changes to the template files, but it controls who may merge into the branch, not which repositories can see the published starter workflow in the Actions tab.

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