GitHub Actions Interview Questions (2026): With Answers

A workflow is an automated process defined in a YAML file under .github/workflows/ in the repository. Each file describes one or more jobs that run when a trigger fires, a push, a pull request, a schedule, or a manual dispatch.

name: CI
on:
 push:
  branches: [main]
 pull_request:

jobs:
 test:
  runs-on: ubuntu-latest
  steps:
   - uses: actions/checkout@v4
   - run: npm test

A repo can have any number of workflow files, and each one is independent. There's no requirement that they share triggers or runners.

A job is a set of steps that execute on the same runner. Jobs run in parallel by default, each getting its own fresh virtual machine or container, unless you use needs to force an order. A step is a single task inside a job, either a shell command via run or a call to a reusable action via uses. Steps in the same job share the filesystem and can pass data forward through outputs.

An event is anything that can trigger a workflow run, most commonly a repository activity like push, pull_request, or issues, but also a schedule (schedule, cron syntax) or a manual trigger (workflow_dispatch). A single workflow file can list several events under on, and the same job can behave differently depending on which event fired it by checking github.event_name.

An action is a reusable unit of code that performs one specific task, checking out a repo, installing a language toolchain, publishing a package, and gets invoked from a step with uses. A workflow is the file that orchestrates a sequence of actions and shell commands into jobs. Actions are the building blocks; a workflow is the recipe that calls them in order.

A runner is the machine, virtual or physical, that actually executes a job's steps. GitHub-hosted runners (ubuntu-latest, windows-latest, macos-latest) are fresh VMs GitHub provisions and tears down per job, with common tools preinstalled. Self-hosted runners are machines you register and manage yourself, useful when you need specific hardware, network access to internal resources, or persistent local caches the hosted runners can't offer.

A fresh runner starts with an empty filesystem, no copy of your repository. actions/checkout clones the repo (by default, a shallow clone of the triggering commit) into the runner's workspace so later steps have something to build or test against. Skip it and any step that expects source files to exist just fails immediately.

steps:
 - uses: actions/checkout@v4
 - run: npm test

run executes a shell command or script directly, whatever the default shell for that OS is, unless overridden. uses invokes a packaged action, someone else's (or your own) reusable code, referenced by repo path and version. A step has exactly one or the other, never both.

Add workflow_dispatch to the on block, optionally with an inputs map describing each field. GitHub then shows a "Run workflow" button on the Actions tab with a form built from those inputs, or you can trigger the same run through the API or CLI with the input values as parameters.

on:
 workflow_dispatch:
  inputs:
   environment:
    description: Target environment
    required: true
    default: staging

Use the schedule trigger with standard five-field cron syntax, always in UTC. The catch: GitHub explicitly does not guarantee your scheduled workflow runs at the exact minute you specified, especially during periods of high load across all of GitHub's infrastructure, a scheduled run can be delayed by minutes without it counting as a failure.

on:
 schedule:
  - cron: '0 2 * * *' # 2 AM UTC daily

From the Actions tab, a completed run has a "Re-run failed jobs" option alongside "Re-run all jobs." Re-running only failed jobs skips any job that already succeeded and reuses its outputs, which matters most on a long matrix build where one flaky combination failed and you don't want to burn runner minutes rebuilding everything else that already passed.

GITHUB_WORKSPACE is the default working directory on the runner, where actions/checkout puts the cloned repo and where run steps execute by default. Two jobs can't share it directly, though, because each job gets its own fresh runner and workspace. Passing files between jobs requires actions/upload-artifact in the first job and actions/download-artifact in the second.

needs lists the job IDs a job depends on, forcing it to wait until those jobs finish before starting. By default, if any job in the needs list fails, the dependent job is skipped entirely rather than run.

jobs:
 build:
  runs-on: ubuntu-latest
  steps: [...]
 deploy:
  needs: build
  runs-on: ubuntu-latest
  steps: [...]

To run a job even when a dependency failed, add if: always() or if: failure() on the dependent job, which overrides the default skip behavior.

Use runs-on with the labels assigned to the self-hosted runner when it was registered, instead of a GitHub-hosted label like ubuntu-latest. Self-hosted runners always carry the self-hosted label plus whatever custom labels you add, and every registered self-hosted runner also gets OS and architecture labels automatically.

