2.1. Workflow Triggers and Events

💡 First Principle: The on: block is a subscription, not a schedule — you are telling GitHub which of its events should wake your workflow, and everything about when, how often, and with what privileges your automation runs follows from that subscription.

Getting triggers wrong fails in two directions, and the exam tests both. Subscribe too narrowly and the automation silently never runs — the classic "why didn't my workflow fire?" scenario, usually a branch filter, a path filter, or a wrong activity type. Subscribe too broadly and you pay for redundant runs, or worse, you hand a workflow with write permissions and secrets to code that came from a stranger's fork. Trigger selection is simultaneously a correctness decision, a cost decision, and a security decision.

⚠️ Common Misconception: pull_request and pull_request_target are not interchangeable. pull_request checks out the merge result and, for fork PRs, gets a read-only token with no secrets. pull_request_target runs in the base repository's context — full token, secrets available — while being triggered by untrusted contributors. Combining it with an explicit checkout of the PR head is one of the best-known ways to hand a repository to an attacker (revisited in 6.1.2).