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

Control access to actions and workflows and configure organisation use policies that restrict which actions may run.

Configure organisation-level GitHub Actions permissions and set an allowed actions policy to restrict which actions repositories may use. Distinguish between policies set at the enterprise, organisation, and repository level and how they interact.

actions permissionsallowed actions policyorganisation policyusage restrictions

Practice question for this objective

Free sampleManage GitHub Actions for the enterprisehard

An organisation has set Actions permissions to Allow specified actions and reusable workflows with a short allow list of approved third-party actions. A repository in the organisation defines its own composite action in .github/actions/build and references it from a workflow with a relative path. The team asks whether they must add this internal action to the organisation allow list for the workflow to run. Which statement is accurate?

AActions defined within the same repository as the calling workflow are always permitted regardless of the allowed actions policy, so the internal composite action runs without any allow-list entry. Correct
BThe internal action must be added to the allow list using its owner/repo path, because the select policy evaluates every uses reference identically whether the action is local or fetched from elsewhere.
CThe workflow must switch to Allow <org> actions and reusable workflows first, because only that policy recognises actions stored inside the organisation's own repositories as trusted internal code.
DThe team must publish the composite action to GitHub Marketplace and enable the verified creators toggle, because the select policy resolves internal actions only through their Marketplace listing.

Recognise that actions within the calling repository are exempt from the allowed actions policy and need no allow-list entry. The allowed actions policy screens references to actions and reusable workflows that come from outside the calling repository, but actions stored in the same repository as the workflow are always allowed regardless of which policy is selected. A relative-path composite action therefore runs under the select policy without any allow-list entry, so there is no need to list it, change the whole policy, or publish it to Marketplace.

Why A is correct: GitHub exempts actions that live in the same repository as the workflow from the allowed actions policy, so a relative-path internal action runs even under the select policy with no allow-list entry needed.

Why B is wrong: Tempting because the policy does screen uses references, but same-repository actions are exempt, so requiring an allow-list entry for a local action misreads how the select policy treats internal code.

Why C is wrong: Tempting because that policy name mentions organisation actions, but the select policy already permits same-repository actions, so changing the whole policy to run one local action is unnecessary.

Why D is wrong: Tempting because Marketplace and toggles relate to permitted sources, but a same-repository action needs no Marketplace listing, and the verified-creator toggle has no bearing on local internal code.

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.

Leave the runner group available to all repositories but disable the organisation's default group, because new repositories inherit access only from the default group and not from any group created later.
Why it is wrong: Tempting because a default group exists, but a group set to all repositories grants access to every repository including new ones. Disabling the default group does not change a separate group that is already open to all repositories.
Leave the allow list empty and rely on the organisation-owned scope, because actions published to GitHub Marketplace are trusted by default once any non-enterprise option is selected.
Why it is wrong: Tempting because the policy name mentions non-enterprise actions, but the select option grants nothing extra until patterns are entered, so an empty list blocks every third-party action rather than permitting the curated set.
Set repository access to Private repositories, then individually convert each experimental repository to public so it falls outside the secret's reach without further per-secret edits.
Why it is wrong: Tempting because the Private option scopes by visibility, but flipping repositories to public to dodge a secret changes their security posture broadly and is a clumsy, error-prone way to exclude a few repositories.

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