Your enterprise hosts GPU self-hosted runners in a runner group restricted to selected private repositories. What happens when a workflow in a non-allowed private repo targets those runner labels?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Runner groups are ACLs: only listed repos (or all repos if configured) can consume those runners. No auto-admin, no secret ubuntu GPU fallback, and private repos are a primary use case for groups.
Full explanation below image
Full Explanation
Runner groups organize self-hosted runners and control which organizations/repositories may use them. For private repositories, administrators commonly allow only production or ML repos to access expensive GPU pools. If a workflow’s runs-on labels only match runners in a group that excludes the repository, the job will not be picked up by those runners (it sits waiting or effectively cannot start on that pool). GitHub does not silently substitute ubuntu-latest with GPU capabilities. Runner groups are especially important for private and internal repos where untrusted code should not reach privileged hardware. Combine group access controls with labels, network isolation, and ephemeral runners for defense in depth.