SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
GH-200 · Domain 1

Author and manage workflows practice questions

Author and manage workflows is worth 24% of the GH-200 exam — the heaviest of the 5 domains. Triggers and events, workflow structure (jobs, steps, conditions, matrices, service containers, contexts and expressions, YAML anchors), and execution outputs: caching, artifacts, job summaries and badges. Official weight range 20–25%. 6 fully worked examples are further down this page, answers included.

Exam weight
24%
the heaviest of the 5 domains
Questions
92
across 2 topics
Free, no account
5/day
a free account allows 30 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 5 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Author and manage workflows questions, fully explained

Questions from the GH-200 bank mapped to domain 1, with the answer key and the reasoning behind every option. None of them repeat the examples on the main GH-200 practice page.

Question 1Author and manage workflows

A team in Sydney wants a cleanup workflow to start at 02:00 local time every day. The run must stay at 02:00 local time when daylight saving time starts and ends, and the team does not want to edit the workflow twice a year. How should the trigger be configured?

Choose one.

  • a
    Keep the cron at 02:00 and add a timezone key set to Australia/Sydney Correct

    Correct. A schedule entry accepts an optional IANA timezone string next to cron, and GitHub then follows that zone's daylight saving changes.

  • b
    Convert 02:00 Sydney time to UTC once and use that hour in the cron

    This works only until the next daylight saving change. Without a timezone key the cron is UTC, so the local start time shifts by an hour twice a year.

  • c
    Keep the cron at 02:00 and set a TZ variable in the workflow env block

    The env block changes the environment of the job's processes after it starts. It does not change when the scheduler fires, which stays in UTC.

  • d
    Add two cron entries, one for standard time and one for daylight time

    Both entries would fire all year, so the workflow would run twice a day, and the team would still need to manage the UTC offsets by hand.

The concept

Scheduled workflows run in UTC unless a timezone is set on the schedule entry.

Why that’s the answer

By default the cron expression in a schedule trigger is evaluated in UTC. GitHub lets you add a timezone key with an IANA zone name beside each cron entry, and the schedule then tracks that zone, including daylight saving changes. A fixed UTC conversion drifts by an hour twice a year, an env variable affects only the job's processes, and two cron entries both fire every day.

How to reason it out
  1. Identify the requirement: a local wall-clock time that survives daylight saving changes.
  2. Recall that cron in a schedule trigger is UTC by default.
  3. Recall that each schedule entry can carry an IANA timezone.
  4. Reject options that only change the job environment or duplicate the schedule.

Exam tip: Cron is UTC by default; add timezone: <IANA zone> to follow local time and daylight saving.

GitHub Actions Triggers, Events, Caching, Artifacts and Outputs (GH-200) — the lesson that teaches this.

Question 2Author and manage workflows

A repository has five deployment environments, but a manually started release workflow may only target staging or production. Operators must pick the target from a drop-down list, free text must not be possible, and staging must be preselected. Which input definition meets these requirements?

Choose one.

  • a
    type: string, options: [staging, production], default: staging

    A string input renders a free-text box; the options list belongs to choice inputs, so operators could still type any value.

  • b
    type: environment, required: true, default: staging, description: Target

    An environment input does render a drop-down, but it lists every environment in the repository, so all five targets would be selectable.

  • c
    type: choice, options: [staging, production], default: staging Correct

    Correct. A choice input renders a drop-down limited to the listed options, and default preselects staging.

  • d
    type: choice, options: [production, staging], required: false

    With no default, the Run workflow form preselects the first listed option, which here is production, so staging is not preselected.

The concept

workflow_dispatch input types and properties.

Why that’s the answer

workflow_dispatch inputs can be boolean, choice, number, environment or string. Only a choice input restricts the operator to an explicit options list, and default sets the preselected value. The environment type is a close twin, but it lists all of the repository's environments, not a chosen subset. A string input is free text whatever else you add.

How to reason it out
  1. List the requirements: drop-down, only two values, staging preselected.
  2. Match 'only these values' to the choice type with an options list.
  3. Rule out environment, which shows every repository environment.
  4. Confirm a default is set so staging is preselected.

