Free GitHub GH-200 Actions practice questions

10 free GitHub GH-200 Actions practice questions with the correct answer and a full explanation for each, taken from the CertStash pack of 124 questions. Work through them, then open each answer to check your reasoning.

Question 1

How should you print a debug message in your workflow?

  1. echo "::debug::Set variable myVariable to true"
  2. echo "Set variable MyVariable to true" >> $DEBUG_MESSAGE
  3. echo "::add-mask::Set variable myVariable to true"
  4. echo "debug_message=Set variable myVariable to true" >> &GITHUB_OUTPUT
Show answer and explanation

Correct answer: A. echo "::debug::Set variable myVariable to true"

GitHub Actions uses the workflow command syntax `::debug::` to print debug messages to the workflow logs. This is the standard mechanism for outputting debug-level information that appears in the runner's output when debug logging is enabled. Option A correctly formats this command with the proper syntax.

Why the other options are wrong

  • B. Writing to a $DEBUG_MESSAGE variable is not a recognized GitHub Actions mechanism for debug output.
  • C. The `::add-mask::` command is used to mask sensitive values in logs, not to print debug messages.
  • D. This syntax attempts to set an output variable, not print a debug message, and uses incorrect shell redirection syntax for GitHub Actions.

Question 2

As a developer, you are designing a workflow and need to communicate with the runner machine to set environment variables, output values used by other actions, add debug messages to the output logs, and other tasks.

Which of the following options should you use?

  1. composite run step
  2. enable debug logging
  3. self-hosted runners
  4. environment variables
  5. workflow commands
Show answer and explanation

Correct answer: E. workflow commands

Workflow commands are the designated mechanism for communicating with the GitHub Actions runner to perform tasks such as setting environment variables, outputting values for other actions, adding debug messages, and masking values. Workflow commands use the `::command::` syntax and are the standard interface for runner machine interaction.

Why the other options are wrong

  • A. Composite run steps are used to combine multiple run steps into a reusable action, not for communicating with the runner.
  • B. Debug logging is used to enable verbose output but is not the mechanism for performing these communication tasks.
  • C. Self-hosted runners are runner machines, not a communication method.
  • D. Environment variables are one tool that can be set, but workflow commands are the broader mechanism that handles all these tasks.

Question 3

When should you use the GITHUB_TOKEN in a workflow?

  1. when you want to make authenticated calls to the GitHub API
  2. when you want to connect to the runner via SSH
  3. when you want to access repository-level secrets
  4. when you want to call an action from the marketplace
Show answer and explanation

Correct answer: A. when you want to make authenticated calls to the GitHub API

GitHub API The GITHUB_TOKEN is an automatically generated authentication token provided to workflows by GitHub Actions. Its primary purpose is to enable authenticated calls to the GitHub REST API, allowing workflows to perform operations like creating issues, managing releases, or accessing repository data while maintaining proper authentication and authorization.

Why the other options are wrong

  • B. SSH connections to the runner are managed through SSH keys and runner configuration, not the GITHUB_TOKEN.
  • C. Repository-level secrets are accessed through the secrets context in workflows, not through the GITHUB_TOKEN.
  • D. Actions from the marketplace are called by reference in the workflow file; no authentication token is required to call them.

Question 4

In which of the following scenarios should you use self-hosted runners? (Each correct answer presents a complete solution.

Choose two.)

  1. when the workflow jobs must be run on Windows 10
  2. when jobs must run for longer than 6 hours
  3. when a workflow job needs to install software from the local network
  4. when GitHub Actions minutes must be used for the workflow runs
  5. when you want to use macOS runners
Show answer and explanation

Correct answer: B, C

B. when jobs must run for longer than 6 hours C. when a workflow job needs to install software from the local network Self-hosted runners should be used when jobs must run for longer than 6 hours since GitHub-hosted runners have a maximum execution time of 6 hours per job, and when a workflow job needs to install software from the local network since GitHub-hosted runners cannot access internal network resources. These scenarios represent limitations of hosted runners that self-hosted runners solve.

Why the other options are wrong

  • A. Windows 10 runners are available as GitHub-hosted runners, so there is no need for self-hosted runners for this purpose.
  • D. This describes a reason to use GitHub-hosted runners to conserve minutes, not a reason to use self-hosted runners.
  • E. macOS runners are available as GitHub-hosted runners, eliminating the need for sel-osted runners for this purpose.

Question 5

As a developer, you need to leverage Redis in your workflow.

What is the best way to use Redis on a self-hosted Linux runner without affecting future workflow runs?

  1. Install Redis on the hosted runner image and place it in a runner group. Specify label: in your job to target the runner group.
  2. Set up Redis on a separate machine and reference that instance from your job.
  3. Specify container: and services: in your job definition to leverage a Redis service container.
  4. Add a run step to your workflow, which dynamically installs and configures Redis as part of your job.
Show answer and explanation

Correct answer: C. Specify container: and services: in your job definition to leverage a Redis service container.

Using service containers with the `services:` keyword in the job definition is the best practice for leveraging Redis in workflows without affecting future runs. Service containers are ephemeral, they are created for the duration of the job and cleaned up afterward, leaving no persistent changes on the self-hosted runner. This approach isolates the workflow's dependencies and prevents side effects.

Why the other options are wrong

  • A. Installing Redis directly on the self-hosted runner image affects future workflow runs and creates persistent configuration that impacts other users.
  • B. While possible, setting up Redis on a separate machine is less isolated and harder to manage than using a containerized service.
  • D. Dynamically installing Redis in a run step works but is inefficient and still leaves potential residual configuration on the runner that could affect future runs.

Question 6

