GitHub Actions (GH-200) practice questions

A maintenance workflow must run automatically every night at 02:00 UTC to prune stale caches, with no human starting it and no code change needed to fire it. Which trigger should be configured at the top of the workflow file?

on:
  <trigger>:
    - cron: '0 2 * * *'

• Aschedule, because it accepts one or more cron expressions and triggers the workflow on the defined recurring time-based interval.check_circle Correct
• Bworkflow_dispatch, because a recurring nightly job is started from the Actions tab and the cron expression sets the default run time.
• Crepository_dispatch, because it listens for a timed webhook that GitHub emits internally to drive cron-based recurring runs.
• Dpush, because adding a cron filter under the push event tells GitHub to replay the last push on the recurring schedule.

Why A is correct: The schedule event takes a list of cron expressions evaluated against UTC, so '0 2 * * *' fires the workflow every night at 02:00 without any human action or code change.

Why B 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.

Why C is wrong: Tempting because repository_dispatch is also event driven, but it fires only when an external system posts a custom event to the API, not on any internal timer, so a cron field is ignored here.

Why D is wrong: Tempting because push is a very common trigger, but it fires only when commits are pushed and supports no cron field, so it cannot produce a nightly time-based run.

A run-history list shows a workflow that executed without any new commit, with no operator named as the actor and no external API call recorded. The workflow file declares the on block below. Which trigger most likely produced this run?

on:
  push:
    branches: [main]
  workflow_dispatch:
  schedule:
    - cron: '0 6 * * 1'

• AThe push event, because the run history records a commit to main even when the diff is empty and the user interface omits the pushing actor.
• BThe workflow_dispatch event, because a teammate clicked Run workflow and GitHub anonymises the actor on manually started runs to protect the operator.
• CThe repository_dispatch event, because an outside system posted a custom payload that the run history hides from the actor and commit columns by design.
• DThe schedule event, because a cron-triggered run fires on its own timetable with no commit and is attributed to the workflow rather than to any human or external caller.check_circle Correct

Why A is wrong: Tempting because push is listed first in the on block, but a push run always references a head commit and names the pusher as actor, neither of which appears in this run.

Why B is wrong: Tempting because workflow_dispatch needs no commit, but a manual run always records the person who clicked Run workflow as the actor, so an unnamed operator rules it out.

Why C is wrong: Tempting because that event also lacks a commit, but repository_dispatch is not in the on block and the stem states no external API call was recorded, so it cannot be the cause.

Why D is correct: A scheduled run fires from the cron timetable with no commit and no operator, and run history attributes it to the workflow itself, matching the empty actor and absent commit observed.

A team has three workflow steps that each run shell commands: install a CLI, authenticate it, then call it with arguments. They want to package exactly these run steps into one reusable unit that they can publish and call with a single uses: reference, without rewriting the logic in another language or building an image. Which action type should they author?

runs:
  using: "<type>"
  steps:
    - run: ./install.sh
      shell: bash
    - run: ./auth.sh
      shell: bash

• AA JavaScript action, because the runner can only execute bundled shell run steps after they are first rewritten as a Node.js entry point that the toolkit invokes on each platform.
• BA Docker container action, because grouping several shell commands into a single action is only supported once the commands are baked into an image that the runner pulls before each invocation.
• CA composite action, because its action.yml uses a runs block with using: composite and a steps list, letting them bundle the existing shell run steps into one unit referenced through uses:.check_circle Correct
• DA reusable workflow, because a file under .github/workflows called through workflow_call is the supported way to package shell run steps for reference by uses: inside another job's steps.

Why A is wrong: Tempting since JavaScript actions run directly on the runner, but they require rewriting the logic as a Node entry point, which the team explicitly wants to avoid for plain shell steps.

Why B is wrong: Tempting because containers also run shell commands, but a Docker action needs an image build and only runs on Linux runners, which is heavier than the shell-only packaging requested.

Why C is correct: Composite actions are defined by using: composite plus a steps list, which is exactly the construct for wrapping a sequence of run steps into one publishable action referenced with uses.

Why D is wrong: Tempting as reusable workflows also promote reuse, but they are called at the job level with uses under jobs, not as a step action, so they cannot bundle individual run steps.