Exam tip: Use type: choice with options and a default when operators must pick from a fixed list.

GitHub Actions Triggers, Events, Caching, Artifacts and Outputs (GH-200) — the lesson that teaches this.

Question 3Author and manage workflows

A developer creates release.yml on the branch feature/release-tool with a manual trigger that takes a version input. The workflow must only ever start manually, and it must be tested with operator-supplied inputs before the full logic is merged. The Run workflow button does not appear, and dispatching it with the feature branch as the ref fails. What should the developer do?

Choose one.

  • a
    Add a repository_dispatch trigger to the release workflow on the feature branch and send the version in client_payload

    repository_dispatch has the same requirement: the workflow file must exist on the default branch, so the feature-branch-only copy still never runs.

  • b
    Merge a stub of the workflow file to main, then dispatch it with the feature branch as the ref Correct

    Correct. A manual trigger only works once the file exists on the default branch. After that, a dispatch can target another ref, and the run uses that ref's version of the workflow with the supplied inputs.

  • c
    Add a temporary push trigger for the feature branch to release.yml and remove it before the finished version merges

    A push run would start, but push events carry no workflow inputs, so the workflow cannot be tested with operator-supplied values.

  • d
    Enable the release workflow from the Actions tab with the feature branch selected, then dispatch it manually on that ref

    Workflows are not enabled per branch. The workflow is not listed at all until a file with that name exists on the default branch.

The concept

A workflow_dispatch workflow must exist on the default branch before it can be dispatched, but a dispatch can then target another ref.

Why that’s the answer

GitHub only offers a manual run for workflow files present on the default branch. Once release.yml exists on main, the UI, API or CLI can dispatch it against feature/release-tool, and the run uses the workflow file and code from that ref with the supplied inputs. A temporary push trigger runs the code but provides no inputs, and repository_dispatch has the same default-branch requirement.

How to reason it out
  1. Recognise why the button is missing: the file is not on the default branch.
  2. Recall that once the file is on the default branch, dispatch can target any branch or tag.
  3. Check each alternative against 'manual only' and 'test with inputs'.
  4. Choose merging a stub to main and dispatching against the feature branch.

Exam tip: Manual triggers need the file on the default branch; after that, dispatch any ref to test its version.

GitHub Actions Triggers, Events, Caching, Artifacts and Outputs (GH-200) — the lesson that teaches this.

Question 4Author and manage workflows

An external incident-management system must start one workflow when an incident is resolved or escalated. The workflow runs different jobs depending on which kind of signal arrived, and the system sends a JSON document whose fields vary by incident. The system can call GitHub's REST API with a token. Which trigger should the workflow use?

Choose one.

  • a
    workflow_dispatch with one input per JSON field, started by the system through the REST API

    The API can start a manual workflow, but its inputs must be declared in advance and there is no event type to tell the two signals apart.

  • b
    workflow_run listening for the system's runs, reading fields from the triggering run's payload

    workflow_run reacts only to other GitHub Actions workflows in the repository, not to calls from an outside system.

  • c
    repository_dispatch with types for both signals, reading fields from the event's client_payload Correct

    Correct. The system sends an event_type and a free-form client_payload; the workflow filters on types and branches its jobs on github.event.action.

  • d
    A repository webhook for the system's URL, with the workflow triggered by the webhook's deliveries

    Repository webhooks send events out of GitHub to another server. They do not let an outside system start a workflow.

The concept

repository_dispatch lets external systems start workflows with an event type and payload.

Why that’s the answer

repository_dispatch is the webhook-style trigger for activity outside GitHub. The caller sends an event_type (which the workflow can filter with types and read as github.event.action) and a client_payload of arbitrary JSON (read as github.event.client_payload). workflow_dispatch can also be called over the API, but its inputs are fixed and it has no event type. workflow_run and outbound repository webhooks do not accept external triggers.

How to reason it out
  1. Note the signal comes from outside GitHub through the REST API.
  2. Note two kinds of signal must be distinguished and the payload varies.
  3. Match event types plus free-form payload to repository_dispatch.
  4. Reject workflow_dispatch (fixed inputs, no type) and workflow_run (GitHub workflows only).

