6.2. Performance and Cost Optimization
💡 First Principle: Actions bills for wall-clock minutes on runners and for storage of artifacts and packages, so every optimization is one of three moves — don't run it, run it faster, or keep less of it — and knowing which lever a scenario needs is the whole skill.
Why care: cost problems present as vague complaints ("our Actions bill tripled," "PR feedback takes 25 minutes"), and the exam expects a specific mechanism in reply. The levers are unglamorous and highly testable: filters, concurrency, caching, matrix sizing, runner choice, and retention.
⚠️ Common Misconception: "More caching always makes builds faster." A cache that misses on every run costs time to save and restore while never being reused — keying on github.sha is the classic self-defeating example (2.3.1). Cache what is expensive to rebuild and stable across runs; measure the hit rate before adding more.
