GitHub Actions · 15% of the exam

Manage GitHub Actions for the Enterprise: free practice questions

5 sample questions from our 21-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real GitHub exam.

1. A platform engineering team manages a self-hosted runner fleet for multiple organizations within a GitHub Enterprise. They want a subset of high-memory runners to be accessible only to the `data-engineering` and `ml-platform` organizations, while remaining hidden from all other organizations. What is the correct approach?

A. Add the high-memory runners to the default runner group, then use runner labels to restrict access within workflows
B. Create a runner group at the enterprise level, assign the high-memory runners to it, and set the group's organization access to only `data-engineering` and `ml-platform`✓ Correct
C. Create a separate runner group in each of the two organizations and register the same physical runners in both groups simultaneously
D. Set a custom label (e.g., `high-memory`) on the runners and document that only `data-engineering` and `ml-platform` should use that label in their `runs-on` key

Explanation

Option B is correct because enterprise-level runner groups are specifically designed to control which organizations can access a given set of runners. By creating an enterprise runner group and limiting its access to only the two specified organizations, the runners are invisible and inaccessible to all other organizations. Option A is wrong because the default runner group is accessible to all organizations by default, and runner labels alone do not enforce access control—any org could still reference the label. Option C is wrong because a self-hosted runner can only be registered in one location at a time; registering the same runner in two org-level groups simultaneously is not supported. Option D is wrong because labels are a targeting mechanism, not an access-control mechanism; any organization with access to the runner could use the label.

2. 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. Configure the runner as a persistent runner and use a cron job to restart the runner service after each job
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. Assign the runner to an enterprise runner group with 'Allow public repositories' disabled
E. Enable runner autoscaling using a webhook-driven scale-set and set `minRunners` to 0
F. Store the runner registration token as an encrypted organization secret and rotate it weekly

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 B 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 D is wrong because disabling public repo access is a security policy for repo visibility, not an isolation mechanism for compute. Option E is wrong because autoscaling with `minRunners=0` is a capacity management technique and does not itself enforce single-use tokens. Option F 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.

3. An enterprise administrator is reviewing GitHub Actions billing for an organization on the GitHub Team plan. A developer claims that macOS runner minutes are being exhausted much faster than Linux runner minutes despite similar job counts. Which statement best explains this behavior?

A. macOS runners have a lower per-minute rate than Linux runners, so the minute multiplier inflates costs faster
B. macOS runner minutes are multiplied by a factor of 10 compared to Linux runner minutes, causing faster consumption of the included minute allowance✓ Correct
C. macOS runners are not included in the Team plan and are billed at a flat rate per job
D. macOS runner minutes count against a separate quota that is shared with GitHub Packages storage

Explanation

Option B is correct because GitHub applies minute multipliers to non-Linux runners: macOS jobs consume minutes at 10× the rate of Linux jobs against the plan's included minute allowance, causing rapid depletion even with fewer jobs. Option A is wrong because it inverts the relationship — macOS has a higher multiplier (more expensive), not lower. Option C is wrong because macOS runners are included in Team plan minutes but with the multiplier; they are not billed at a flat rate per job. Option D is wrong because Actions minutes and GitHub Packages storage are tracked separately; macOS minutes draw from the Actions minute allowance, not a shared Packages quota.

4. An organization on GitHub's Team plan has 10 developers. At the end of the billing month, the Actions usage dashboard shows that the organization has consumed 3,200 minutes using Ubuntu GitHub-hosted runners. How many of those minutes are billable?

A. 0 minutes, because the Team plan includes unlimited minutes for GitHub-hosted runners
B. 200 minutes, because the Team plan includes 3,000 free minutes per month and Ubuntu runners are billed at a 1× multiplier✓ Correct
C. 400 minutes, because the Team plan includes 3,000 free minutes but Ubuntu runners are billed at a 2× multiplier
D. 3,200 minutes, because free minutes only apply to self-hosted runners, not GitHub-hosted runners

Explanation

Option B is correct. GitHub's Team plan includes 3,000 free Actions minutes per month, and Linux (Ubuntu) GitHub-hosted runners consume minutes at a 1× multiplier (i.e., 1 minute of run time = 1 minute deducted). The organization used 3,200 minutes, so 3,200 − 3,000 = 200 minutes are billable. Option A is wrong because the Team plan does not offer unlimited minutes; only Enterprise Cloud with certain agreements might have different terms. Option C is wrong because the 2× multiplier applies to Windows runners, not Ubuntu/Linux runners. Option D is wrong because free included minutes apply to GitHub-hosted runners, not self-hosted runners (self-hosted runners are always free with regard to per-minute charges).

5. A company uses GitHub Enterprise Cloud and has strict network security policies. After enabling an IP allowlist on their enterprise, developers report that GitHub Actions workflows using GitHub-hosted runners fail because GitHub's service cannot update commit statuses. What is the most likely cause and the correct remediation?

A. GitHub-hosted runners use dynamic IPs; the team must switch to self-hosted runners on a static IP
B. The IP allowlist is blocking inbound connections from GitHub-hosted runner IP ranges; the enterprise must add GitHub's published runner IP ranges to the allowlist✓ Correct
C. The IP allowlist affects the Actions service endpoint, not commit status APIs; a separate webhook allowlist must be configured
D. Enabling the IP allowlist automatically disables GitHub Actions; it must be re-enabled under enterprise Actions settings

Explanation

Option B is correct because when an enterprise IP allowlist is active, it restricts which IP addresses can interact with the enterprise's GitHub resources — including API calls made by GitHub-hosted runners back to GitHub.com endpoints. GitHub publishes its hosted runner IP ranges via the `meta` API endpoint, and these ranges must be explicitly added to the allowlist for runner-to-GitHub communication to succeed. Option A is wrong because switching to self-hosted runners is not required; the correct fix is allowlisting GitHub's published runner IPs, which is a supported and documented approach. Option C is wrong because there is no separate 'webhook allowlist'; the IP allowlist applies broadly and the fix is to add the runner IP ranges to the existing allowlist. Option D is wrong because enabling an IP allowlist does not disable GitHub Actions; Actions continues to function, but outbound calls from runners to GitHub APIs are blocked until the IP ranges are allowlisted.

16 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free