4.1. Interpreting Workflow Behavior
💡 First Principle: A run is a complete record of a decision the platform already made — the trigger, the resolved configuration, the expanded matrix, every command and its exit code — so troubleshooting is not guesswork but reading the record in the right order: what fired it, what it resolved to, and where the exit code turned nonzero.
Why care: the exam's scenario questions almost never hand you the actual bug. They hand you a symptom ("the workflow ran twice," "the variable was empty," "half the jobs say cancelled") and expect you to know which record explains it. Reading in the wrong order — diving into step logs when the problem is the trigger — is how candidates burn time and pick plausible-but-wrong answers.
Every run page carries three layers of evidence. The run header names the triggering event, actor, branch, and commit — that's the trigger layer. The Set up job log section in every job shows the resolved runner image and version, the resolved environment variables, and — critically — the exact versions of every action downloaded. Then the step logs carry the actual commands and their output. Work outside-in.
⚠️ Common Misconception: "Re-running a failed workflow picks up the fix I just pushed." A re-run replays the same commit SHA with the same workflow file version as the original run. Re-run is for flaky infrastructure, not for testing changes — to test a fix, push it and let a new run trigger. (Re-running only failed jobs reuses successful jobs' results; re-running all jobs starts the whole run over, still at the original SHA.)
