SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
GH-200 · Domain 4

Manage GitHub Actions for the enterprise practice questions

Manage GitHub Actions for the enterprise is worth 24% of the GH-200 exam — the heaviest of the 5 domains. Actions at organization and enterprise scale: governance policies and reusable components, GitHub-hosted and self-hosted runners and runner groups, networking, and secrets and variables at every scope. Official weight range 20–25%. 6 fully worked examples are further down this page, answers included.

Exam weight
24%
the heaviest of the 5 domains
Questions
92
across 2 topics
Free, no account
5/day
a free account allows 30 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 5 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Manage GitHub Actions for the enterprise questions, fully explained

Questions from the GH-200 bank mapped to domain 4, with the answer key and the reasoning behind every option. None of them repeat the examples on the main GH-200 practice page.

Question 1Manage GitHub Actions for the enterprise

An enterprise owner set the enterprise policy to allow only enterprise actions and reusable workflows. Now every workflow that uses actions/checkout fails at job setup. Teams otherwise use only actions stored in enterprise repositories. The owner must keep third-party actions blocked and must not maintain copies of GitHub's actions. What should the owner do?

Choose one.

  • a
    Ask each organization owner to add actions/checkout@* and the other GitHub actions to the organization's allowed list

    An organization cannot allow what the enterprise policy blocks; the enterprise setting limits every organization under it.

  • b
    Change the enterprise policy to allow enterprise and select non-enterprise actions, and check "Allow actions created by GitHub" Correct

    This keeps every third-party publisher blocked while admitting the actions in the actions and github organizations, with no copies to maintain.

  • c
    Fork GitHub's actions/checkout repository into an enterprise organization and point the workflows at that fork

    A fork is an enterprise action and would run, but it is a copy of GitHub's action that someone must keep updated, which the owner must avoid.

  • d
    Enable the policy that requires GitHub and third-party actions to be pinned to a full-length commit SHA

    Pinning changes how an action is referenced. It does not change which publishers the allowed-actions policy accepts.

The concept

An enterprise-level allowed-actions policy limits every organization; the enterprise-only setting blocks GitHub-authored actions.

Why that’s the answer

GitHub documents that the enterprise-only option also blocks actions such as actions/checkout. The fix is at the enterprise level: switch to the select policy and admit actions created by GitHub. Organizations cannot loosen an enforced enterprise policy, pinning does not change the source rules, and forking works but creates copies to maintain.

How to reason it out
  1. Recognise that the enterprise-only option blocks GitHub-authored actions.
  2. Remember that organizations cannot override an enterprise restriction.
  3. Reject forking because of the no-copies constraint.
  4. Switch the enterprise to the select policy with GitHub-created actions allowed.

Exam tip: Fix a too-strict enterprise policy at the enterprise; organizations cannot loosen it.

Govern GitHub Actions in the Enterprise: Policies, Templates, Secrets and Variables (GH-200) — the lesson that teaches this.

Question 2Manage GitHub Actions for the enterprise

An organization uses the policy that allows its own actions plus a specified list of others. Its workflows must be able to call the reusable workflow deploy.yml stored in the .github/workflows directory of platform-org/pipelines, a public repository in another organization, at any tag or commit. Which entry should be added to the list?

Choose one.

  • a
    platform-org/pipelines/.github/workflows/deploy.yml@* Correct

    Reusable workflows are listed as OWNER/REPOSITORY/PATH/FILENAME@ref, and the * wildcard after @ matches every tag, branch and SHA.

  • b
    platform-org/pipelines/.github/workflows/deploy.yml@main

    This matches only calls that reference main, so calls pinned to a tag or SHA would still be refused.

  • c
    platform-org/pipelines/deploy.yml@*

    The pattern omits the .github/workflows path, so it does not identify the workflow file that callers reference.

  • d
    !platform-org/pipelines/.github/workflows/deploy.yml@*

    The ! prefix blocks a match instead of allowing it, which is the opposite of the requirement.

