Free GH-200 flashcards

Which GitHub Actions trigger fires a workflow on a recurring timetable, such as nightly at 02:00 UTC, with no commit and no manual action?

The schedule event. It accepts one or more cron expressions evaluated in UTC, so an entry like '0 2 * * *' starts the workflow every night at 02:00 with no human action and no code change. It is the only event that honours a cron field.

workflow_dispatch can fire a job automatically every night because its cron expression sets a default run time.

workflow_dispatch only adds a manual Run workflow button and accepts no cron field, so it cannot fire automatically on a timetable. Recurring time-based runs come from the schedule event with a cron expression.

Which GitHub Actions component keeps shared security-scanning logic as one central definition so a fix immediately reaches every consuming repository?

A reusable workflow. It lives in one repository and consumers reference it through the uses key at job level, so they execute the central file itself rather than a copy. A change to that file applies to every caller on its next run, so a single bug fix propagates without touching each repository.

A starter workflow can govern shared logic centrally because every repository runs an identical copy of the seeded security checks.

Wrong. Selecting a starter workflow copies the file into the repository, so a later central fix never reaches copies already created. Starter workflows standardise how new repositories begin, but they do not stay a single shared definition. Use a reusable workflow when fixes must propagate to all consumers.

In GitHub Actions run history, which trigger produces a run with no associated commit, no named actor, and no recorded API dispatch?

The schedule event. A cron-driven run fires on its own timetable with no human operator and no external caller, so GitHub attributes it to the workflow itself rather than to an actor. With no head commit and no API dispatch recorded, the time-based schedule trigger is the only remaining cause.

A push run can appear in history with a commit to main but with the pushing actor omitted from the interface.

A push run always references a head commit and names the pusher as the actor. If a run shows no commit and no actor, push cannot be the cause, because both fields are always populated for a push event.

Which action type bundles a sequence of existing shell run steps into one publishable unit callable with uses, without rewriting the logic?

A composite action. Its action.yml declares a runs block with using: composite and a steps list, so several run steps are grouped into a single action that other workflows reference with uses. No Node entry point and no container image are needed, so plain shell logic is kept as is.

A JavaScript action can package plain shell run steps once they are rewritten as a Node.js entry point.

This misses the goal. A JavaScript action does run on the runner, but it requires the logic to be rewritten as a Node entry point. To bundle existing shell run steps unchanged, use a composite action with using: composite and a steps list.