GitHub Actions · 20% of the exam

Consume Workflows: free practice questions

5 sample questions from our 24-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real GitHub exam.

1. 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 `uses` key must reference the reusable workflow with the syntax `{owner}/{repo}/.github/workflows/{file}@{ref}`.✓ Correct
B. The caller can pass `deploy_env` under the `with` key of the `uses` step.✓ Correct
C. The reusable workflow's outputs are accessible in the caller via `needs.<job_id>.outputs.<output_name>`.✓ Correct
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. Outputs from the reusable workflow are directly available as environment variables in the caller job without any `needs` reference.

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`.

2. An engineering team wants to view a high-level summary of a completed workflow run — including a custom table of test results that was written by a step — without having to download or scroll through the full raw logs. Where should they look?

A. The workflow run's 'Annotations' panel in the pull request Checks tab
B. The workflow run summary page, accessible via the 'Summary' link in the left sidebar of the run details view✓ Correct
C. The repository's Actions tab filtered by workflow name, then expanding the job logs for each step
D. The repository Insights tab under the 'Actions' section

Explanation

The workflow run summary page (written to via `$GITHUB_STEP_SUMMARY`) is the correct place to view custom Markdown content, tables, and other structured output generated by steps. It is accessed through the 'Summary' link in the run details sidebar. Option A is wrong; annotations appear in the PR Checks tab but are limited to notice/warning/error annotations and cannot contain arbitrary Markdown tables. Option C is wrong; job logs show raw step output, not the rendered summary. Option D is wrong; the Insights tab provides aggregate usage metrics, not per-run custom summaries.

3. A caller workflow in repository `org/app` wants to call a reusable workflow located at `.github/workflows/build.yml` in the same repository. The reusable workflow declares `on: workflow_call`. Which `uses` value is correct in the caller workflow?

A. `uses: .github/workflows/build.yml`✓ Correct
B. `uses: org/app/.github/workflows/build.yml@main`
C. `uses: workflow_call:.github/workflows/build.yml`
D. `uses: ./build.yml`

Explanation

When calling a reusable workflow within the same repository, the correct syntax uses a relative path starting with `./` — specifically `.github/workflows/build.yml` (note: the leading `.` refers to the repo root). The relative path format (without `@ref`) is used for same-repository calls. Option B is the correct format for calling a reusable workflow from a *different* repository (requires `owner/repo/path@ref`); it works here but is unnecessarily verbose and not the idiomatic approach for same-repo calls — however, it is technically valid. Option C is wrong; `workflow_call:` is not a valid `uses` prefix. Option D is wrong; the path must include the `.github/workflows/` prefix.

4. 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.

5. An organization enforces a policy that the `production` GitHub Environment may only be deployed to from the `main` branch and tags matching `v*`. A workflow on a `hotfix/critical` branch references the `production` environment. What happens when this workflow runs?

A. The deployment job is queued and waits indefinitely for a required reviewer to override the branch restriction
B. The deployment job fails with an error indicating the branch does not match the allowed deployment branches or tag patterns✓ Correct
C. GitHub automatically promotes the `hotfix/critical` branch to `main` before allowing the deployment
D. The deployment proceeds normally because branch restrictions on environments only apply to the GitHub UI, not to workflow runs

Explanation

GitHub enforces deployment branch and tag policies at the environment level. If the triggering ref does not match the configured allowed branches/tags, the deployment job fails — it is not queued, overridable by reviewers, or bypassed. Option A is wrong; reviewers can approve/reject deployments but cannot override deployment branch restrictions. Option C is wrong; GitHub does not merge or promote branches automatically. Option D is wrong; deployment branch restrictions apply equally to workflow runs and are enforced by the GitHub Actions runtime, not just the UI.

19 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free