Associate-level GitHub certification covering workflow authoring, action development, enterprise-scale management and secure, optimised automation with GitHub Actions, with a worked explanation on every practice question.
Free sample questions
No account needed. Every question has a worked explanation, just like the full bank.
lock_openFree sampleAuthor and manage workflowsmedium
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.
Recognise that the schedule event with a cron expression is the trigger for recurring time-based workflow runs. GitHub Actions runs a workflow on a recurring timetable only through the schedule event, which accepts cron expressions evaluated in UTC. A cron entry such as '0 2 * * *' therefore fires the workflow nightly at 02:00 UTC with no commit and no manual action. The other events fire on a push, a manual button, or an externally posted custom event, and none of them honours a cron field.
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.
lock_openFree sampleAuthor and manage workflowsmedium
An engineer needs to let teammates start a release workflow on demand from the Actions tab and have them choose a deployment environment from a typed field when they do. Which trigger configuration meets both requirements?
on:
<trigger>:
inputs:
environment:
type: choice
options: [staging, production]
- Aschedule, with an inputs block listing the environment choices, so the run is launched on demand and reads the selected value.
- Bworkflow_dispatch, because it adds a manual run button in the Actions tab and supports an inputs block including typed choice fields.check_circle Correct
- Cpush, with branch filters mapped to the inputs choices, so pushing to a branch starts the run and selects the matching environment.
- Drepository_dispatch, because it shows a manual button in the Actions tab and exposes the same inputs choices to the person starting the run.
Use workflow_dispatch to expose a manual run button with typed inputs such as a choice field. Only the workflow_dispatch event adds a Run workflow button in the Actions tab and supports an inputs block, where a field can be declared as type choice with a fixed set of options. That combination gives teammates an on-demand launch and a typed environment selector. The schedule and push events fire automatically and accept no inputs, and repository_dispatch is driven by an API call rather than a tab button.
Why A is wrong: Tempting because inputs look plausible under any event, but schedule fires only on a cron timer, offers no manual launch button, and does not accept an inputs block at all.
Why B is correct: The workflow_dispatch event enables a manual run control in the Actions tab and accepts an inputs block, so a choice-typed environment field is presented for the operator to select before the run.
Why C is wrong: Tempting because push starts runs from developer activity, but it fires automatically on commits rather than on demand and provides no typed input prompt for the operator to choose an environment.
Why D is wrong: Tempting because it is also manually driven, but repository_dispatch is started by an API call carrying a client_payload, not by an Actions tab button, and it does not render a typed inputs form.
lock_openFree sampleAuthor and manage workflowsmedium
A workflow should run its build only when a push changes files under the src directory on the main branch, and stay idle for pushes that touch documentation elsewhere. Which on configuration scopes the trigger to that intent with the least extra logic?
on:
push:
branches: [main]
<filter>:
- 'src/**'
- AUse a tags filter listing 'src/**', because tag patterns restrict a push trigger to commits that modify files inside the named directory.
- BUse a branches filter listing 'src/**', because adding the directory glob alongside main narrows the branch filter to that path.
- CUse a paths filter listing 'src/**', because the push then fires only when the pushed commits change files matching that path glob on main.check_circle Correct
- DUse a paths-ignore filter listing 'src/**', because excluding that glob tells the push trigger to run only when those files change.
Scope a push trigger to specific files with a paths filter, distinct from branches, tags, and paths-ignore. A push trigger can be narrowed by both branch and file path. The paths filter runs the workflow only when at least one changed file matches a listed glob, so branches main combined with paths 'src/**' fires solely for source changes on main. A branches or tags filter matches ref names rather than files, and paths-ignore would do the opposite by skipping the very changes the team wants to build.
Why A is wrong: Tempting because tags is a real push filter, but it matches Git tag names rather than changed file paths, so it cannot limit the run to pushes that touch the src directory.
Why B is wrong: Tempting because branches already appears in the snippet, but a branches filter matches branch names, not file paths, so 'src/**' there would simply never match a branch and the build would not run.
Why C is correct: The paths filter restricts a push or pull_request trigger to runs where at least one changed file matches the glob, so combining branches main with paths 'src/**' runs the build only for source changes.
Why D is wrong: Tempting because it names the right glob, but paths-ignore inverts the intent and skips the run when src files change, firing instead for unrelated documentation edits.
Examworthy is not affiliated with or endorsed by GitHub. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. GH-200 and related marks belong to their respective owners.
