GitHub Actions GH-200: Workflow Troubleshooting

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Consume and Troubleshoot Workflows

A repository has a workflow named security-audit.

Exhibit:

During a month-long freeze, the team wants all new runs for this workflow to stop immediately. They must keep the workflow YAML file in the repository and preserve all existing workflow history for audit. What is the best next action?

Options:

• A. Turn off GitHub Actions for the entire repository

• B. Delete .github/workflows/security-audit.yml

• C. Remove the schedule trigger from the workflow file

• D. Disable the security-audit workflow

Best answer: D

Explanation: The right action is to disable the specific workflow. That stops new runs without deleting the workflow file or removing previous run history, which matches both operational and audit requirements.

GitHub Actions lets you disable an individual workflow when you need runs to stop temporarily but do not want to remove the workflow definition or lose historical runs. In this scenario, the team wants to pause only security-audit, preserve the YAML file in the repository, and retain past executions for audit review.

Disabling the workflow is the clean lifecycle action because it:

• stops future triggers from starting new runs
• keeps the workflow file intact
• preserves prior run history
• allows later re-enablement

Deleting or rewriting the workflow file changes repository content, and disabling Actions for the whole repository is broader than required. The key distinction is between pausing one workflow and altering or removing automation assets.

• Delete the file fails because it removes the workflow definition from the repository, which the team must keep.
• Remove the schedule changes the YAML and may still leave other triggers available, so it is not the clean pause mechanism.
• Disable all Actions is too broad because it affects unrelated workflows in the repository.

Question 2

Topic: Consume and Troubleshoot Workflows

A workflow run ended as failed because a downstream deploy job failed. In the successful test matrix job for windows-latest, the team generated test-results/windows-latest.xml and used this fragment:

- run: ./run-tests --report test-results/${{ matrix.os }}.xml
- uses: actions/cache@v4
  with:
    path: test-results
    key: reports-${{ github.sha }}-${{ matrix.os }}
- run: echo "Windows report created" >> $GITHUB_STEP_SUMMARY

The next day, engineers open that failed run and need to download the exact XML file from it. They can see logs and the step summary, but no downloadable file. What is the best explanation?

Options:

• A. The report was cached, not uploaded as an artifact; caches are for reuse, not per-run downloadable evidence.

• B. The XML should be retrievable from logs because logs and artifacts are retained the same way.

• C. The report needed to be published as a release asset because only releases keep workflow outputs for later download.

• D. The step summary should expose generated files, but summaries are hidden when another job in the run fails.

Best answer: A

Explanation: Artifacts are the GitHub Actions mechanism for preserving downloadable files from a specific run. A cache is meant for reuse across runs and has different retention and visibility behavior, while logs and summaries only preserve text output.

Use an artifact when you need the exact files produced by a specific workflow run. actions/cache stores reusable data for future runs based on keys, and its lifecycle is governed by cache eviction behavior rather than being shown as downloadable run evidence. Logs capture console output, and GITHUB_STEP_SUMMARY renders Markdown for humans, but neither stores arbitrary files for download. Release assets are attached to a GitHub Release, typically for distributing versioned outputs, not routine CI evidence from a run.

If this XML file must be available from that run:

• upload it with actions/upload-artifact
• set retention-days as needed
• use if: always() when you need it even if later steps fail

The key distinction is purpose: caches optimize future runs, while artifacts preserve run outputs.

• The summary option fails because a job summary is rendered Markdown text, not a file attachment store.
• The logs option fails because logs keep stdout and stderr output, not generated XML files.
• The release asset option fails because release assets belong to GitHub Releases, not ordinary workflow-run evidence.

Question 3

Topic: Consume and Troubleshoot Workflows

An organization wants to standardize release automation across 40 repositories. All repositories are in the same organization and can access shared workflows from a central private repository.

The shared automation must:

• run multiple jobs on different runners
• require an environment approval before publishing to production
• accept inputs such as package name and release channel
• be updated once by the platform team and immediately used by all repositories

Each application repository should keep only a small caller workflow. Which configuration is best?

Options:

• A. Create a composite action that contains the build, test, and publish process

• B. Create a workflow template and copy the full release workflow into each repository

• C. Create a JavaScript action that each repository runs from a single step

• D. Create a reusable workflow in a central repository and invoke it with workflow_call

Best answer: D

Explanation: This requirement is for a centrally managed workflow, not just a shared step. A reusable workflow is the best fit because it can orchestrate multiple jobs, runners, inputs, and environment approvals while keeping one source of truth for all repositories.

Use a reusable workflow when the shared automation is an entire workflow that repositories should call at runtime. In this scenario, the process spans multiple jobs, may target different runners, and includes an environment approval before production publishing. Those are workflow-level capabilities, not step-level action capabilities.