runs-on: [self-hosted, linux, gpu]

timeout-minutes set at the job or step level forces GitHub Actions to cancel that job or step if it's still running past the limit, which matters because the default timeout for an entire job is 360 minutes, six hours, plenty of time for a hung process or an infinite retry loop to burn through a lot of billed runner time before anyone notices.

jobs:
 test:
  timeout-minutes: 15
  runs-on: ubuntu-latest

Separate jobs get their own runner, run in parallel where there's no dependency between them, and can be individually retried, one failed deploy job doesn't force you to rerun a build that already succeeded. Splitting also lets you attach different permissions to each job, the build job needs no write access at all, while only the deploy job needs the credentials to actually push to production.

A matrix strategy defines one or more variables, and GitHub Actions runs the job once for every combination of their values, in parallel, up to the account's concurrency limits. It's the standard way to test the same code across multiple language versions or operating systems without duplicating the job definition.

jobs:
 test:
  strategy:
   matrix:
    node: [18, 20, 22]
    os: [ubuntu-latest, windows-latest]
  runs-on: ${{ matrix.os }}
  steps:
   - uses: actions/setup-node@v4
    with:
     node-version: ${{ matrix.node }}

That example spins up six separate jobs. Add exclude to drop specific combinations, or include to add one-off combinations that don't follow the cross-product pattern.

By default, fail-fast is true for a matrix strategy, so the moment any one combination fails, GitHub Actions cancels every other in-progress job in that matrix. That's useful for saving runner minutes on a build that's clearly broken everywhere, but it hides whether the failure is specific to one combination or universal.

strategy:
 fail-fast: false
 matrix:
  node: [18, 20, 22]

Setting fail-fast: false lets every combination run to completion independently, which is what you want while you're actually diagnosing a cross-version compatibility bug rather than just gating a merge.

Both use the same expression syntax, but a job-level if decides whether the entire job, and everything downstream that needs it, runs at all. A step-level if only skips that one step; the rest of the job continues normally, and later steps can still reference the skipped step's context (its outcome will show as skipped).

jobs:
 deploy:
  if: github.ref == 'refs/heads/main'
  runs-on: ubuntu-latest
  steps:
   - name: Notify Slack
    if: failure()
    run:./notify.sh

The github context carries metadata about the triggering event and repo state, github.event specifically is the full JSON payload of whatever event fired the workflow (a pull request's title, a pusher's username). The env context reads environment variables set anywhere in the workflow, at the workflow, job, or step level. The secrets context exposes configured secrets by name, and GitHub automatically redacts any value pulled from it before it can appear in logs, even if a step accidentally echoes it.

Variables in an env map are evaluated independently and can't reference each other within that same map, because they're not resolved in a guaranteed order, per GitHub's own workflow syntax documentation (GitHub Docs, Workflow syntax for GitHub Actions). If you need one variable derived from another, compute it in a run step and write it to $GITHUB_ENV, which does support sequential, order-dependent assignment across steps.

steps:
 - run: echo "BUILD_ID=${{ github.run_id }}-${{ github.run_attempt }}" >> "$GITHUB_ENV"
 - run: echo "Build was $BUILD_ID"

Define an output on the source job's step, reference it in the job's outputs map, then read it in the dependent job through the needs context.

jobs:
 build:
  runs-on: ubuntu-latest
  outputs:
   version: ${{ steps.get_version.outputs.value }}
  steps:
   - id: get_version
    run: echo "value=1.4.0" >> "$GITHUB_OUTPUT"
 deploy:
  needs: build
  runs-on: ubuntu-latest
  steps:
   - run: echo "Deploying ${{ needs.build.outputs.version }}"

Outputs only flow through jobs listed in needs. A job that doesn't explicitly depend on the source job has no way to read its outputs, even if it runs later in practice.

Set defaults.run.working-directory at the job or workflow level, and every run step inherits it unless a step overrides it individually with its own working-directory key. This is the common fix for a monorepo where every command in a job needs to execute from the same subdirectory, rather than prefixing each step with its own cd.

jobs:
 build:
  defaults:
   run:
    working-directory: services/billing
  steps:
   - run: npm ci
   - run: npm run build

