In GitHub Actions, what does runs-on select, and what is a hosted ubuntu-latest runner?

## The label-matching model Every job must declare where it runs. `runs-on` is that declaration, and it works by matching **labels**, never hostnames. GitHub's scheduler takes the labels in the job and dispatches the job to a runner that carries them all. ## GitHub-hosted runners `ubuntu-latest`, `windows-latest` and `macos-latest` are the standard GitHub-hosted labels. GitHub provisions, patches, and meters these machines. Three properties matter in interviews: - **Ephemerality.** Each job gets a fresh VM. There is no leakage of files, environment, or installed software between jobs or between workflow runs. This is what makes hosted runners safe to expose to pull requests from forks. - **Pre-installed tooling.** The images ship compilers, language runtimes, package managers, Docker (on Linux) and the CLI tools most builds expect. The exact inventory per image lives in the `actions/runner-images` repository, which is the honest answer to "is X installed?". - **Administrative access.** You get sudo (or administrator on Windows), so a job can install what the image lacks — at the cost of doing it again on every run, which is what `actions/cache` and container images exist to amortise. ## `-latest` versus a pinned image `ubuntu-latest` is an alias that GitHub re-points when a new LTS image is promoted. That rollover is announced but it *will* eventually change your toolchain underneath you. Pinning `ubuntu-24.04` or `macos-14` makes the change explicit: you bump the label when you are ready and you can bisect a breakage to the bump. Many teams pin on release-critical workflows and leave `-latest` on cheap ones. ## Lists mean AND ```yaml runs-on: [self-hosted, linux, x64] ``` This is not a preference order or a fallback list — the runner must carry every label. A frequent bug is listing two mutually exclusive labels, which produces a job that queues forever because no runner satisfies the set. GitHub eventually times a permanently queued job out rather than running it. ## Sizes and larger runners Standard hosted runners are modest machines. Organisations can configure **larger runners** with more vCPUs and memory, which are addressed by the custom label given at configuration time — so `runs-on:` still looks the same, only the label changes. Larger runners are billed at a higher per-minute rate, so they are a targeted tool for a genuinely parallel or memory-hungry job, not a blanket default. ## Consequence for workflow design Because each job gets its own machine, two jobs never share a filesystem. Anything one job produces that another needs must cross via artifacts, cache, or job outputs. Candidates who assume a shared working directory between `build` and `test` jobs are revealing they have only ever used a single-job workflow.