A reusable workflow also lets the platform team maintain one definition and expose inputs and secret mappings to caller workflows. That gives each repository a thin wrapper while ensuring future changes are made once and used everywhere.

A workflow template is better for bootstrapping new repositories, but it creates copied YAML that can drift. Actions are better for reusable steps or logic inside a job, not for centrally managing a whole release pipeline.

• The workflow template option is tempting for standardization, but copied workflow files do not automatically inherit later platform-team updates.
• The composite action option works for bundling steps inside one job, but it cannot define separate jobs, runner selection per job, or workflow-level approval flow.
• The JavaScript action option packages logic for a single step, so it is too narrow for a multi-job release process with centralized orchestration.

Question 4

Topic: Consume and Troubleshoot Workflows

A pull request run failed, and the downstream package job has needs: test. The workflow run summary shows:

Workflow: validate-and-package
Conclusion: failure

Jobs
- lint ................................ success
- test (os: ubuntu-latest, node: 18) . success
- test (os: ubuntu-latest, node: 20) . success
- test (os: windows-latest, node: 20)  failure
- package ............................. skipped

Failed job steps for `test (os: windows-latest, node: 20)`
- Checkout .............. success
- Setup Node ............ success
- Install dependencies .. success
- Run unit tests ........ failure
- Upload coverage ....... skipped

What is the best next diagnostic action?

Options:

• A. Compare Ubuntu artifacts before opening failed logs

• B. Review logs for test (windows-latest, node 20) at Run unit tests

• C. Rerun the full workflow immediately

• D. Review the skipped package job first

Best answer: B

Explanation: The run summary already identifies both the failing matrix job and the failed step. The fastest diagnostic path is to open that job’s logs at Run unit tests, because the skipped package job is only a downstream result of needs: test.

In GitHub Actions, the run summary is the quickest way to locate the root failure: find the first failed job, then inspect the first failed step inside that job. Here, the summary narrows the issue to the test matrix variant running on Windows with Node 20, and it explicitly shows Run unit tests as the failing step.

• Successful matrix variants can help with comparison later, but they do not explain the failed conclusion.
• A skipped downstream job usually reflects a dependency such as needs, not the original problem.
• Reruns are useful after you inspect whether the failure is code-related, environment-specific, or transient.

The key takeaway is to use the summary to jump directly to the failed matrix job and step log.

• Skipped downstream job is not the best starting point because package was skipped due to its dependency on test.
• Successful artifacts first is less direct because the summary already points to a specific failed job and step.
• Immediate rerun is premature when the summary has already pinpointed where the actionable error occurred.

Question 5

Topic: Consume and Troubleshoot Workflows

A workflow already defines a staging deployment job with YAML anchors. You need a deploy-prod job that reuses the shared base, keeps permissions.contents: read, adds permissions.id-token: write, keeps env.REGION: us-east-1, changes only env.SLOT to prod, and still receives future updates from the shared base.

jobs:
  deploy-staging: &job_base
    runs-on: ubuntu-latest
    permissions: &base_permissions
      contents: read
    env: &base_env
      REGION: us-east-1
      SLOT: staging
    steps:
      - run: ./deploy.sh

Which configuration is best for deploy-prod?

Options:

• A. ```yaml deploy-prod: runs-on: ubuntu-latest permissions: contents: read id-token: write env: REGION: us-east-1 SLOT: prod steps:
  • run: ./deploy.sh

- B. ```yaml
deploy-prod:
  <<: *job_base
  permissions:
    <<: *base_permissions
    id-token: write
  env:
    <<: *base_env
    SLOT: prod

• C. ```yaml deploy-prod: «: *job_base permissions: id-token: write env: SLOT: prod

- D. ```yaml
deploy-prod:
  <<: [*job_base, *base_permissions, *base_env]
  permissions:
    id-token: write
  env:
    SLOT: prod

Best answer: B

Explanation: YAML merge behavior is shallow at each mapping level. To keep inherited permissions and env values while changing only one nested key, the job must merge the base job and then separately merge the nested permissions and env mappings.

In GitHub Actions YAML, <<: *job_base copies the top-level keys from the anchored job, such as runs-on, steps, permissions, and env. But if you then define a new permissions: or env: block, that nested mapping replaces the inherited one; it is not deep-merged automatically. To preserve existing nested values, you must anchor those nested mappings separately and merge them inside their own blocks.

• Merge *job_base to reuse the overall job.
• Merge *base_permissions inside permissions and add id-token: write.
• Merge *base_env inside env and override only SLOT.

A fully duplicated job can work for the current values, but it fails the maintainability requirement because future changes to the shared base will not flow automatically.

• The option that redefines permissions and env after merging the base job drops inherited nested keys like contents: read and REGION.
• The fully duplicated job matches today’s values, but it breaks the requirement to stay linked to the shared base for future changes.
• The option that merges *base_permissions and *base_env at the job level applies those mappings in the wrong place and still overwrites the nested blocks.