Composite actions bundle several existing steps, shell commands and other actions, into one reusable unit, and they're the right default when you're just trying to stop copy-pasting the same five steps across workflows. JavaScript actions run directly on the runner without container overhead, execute fast, and work across Linux, Windows, and macOS, but the code has to be pure JavaScript with no external binaries the runner doesn't already have. Docker container actions package a full environment, OS, tools, dependencies, guaranteeing consistency at the cost of slower startup and Linux-only runners (GitHub Docs, About custom actions).

A composite action needs an action.yml that declares using: composite and lists the same kind of steps you'd write directly in a workflow.

name: Build App
runs:
 using: composite
 steps:
  - uses: actions/setup-node@v4
   with:
    node-version: 20
  - run: npm ci
   shell: bash
  - run: npm run build
   shell: bash

The shell key is required on every run step inside a composite action, unlike in a regular workflow job where defaults.run.shell can set it once for everything.

workflow_call is a trigger that lets one workflow file invoke another whole workflow, jobs and all, as a unit, passing inputs, secrets, and reading back outputs. A composite action bundles steps inside a single job; a reusable workflow bundles entire jobs, which means it can define its own matrix strategy, its own runs-on, and multiple jobs with their own dependency graph, none of which a composite action can do.

#.github/workflows/deploy.yml
on:
 workflow_call:
  inputs:
   environment:
    required: true
    type: string
  secrets:
   DEPLOY_TOKEN:
    required: true
jobs:
 deploy:
  runs-on: ubuntu-latest
  steps:
   - run:./deploy.sh --env ${{ inputs.environment }}
    env:
     TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Pin the action to a full-length commit SHA instead of a version tag or branch name. GitHub's own hardening guidance states that pinning to a full commit SHA is currently the only way to use an action as a truly immutable reference (GitHub Docs, Security hardening for GitHub Actions). A tag like @v4 can be moved to point at different code at any time, by the maintainer or by an attacker who compromises the maintainer's account, and your workflow would silently start running whatever that tag now points to.

# risky, tag can move
- uses: some-org/some-action@v4

# safe, immutable
- uses: some-org/some-action@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

A concurrency group is a name, which can include an expression, that ensures only one job or workflow run sharing that group name is active at a time. Anything else queued under the same group waits its turn. cancel-in-progress: true changes that behavior so a new run in the group cancels whatever's already running instead of waiting behind it, which is the common setting for CI on a PR branch where only the latest push actually matters.

concurrency:
 group: ci-${{ github.ref }}
 cancel-in-progress: true

Combine a matrix over os with a step-level if that checks matrix.os, or split the deploy step into its own job that only depends on the Linux leg of the matrix.

strategy:
 matrix:
  os: [ubuntu-latest, windows-latest]
runs-on: ${{ matrix.os }}
steps:
 - run: npm run build
 - name: Deploy
  if: matrix.os == 'ubuntu-latest'
  run:./deploy.sh

GITHUB_TOKEN is an automatically generated, scoped credential GitHub creates for every workflow run, used for actions that need to talk back to the repo, commenting on a PR, pushing a tag, creating a release. GitHub's hardening guidance recommends setting the organization or repository default to read-only access to contents, then explicitly elevating permissions per workflow or per job only where a step genuinely needs write access.

permissions:
 contents: read
 pull-requests: write  # only where actually needed

No, not for the standard pull_request trigger. Secrets configured in the base repo aren't exposed to workflows running against a fork's code under that trigger, which is exactly why some teams reach for pull_request_target to get access back, often without weighing the tradeoff described above. If a workflow genuinely needs to publish results that require a secret against fork PRs, the safer pattern is to split it into two workflows, one untrusted build job with no secrets, and a second privileged job triggered by workflow_run that only reads artifacts the first job produced.

GitHub automatically redacts secret values from workflow logs, but it does that by matching the literal registered string. A structured blob, a whole JSON credentials file stuffed into one secret, only gets redacted as that exact blob. If any step logs a single field pulled out of it, that field's value was never separately registered as a secret, so it prints in plain text. Registering each sensitive value as its own named secret means every individual value is covered by redaction, not just the whole blob.

