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

Apply IP allow lists and networking settings to runners and troubleshoot runner connectivity and capacity issues.

Apply IP allow list rules and networking settings to control outbound traffic from runners to protected resources. Troubleshoot runner connectivity failures and capacity issues by reviewing runner diagnostic logs and queue depth.

IP allow listrunner networkingrunner troubleshootingrunner capacity

Practice question for this objective

Free sampleManage GitHub Actions for the enterprisemedium

A self-hosted runner sits inside a corporate network where all outbound HTTPS traffic must pass through an authenticated forward proxy. After registration the runner cannot reach GitHub and stays offline because its connections are not routed through that proxy. The administrator wants the runner application to send its traffic through the proxy without rewriting any workflow. Which configuration directs the runner's outbound connections through the proxy?

# in the runner's .env file
https_proxy=proxy.internal:8080
no_proxy=localhost,127.0.0.1

ASet the proxy environment variables such as https_proxy and no_proxy for the runner, because the runner application reads them to route its outbound connections through the forward proxy. Correct
BAdd a runs-on label named proxy to every job, because that label instructs GitHub to route the dispatched job through the organisation's configured forward proxy before it reaches the runner.
CAdd a concurrency group to the workflow named proxy, because grouping the runs causes GitHub Actions to funnel the queued jobs through a single proxied connection to the offline runner.
DStore the proxy address as an organisation secret and reference it in each job, because the runner reads that secret at startup and applies it as its outbound network route automatically.

Route a self-hosted runner's outbound traffic through a corporate proxy by setting the runner's proxy environment variables such as https_proxy and no_proxy. A self-hosted runner honours the conventional proxy environment variables, so providing https_proxy for its outbound HTTPS and no_proxy for local exemptions, typically in its .env file or service environment, makes the runner application connect to GitHub through the forward proxy. Job labels, concurrency groups, and secrets affect dispatch, scheduling, or job-time configuration respectively, none of which controls how the runner service itself reaches GitHub before any job starts.

Why A is correct: The self-hosted runner reads the standard proxy environment variables, so defining https_proxy and no_proxy for the runner sends its outbound traffic through the forward proxy while exempting local addresses.

Why B is wrong: Tempting because labels do steer dispatch, but a label only matches a runner to a job and carries no proxy routing, so the runner's own outbound traffic still bypasses the proxy and fails.

Why C is wrong: Tempting because concurrency governs run scheduling, but it only queues or cancels runs in a group and has nothing to do with how the runner reaches GitHub over the network.

Why D is wrong: Tempting because secrets hold sensitive configuration, but a secret is only injected into a running job's environment, not into the runner service before it connects, so registration still fails.

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.

Add the published IP address ranges for GitHub-hosted runners to the organisation's IP allow list manually, because the runner egress addresses are fixed values that an administrator copies into the list once.
Why it is wrong: Tempting because hosted runner ranges are documented, but they change frequently and are large, so a one-off manual copy quickly goes stale and breaks again. GitHub provides an automatic option rather than expecting a static manual entry.
Set runs-on to ubuntu-latest and add a strategy.max-parallel value, so the scheduler allocates extra CPU and memory to the standard image while the larger jobs run.
Why it is wrong: Tempting because it tunes the matrix, but max-parallel only limits how many jobs run at once and never changes the hardware size of a standard hosted runner image.
Raise the strategy max-parallel value on the matrix, because that key controls how many jobs a single self-hosted runner accepts and processes at the same time on one machine.
Why it is wrong: Tempting because max-parallel does bound matrix concurrency, but it only caps how many jobs may run, not how many a single runner can host, so one runner still serialises them.

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