Question 6

Topic: Consume and Troubleshoot Workflows

After pushing a change, the Actions tab shows that this workflow failed validation before any matrix jobs were created. The team had just added an include entry to extend the matrix.

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
      include:
        - os: ubuntu-latest
          node: 20
    steps:
      - run: echo ${{ matrix.os }}

What is the best cause of the failure?

Options:

• A. ubuntu-latest and windows-latest must be quoted in the matrix array.

• B. Each include entry must define every matrix key, so adding node: 20 makes the matrix invalid.

• C. include is indented at the wrong level and must be nested under matrix.

• D. runs-on cannot reference matrix.os; matrix values are only available inside steps.

Best answer: C

Explanation: This is a YAML structure problem, not a runner or matrix-value problem. In GitHub Actions, include is part of the matrix definition, so placing it as a sibling of matrix causes workflow validation to fail before any jobs are generated.

GitHub Actions reads workflow YAML by structure, and indentation changes that structure. Under jobs.<job_id>.strategy, valid settings include matrix, fail-fast, and max-parallel. The include list is not a separate strategy setting; it must be nested under strategy.matrix.

Because include is indented as a sibling of matrix, Actions cannot parse the strategy correctly, so the workflow fails before matrix expansion and no variants are created.

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    include:
      - os: ubuntu-latest
        node: 20

The key takeaway is that matrix troubleshooting often comes down to YAML structure: a small indentation shift can change the meaning of the whole block.

• Unquoted runner labels like ubuntu-latest are valid plain YAML scalars in workflow files.
• Using ${{ matrix.os }} in runs-on is supported once the matrix is defined correctly.
• An include entry can add an extra key such as node; it does not have to appear in every base matrix combination.

Question 7

Topic: Consume and Troubleshoot Workflows

A repository uses this workflow:

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: [18, 20]
    runs-on: ${{ matrix.os }}
    steps:
      - run: npm test
      - if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: test-results-${{ matrix.os }}-${{ matrix.node }}
          path: test-results/

A run failed only for windows-latest with node: 20. The maintainer wants to change the workflow to add debug steps and then delete the failed run. What is the best next diagnostic action?

Options:

• A. Commit debug steps, then rerun only the failed job.

• B. Download the failed job logs and test-results-windows-latest-20 artifact first.

• C. Delete the failed run after noting the exit code.

• D. Rerun the full matrix to refresh runner state.

Best answer: B

Explanation: Before changing workflow files or deleting runs, preserve the evidence from the original failure. Downloading the failing job logs and its failure artifact keeps the exact matrix-specific context available for comparison after any later changes or reruns.

The key troubleshooting practice is to preserve the original diagnostic evidence before you modify the workflow or remove the run. In this case, the failure is limited to one matrix variant, so the most valuable evidence is the logs and uploaded artifact from windows-latest with Node 20.

• Save the failing job logs.
• Download the artifact produced on failure.
• Keep the exact matrix combination tied to that evidence.

If you change the workflow first, later runs may behave differently because the workflow, logging, or runner conditions have changed. If you delete the run, you lose the original context entirely. Reruns are useful later, but only after the initial evidence is preserved.

• Adding debug steps and rerunning first changes the test conditions before the original failure evidence is captured.
• Deleting the run after copying only the exit code throws away detailed logs and any failure artifacts.
• Rerunning the whole matrix may help reproduce the issue, but it does not preserve the original failing run’s evidence.

Question 8

Topic: Consume and Troubleshoot Workflows

A workflow comments on pull requests after tests pass. A run triggered by pull_request from a branch in the same repository completes npm test successfully, then fails in the final step.

on: pull_request
permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: npm test
      - name: Post summary
        uses: actions/github-script@v7
        with:
          script: |
            await github.rest.issues.createComment({
              ...context.repo,
              issue_number: context.issue.number,
              body: 'Tests passed'
            })

Post summary
HttpError: Resource not accessible by integration
Error: Unhandled error: HttpError: Resource not accessible by integration

What is the best cause of the failure?

Options:

• A. The job’s GITHUB_TOKEN lacks the write permission needed to create the comment.

• B. The previous shell command returned a nonzero exit code.

• C. A repository secret was missing, so the action received an empty token.

• D. The github-script step omitted a required input and failed validation.

Best answer: A

Explanation: This is a permission error, not a runner or shell failure. The workflow explicitly limits permissions to contents: read, and the log message Resource not accessible by integration indicates the token could call GitHub but was denied the write action.

The key clue is the log message, not just the failed step. actions/github-script successfully started and attempted the API call, which means the runner was available and the action input was valid enough to execute. The failure occurs when github.rest.issues.createComment(...) tries to write a pull request comment, but the workflow-level permissions: block gives the automatically provided GITHUB_TOKEN only contents: read.