Rotate the credential immediately, treat it as compromised the moment it's visible in a log regardless of who could plausibly have seen it. Delete the exposed log, since GitHub's own redaction only works going forward on values it already knows about, it doesn't retroactively scrub a log that already rendered before the secret was masked. Rotating first and deleting the evidence second, not the other way around, since the log deletion doesn't undo the exposure that already happened.

A cache is meant to speed up future runs by reusing dependencies or build intermediates, node_modules, a compiled Rust target directory, across separate workflow runs, keyed by a hash you control. An artifact is a workflow run's output, a built binary, a test report, a coverage file, meant to be downloaded by a human or passed to a later job in the same run. Caches are best-effort and can be silently evicted; artifacts are the durable output you actually rely on existing.

It first looks for an exact match on key. If none exists, it falls back through restore-keys in the order you listed them, matching by prefix, and restores the most recently created cache matching the first prefix that hits at all. That's a partial hit, not an exact one, and the job still needs to run whatever install step would populate the parts that changed, since a partial hit is a starting point, not a guarantee.

- uses: actions/cache@v4
 with:
  path: ~/.npm
  key: npm-${{ hashFiles('package-lock.json') }}
  restore-keys: |
   npm-

The default repository cache limit is 10GB total, and GitHub automatically evicts unused caches after 7 days regardless of size. Once a repo goes over the 10GB cap, GitHub evicts the least recently accessed caches first to make room, which means a cache you rely on can silently disappear if the repo accumulates a lot of matrix-variant cache keys that never get cleaned up on their own.

An environment is a named deployment target, staging, production, that a job can reference to attach environment-specific secrets, variables, and protection rules. A protection rule can require manual approval from specific reviewers before the job proceeds, restrict which branches are allowed to deploy to that environment, or add a wait timer. The job pauses at that point in the run until the rule's condition is satisfied, rather than failing outright.

jobs:
 deploy:
  environment: production
  runs-on: ubuntu-latest
  steps:
   - run:./deploy.sh

Use paths or paths-ignore under the trigger event to filter which file changes actually kick off the workflow, useful in a monorepo where a change to one service's directory shouldn't rebuild every other service.

on:
 push:
  paths:
   - 'services/billing/**'

The filter only applies to push and pull_request events; a manually triggered workflow_dispatch run ignores path filters entirely and always runs, which surprises people the first time they test one manually.

