GitHub Actions (GH-200) · 25% practice allocation

GitHub GH-200: Manage GitHub Actions for the Enterprise Practice Questions

5 free sample questions from the Manage GitHub Actions for the Enterprise domain, with answers and explanations. The full GH-200 bank has 133 questions across 5 domains. Questions are scenario-based and written from the official GitHub exam guide.

A DevOps engineer is configuring a self-hosted runner for a high-security pipeline. The security requirement states that each job must run on a clean, freshly provisioned instance, and the runner registration token used to register each instance must expire after a single use. Which two features should the engineer combine to satisfy these requirements? (Select TWO)

A. Register the runner with the --ephemeral flag so it de-registers after completing one job✓ Correct
B. Assign the runner to an enterprise runner group with 'Allow public repositories' disabled
C. Use the Actions REST API to generate a just-in-time (JIT) runner configuration token that is valid for a single registration✓ Correct
D. Store the runner registration token as an encrypted organization secret and rotate it weekly
E. Configure the runner as a persistent runner and use a cron job to restart the runner service after each job
F. Enable runner autoscaling using a webhook-driven scale-set and set minRunners to 0

Explanation

Options A and C are correct together. The --ephemeral flag instructs the runner application to de-register itself after processing a single job, guaranteeing a clean instance per job. Just-in-time (JIT) tokens (generated via the REST API's JIT registration endpoint) are single-use registration credentials that expire immediately after use, satisfying the requirement that tokens cannot be reused to register additional runners. Option E is wrong because restarting a persistent runner does not wipe the environment; it reuses the same OS and any leftover artifacts from previous jobs. Option B is wrong because disabling public repo access is a security policy for repo visibility, not an isolation mechanism for compute. Option F is wrong because autoscaling with minRunners=0 is a capacity management technique and does not itself enforce single-use tokens. Option D is wrong because rotating a token weekly still allows the same token to register multiple runners during that window and does not satisfy the single-use requirement.

A GitHub organization administrator creates an encrypted secret named DEPLOY_KEY at the organization level. The organization contains a mix of public and private repositories. The administrator needs to make this secret available to private and internal repositories only, explicitly excluding public repositories. Which visibility setting should the administrator choose when creating the secret?

A. Selected repositories, then manually add each private and internal repository
B. All repositories
C. No repositories, then use environment secrets in each repository instead
D. Private repositories✓ Correct

Explanation

Option D is correct. GitHub organization-level secrets have a 'Private repositories' visibility option that automatically makes the secret available to all private and internal repositories within the organization while explicitly excluding public repositories—exactly matching the requirement without needing to enumerate every repository. Option B is wrong because 'All repositories' would expose the secret to public repositories, which violates the security requirement. Option A is wrong because 'Selected repositories' would work functionally but requires manual enumeration and ongoing maintenance whenever new private/internal repositories are created, making it far less practical than the purpose-built 'Private repositories' option. Option C is wrong because environment secrets are scoped to specific deployment environments within a repository, not to organization-wide access, and would require duplicating the secret in every repository.

A workflows team wants to direct certain jobs in their CI pipeline to a specific set of self-hosted runners that have GPU hardware. The runners have been registered with the label 'gpu-enabled'. How should a workflow job be configured to exclusively target these runners?

A. Set runs-on: self-hosted and specify runner-label: gpu-enabled as a separate job property
B. Set runs-on: [self-hosted, gpu-enabled] to match only runners carrying both labels✓ Correct
C. Set runs-on: gpu-enabled without the 'self-hosted' label, since custom labels override the default
D. Set runs-on: self-hosted and add a hardware: gpu key under the job definition

Explanation

Option B is correct because GitHub Actions runner selection uses an AND logic for label arrays — a runner must carry ALL specified labels to be eligible. Including both 'self-hosted' and 'gpu-enabled' ensures the job only runs on self-hosted runners with the GPU label. Option D is wrong because hardware: gpu is not a valid workflow syntax key; there is no such job property. Option C is wrong because omitting 'self-hosted' could cause ambiguity and the label alone is not sufficient to guarantee a self-hosted runner is selected if a GitHub-hosted runner somehow carries the same label name; best practice always includes 'self-hosted'. Option A is wrong because runner-label is not a valid workflow job property in GitHub Actions syntax.

An enterprise administrator wants to enforce a mandatory security-scanning workflow across every repository in an organization, regardless of the workflows already defined in those repositories. The scanning workflow must run on every pull request and cannot be disabled at the repository level. Which GitHub Actions feature is designed specifically for this requirement?

A. A reusable workflow stored in a .github repository that all teams are instructed to call
B. A required workflow configured at the organization level that is triggered on pull_request events✓ Correct
C. A branch protection rule requiring a specific status check named after the security scan job
D. An enterprise-level Actions policy that restricts allowed actions to only the security scanning action

Explanation

Option B is correct. Required workflows (configured by organization administrators) are enforced at the organization level and will automatically run on specified events (such as pull_request) in every targeted repository without needing to be referenced in the repository's own workflow files. Repository owners cannot disable or bypass them, satisfying the enforcement requirement. Option A is wrong because a reusable workflow is a convenience tool that teams must explicitly call from their own workflows; it is opt-in and can be omitted, providing no enforcement guarantee. Option C is wrong because a branch protection status check requirement only enforces that a check must pass—it doesn't automatically inject or run a workflow; the workflow still needs to exist in the target repository. Option D is wrong because an Actions policy restricts which actions/workflows can be used, not which workflows are automatically executed across repositories.

An organization administrator needs to allow GitHub Actions workflows to use only actions authored by GitHub itself and actions published in the GitHub Marketplace by verified creators, while blocking all other third-party actions. Which setting in the organization's Actions policy should they configure?

A. Disable GitHub Actions entirely and re-enable it with an allowlist of specific action namespaces
B. Set allowed actions to 'All actions and reusable workflows'
C. Set allowed actions to 'Local actions only'
D. Set allowed actions to 'Allow GitHub-created actions and actions by verified creators'✓ Correct

Explanation

Option D is correct because GitHub provides a specific policy setting to allow only GitHub-created actions and those from Marketplace verified creators, which precisely meets the requirement. Option B is wrong because it permits all third-party actions, violating the security constraint. Option C is wrong because 'local actions only' would restrict workflows to actions defined within the organization's own repositories, breaking any use of GitHub-created actions from public repos. Option A is wrong because there is no native feature to disable and re-enable Actions with a namespace allowlist; the correct approach is the built-in 'selected actions' policy.

Test yourself across every GH-200 domain

The free GH-200 practice test mixes about 20 questions weighted like the exam. The full 133-question bank adds instant grading, flashcards and a timed mock exam.

Take the free GH-200 practice test Practice the full bank

Study this domain

Manage GitHub Actions for the Enterprise study guide (GH-200) →

Other GH-200 domains

← All GitHub Actions study resources