GH-200 - Author and manage workflows (25% of the exam) - Section 1.1

Configure workflow triggers for scheduled, manual, webhook and repository events, and choose appropriate event scope and permissions.

Define the on key and configure scheduled (schedule cron), manual (workflow_dispatch), and repository event triggers such as push and pull_request. Distinguish event scope and the permissions granted to each trigger type.

on triggersschedule cronworkflow_dispatchrepository events

Practice question for this objective

Free sampleAuthor and manage workflowsmedium

An external provisioning service must trigger a GitHub Actions workflow over the REST API after it finishes setting up infrastructure, passing a custom JSON payload that the run can read. Which event should the workflow listen for?

on:
  <trigger>:
    types: [infra-ready]

Aworkflow_dispatch, because an external system posts the custom event to the API and the run reads the data through the github.event.client_payload context.
Bpush, because an external system can post a commit to the API and the run reads the supplied data through the github.event.client_payload context.
Cschedule, because an external system registers a cron entry through the API and the run reads the supplied data through the github.event.client_payload context.
Drepository_dispatch, because an external system posts a custom event type to the API and the run reads the data through the github.event.client_payload context. Correct

Select repository_dispatch to let an external system trigger a workflow with a custom event type and client_payload. The repository_dispatch event exists so systems outside GitHub can start a workflow by POSTing to the dispatches REST endpoint with a custom event_type and an optional client_payload. The run then reads the supplied data through github.event.client_payload. workflow_dispatch targets human-initiated runs with declared inputs, while push and schedule carry no external custom payload at all.

Why A is wrong: Tempting because both events are manually initiated, but workflow_dispatch is meant for a person using the UI or CLI and exposes named inputs, not a free-form client_payload from an external service.

Why B is wrong: Tempting because pushing through the API does start runs, but push carries commit and ref data only, has no custom event_type, and never populates a client_payload field.

Why C is wrong: Tempting because both are non-interactive, but schedule fires on an internal cron timer with no external payload, so there is no client_payload for the run to read.

Why D is correct: The repository_dispatch event is designed for outside systems to start a workflow through the REST API with a chosen event_type and a client_payload that the run reads via github.event.client_payload.

See more GH-200 practice questions, answers explained.

Exam traps in Author and manage workflows

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-200 bank for this domain.

Add a branches field listing opened and reopened, because branch filters select which pull request lifecycle stages start the workflow.
Why it is wrong: Tempting because branches is a valid pull_request filter, but it matches base branch names, not activity stages, so listing opened there would never match and the run behaviour stays unchanged.
workflow_dispatch, because a recurring nightly job is started from the Actions tab and the cron expression sets the default run time.
Why it is wrong: Tempting because workflow_dispatch also appears under on, but it only enables a manual run button and accepts no cron field, so it cannot fire the job automatically at 02:00 UTC.
Declare on: schedule with a cron entry so the deploy fires on a timer
Why it is wrong: A schedule trigger fires automatically on a timetable, which contradicts the requirement that an operator starts the deploy manually.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.