Reviewed 10 October 2026 against the linked published scope. January 2026 outline: workflow authoring 20–25%, consumption/troubleshooting 15–20%, action authoring 15–20%, enterprise management 20–25%, security/optimization 10–15%.
Memory hook: Choose the event, trace the trust boundary, then follow data and permissions through jobs.
Read the essentials, cover the answers and explain the decision aloud. Open the topic summaries below whenever a distinction is unclear.
Workflow structure and evaluation
- YAML workflows live in
.github/workflows. Events choose when/ref context; jobs choose runners; steps run actions or shell commands.needsadds job dependencies; steps within a job normally run sequentially. workflow_dispatchaccepts manual inputs;workflow_calldefines a reusable workflow interface. Scheduled runs use default-branch behavior and can be delayed. Select events by required trust and execution semantics, not only convenience.pull_requestandpull_request_targethave materially different trust/permission contexts. Never combine privileged credentials with checkout/execution of untrusted contribution code merely to make a fork build work.- A matrix expands combinations.
include/excluderefine them;fail-fastandmax-parallelcontrol behavior/capacity. A large matrix can multiply cost and queue time. - Contexts such as
github,inputs,matrix,needs,steps,varsandsecretsexpose different data at different stages. Server-side expression evaluation is not the same as shell variable expansion on a runner. - Service containers provide dependencies such as databases; verify supported runner OS, network names/ports and health. Anchors/aliases reuse YAML nodes; preserve the guide's caveat about merge mappings versus documented runtime support.
Data, reuse and custom actions
- Write step outputs to
GITHUB_OUTPUT; expose job outputs and consume throughneeds.GITHUB_ENVsets environment for later steps of that job, not the step writing it or every other job.GITHUB_STEP_SUMMARYwrites Markdown to a run summary. - Artifacts carry explicit build/test files across jobs/runs according to access/retention. Caches accelerate repeat dependencies through keys/fallbacks. A cache hit is not a verified release artifact or a secret store.
- A starter workflow copies a scaffold; a reusable workflow centrally defines jobs called with
workflow_call; a composite action groups step logic. Pin dependencies and make input/output/secret interfaces explicit. - Actions can use JavaScript, Docker or composite execution.
action.yml/action.yamldeclares metadata, inputs, outputs and execution. Docker actions need an appropriate Linux environment; JavaScript runtime support follows declared/current platform support. - Release immutable references where suitable. A full commit SHA identifies an action version more precisely than a movable major tag. Test supported OS/runtime and failure behavior before distribution.
Runners, governance and security
- Hosted runners supply managed images; self-hosted runners require patching, isolation, tool management and cleanup. Runner labels select capability; groups scope access. Untrusted jobs on persistent privileged runners can compromise later work.
- Inspect event, actor, ref, workflow revision, permissions and first meaningful error. Correlate matrix job names to inputs. Image updates, missing dependencies, egress, disk and token scopes cause different failure modes.
- By default, a concurrency group permits one running and one pending run/job; newer pending work replaces the previous pending item even when running-work cancellation is disabled. Do not assume every deployment will be durably queued. Explicit queuing options have their own limits and compatibility rules. Environment protections gate eligible deployments and secrets; organization/enterprise policy can restrict actions, workflow access and runners.
GITHUB_TOKENis a job-scoped temporary token with configurable permissions; a PAT has separate identity/scope/lifetime. Set minimal permissions. Configuration variables are not secret storage; scope secrets at organization/repository/environment appropriately.- OIDC permits short-lived cloud federation.
id-token: writeallows requesting an identity token, not unrestricted cloud access; the cloud trust policy must restrict issuer/audience/subject claims and granted roles. - Treat PR titles, branches, issue bodies and downloaded artifacts as untrusted data. Avoid injecting expressions directly into shell source; use data/environment inputs with appropriate quoting and validation.
- Verify artifact attestations/provenance as part of deployment policy. A signature is evidence of origin/build, not proof the software is harmless. Apply retention, targeted matrices and caching to control cost.
Traps
- Secrets do not automatically pass safely through every reusable workflow or event.
- Masking logs does not sanitize all transformations of a secret.
- A trusted workflow processing an untrusted artifact still crosses a trust boundary.
Final active recall
1. Output versus artifact versus cache?
Small structured job data, explicit build/test files, and reusable performance data respectively.
2. Does id-token: write grant cloud administrator access?
No. It permits token issuance; cloud trust and role policy govern access.
3. Why is pull_request_target with untrusted checkout dangerous?
It can expose a privileged execution context to attacker-controlled code.
4. Does GITHUB_ENV change the current writing step environment?
No. It is made available to subsequent steps in that job.
5. Starter versus reusable workflow?
A starter is copied and maintained separately; a reusable workflow is called as a versioned shared definition.
Sources and further practice
- Official exam scope
- Objective-to-topic coverage map. Each full topic links to its supporting primary technical documentation.
- GitHub Actions documentation
Every topic at a glance
Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.
01 · Events, Inputs and Workflow Trust
Memory hook: The trigger chooses both the event and the trust boundary.
Must remember
Workflow files live under .github/workflows/ and declare events with on. Push and pull-request events support branch/path filters; when both apply, reason about their combined conditions. Manual workflow_dispatch inputs can be typed and required. workflow_call exposes a reusable workflow interface with declared inputs/secrets. repository_dispatch receives an external event through the API.
Scheduled workflows use supported cron scheduling and default-branch behavior; they are not precise real-time schedulers and may be delayed. Know which events require the workflow file on the default branch. Inspect event action types and payload fields rather than assuming every event contains a pull-request number.
Untrusted contribution workflows need restricted permissions and secrets. pull_request_target runs in the base-repository context and requires special care; never combine privileged credentials with execution of untrusted proposed code. Current checkout safeguards help, but they do not make every downloaded script or artifact trusted.
Validate manual/external inputs against the operation's expected values. A declared string input can still contain malicious shell characters. Pass data through safe environment/argument handling and validate it; do not interpolate untrusted expressions directly into executable script text.
Set permissions at the smallest suitable scope and choose events that fit the required operation. Prevent unintended recursive automation while understanding exceptions for explicit dispatches. A successful token-authenticated API call does not necessarily trigger every downstream workflow as a human push would.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Human starts a parameterized workflow | workflow_dispatch with validated inputs. |
| A workflow calls shared orchestration | workflow_call. |
| Test a fork contribution | Restricted untrusted-code workflow without privileged secrets. |
Traps
- An event name alone does not prove its payload has every expected field.
- A privileged base-context workflow must not execute untrusted PR code.
02 · Jobs, Matrices and Evaluation Context
Memory hook: Jobs form the graph; steps share a job; contexts supply data.
Must remember
Jobs run independently unless needs declares dependencies. Steps within a job run in order on that job's runner. Separate jobs do not share a filesystem by default. if controls eligibility, and status functions influence behavior after failure/cancellation; use cleanup conditions carefully so they do not create hangs or unwanted deployment.
A matrix expands combinations such as OS and runtime version. include adds/adjusts combinations; exclude removes combinations. fail-fast controls cancellation of related matrix jobs after failures, while max-parallel limits concurrent variants. Count the expanded jobs before estimating runtime or cost.
Expressions use contexts such as github, inputs, matrix, needs, steps, runner, vars and secrets. Workflow evaluation and runner-shell expansion occur at different times. Environment variables available in a shell are not automatically available in every workflow expression field. Preserve types deliberately when working with boolean inputs and JSON outputs.
Service containers provide dependencies such as a test database, with ports and health checks. A job running inside a container reaches services differently from a job directly on the runner; use the appropriate hostname/port mapping. Container support depends on runner OS/platform.
YAML anchors (&) name reusable nodes; aliases (*) reference them. A YAML merge key (<<) conventionally combines mappings, with explicit keys overriding merged values. The exam outline names merge mappings, but verify runtime support rather than assuming all YAML processors implement them. Editor schema/Actions extensions catch many structural mistakes; they cannot prove the workflow is secure or correct.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Deploy only after two test jobs pass | needs dependencies and suitable conditions. |
| Test several OS/runtime pairs | A bounded matrix. |
| Database required only for integration tests | A service container with readiness checks. |
Traps
- GITHUB_ENV does not share files or variables with a different job.
- A valid YAML document is not necessarily a valid Actions workflow.
03 · Outputs, Artifacts, Caches and Summaries
Memory hook: Outputs carry small values; artifacts carry deliverables; caches save repeat work.
Must remember
Write step outputs through GITHUB_OUTPUT, then map them to job outputs for dependent jobs using needs. GITHUB_ENV sets environment values for later steps in the same job; the writing step must still use its local value normally. Use correct multiline delimiters and do not place secrets in public outputs or summaries.
Artifacts persist selected files such as build products and test reports across jobs/runs under retention policies. Upload only intended paths; broad directory uploads can leak credentials or source data. An artifact's name is not proof of origin or integrity. Verify digest/provenance where the deployment trust model requires it.
Caches speed repeat dependency/build work. Keys should reflect relevant OS, toolchain and lockfile inputs; restore-key fallback can retrieve less exact matches. A cache miss should slow a correct build rather than make it impossible. Never treat caches as durable release storage or a safe place for secrets.
GITHUB_STEP_SUMMARY adds Markdown to the run's job summary. Keep reports concise and link appropriate artifacts/logs. Status badges show workflow status for a configured branch/event; they are not evidence that a particular production deployment passed.
Manage retention at supported repository/organization levels and through appropriate APIs for logs, runs and artifacts. Short retention saves storage but can remove incident/debug evidence. Set environment protections for deployment jobs and preserve the exact built artifact through promotion instead of silently rebuilding different bytes for production.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Pass a version string to a dependent job | Step output mapped to job output. |
| Keep a test report for review | Artifact with deliberate retention. |
| Avoid re-downloading unchanged dependencies | Cache keyed by relevant dependency/toolchain inputs. |
Traps
- A cache is not a release archive.
- The step writing GITHUB_ENV does not magically re-read its environment.
04 · Debugging Runs and Controlling Cost
Memory hook: Read the first meaningful failure before rerunning everything.
Must remember
Start with event, ref/commit, actor, workflow version and permissions. A workflow that never started needs trigger/filter/default-branch investigation; a queued job needs runner/concurrency/capacity investigation; a started job needs step logs and exit status. These are different failure layers.
Inspect the first meaningful error, not only the final failed cleanup line. Enable supported debug logging only as needed and review exposure risk. Compare successful and failing runs for runner image, dependency version, input, secret scope and environment differences. ubuntu-latest or windows-latest can move to new images; pin explicit supported versions when stability is required and maintain them deliberately.
Matrix job names identify failing combinations. Rerun a specific failed variant when appropriate, while understanding which workflow/action refs are resolved again. A floating branch/tag may now point to different code; pinning a commit makes provenance clearer. Download logs/artifacts through the UI or authorized API/CLI for focused analysis.
Concurrency groups limit overlapping work. By default, a group permits one running and one pending run/job; a newer pending item replaces the previous pending item even when cancel-in-progress is false. Do not assume this is a durable queue for every deployment. Explicit queuing options have separate limits and compatibility rules. Canceling an old test run differs from interrupting a production migration. Bound matrices, use path filters carefully, parallelize independent work and cache expensive repeat dependencies. Skipping tests only to lower minutes can remove the control that justified deployment.
Disabling a workflow stops future eligible execution without being the same as deleting its file/history. Deleting runs or artifacts removes evidence and may affect retention needs. Measure queue time, run duration, failure/retry rates and storage usage; optimize the actual expensive path rather than assuming the longest visible job is the only cost.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| No workflow run exists | Inspect trigger, branch/path filters and workflow availability. |
| Job remains queued | Inspect runner labels/groups, availability and concurrency. |
| Only one OS variant fails | Compare image/toolchain and that matrix job’s logs. |
Traps
- Rerunning a floating reference may execute changed code.
- Cancel-in-progress can be unsafe for noninterruptible deployment operations.
05 · Reusable Workflows, Templates and Enterprise Policy
Memory hook: Copy a starter; call a workflow; compose steps in an action.
Must remember
A starter workflow is a scaffold copied into a repository and then maintained there. A reusable workflow is called through a job-level uses reference and a workflow_call interface. A composite action packages steps and is invoked within a job. Choose the unit that matches ownership and execution requirements.
Declare reusable inputs, secrets and outputs as an interface. Callers pass supported values explicitly or use permitted secret inheritance. Workflow-level env does not automatically become the called workflow's environment. Map outputs back through the reusable interface when a caller needs a result.
Private/non-public templates and reusable workflows need suitable visibility/access settings. Both caller policy and the called repository's sharing configuration matter. A nested call cannot elevate the caller's token permissions. Pin approved versions and test upgrades with representative consumers before broad rollout.
Organization/enterprise policies can restrict allowed actions, require approved sources and control runner access. A Marketplace listing alone does not satisfy a company's trust policy. Central reuse reduces drift, but a central mistake affects many repositories; staged release and rollback remain necessary.
Use meaningful template metadata so developers can discover suitable starters. Treat a copied starter as independent code thereafter: fixing the central template does not automatically update every existing repository. Track adoption and update paths explicitly rather than assuming all consumers are current.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Standardize a full multi-job pipeline | Reusable workflow. |
| Package a few repeated steps | Composite action. |
| Give teams an editable starting example | Starter workflow/template. |
Traps
- A template update does not automatically patch existing copies.
- A nested workflow cannot increase token permissions beyond its caller.
06 · Custom Actions, Metadata and Releases
Memory hook: The action is a product with an interface and a supply chain.
Must remember
JavaScript actions run the supported runtime declared in action metadata. Docker container actions package an execution environment and require a compatible runner platform. Composite actions combine steps and require explicit shell/working-directory handling where appropriate. Choose based on portability, dependency isolation and maintenance needs.
An action uses action.yml or action.yaml to declare name, description, inputs, outputs and runs behavior. Metadata defaults and required declarations do not replace runtime validation for every input path. Document side effects and permissions, return useful errors and avoid logging secrets.
Workflow commands and environment files communicate outputs, annotations, path changes and summaries. Untrusted output must not be allowed to impersonate control instructions or inject shell code. A Docker action needs intentional entrypoint/argument behavior; a JavaScript action needs packaged runtime dependencies so consumers are not dependent on a developer's local node_modules.
Test supported operating systems, runtimes, failure paths and upgrade behavior. The chosen JavaScript runtime and minimum runner compatibility evolve; follow current action metadata/runtime documentation. A composite step can fail because a tool exists on one image but not another.
Distribute privately, publicly or through Marketplace as appropriate. Publish clear versions and changelogs. A full commit SHA identifies source precisely; floating major tags offer convenient updates but can change. Where immutable release/action mechanisms apply, understand their guarantees and compatibility rather than assuming every tag is immutable. Consumers should verify source, permissions and provenance before executing it.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Cross-platform logic using a supported JS runtime | JavaScript action. |
| Controlled Linux container environment | Docker action on compatible runners. |
| Reuse existing shell/actions steps | Composite action. |
Traps
- Marketplace publication is not a security audit.
- An action that worked on a developer laptop may omit needed packaged dependencies.
07 · Hosted and Self-Hosted Runner Operations
Memory hook: A runner is a security boundary and an operating responsibility.
Must remember
GitHub-hosted runners provide managed job environments with published images/tooling. Self-hosted runners give control over hardware, installed software and network reachability, but the organization owns patching, isolation, cleanup and capacity. A machine inside a private network can expose that network to whatever code it executes.
runs-on labels select eligible runners; runner groups restrict repository/workflow access. Labels describe matching capability, not a security permission by themselves. Check group policy, runner online status, labels and capacity when jobs queue. Separate trust levels and avoid executing untrusted public contributions on persistent privileged infrastructure.
Prefer ephemeral, isolated execution where suitable. Remove job residue, restrict outbound/internal access and avoid credentials on the host that exceed the job's need. Containerized steps do not automatically make a compromised persistent host safe. Keep the runner application and system dependencies supported.
Hosted image release notes and tool caches show available software. Use setup actions or controlled installation for required versions, with caches/images where appropriate. A latest image label is a moving target. Network access, proxies, IP allow lists and registry/package endpoints must support the actual job path.
Scale from queue depth, concurrency and job duration, while considering startup delay and cost. Larger runners can shorten some jobs but do not fix serialized workflows or slow external services. Autoscaling should remove unused capacity safely after work completes. Audit which repositories can reach sensitive runner groups and review changes to those permissions.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Need private network access and specialized hardware | A carefully isolated self-hosted or suitable managed runner design. |
| Restrict production-capable runners | Runner group policy plus scoped workflow access. |
| Job queues despite an online runner | Check labels, group access, capacity and platform requirements. |
Traps
- A label is not an authorization boundary.
- A self-hosted runner can retain hostile state between jobs.
08 · Secrets, OIDC and Artifact Trust
Memory hook: Give the job a narrow identity, then verify what it produced.
Must remember
Configuration variables are readable configuration, not secret storage. Secrets can be scoped at organization, repository and environment levels under access policies. Environment protections can gate deployment access. Check precedence and availability rather than assuming a secret exists in every fork, reusable workflow or environment context.
GITHUB_TOKEN is an automatically issued job token with a limited lifecycle and configurable permissions. Set only required scopes; an omitted scope in an explicit permissions map is not automatically granted broadly. A personal access token has a different owner/lifecycle and should be used only when justified. Secret masking reduces accidental display but is not a guarantee against transformations or intentional exfiltration.
OIDC federation lets a job exchange an identity token for temporary cloud credentials. id-token: write permits requesting that token; it does not itself grant cloud-resource permissions. The cloud trust policy must constrain issuer, audience and claims to approved repository/workflow/environment contexts. A broadly trusted subject can undo the benefit of removing a long-lived secret.
Treat issue titles, branch names, PR text and artifacts from untrusted runs as data. Avoid inserting them directly into run scripts; use validated inputs and safe argument/environment handling. Review third-party actions, pin full commit SHAs where appropriate and maintain approved updates. Permissions, provenance and runner isolation complement version pinning.
Artifact attestations establish supported build provenance and integrity claims. Verify expected repository/workflow/identity and digest before deployment, not merely that some signature exists. An attestation does not prove code is vulnerability-free or business-correct. Use required reviewers, protected environments and a tested rollback for consequential deployment.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Cloud deployment without permanent cloud keys | OIDC with narrow cloud trust and role permissions. |
| Verify where an artifact came from | Attestation verification against expected identity and digest. |
| Untrusted PR title needed by a script | Pass as validated data with safe shell handling. |
Traps
- id-token: write does not authorize arbitrary cloud operations.
- Signed provenance is not proof of vulnerability-free code.