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

Configure GitHub-hosted runners and identify preinstalled software, installing additional tools at runtime when required.

Describe the available GitHub-hosted runner images and the software pre-installed via the toolcache. Install additional tools at job runtime using setup actions when a required tool version is absent from the runner image.

GitHub-hosted runnersrunner imagestoolcachesetup actions

Practice question for this objective

Free sampleManage GitHub Actions for the enterprisemedium

Before changing a workflow, an engineer wants to confirm which versions of a language runtime come preinstalled on the GitHub-hosted Ubuntu runner image so they can decide whether a setup step is even needed. What is the most reliable way to determine the preinstalled software for that image?

  • AOpen the repository Settings and read the Actions runners page, which enumerates the preinstalled tools and version numbers for every GitHub-hosted image label.
  • BRead the cache restore logs from a previous run, since the toolcache section records the complete inventory of language runtimes baked into the hosted image at build time.
  • CInspect the runner image software manifest that GitHub publishes for each hosted image, which lists the preinstalled tools and their versions for that operating system. Correct
  • DQuery the workflow run API for the runner object, whose properties field returns the preinstalled package list and version metadata for the hosted image that executed the job.
Consult the published runner image software manifest to identify the tools and versions preinstalled on a GitHub-hosted image. Each GitHub-hosted image has a software manifest published in the runner images repository that authoritatively lists preinstalled tools and their versions per operating system, which is the reliable source for deciding whether a setup step is needed. The repository Settings runners page handles self-hosted runners, cache logs show only restored paths, and the runner API object reports labels and status rather than a software inventory.

Why A is wrong: Tempting because runner configuration lives under Settings, but that page manages self-hosted runners and usage, and it does not publish the preinstalled software list for hosted images.

Why B is wrong: Tempting because the toolcache holds some runtimes, but cache logs only show what a step restored, not the full preinstalled manifest, and many tools live outside the toolcache.

Why C is correct: GitHub maintains a per-image software manifest in the runner images repository, and it authoritatively lists the preinstalled tools and versions for each hosted operating system image.

Why D is wrong: Tempting because the API exposes run details, but the runner object reports labels and status, not a preinstalled software inventory, so it cannot answer which versions ship on the image.

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 a step running apt-get install nodejs so the package manager pulls the requested Node.js release directly onto the hosted runner before the build job begins.

    Why it is wrong: Tempting because apt-get does install software, but it ignores the toolcache, may not offer the exact version, and is slower and less reproducible than the maintained setup action.

  • It silently falls back to the newest Python already preinstalled on the image, ignoring the version requested in the with block of the step.

    Why it is wrong: The action honours the requested version rather than substituting a preinstalled one, so it does not quietly ignore the pinned value.

  • GitHub silently redirects the job to the current ubuntu-latest image and the run proceeds with no warning or interruption to the team's jobs.

    Why it is wrong: GitHub does emit deprecation notices and does not silently swap a retired pinned label, so jobs relying on the old image are not transparently rerouted.

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