1.2. The GitHub Actions Execution Model
💡 First Principle: Every GitHub Actions run is one sentence: an event triggers a workflow, which runs one or more jobs, each on a fresh runner, executing steps in order. Every exam scenario — every trigger question, every data-passing question, every debugging question — is asking about one link in that chain.
This model deserves to be over-learned, because the exam rewards decomposing scenarios into it. When a question asks "why didn't the deploy job see the file the build job created?", it's testing the fresh runner link. When it asks "why did this workflow run twice?", it's testing the event link. Hold the chain in your head and unfamiliar questions become familiar.
A workflow is a YAML file in .github/workflows/ that declares when it runs (on:) and what it runs (jobs:). Workflows are the unit of triggering. Jobs are the unit of parallelism and isolation — by default they run simultaneously, each on its own machine. Steps are the unit of sequence — inside a job they run one after another, sharing that machine. Keep those three "units" straight and half of Phase 2 becomes intuitive.
⚠️ Common Misconception: "A pipeline is one continuous machine." In GitHub Actions each job gets a brand-new virtual machine that is destroyed afterward. Files, installed tools, and environment changes do not survive between jobs — anything a later job needs must be passed deliberately (artifacts, outputs, caches — Phase 2.3).