In GitHub Actions, this kind of authorization problem commonly appears as Resource not accessible by integration:

• The job started, so runner setup succeeded.
• The action ran, so this is not a missing required input.
• The API rejected the write request, so this is not a shell command exit failure.

The fix is to grant only the needed write permission for that step instead of leaving the token read-only.

• Missing secret does not fit because the step uses the automatic GITHUB_TOKEN, not a repository secret passed into with or env.
• Missing input would typically show an error like Input required and not supplied, not a GitHub API authorization message.
• Command exit failure would appear as a shell error such as Process completed with exit code 1, and the stem already says npm test completed successfully.

Question 9

Topic: Consume and Troubleshoot Workflows

A workflow fails before any job starts. The repository contains this workflow:

name: CI
on: [push]

jobs:
  build:
    uses: octo-org/shared-automation/.github/actions/build@v2

Run details show:

Invalid workflow file
jobs.build.uses is not a reusable workflow

In octo-org/shared-automation, the referenced path contains an action.yml file. Which explanation best fits the failure?

Options:

• A. The shared component should be a starter workflow, because starter workflows are callable with owner/repo/path@ref.

• B. The shared component should be a workflow template, because templates are invoked from the source repository at runtime.

• C. Cross-repository reusable workflows are unsupported, so the workflow must be copied into the repository.

• D. The reference targets a composite action; jobs.<job_id>.uses only calls reusable workflows exposed with workflow_call.

Best answer: D

Explanation: The failure occurs during workflow validation because the caller is using a composite action where GitHub Actions expects a reusable workflow. Composite actions are defined by action.yml and run as steps, while reusable workflows are workflow files called at the job level.

The key distinction is step reuse versus workflow reuse. A reusable workflow is a full workflow file stored under .github/workflows and designed to be called with jobs.<job_id>.uses; it must declare on: workflow_call. A composite action is defined by action.yml and packages multiple steps, but it is invoked from steps[*].uses, not from a job.

Workflow templates and starter workflows are different again: they help create workflow files, but they are copied into a repository rather than executed from the source at run time. In this scenario, the validation message and the presence of action.yml are direct evidence that the path points to a composite action, not a reusable workflow.

The closest distraction is the idea that templates or starter workflows can be called dynamically, but they cannot.

• Workflow template confusion fails because templates are copied into repositories; they are not runtime targets for jobs.<job_id>.uses.
• Starter workflow confusion fails because starter workflows are scaffolding examples, not callable shared automation components.
• Cross-repo limitation fails because reusable workflows can be called from other repositories when referenced correctly.

Question 10

Topic: Consume and Troubleshoot Workflows

An integration job started failing in one run, even though the same commit succeeded earlier and succeeded again when only the failed job was rerun. The team manages Node.js outside the workflow and expects it on every self-hosted runner.

jobs:
  integration:
    runs-on: [self-hosted, linux, x64, build]
    steps:
      - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608
      - run: node --version
      - run: npm ci
      - run: npm test

Failed-run log excerpt:

/usr/bin/bash: line 1: node: command not found

Which is the best explanation for the failure?

Options:

• A. Insufficient GITHUB_TOKEN permissions caused npm ci to fail.

• B. The pinned actions/checkout commit blocked access to Node.js.

• C. A workflow configuration change caused different steps to run.

• D. One self-hosted runner drifted and build-03 lacks Node.js.

Best answer: D

Explanation: The failure happens at node --version, before package installation or tests begin. Because the same commit and same job succeed on another runner with the same labels, the strongest conclusion is environment drift on build-03, such as a missing Node.js installation.

When the same commit and workflow behave differently across self-hosted runners, compare the failing run with a known-good run before changing the workflow. Here, both successful runs use build-01, while the failed run uses build-03, and the failure occurs at node --version. That shows the job never reaches dependency installation or test execution, so the problem is not with npm, package authentication, or later job logic.

• Compare runner name, labels, and group membership.
• Verify installed tool versions and provisioning state on the failing runner.
• Check recent image, package, or PATH changes on that runner.

This pattern indicates self-hosted environment drift, not workflow configuration drift.

• The option blaming actions/checkout does not fit because checkout does not provide the node binary, and the failure happens before repo-specific build logic.
• The option about workflow changes conflicts with the identical commit and the successful rerun of the same job.
• The option about GITHUB_TOKEN permissions does not match the log, because permission issues would appear during registry or API access, not at node --version.

Continue with full practice

Use the GitHub Actions GH-200 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try GitHub Actions GH-200 on Web View GitHub Actions GH-200 Practice Test

Related focused pages

• Free GitHub Actions GH-200 Full-Length Practice Exam
• Author and Manage Workflows
• Author and Maintain Actions
• Enterprise Actions
• Secure Automation

Free review resource

Read the GitHub Actions GH-200 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.