1.3. The Reuse Spectrum: Actions, Workflows, and the Marketplace
💡 First Principle: Automation logic wants to be written once and reused — but "reuse" happens at three different granularities in GitHub Actions, and each mechanism copies or references code differently. Most confusion on the exam (and in real orgs) comes from blurring these three.
Why care? Because a wrong choice compounds. Pick copy-paste templates where you needed centralized workflows and you'll patch the same bug in forty repositories. Publish a step as a reusable workflow when it should have been a composite action and nobody can embed it mid-job. The exam tests this decision directly, and Phase 4.3 gives it a full comparison treatment.
Actions are packaged steps — the uses: lines inside a job. Thousands exist on the Marketplace, from actions/checkout down to niche deploy tools; you'll author your own in Phase 5. Reusable workflows are entire workflows other workflows call — one central definition, versioned, invoked at run time. Starter workflows are scaffolds offered in the "new workflow" UI — copied into the repository once, then owned by that repository forever after.
The ecosystem is the multiplier here: most workflows are mostly other people's actions, glued together with a little of your own logic. That's also why Phase 6 spends so much time on trusting third-party code you invite onto your runners.
⚠️ Common Misconception: "A workflow created from a starter template stays linked to it and picks up updates." Starter workflows are copy-on-create — the copy is fully independent. Only reusable workflows give you a central definition that consumers pick up at call time.
Reflection Question: Your org's security team wants one blessed deployment pipeline that every team must run unmodified, with updates taking effect everywhere at once. Which reuse mechanism fits — and why do the other two fail that requirement?
