GitHub Actions (GH-200) · 17% practice allocation

GitHub GH-200: Consume and Troubleshoot Workflows Practice Questions

5 free sample questions from the Consume and Troubleshoot Workflows domain, with answers and explanations. The full GH-200 bank has 133 questions across 5 domains. Questions are scenario-based and written from the official GitHub exam guide.

Your team has enabled branch protection on the main branch and required the 'CI / build' status check to pass before merging. A pull request is blocked even though the build job succeeded. After investigation, you discover that the check name reported in the workflow is 'CI / Build' (capital B). What is the most likely cause of the merge block?

A. The workflow file must be located in the default branch for status checks to register.
B. Status checks from workflow jobs only count when the workflow is triggered by the pull_request event.
C. Required status check names are case-sensitive; 'CI / Build' does not match 'CI / build'.✓ Correct
D. The branch protection rule requires a specific GitHub App to report the check, not Actions.

Explanation

Required status check names in branch protection rules are matched case-sensitively against the check name reported by the workflow (the job name or a step's check name). 'CI / Build' and 'CI / build' are treated as different checks, so the required check never passes. — The workflow file location on the default branch affects whether the workflow runs at all, not the name matching. — pull_request is the typical trigger, but the check name mismatch is the direct cause here. — Nothing in the scenario indicates a GitHub App requirement; the issue is purely the name mismatch.

A platform team manages a large monorepo with hundreds of workflows. At the end of the billing cycle, the finance team asks for a breakdown of GitHub Actions usage. Which TWO locations in GitHub can an organization administrator use to review Actions billing minutes and storage consumption?

A. Organization Settings → Actions → General → Runner usage
B. Repository Insights → Actions tab → Usage metrics
C. Organization Settings → Billing and plans → Plans and usage✓ Correct
D. Repository Settings → Environments → Storage quota
E. The Usage Report downloadable CSV from the Billing page✓ Correct

Explanation

Organization Settings → Billing and plans shows a real-time summary of included vs. consumed Actions minutes and storage, broken down by product. The downloadable Usage Report CSV (also from the Billing page) provides a detailed per-workflow, per-repo breakdown suitable for finance reporting. — Repository Insights → Actions does not expose billing minutes or storage data; it shows run frequency and pass/fail trends. — Organization Settings → Actions → General covers runner configuration (e.g., allowed actions), not billing metrics. — Repository Settings → Environments has no storage quota display; environment settings cover protection rules and secrets.

A developer wants to manually trigger a GitHub Actions workflow and pass a custom environment name (e.g., 'staging' or 'production') as an input. Which workflow trigger and input type should they use?

A. workflow_call with an input of type string
B. workflow_dispatch with an input of type choice✓ Correct
C. repository_dispatch with a client_payload field
D. schedule with a cron expression and environment variable

Explanation

workflow_dispatch supports manual triggers and allows defining typed inputs including 'choice', which lets you specify an enumerated list of options like 'staging' and 'production'. — workflow_call is for reusable workflows called by other workflows, not manual user triggers. — repository_dispatch requires an external API call and uses client_payload, not a built-in UI input. — schedule only runs on a time-based cron schedule and does not support interactive inputs.

A workflow calls a reusable workflow defined in a different repository. The reusable workflow declares an input deploy_env (type: string, required: true) and an output release_url. The caller workflow must pass the input and use the output in a subsequent job. Which THREE statements about this cross-repository reusable workflow call are correct?

A. The reusable workflow's outputs are accessible in the caller via needs.<job_id>.outputs.<output_name>.✓ Correct
B. The uses key must reference the reusable workflow with the syntax {owner}/{repo}/.github/workflows/{file}@{ref}.✓ Correct
C. Outputs from the reusable workflow are directly available as environment variables in the caller job without any needs reference.
D. The caller workflow must be in the same organization as the reusable workflow for cross-repo calls to work.
E. If the reusable workflow uses secrets: inherit internally, the caller automatically forwards all its secrets.
F. The caller can pass deploy_env under the with key of the uses step.✓ Correct

Explanation

Cross-repo reusable workflow calls require the full {owner}/{repo}/.github/workflows/{file}@{ref} syntax (e.g., @main or @v1). — Inputs defined in the called workflow are passed via the with key in the caller, just like action inputs. — Outputs declared by the reusable workflow are surfaced to the caller through the standard needs.<job_id>.outputs.<output_name> expression, allowing downstream jobs to consume them. — Cross-repository reusable workflow calls work across organizations as long as the called workflow's repository visibility and 'Allow reuse' settings permit it; they are not restricted to the same organization. — secrets: inherit in the caller forwards the caller's secrets to the called workflow; it is a caller-side setting, not an internal setting of the reusable workflow. — Outputs are NOT automatically available as environment variables; they must be explicitly referenced via needs.

A workflow badge is embedded in the repository README using the URL format https://github.com/{owner}/{repo}/actions/workflows/{workflow_file}/badge.svg. A developer notices the badge always shows the status of the main branch run, even though they want it to show the status for the release branch. How should the badge URL be modified?

A. Create a separate workflow file named release.yml specifically for badge tracking
B. Replace badge.svg with release/badge.svg
C. Add &event=push to the query string alongside the branch parameter
D. Append ?branch=release as a query parameter to the badge URL✓ Correct

Explanation

The GitHub Actions badge URL accepts a ?branch=<branch-name> query parameter that scopes the displayed status to runs on that specific branch. Appending ?branch=release will show the latest push/workflow status for the release branch. — There is no release/badge.svg path format; the URL structure does not support branch as a path segment. — Creating a separate workflow file is unnecessary overhead and does not solve the existing badge URL issue. — &event=push is a valid additional filter but is not the primary fix; without ?branch=release first, it alone won't target the right branch.

Test yourself across every GH-200 domain

The free GH-200 practice test mixes about 20 questions weighted like the exam. The full 133-question bank adds instant grading, flashcards and a timed mock exam.

Take the free GH-200 practice test Practice the full bank

Study this domain

Consume and Troubleshoot Workflows study guide (GH-200) →

Other GH-200 domains

← All GitHub Actions study resources