Use this cheat sheet for GitHub Actions after you can read YAML and need faster exam decisions. Actions questions are usually not about remembering a keyword in isolation. They ask whether the automation is triggered correctly, scoped safely, ordered correctly, and debuggable when it fails.
Actions answer sequence
Use this when the stem mixes workflow triggers, permissions, secrets, jobs, or CI behavior.
flowchart TD
S["Scenario"] --> W["Classify the workflow lane"]
W --> P["Check triggers, jobs, or permissions"]
P --> S2["Check secrets, runners, or artifacts"]
S2 --> V["Verify run status, logs, and output"]
Read every Actions question in this order
- Identify the event: push, pull request, schedule, manual dispatch, workflow call, release, issue, or deployment.
- Identify the execution layer: workflow, job, step, action, runner, environment, or reusable workflow.
- Check trust boundary: branch, fork, secret exposure, token permission, environment approval, and third-party action risk.
- Check dependency order:
needs, matrix, conditions, concurrency, artifacts, and environments.
- Troubleshoot from the failing step and context before changing the whole workflow.
Workflow anatomy
| Part |
What it controls |
on |
event, path, branch, tag, schedule, or manual trigger |
jobs |
independent or dependent units of execution |
runs-on |
runner type and operating system |
steps |
shell commands or action invocations inside a job |
uses |
external action, local action, or reusable workflow reference |
with |
input values for an action or reusable workflow |
env |
environment variables at workflow, job, or step scope |
permissions |
GITHUB_TOKEN scope for workflow or job |
Trigger and context traps
| Scenario |
Better instinct |
| workflow did not run |
check event, branch filter, path filter, default branch, workflow file path, and disabled state |
| workflow ran unexpectedly |
check broad event trigger, missing path ignore, tag trigger, and schedule behavior |
| pull request from fork needs secrets |
treat as untrusted; avoid exposing secrets to arbitrary fork code |
| privileged PR automation |
understand pull_request_target risk before using it |
| manual run required |
workflow_dispatch supports explicit operator start and inputs |
| workflow reused by other workflows |
workflow_call defines callable inputs, secrets, and outputs |
Jobs, dependencies, and data flow
| Requirement |
Start with |
| job must wait for test job |
needs |
| run across versions or platforms |
matrix strategy |
| skip a job based on condition |
if expression at job or step scope |
| share build output across jobs |
upload/download artifact |
| speed up dependency installs |
cache with a correct key and restore strategy |
| prevent overlapping deploys |
concurrency group and cancellation behavior |
| deploy with approval |
environment protection rules and required reviewers |
Security checklist
| Control |
Exam instinct |
permissions |
set minimum token permissions, preferably at job scope for sensitive workflows |
| secrets |
keep out of logs, forks, untrusted events, and checked-in files |
| OIDC |
use short-lived cloud credentials instead of long-lived static cloud keys where supported |
| environments |
protect production deployments with reviewers and environment secrets |
| third-party actions |
pin trusted versions or SHAs according to risk |
| branch protection |
require checks and reviews before merge |
| self-hosted runners |
isolate, patch, label carefully, and avoid running untrusted jobs on sensitive machines |
Authoring actions and reuse
| Need |
Best fit |
| reuse workflow across repos |
reusable workflow |
| bundle multiple shell steps |
composite action |
| custom logic with Node runtime |
JavaScript action |
| isolated packaged runtime |
Docker action |
| share values from an action |
outputs |
| avoid copy-pasted YAML |
reusable workflow, composite action, or organization template |
Troubleshooting map
| Symptom |
First things to check |
| checkout or dependency step fails |
permissions, runner OS, network, package registry auth, and cache state |
| deployment job skipped |
if, branch filter, environment rule, needs, and prior job result |
| secret appears empty |
event trust boundary, environment scope, repo/org secret availability, and name mismatch |
| token denied |
job permissions, repository settings, branch protection, and API endpoint requirement |
| matrix job is wrong |
include/exclude rules, variables, and conditional expressions |
| artifact missing |
upload path, job order, retention, and download target |
Common traps
| Trap |
Better instinct |
broad GITHUB_TOKEN permissions |
scope permissions to what the job needs |
| secrets in forked PR workflows |
do not expose secrets to untrusted code |
| deployment from every branch |
use branch filters, environments, approvals, and protection rules |
| copy-paste workflows everywhere |
use reusable workflows or composite actions |
| cache as correctness mechanism |
cache speeds builds; it should not hide missing dependency declarations |
| rerun without evidence |
inspect logs, annotations, event payload, and failing command first |
Final 15-minute review
| If the stem says… |
Start here |
| trigger does not work |
event, branch/path filters, default branch, and workflow file location |
| job order |
needs, artifacts, outputs, matrix, and conditions |
| secret or cloud credential |
event trust, secret scope, OIDC, permissions, and logs |
| production deployment |
environment, approval, branch protection, concurrency, and rollback |
| reuse |
reusable workflow versus composite action versus custom action |
| flaky workflow |
runner state, external dependency, cache, race, timeout, and logs |
Practice fit
Use IT Mastery for the exact product route, practice status, spaced review when available, and close-answer explanation practice as coverage expands.
One-line decision rule
GitHub Actions answers should make automation trigger deliberately, run in the right order, expose only necessary trust, and leave clear evidence when it fails.