Exam tip: External system, typed events, arbitrary JSON: repository_dispatch with types and client_payload.

GitHub Actions Triggers, Events, Caching, Artifacts and Outputs (GH-200) — the lesson that teaches this.

Question 5Author and manage workflows

A workflow with the trigger on: pull_request runs when pull requests are opened and when new commits are pushed to them. It must now also run when a label is added to a pull request, without losing any of its current runs. How should the trigger be changed?

Choose one.

  • a
    pull_request with types: [labeled] and no other activity types

    This adds label runs but replaces the defaults, so the workflow would stop running when pull requests are opened, updated or reopened.

  • b
    Add a label trigger with types: [created] beside the pull_request one

    The label event fires when a label is created, edited or deleted in the repository, not when one is applied to a pull request.

  • c
    Add an issues trigger with types: [labeled] beside the pull_request one

    The issues event covers issues; labelling a pull request is reported through the pull_request event's labeled activity type.

  • d
    pull_request with types: [opened, synchronize, reopened, labeled] Correct

    Correct. Setting types replaces the default list, so the three default activity types must be listed along with labeled.

The concept

Activity types on the pull_request event and its default types.

Why that’s the answer

Without a types filter, pull_request runs only for opened, synchronize and reopened. Adding types replaces that default, so to keep existing runs and add label runs you list all four. The label event concerns repository label definitions, and issues: labeled concerns issues, so neither fires when a pull request is labelled.

How to reason it out
  1. Recall the default activity types for pull_request.
  2. Recall that an explicit types list replaces the default.
  3. Find the event that reports a label being applied to a pull request.
  4. List the defaults plus labeled.

Exam tip: Setting types on pull_request replaces the defaults (opened, synchronize, reopened); list them again if you still need them.

GitHub Actions Triggers, Events, Caching, Artifacts and Outputs (GH-200) — the lesson that teaches this.

Question 6Author and manage workflows

A repository has this trigger:on: push: branches: [main] paths: ['src/**'] pull_request: paths-ignore: ['docs/**']Which event starts a run of this workflow?