You installed specific software on a Linux self-hosted runner. You have users with workflows that need to be able to select the runner based on the identified custom software.

Which steps should you perform to prepare the runner and your users to run these workflows? (Each correct answer presents part of the solution.

Choose two.)

  1. Configure the webhook and network to enable GitHub to trigger workflow.
  2. Create the group custom-software-on-linux and move the runner into the group.
  3. Inform users to identify the runner with the labels custom-software and linux.
  4. Add the label linux to the runner.
  5. Inform users to identify the runner based on the group.
  6. Add the label custom-software to the runner.
Show answer and explanation

Correct answer: C, F

C. Inform users to identify the runner with the labels custom-software and linux. F. Add the label custom-software to the runner. To enable users to select runners based on custom software, you must add the label `custom-software` to the runner to identify it as having that software, and then inform users to identify the runner using the labels `custom-software` and `linux` in their workflow files. Labels are the mechanism for targeting specific runners with particular capabilities or configurations.

Why the other options are wrong

  • A. Webhook configuration is not necessary for users to select runners; it is used for triggering workflows based on repository events.
  • B. Runner groups are used for organizing runners and controlling access permissions, not for identifying runners by software capabilities.
  • D. While adding the linux label is helpful, the question asks for the complete solution, which also requires adding the custom-software label.
  • E. Users target runners by labels, not by runner groups, when selecting specific runners for their workflows.

Question 7

You need to trigger a workflow using the GitHub API for activity that happens outside of GitHub.

Which workflow event do you use?

  1. workflow_run
  2. deployment
  3. check_suite
  4. repository_dispatch
Show answer and explanation

Correct answer: D. repository_dispatch

The `repository_dispatch` event is designed to trigger workflows using the GitHub API for activity that happens outside of GitHub. It allows external systems to send a POST request to the GitHub API with a custom event type, enabling workflows to be triggered based on events not natively supported by GitHub Actions.

Why the other options are wrong

  • A. The `workflow_run` event triggers workflows based on the completion of another workflow, not external API calls.
  • B. The `deployment` event is triggered by deployment activity, not by external systems via the GitHub API.
  • C. The `check_suite` event is triggered by check suite activity on pull requests, not by external API calls for custom events.

Question 8

In which locations can actions be referenced by workflows? (Each correct answer presents a complete solution.

Choose three.)

  1. an .action extension file in the repository
  2. a published Docker container image on Docker Hub
  3. a public NPM registry
  4. the runs-on: keyword of a workflow file
  5. the repository’s Secrets settings page
  6. a separate public repository
  7. the same repository as the workflow
Show answer and explanation

Correct answer: B, F, G

B. a published Docker container image on Docker Hub F. a separate public repository G. the same repository as the workflow Actions can be referenced from three main locations: a published Docker container image on Docker Hub, a separate public repository on GitHub, and the same repository as the workflow. These are the standard ways workflows can consume reusable actions. Docker Hub references use the `docker://` protocol, repository references use the `owner/repo@ref` syntax, and same-repository actions use the `./path/to/action` syntax.

Why the other options are wrong

  • A. There is no `.action` file extension format for actions; actions are defined in directories with action.yml/action.yaml files or as Docker containers.
  • C. The public NPM registry is not a standard location for GitHub Actions; actions are not typically distributed through NPM.
  • D. The `runs-on:` keyword specifies the runner type for a job, not a location from which actions are referenced.
  • E. The repository's Secrets settings page is where secrets are stored for use in workflows, not where actions are referenced or located.

Question 9

Scheduled workflows run on the:

  1. specified commit and branch from the workflow YAML file.
  2. latest commit from the branch named schedule.
  3. latest commit and branch on which the workflow was triggered.
  4. latest commit from the branch named main.
  5. latest commit on the default or base branch.
Show answer and explanation

Correct answer: E. latest commit on the default or base branch.

Scheduled workflows (triggered by the `schedule` event) execute on the latest commit of the default or base branch of the repository. This is the standard behavior in GitHub Actions, scheduled jobs cannot specify arbitrary branches and always run against the repository's default branch (typically main) to ensure consistent, predictable execution.

Why the other options are wrong

  • A. Scheduled workflows do not use a branch specification in the workflow YAML; they always target the default branch.
  • B. There is no special branch named 'schedule'; this is a misunderstanding of how scheduled triggers work.
  • C. Scheduled workflows do not run on arbitrary branches where the workflow was triggered; they run on the default branch.
  • D. While the default branch is often main, the correct answer references the default or base branch generically, which is the accurate specification.

Question 10

Custom environment variables can be defined at multiple levels within a workflow file including: (Each answer presents a complete solution.

Choose three.)

  1. top level.
  2. step level.
  3. default level.
  4. runner level.
  5. job level.
  6. stage level.
Show answer and explanation

Correct answer: A, B, E

A. top level. B. step level. E. job level. Custom environment variables in GitHub Actions workflows can be defined at three levels: at the top level (affecting all jobs), at the job level (affecting all steps in that job), and at the step level (affecting only that specific step). These three hierarchical scopes allow fin-rained control over variable visibility and inheritance throughout the workflow execution.

Why the other options are wrong

  • C. There is no 'default level' for defining environment variables in GitHub Actions workflows.
  • D. Runner level is not a valid scope for defining custom environment variables in workflow files.
  • F. Stage level does not exist as a scope in GitHub Actions; workflows use jobs and steps, not stages.

That was 10 of 124.

The full GitHub GH-200 Actions pack has all 124 questions, each with the answer, the explanation and why the other options are wrong, plus a questions-only copy for timed runs. US$39, paid once, with free monthly updates and a pass-or-your-money-back guarantee.

Get the full pack