GitHub Actions

The blueprint

A mock exam here has 60 questions in 100 minutes, split across the domains in the same proportions as the official exam guide. The official pass mark is 700 of 1,000 (scaled). FixOps scores practice against a target of 75%.

1. 01

   Author and manage workflows

   24%

2. 02

   Consume and troubleshoot workflows

   19%

3. 03

   Author and maintain actions

   19%

4. 04

   Manage GitHub Actions for the enterprise

   24%

5. 05

   Secure and optimize automation

   14%

Sample questions

Three of the 10 questions in the free diagnostic. Open one to see the answer and why.

Revision notes: Author and manage workflows

The notes for one domain, free to read here and in the app. FixOps Pro has them for all 5 domains.

Choosing triggers and inputs, structuring jobs and steps with conditions and dependencies, using contexts, expressions, matrices and service containers, and passing data with outputs, environment files, caches and artifacts.

Triggers and inputs

• schedule uses POSIX cron, in UTC unless a time zone is set, runs from the default branch, and fires at most every 5 minutes.
• Many events, including schedule, workflow_dispatch and issue_comment, only run when the workflow file exists on the default branch.
• workflow_dispatch inputs can be boolean, choice, number, environment or string; up to 25 inputs.
• The inputs context keeps booleans as booleans, while github.event.inputs holds strings.
• workflow_call inputs must declare a type: boolean, number or string; passing an undeclared input is an error.
• pull_request without types runs for opened, synchronize and reopened.
• paths and paths-ignore cannot be combined for one event; use paths with ! patterns to exclude.
• When branch and path filters are both set, both must match; path filters are not evaluated for tag pushes.
• repository_dispatch carries an event_type and a client_payload from an external system.
• workflow_run starts after another workflow whatever its result; check github.event.workflow_run.conclusion.

Jobs, steps and conditions

• A job whose needs failed or were skipped is skipped, unless its if uses always(), failure() or !cancelled().
• if is evaluated as an expression, but a condition starting with ! must use ${{ }} or quotes.
• A job's if is evaluated before its matrix, so it cannot use matrix values.
• Secrets cannot be used directly in if; map them to env and test the variable.
• timeout-minutes defaults to 360; hosted jobs stop at 6 hours and self-hosted jobs at 5 days.
• Environment variables resolve from the most specific level: step, then job, then workflow.
• Inside a job container, run steps default to sh rather than bash.
• run-name names each run and can use the github and inputs contexts.

Contexts, expressions and YAML reuse

• github.ref is the full ref such as refs/heads/main; github.ref_name is the short name.
• Expressions in ${{ }} are evaluated before a run script is created, which is why untrusted values belong in env.
• A workflow-level concurrency group can use the github, inputs and vars contexts.
• hashFiles() builds cache keys that change only when the hashed files change.
• YAML anchors (&name) and aliases (*name) repeat content within one workflow file.

Matrices and service containers

• A matrix runs one job per combination, up to 256 jobs per workflow run.
• include adds values to matching combinations or creates new ones; exclude removes partial matches first.
• fail-fast defaults to true and cancels the other legs when one fails; max-parallel caps concurrency.
• Pin a specific runner image label while adapting to a change of an -latest label.
• A job running in a container reaches a service by its label as host name; a job on the runner uses localhost and mapped ports.
• Docker health check options on a service make the runner wait until it is healthy.
• Service containers, job containers and Docker actions need a Linux runner.

Passing data and recording results

• GITHUB_ENV sets variables for later steps; the writing step does not see the new value.
• GITHUB_OUTPUT sets step outputs, read as steps.<id>.outputs.<name>.
• Job outputs map step outputs and are read through needs; at most 1 MB per job and 50 MB per run.
• GITHUB_PATH prepends a directory to PATH for later steps.
• Multi-line values use NAME<<DELIMITER, the lines, then the delimiter.
• Artifacts move files between jobs and outlive the run; retention-days shortens one artifact's life.
• GITHUB_STEP_SUMMARY shows Markdown on the run page, up to 1 MiB per step.
• A badge URL ends in badge.svg and accepts ?branch= and ?event=.
• Environments add protection rules such as required reviewers, and deployment: false uses their secrets without a deployment.
• concurrency with cancel-in-progress stops superseded runs; queue: max keeps up to 100 waiting.

Easy to mix up

• inputs keeps booleans; github.event.inputs turns them into strings.
• GITHUB_ENV reaches later steps of the same job; job outputs reach other jobs.
• always() also runs after a cancellation; !cancelled() does not.
• include adds combinations or values; exclude removes them, and include is applied last.
• A job container reaches services by name; a job on the runner reaches them on localhost.