Choose one.

  • a
    A push to the main branch whose single changed file is docs/guide.md

    The push filter requires both the branch and a changed path under src/. The branch matches but no file under src/ changed.

  • b
    A push to the release/1.2 branch whose single changed file is src/app.js

    The path matches, but the push filter also limits branches to main, and both filters must match for the run to start.

  • c
    A pull request whose commits change the file docs/api/intro.md alone

    Every changed file matches docs/**, so paths-ignore skips this pull request run.

  • d
    A pull request whose commits change docs/guide.md and src/app.js Correct

    Correct. paths-ignore skips a run only when every changed file matches an ignored pattern; src/app.js does not, so the pull request run starts.

The concept

How branch and path filters combine for push and pull_request.

Why that’s the answer

When an event has both a branches filter and a paths filter, both must be satisfied. A paths-ignore filter skips the run only when all changed files match the ignored patterns; one file outside them is enough to run. So the push to main without a src/ change and the push to release/1.2 are filtered out, the docs-only pull request is ignored, and the mixed pull request runs.

How to reason it out
  1. Evaluate the push filter: branch must be main AND a file under src/ must change.
  2. Evaluate the pull_request filter: skip only if every file is under docs/.
  3. Test each event against its own event's filter.
  4. Only the mixed docs-and-src pull request passes.

Exam tip: Branch and path filters must both match; paths-ignore skips a run only if every changed file is ignored.

GitHub Actions Triggers, Events, Caching, Artifacts and Outputs (GH-200) — the lesson that teaches this.

What GH-200 domain 1 tests, topic by topic

The official exam guide breaks Author and manage workflows into 2 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published GH-200 practice questions per topic in Author and manage workflows
TopicWhat it coversQuestions
Workflow triggers, events, execution and outputsOfficial GH-200 study guide, "Author and manage workflows" (skills measured as of January 2026). "Configure workflow triggers and events": Configure workflows to run for scheduled, manual, webhook, and repository events; Choose appropriate scope, permissions, and events for workflow automation; Define and validate workflow_dispatch inputs (types, required, defaults) and pass inputs to reusable workflows via workflow_call with inputs and secrets mapping. "Manage workflow execution and outputs": Configure caching and artifact management; apply retention policies via REST APIs (logs, artifacts, workflow runs) at org/repo level; Pass data between jobs and steps (artifacts, outputs, environment files via GITHUB_ENV and GITHUB_OUTPUT, reusable workflow outputs); Generate job summaries using GITHUB_STEP_SUMMARY for rich Markdown reports (test results, coverage, links); Add workflow status badges and environment protections.45
Design and implement workflow structureOfficial GH-200 study guide, "Author and manage workflows" (skills measured as of January 2026). "Design and implement workflow structure": Use jobs, steps, and conditional logic; Implement dependencies between jobs; Use workflow commands and environment variables; Use service containers (services:) for dependent services (databases, queues); configure ports, health checks, and container options; Use strategy and matrix to generate job variations (OS, language/runtime versions); apply include/exclude; control fail-fast and max-parallel; optimize matrix size for cost and performance; account for runner image changes (Ubuntu 20.04 deprecation, Windows; Implement YAML anchors and aliases (&, * and merge <<) to reuse repeated mappings/steps within a single workflow file; Use predefined contexts (github, runner, env, vars, secrets, inputs, matrix, needs, strategy, job, steps, github.event, github.ref) to access workflow, repository, and runtime metadata; understand immutable actions behavior and version pinning requirements; Evaluate expressions with ${{ }} referencing contexts; distinguish static (workflow parse) vs runtime evaluation; prevent secret leakage in logs and expressions; Leverage editor tooling (GitHub Actions VS Code extension / YAML schema completion, metadata IntelliSense, validation) to author and maintain workflows efficiently.47
Total92

Revise Author and manage workflows before you drill it

GitHub Actions Triggers, Events, Caching, Artifacts and Outputs (GH-200)Expect scenario questions built on short YAML snippets: a workflow that never ran, a value that arrives empty, an upload that fails, or a security review of a trigger. You are asked to predict which event starts a run, to spot the missing piece in an output or secret chain, or to choose the trigger, filter, token, API call or environment setting that meets every stated constraint. Wrong options are usually real Actions features used in the wrong place — a near-twin trigger, GITHUB_ENV where an output is needed, a repository secret where an environment secret is required — and some items ask you to select two answers.GitHub Actions Workflow Structure: Jobs, Conditions, Matrices and Contexts (GH-200)Expect scenario items, often with a short YAML snippet, that ask what a workflow does or which change fixes it under a stated constraint. Dependency and condition items ask which jobs run or are skipped after a failure, and which if expression reacts to exactly one job's outcome without firing on cancellation or on an earlier failure. Context items test where each context is allowed (secrets in conditions, matrix or runner in job-level keys), env precedence, and outcome versus conclusion. Matrix items ask which include or exclude entry produces exactly the required jobs, how fail-fast, continue-on-error and max-parallel combine or differ from concurrency, and how to pass outputs from several matrix jobs. Required-check items contrast a job skipped by if with a workflow skipped by a filter. Service-container items hinge on host name, port mapping and health checks. Security items test script injection through ${{ }}, which values redaction misses, which uses: references can change, and what the SHA-pinning policy accepts. Distractors are usually real Actions features applied in the wrong place, so check each option against where it is evaluated and what it actually controls.

Other GH-200 domains

Domain 2: Consume and troubleshoot workflows19% of the exam · 71 questionsDomain 3: Author and maintain actions18% of the exam · 71 questionsDomain 4: Manage GitHub Actions for the enterprise24% of the exam · 92 questionsAll GH-200 practice questionsMixed sessions across all 5 domains — the way the real exam interleaves them.

Author and manage workflows: your questions

Author and manage workflows is domain 1 of the GH-200 exam guide and carries 24% of the scored content — the heaviest of the 5 domains. On a 60-question paper that works out to roughly 14 questions, though GitHub does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official GH-200 exam guide.