List the matrix job's ID once in needs, not once per combination. GitHub Actions treats a matrix job as a single job entity for dependency purposes, and a downstream job that needs it won't start until every generated combination has finished, and will be skipped if any combination failed (assuming default fail-fast behavior didn't already cancel the rest).

jobs:
 test:
  strategy:
   matrix:
    node: [18, 20, 22]
  runs-on: ubuntu-latest
  steps: [...]
 deploy:
  needs: test
  runs-on: ubuntu-latest
  steps: [...]

Start with the actual runner environment, GitHub-hosted runners come with specific preinstalled versions of tools that may not match a developer's laptop, so pin exact versions with actions/setup-node or equivalent rather than assuming whatever's on the runner's PATH. Re-enable debug logging with the ACTIONS_STEP_DEBUG and ACTIONS_RUNNER_DEBUG secrets set to true, which surfaces a lot more detail than the default log level. Also check for environment-specific state a local run wouldn't hit, working directory differences, missing environment variables that only exist on a developer's machine, or a test that depends on file system case sensitivity, since Linux runners are case-sensitive and a lot of local development happens on macOS, which by default isn't.

Branch protection's required status checks are set per job name, and a matrix job reports one status check per generated combination, each with the matrix values appended to its name (something like test (18, ubuntu-latest)). That means adding a new value to the matrix later, a new Node version, changes the exact check names branch protection is watching for, and a rule configured against the old names can end up waiting on a check that no longer gets produced, silently blocking every merge until someone notices and updates the required checks list.

Secrets don't inherit by default into a reusable workflow invoked via workflow_call, because GitHub treats the called workflow as its own trust boundary, a workflow you might be calling from someone else's repo shouldn't silently get access to your caller's secrets. You either pass secrets explicitly, name by name, or opt in wholesale with secrets: inherit.

jobs:
 call-deploy:
  uses:./.github/workflows/deploy.yml
  with:
   environment: production
  secrets: inherit
  # or explicitly:
  # secrets:
  #  DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

This is a question that trips people who've only ever called workflows within their own org, where secrets: inherit is common enough that they forget the explicit form even exists, or why the boundary is there in the first place.

Yes, but GitHub caps the nesting depth, a caller workflow can call reusable workflows up to four levels deep, and a single workflow run can reference up to 20 unique reusable workflows total. In practice this rarely bites anyone until an org tries to build a shared library of composable pipeline stages and starts layering call-a-workflow-that-calls-a-workflow patterns without tracking the depth.

On a public repository, anyone can open a pull request, and if your workflow runs on a self-hosted runner without safeguards, that PR's code can execute directly on your infrastructure, potentially reading anything else reachable from that machine, other repos' cached credentials, internal network segments, local secrets on disk. GitHub-hosted runners are ephemeral and torn down after every job specifically to contain that blast radius. GitHub's guidance is to avoid self-hosted runners for public repos altogether, or to gate them tightly behind required approval for workflows from forks.

pull_request runs the workflow using the workflow file and code from the merge of the fork's branch, with no write access to repo secrets or the ability to push back to the base repo, a sandboxed context by design. pull_request_target runs using the workflow file from the base branch, but with full write permissions and secrets access, while still checking out code from the fork if you add an explicit checkout step for the PR's head ref. That combination, privileged permissions plus untrusted code, is the exact pattern GitHub's hardening guide flags as the most common way teams accidentally hand an attacker their secrets (GitHub Docs, Security hardening for GitHub Actions).

A workflow expression like ${{ github.event.pull_request.title }} gets substituted into the script as literal text before the shell runs it, not passed in as a safely escaped argument. A PR title containing shell metacharacters, backticks or $( ), becomes code the runner executes, not a string it prints. GitHub's hardening docs recommend one of two fixes: pass untrusted values into a real action as an input rather than interpolating them into a script, or assign the value to an intermediate environment variable first and reference that variable in the shell.

# risky
- run: echo "PR title: ${{ github.event.pull_request.title }}"

# safe
- env:
  TITLE: ${{ github.event.pull_request.title }}
 run: echo "PR title: $TITLE"

GitHub Actions documentation is explicit that if you specify access for any one permission, everything not specified is set to none, not left at its default. An empty permissions: {} block, or one that lists a subset, drops every unlisted scope to no access at all, which is a deliberate design so teams can't accidentally leave a permission at a broad default just by forgetting to mention it. It's the safest way to write a workflow that truly needs zero write access to anything.

Cache access follows a defined scope hierarchy, per GitHub's caching documentation: a run can restore a cache created on the same branch, or on the repository's default branch, but not from sibling or child branches (GitHub Docs, Caching dependencies to speed up workflows). A cache written on a pull request is scoped to that PR's merge ref specifically and can't be read back from the base branch even after merge. That's a deliberate isolation boundary, not a bug, so an untrusted PR branch can't poison a cache that a privileged main-branch build later trusts blindly.

If the artifact came from an earlier job that ran against untrusted input, a fork's PR branch, say, treating that artifact's contents as trusted and executing it in a later, privileged job effectively smuggles untrusted code across the trust boundary the two-job split was supposed to enforce. The safer pattern is to treat anything produced by an untrusted build job as data to inspect or upload, never as a script or binary the privileged job runs directly.

The most common cause is referencing the input through the wrong context. Inputs to a manually triggered workflow_dispatch run are read through github.event.inputs. or the newer, type-aware inputs. context, not through env or a bare variable name. A close second cause: every workflow_dispatch input arrives as a string by default unless you explicitly declare its type as boolean or number, so an if condition comparing it directly to a boolean literal without conversion silently evaluates the wrong way.

on:
 workflow_dispatch:
  inputs:
   run_migrations:
    type: boolean
    default: false
jobs:
 deploy:
  steps:
   - if: ${{ inputs.run_migrations }}
    run:./migrate.sh

Yes, GitHub caps a matrix at 256 jobs per workflow run. It's an easy limit to hit by accident once you're crossing three or four dimensions, say five OS versions by five language versions by five feature flags, which is 125 already, and adding one more axis can tip a workflow past the ceiling with no warning until the run actually fails to generate. When a matrix legitimately needs that much coverage, splitting it across separate workflow files or explicitly trimming combinations with exclude is the usual fix.