2.3. Workflow Execution and Outputs

💡 First Principle: A run's machines are destroyed when it ends, so everything you want to keep must be explicitly handed to a persistence mechanism — and Actions offers several, each with different lifetime, scope, and cost characteristics.

Why this matters beyond trivia: choosing wrong is how teams end up with 90-day artifact bills for build logs nobody reads, or a "cache" of release binaries that silently evaporates. The mechanisms sort cleanly once you ask two questions — does a human need to download this? and is it merely an optimization? — and the exam's data-passing scenarios are all answerable from that.

⚠️ Common Misconception: Caches and artifacts are treated as two names for the same storage. They are not: an artifact is a deliverable you intend to retrieve (downloadable in the UI and API, retention you configure, counts against storage billing), while a cache is a best-effort speed-up (restored by key, branch-scoped, evicted after 7 days unused or when the repo passes its 10 GB limit). Never store anything you can't regenerate in a cache; never use an artifact as a build accelerator.