Study notes · 10% of the exam

GitHub Actions and CI/CD

GitHub Actions runs YAML workflows from .github/workflows on events. Know how triggers and filters decide whether a run is created, how jobs, steps, outputs and matrices fit together, and how secrets, GITHUB_TOKEN permissions and runner choice shape security.

Key points

1
Triggers live under on:. With both branches and paths set, both must match; pull_request runs by default only for opened, synchronize and reopened.
2
Jobs run on separate fresh runners. Pass small values with step outputs ($GITHUB_OUTPUT) mapped to job outputs:, and files with artifacts.
3
needs: jobs are skipped when a dependency fails unless you use a status function such as always(), failure() or !cancelled().
4
Fork pull requests get no secrets and a read-only GITHUB_TOKEN; pull_request_target has secrets, so never run the PR's code in it.
5
Set least-privilege permissions:; listing any permission sets the rest to none. Prefer OIDC (id-token: write) over long-lived cloud keys.
6
Never interpolate untrusted context values like PR titles into run:; pass them through environment variables. Pin third-party actions to a full commit SHA.
7
actions/cache matches key exactly then restore-keys by prefix, can't overwrite an existing cache, and only reads caches from the current, base and default branches.

Common traps

Events triggered with the repository GITHUB_TOKEN (such as its pushes) don't start new workflow runs.
With no shell: key, bash runs without pipefail, so a failing command piped into tee can let the step pass.
A required check whose workflow is skipped by a paths filter stays Pending and blocks the merge.

Read the source

Test yourself on GitHub Actions and CI/CD

Ten questions, with the answer and explanation after each one.