The concept

Specified-list entries name actions as OWNER/REPOSITORY@ref and reusable workflows as OWNER/REPOSITORY/PATH/FILENAME@ref.

Why that’s the answer

The list accepts the full path to a reusable workflow file, and * is a wildcard, so @* matches any reference. A fixed @main is too narrow, a pattern without the path does not match the workflow file, and a leading ! turns the entry into a block.

How to reason it out
  1. Identify the item as a reusable workflow, which needs the file path.
  2. Write OWNER/REPOSITORY/.github/workflows/FILENAME.
  3. Use @* because any tag or commit must be accepted.
  4. Make sure the entry has no ! prefix.

Exam tip: Reusable workflow entries include the file path; @* matches every ref; ! blocks.

Govern GitHub Actions in the Enterprise: Policies, Templates, Secrets and Variables (GH-200) — the lesson that teaches this.

Question 3Manage GitHub Actions for the enterprise

An organization is set to allow all actions and reusable workflows. Security reports that every version of the Marketplace action acme/lint-action is compromised. It must be blocked today, while all other actions keep working and nobody has to list the hundreds of actions teams already use. What should an organization owner configure?

Choose one.

  • a
    Keep the current open policy and add !acme/lint-action@* to the organization's list of blocked actions and reusable workflows

    The allow-all policy has no list to edit; allow and block entries exist only under the policy that allows selected non-organization actions.

  • b
    Switch to the policy that allows selected non-organization actions and check just the option for verified Marketplace creators

    This would block every unverified action that teams use today, and it would still allow acme/lint-action if its publisher is verified.

  • c
    Switch to the policy that allows selected non-organization actions and enter *, !acme/lint-action@* as the specified list Correct

    The specified list supports a * wildcard to allow everything and a ! prefix to block a match, so this allows every action except all versions of acme/lint-action.

  • d
    Keep the current open policy and require actions to be pinned to full-length commit SHAs so the compromised tags stop resolving

    Pinning rejects tag references but still allows any SHA of the compromised action, including a malicious commit.

The concept

Blocking a single action means using the select policy with a specified list that combines a * wildcard and a ! entry.

Why that’s the answer

Two facts combine here. First, allow and block entries exist only under the policy that allows selected non-organization actions; the allow-all policy has no list. Second, the list accepts * and ! patterns, so "*, !acme/lint-action@*" keeps everything else working without enumerating it. Verified-creator filtering changes far more than one action, and SHA pinning does not stop a pinned malicious commit.

How to reason it out
  1. Note that allow-all offers no per-action control.
  2. Switch to the select policy, which exposes the specified list.
  3. Allow everything with * so existing workflows keep running.
  4. Block every version with !acme/lint-action@*.

Exam tip: To deny one action and allow the rest: select policy + "*, !owner/repo@*".

Govern GitHub Actions in the Enterprise: Policies, Templates, Secrets and Variables (GH-200) — the lesson that teaches this.

Question 4Manage GitHub Actions for the enterprise

The contoso organization uses the policy "Allow contoso, and select non-contoso, actions and reusable workflows". Only "Allow actions created by GitHub" is checked, and the specified list is empty. In a contoso repository, which TWO uses: references can still run? (Select TWO.)

Choose TWO.

  • a
    uses: ./tools/setup Correct

    Policies never restrict local actions referenced with a ./ path from the repository.

  • b
    uses: docker/login-action@v3

    Docker is a verified Marketplace creator, but that sub-option is not checked, so its actions are blocked.

  • c
    uses: actions/setup-node@v4 Correct

    actions/setup-node is in the actions organization, which "Allow actions created by GitHub" admits.

  • d
    uses: octo-labs/actions/setup-ruby@v1

    A repository named actions in a third-party organization is not created by GitHub; only the actions and github organizations are.

  • e
    uses: hashicorp/setup-terraform@v3

    HashiCorp actions are third-party; without the verified-creator option or a list entry they are blocked.

The concept

Under the select policy, the organization's own and local actions are allowed, plus whatever the checked sub-options and list admit.

Why that’s the answer

Local actions (./ paths) are never restricted by the policy, and "Allow actions created by GitHub" admits the actions and github organizations, which include actions/setup-node. Docker and HashiCorp actions, and the third-party octo-labs/actions repository, would need the verified-creator option or an explicit list entry.

How to reason it out
  1. Allow local ./ actions, which policies never restrict.
  2. Allow actions in the actions and github organizations.
  3. Check the verified-creator option: it is off.
  4. Check the specified list: it is empty, so third-party actions are blocked.

Exam tip: "Created by GitHub" means the actions and github organizations only, not verified partners.

Govern GitHub Actions in the Enterprise: Policies, Templates, Secrets and Variables (GH-200) — the lesson that teaches this.

Question 5Manage GitHub Actions for the enterprise

After a widely used action had its tags moved to malicious code, a security team wants GitHub to refuse any workflow in the organization that references an action by a tag or branch name instead of an immutable commit. Which organization setting provides this?

Choose one.

  • a
    Allow Marketplace actions by verified creators

    This filters actions by publisher. Tags of an allowed action could still be moved to different code.

  • b
    Require actions to be pinned to a full-length commit SHA Correct

    This policy makes runs fail when an action is referenced by anything other than a full commit SHA.

  • c
    Enable immutable releases for the organization's repositories

    Immutable releases protect releases published from the organization's own repositories, not how its workflows reference other actions.

  • d
    Set the default GITHUB_TOKEN permission to read contents

    This limits what the token can do in a run; it does not control how actions are referenced.

The concept

Organizations and enterprises can require actions to be pinned to a full-length commit SHA.

Why that’s the answer

A commit SHA cannot be moved like a tag or branch, so requiring full-length SHAs closes the moved-tag attack. GitHub enforces it as a policy setting. Publisher filtering, immutable releases for your own repositories and token permissions address different risks.

How to reason it out
  1. Identify the risk: mutable tag and branch references.
  2. Look for a control on the reference format in workflows.
  3. Choose the full-length commit SHA pinning policy.

Exam tip: The SHA-pinning policy enforces immutable action references across the organization.

Govern GitHub Actions in the Enterprise: Policies, Templates, Secrets and Variables (GH-200) — the lesson that teaches this.

Question 6Manage GitHub Actions for the enterprise

An organization enables "Require actions to be pinned to a full-length commit SHA". This workflow is in one of its repositories.jobs: build: uses: contoso/pipelines/.github/workflows/build.yml@v2 test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: ./.github/actions/lintWhich references must be changed to comply with the policy?

Choose one.

  • a
    Only the actions/checkout@v4 action reference in the second job Correct

    The policy applies to actions, including GitHub-authored ones. Reusable workflows may still be referenced by tag, and local actions have no ref to pin.

  • b
    Only the build.yml@v2 reusable workflow call in the build job

    GitHub states that reusable workflows can still be referenced by tag under this policy.

  • c
    Both actions/checkout@v4 and the build.yml@v2 workflow call

    The reusable workflow call is exempt; only the action reference needs a SHA.

  • d
    All three, including the local ./.github/actions/lint path

    Local actions are referenced by path in the same repository and are not restricted by Actions policies.

The concept

The SHA-pinning policy covers actions (including GitHub-authored ones) but not reusable workflow calls or local actions.

Why that’s the answer

Two exemptions decide this. Reusable workflows can still be referenced by tag when the policy is on, and policies never restrict local actions referenced with ./. That leaves actions/checkout@v4, which must become actions/checkout@<40-character SHA>.

How to reason it out
  1. Classify each reference: reusable workflow, remote action, local action.
  2. Apply the policy to remote actions, including those created by GitHub.
  3. Exempt the reusable workflow, which may keep its tag.
  4. Exempt the local ./ action.

Exam tip: SHA pinning policy: remote actions yes; reusable workflows and ./ actions no.

Govern GitHub Actions in the Enterprise: Policies, Templates, Secrets and Variables (GH-200) — the lesson that teaches this.

What GH-200 domain 4 tests, topic by topic

The official exam guide breaks Manage GitHub Actions for the enterprise into 2 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published GH-200 practice questions per topic in Manage GitHub Actions for the enterprise
TopicWhat it coversQuestions
Govern actions, workflows, secrets and variablesOfficial GH-200 study guide, "Manage GitHub Actions for the enterprise" (skills measured as of January 2026). "Distribute and govern actions and workflows": Define and manage reusable components and templates; Control access to actions and workflows within the enterprise; Configure organizational use policies. "Manage encrypted secrets and variables": Define and scope encrypted secrets and variables at the organization, repository, and environment levels; Access and use secrets and variables in workflows and actions; manage secrets and variables programmatically via REST APIs.46
Manage runners at scaleOfficial GH-200 study guide, "Manage GitHub Actions for the enterprise" (skills measured as of January 2026). "Manage runners at scale": Configure and monitor GitHub-hosted and self-hosted runners; Apply IP allow lists and networking settings; Manage runner groups and troubleshoot runner issues; Identify preinstalled software/tool versions on GitHub-hosted runners (image release notes, toolcache) and install additional software at runtime (setup-* actions, package managers, caching, container images, custom self-hosted images).46
Total92

Revise Manage GitHub Actions for the enterprise before you drill it

Govern GitHub Actions in the Enterprise: Policies, Templates, Secrets and Variables (GH-200)Expect scenario items that describe an enterprise or organization requirement — who may run workflows, which publishers are acceptable, a compromised action, a moved tag — and ask which enablement, allowed-actions, pattern or pinning setting meets it, often with YAML showing which references comply. Token and fork items describe a failing release job, a 403 when opening a pull request, or contractors working from forks, and ask which setting or permissions key resolves it. Distribution items contrast workflow templates, Access sharing for private and internal repositories and ruleset-required workflows, including visibility rules, ignored filters and why a required workflow never starts. Secret and variable items show values at several scopes and ask which one a job receives, why a value is empty (plan, access policy, the 100-secret window, a missing environment key, naming rules) or where a credential should live, and REST or GitHub CLI items ask for the request or command that creates, updates or shares a value under constraints such as one rotation point or not resending the value.Manage GitHub Actions Runners at Scale: Self-Hosted, Larger Runners and Runner Groups (GH-200)Questions on this topic are usually scenarios with one deciding constraint: a job that must reach exactly one kind of machine, runners that must be reserved for certain repositories or workflows, a firewall or IP allow list that must stay in place, a requirement for clean machines or no servers to maintain, or a tool version that must not drift. Options are concrete artefacts such as runs-on values, config.sh flags, .env lines, service commands, runner group settings and setup-action inputs, and the wrong ones are real features used in the wrong place: labels where a group is needed, repository access where workflow access is needed, usage metrics where performance metrics are needed, the job-completed hook where an ephemeral runner is needed, or static IP ranges where private networking is needed. Expect troubleshooting items that start from a symptom (Offline, waiting for a runner, permission denied on the Docker socket, a build broken by an image update) and ask for the cause or the evidence to collect.

Other GH-200 domains

Domain 1: Author and manage workflows24% of the exam · 92 questionsDomain 2: Consume and troubleshoot workflows19% of the exam · 71 questionsDomain 3: Author and maintain actions18% of the exam · 71 questionsAll GH-200 practice questionsMixed sessions across all 5 domains — the way the real exam interleaves them.

Manage GitHub Actions for the enterprise: your questions

Manage GitHub Actions for the enterprise is domain 4 of the GH-200 exam guide and carries 24% of the scored content — the heaviest of the 5 domains. On a 60-question paper that works out to roughly 14 questions, though GitHub does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official GH-200 exam guide.