Loading...
GitHub Actions
Everything for GitHub Actions in one place — pick a section below. 30 reviewed items across 4 content types, plus a hands-on tutorial.
🔄Hands-on TutorialGuideBuild CI/CD with events, jobs, matrices, caching, secrets, environments, and secure deploys.→
📝Interview Questions20Q&A with detailed answers and code examples→
🏭Use Cases3Real-world production patterns and scenarios→
🔥Production Issues4On-call incidents with root causes and fixes
20 / 20
⚡
Quick Answer
Secure workflows use least-privilege `GITHUB_TOKEN` permissions, avoid exposing secrets to untrusted pull request code, pin third-party actions, and prefer OIDC-based cloud federation over long-lived cloud keys. Deployment should run only from trusted refs or protected environments after review gates pass.
Detailed Answer
Think of a company mailroom where outside contractors can submit packages for inspection. You want the mailroom to test the package, but you do not hand the contractor the master key to the building. Pull requests are similar: they are valuable input, but their workflow code may be untrusted. A secure GitHub Actions design separates inspection from privileged deployment.
GitHub Actions workflows run code from repositories and can access tokens, artifacts, caches, and secrets depending on event type and configuration. The security model gets risky when a workflow triggered by pull request content can read secrets or write to protected branches, registries, or cloud accounts. Least privilege means each workflow and job receives only the permissions it needs, such as read-only contents for tests and short-lived identity for deployments.
Internally, the GITHUB_TOKEN is created for workflow runs and scoped by repository and workflow permissions. Secrets are withheld from many untrusted fork scenarios, but mistakes happen when teams use dangerous events, run untrusted scripts after checkout, or pass secrets into build steps. OIDC, or OpenID Connect, lets GitHub mint a short-lived identity token that a cloud provider exchanges for temporary credentials with conditions on repository, branch, environment, and workflow.
In production, teams split pipelines: pull request workflows lint, test, and build without secrets; merge-to-main workflows publish artifacts; deployment workflows require protected environments, reviewers, and narrow cloud roles. They pin actions by SHA, restrict workflow permissions, avoid writing secrets to logs, validate artifact provenance, and protect caches from untrusted key poisoning. Monitoring includes failed deployments, unexpected permission grants, and audit logs for environment approvals.
The gotcha is that pull_request_target runs In the base repository, which can expose privileged tokens if it checks out and executes attacker-controlled code from the PR. Senior engineers know when to use it only for metadata actions, never for running untrusted build scripts. They also treat third-party actions like dependencies: pin them, review them, and update them deliberately.
Code Example
gh workflow view deploy-payments.yml # Reviews the deployment workflow entry point before changing permissions. gh variable set AWS_REGION --body us-east-1 --repo platform/payments-api # Stores non-secret configuration separately from credentials. gh secret list --repo platform/payments-api # Audits which repository secrets exist and whether old cloud keys remain. gh api repos/platform/payments-api/actions/permissions/workflow --method PUT -f default_workflow_permissions=read # Sets default workflow token access to read-only. gh run list --workflow deploy-payments.yml --branch main --limit 5 # Verifies deployments only run from the trusted main branch workflow.
💡
Interview Tip
A junior engineer typically answers that GitHub Actions uses secrets for deployment, but for a senior/architect role, the interviewer is actually looking for trust-boundary design. Explain why PR code is untrusted, how `GITHUB_TOKEN` permissions should be minimized, why OIDC is safer than static cloud keys, and how protected environments gate deployment. Calling out `pull_request_target` misuse and third-party action pinning is a strong signal that you have seen real CI/CD supply-chain risk. Also discuss artifact trust, cache poisoning, and auditability.
◈ Architecture Diagram
┌──────────┐
│ Pull Req │
└────┬─────┘
↓
┌──────────┐
│ Test │
└────┬─────┘
↓ merge
┌──────────┐
│ Main │
└────┬─────┘
↓ oidc
┌──────────┐
│ Cloud │
└────┬─────┘
↓
┌──────────┐
│ Deploy │
└──────────┘💬 Comments
⚡
Quick Answer
GitHub Actions workflows are YAML-defined automation pipelines stored in .github/workflows/ that respond to events (triggers), execute parallel jobs on runners (GitHub-hosted or self-hosted VMs), and each job contains sequential steps that run shell commands or pre-built actions to accomplish CI/CD tasks.
Detailed Answer
Think of a GitHub Actions workflow like a restaurant kitchen during dinner service. The order ticket arriving is the trigger (a push, PR, or schedule), the kitchen has multiple stations (jobs) that can work in parallel — grill, sauté, pastry — and each station follows a recipe with sequential steps. The runners are the actual cooks at each station, and they can be the house staff (GitHub-hosted) or contract chefs you bring in (self-hosted runners). Just as the expeditor coordinates when dishes from different stations need to come together, job dependencies ensure the right ordering.
At its core, a workflow is a YAML file living in .github/workflows/ that declares one or more triggers under the 'on' key. Triggers include push, pull_request, schedule (cron), workflow_dispatch (manual), repository_dispatch (API), and dozens more. Each trigger can be filtered by branches, paths, or tags. Jobs are the top-level units of parallelism — each job runs on a fresh runner instance with its own filesystem, environment variables, and network stack. Steps within a job execute sequentially and share the runner's filesystem, meaning artifacts created in step one are available in step two.
Internally, when a trigger fires, GitHub's orchestration layer creates a workflow run, decomposes it into jobs, evaluates the 'needs' dependency graph, and queues each ready job onto the runner pool. GitHub-hosted runners spin up a fresh VM (Ubuntu, Windows, or macOS) for every job, pulling down your repository via the actions/checkout action. The runner application on the VM communicates with GitHub over HTTPS long-poll, receiving step instructions and streaming logs back. Each step either invokes a JavaScript or Docker-based action, or runs a shell script via the 'run' key. Expressions like ${{ secrets.TOKEN }} and ${{ github.sha }} are interpolated server-side before the runner sees them, which is critical for security.
In production, teams typically structure workflows with a lint job, a test job that fans out via matrix strategies, a build job that depends on tests passing, and a deploy job gated by environment protection rules. Self-hosted runners become important when you need GPU access, specific hardware, or network access to internal resources. Runner groups and labels let you route jobs to the correct machines. Organizations often set concurrency groups to prevent duplicate deployments and use workflow-level permissions to follow the principle of least privilege for the GITHUB_TOKEN.
A common gotcha is assuming jobs share state — they do not. Each job gets a clean runner, so you must use actions/upload-artifact and actions/download-artifact to pass files between jobs, or use actions/cache for dependency caching. Another pitfall is trigger misconfiguration: using 'on: push' without branch filters means every push to every branch triggers the workflow, burning through your minutes. Also, the default GITHUB_TOKEN permissions changed to read-only in newer repositories, so workflows that push tags or create releases will fail silently unless you explicitly set 'permissions: contents: write' at the job or workflow level.
Code Example
# .github/workflows/payments-api-ci.yml
# Workflow name displayed in the Actions tab
name: Payments API CI Pipeline
# Trigger on push to main and on pull requests targeting main
on:
# Trigger when code is pushed to the main branch
push:
# Only run for pushes to the main branch
branches: [main]
# Only run when source files change
paths: ['src/**', 'tests/**']
# Trigger when a pull request targets main
pull_request:
# Only for PRs against main
branches: [main]
# Allow manual trigger from the Actions tab
workflow_dispatch:
# Set default permissions for the GITHUB_TOKEN
permissions:
# Allow reading repository contents
contents: read
# Allow writing pull request comments
pull-requests: write
# Prevent concurrent runs on the same branch
concurrency:
# Group by workflow name and branch
group: ${{ github.workflow }}-${{ github.ref }}
# Cancel in-progress runs for PRs only
cancel-in-progress: ${{ github.event_name == 'pull_request' }}
# Define all jobs in the workflow
jobs:
# First job: lint the codebase
lint:
# Run on the latest Ubuntu runner
runs-on: ubuntu-latest
# Steps execute sequentially within this job
steps:
# Check out the repository code
- uses: actions/checkout@v4
# Set up Node.js version 20
- uses: actions/setup-node@v4
# Configure the Node.js version
with:
# Use Node.js 20 LTS
node-version: '20'
# Cache npm dependencies automatically
cache: 'npm'
# Install project dependencies
- run: npm ci
# Run the linter across the project
- run: npm run lint
# Second job: run unit tests
test:
# This job depends on lint passing first
needs: lint
# Run on the latest Ubuntu runner
runs-on: ubuntu-latest
# Define a matrix strategy for parallel testing
strategy:
# Define matrix dimensions
matrix:
# Test against multiple Node.js versions
node-version: [18, 20, 22]
# Steps for the test job
steps:
# Check out the repository code
- uses: actions/checkout@v4
# Set up the Node.js version from the matrix
- uses: actions/setup-node@v4
# Use the matrix node version
with:
# Dynamically set Node.js version
node-version: ${{ matrix.node-version }}
# Cache npm dependencies
cache: 'npm'
# Install dependencies cleanly
- run: npm ci
# Execute the test suite with coverage
- run: npm test -- --coverage
# Upload coverage report as an artifact
- uses: actions/upload-artifact@v4
# Configure the artifact upload
with:
# Name the artifact with the node version
name: coverage-node-${{ matrix.node-version }}
# Upload the coverage directory
path: coverage/
# Third job: build the application
build:
# Depends on all test matrix jobs passing
needs: test
# Run on the latest Ubuntu runner
runs-on: ubuntu-latest
# Steps for the build job
steps:
# Check out the repository code
- uses: actions/checkout@v4
# Set up Node.js 20 for the build
- uses: actions/setup-node@v4
# Configure Node.js
with:
# Use Node.js 20 LTS
node-version: '20'
# Cache npm dependencies
cache: 'npm'
# Install dependencies
- run: npm ci
# Build the production bundle
- run: npm run build
# Upload the build output as an artifact
- uses: actions/upload-artifact@v4
# Configure artifact settings
with:
# Name the build artifact
name: payments-api-build
# Upload the dist directory
path: dist/💡
Interview Tip
A junior engineer typically describes GitHub Actions as 'a thing that runs tests when you push code,' which only scratches the surface. To demonstrate intermediate-level understanding, walk the interviewer through the full execution model: triggers fire events, the orchestrator builds a DAG from job dependencies, each job is assigned a fresh runner, and steps execute sequentially sharing the runner filesystem. Mention that GitHub-hosted runners are ephemeral VMs destroyed after the job completes, which is why artifact passing between jobs requires explicit upload and download steps. Discuss concurrency controls to prevent race conditions during deployments, and explain why setting minimal GITHUB_TOKEN permissions matters for supply-chain security. Bonus points if you mention that expressions are evaluated server-side before reaching the runner, preventing secret leakage through shell interpolation attacks.
◈ Architecture Diagram
┌──────────────────────────────────────────────────┐
│ GitHub Repository │
│ ┌──────────────────────────────────────────────┐ │
│ │ .github/workflows/payments-api-ci.yml │ │
│ └──────────────────┬───────────────────────────┘ │
└─────────────────────┼────────────────────────────┘
│
↓
┌──────────────────────────────────────────────────┐
│ Trigger Event │
│ ┌────────────┐ ┌────────────┐ ┌──────────────┐ │
│ │ push │ │ pull_req │ │ wf_dispatch │ │
│ └──────┬─────┘ └──────┬─────┘ └──────┬───────┘ │
└─────────┼──────────────┼──────────────┼──────────┘
└──────────────┼──────────────┘
↓
┌──────────────────────────────────────────────────┐
│ Orchestrator (DAG Builder) │
│ Evaluates job dependencies → builds run order │
└────────────────────┬─────────────────────────────┘
↓
┌──────────────────────────────────────────────────┐
│ ┌──────────┐ ┌──────────────────────────┐ │
│ │ Job: lint │───→│ Job: test (matrix 3x) │ │
│ │ Runner 1 │ │ Runner 2 │ R3 │ R4 │ │
│ └──────────┘ └────────────┬──────────────┘ │
│ │ │
│ ↓ │
│ ┌──────────────────────┐ │
│ │ Job: build │ │
│ │ Runner 5 │ │
│ └──────────────────────┘ │
│ GitHub Actions Runner Pool │
└──────────────────────────────────────────────────┘💬 Comments
⚡
Quick Answer
Reusable workflows are complete workflow files called from other workflows using the 'uses' key at the job level, providing full job-level encapsulation with their own runners and secrets. Composite actions bundle multiple steps into a single action used at the step level, sharing the caller's runner and environment. Use reusable workflows for standardized multi-job pipelines and composite actions for shared step sequences.
Detailed Answer
Imagine you run a franchise of coffee shops. A reusable workflow is like your complete franchise operating manual — it defines entire shifts (jobs) with their own staff (runners) and procedures. A composite action is more like a laminated recipe card posted at the espresso machine — it bundles a sequence of steps that any barista (runner) at any shop can follow within their existing shift. The franchise manual operates independently with its own resources, while the recipe card is embedded into whatever shift is already running.
Reusable workflows are standalone YAML files in .github/workflows/ that declare 'on: workflow_call' as their trigger. They accept typed inputs and secrets, can contain multiple jobs with their own runner specifications, and return outputs. The calling workflow references them with 'uses: org/repo/.github/workflows/file.yml@ref' at the job level. Composite actions, defined in an action.yml file, combine multiple 'run' steps and 'uses' references into a single action that callers invoke at the step level. They accept inputs via the 'inputs' key and produce outputs, but they execute on the caller's runner, sharing its filesystem and environment variables.
Under the hood, when a reusable workflow is called, GitHub's orchestrator fetches the referenced YAML file at the specified git ref, validates the inputs against the declared schema, and merges the called workflow's jobs into the caller's dependency graph. Each job in the reusable workflow gets its own runner — completely isolated from the caller's runner. Secrets must be explicitly passed or inherited using 'secrets: inherit'. Composite actions, by contrast, are resolved at step execution time: the runner downloads the action repository, reads action.yml, and injects the composite steps inline into the current job. The composite steps share the same workspace, PATH modifications, and environment variables as surrounding steps, which enables tight integration but also means side effects can leak.
In production, the decision framework is clear. Use reusable workflows when you need to standardize entire pipelines across repositories — for example, a platform team providing a blessed CI/CD pipeline that product teams must use. Reusable workflows enforce consistency at the job level, support environment protection rules, and can be versioned via git tags. Use composite actions when you need to share a common sequence of steps — like setting up a specific toolchain, running a standard lint-and-format check, or performing authenticated Docker builds. Composite actions are more granular and composable; you can use multiple composite actions within a single job alongside other steps.
A critical gotcha is the nesting limitation: reusable workflows can only be nested up to four levels deep, and a reusable workflow cannot call another reusable workflow from within a composite action step. Another trap is secret handling — reusable workflows require explicit secret passing (or 'secrets: inherit'), and if you forget, the called workflow silently receives empty values rather than throwing an error. With composite actions, a common mistake is assuming they can use 'secrets' context directly — they cannot. Secrets must be passed as inputs from the calling workflow. Additionally, composite actions do not support service containers or the 'if' conditional on individual steps in older runner versions, which can cause unexpected behavior.
Code Example
# .github/workflows/reusable-deploy.yml
# Reusable workflow for deploying services to Kubernetes
name: Reusable Deploy Pipeline
# This workflow is callable from other workflows
on:
# Enable workflow_call trigger for reuse
workflow_call:
# Define inputs the caller must provide
inputs:
# The service name to deploy
service-name:
# Input must be provided by the caller
required: true
# Accept string type
type: string
# Describe the input for documentation
description: 'Name of the service to deploy'
# The target environment for deployment
environment:
# This input is required
required: true
# Accept string type
type: string
# Describe valid values
description: 'Target environment: staging or production'
# Docker image tag to deploy
image-tag:
# This input is required
required: true
# Accept string type
type: string
# Describe the expected format
description: 'Docker image tag like sha-abc1234'
# Define secrets the caller must pass
secrets:
# Kubernetes cluster credentials
KUBE_CONFIG:
# Secret is mandatory
required: true
# Describe the secret
description: 'Base64-encoded kubeconfig'
# Container registry token
REGISTRY_TOKEN:
# Secret is mandatory
required: true
# Describe the secret
description: 'Token for container registry auth'
# Define outputs returned to the caller
outputs:
# Return the deployed image digest
deploy-url:
# Describe what this output contains
description: 'URL of the deployed service'
# Map to the deploy job output
value: ${{ jobs.deploy.outputs.url }}
# Define the jobs in this reusable workflow
jobs:
# Job to validate the deployment configuration
validate:
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Steps for validation
steps:
# Check out the repository
- uses: actions/checkout@v4
# Validate Kubernetes manifests
- run: kubeval manifests/${{ inputs.service-name }}/*.yml
# Name this step for clarity
name: Validate K8s manifests
# Job to deploy the service
deploy:
# Depends on validation passing
needs: validate
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Use the specified environment for protection rules
environment: ${{ inputs.environment }}
# Define job outputs
outputs:
# Capture the service URL
url: ${{ steps.get-url.outputs.service_url }}
# Steps for deployment
steps:
# Check out the repository
- uses: actions/checkout@v4
# Configure kubectl with the provided kubeconfig
- run: echo "${{ secrets.KUBE_CONFIG }}" | base64 -d > kubeconfig.yml
# Name this step
name: Setup kubeconfig
# Deploy using kubectl set image
- run: kubectl --kubeconfig=kubeconfig.yml set image deployment/${{ inputs.service-name }} app=registry.example.com/${{ inputs.service-name }}:${{ inputs.image-tag }}
# Name this step
name: Deploy to ${{ inputs.environment }}
# Get the deployed service URL
- id: get-url
# Retrieve the service external IP
run: echo "service_url=$(kubectl --kubeconfig=kubeconfig.yml get svc ${{ inputs.service-name }} -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')" >> $GITHUB_OUTPUT
# Name this step
name: Get service URL
---
# .github/actions/setup-toolchain/action.yml
# Composite action for setting up the build toolchain
name: 'Setup Build Toolchain'
# Description of what this composite action does
description: 'Sets up Node.js, installs deps, and configures auth'
# Define inputs for this composite action
inputs:
# Node.js version to install
node-version:
# Describe the input
description: 'Node.js version to install'
# Not required because we have a default
required: false
# Default to Node.js 20
default: '20'
# Registry token passed as input (not secret context)
registry-token:
# Describe the input
description: 'NPM registry auth token'
# Required for private packages
required: true
# Define the composite action's steps
runs:
# This is a composite action
using: 'composite'
# Steps that run on the caller's runner
steps:
# Set up Node.js with the specified version
- uses: actions/setup-node@v4
# Configure Node.js setup
with:
# Use the input node version
node-version: ${{ inputs.node-version }}
# Enable npm caching
cache: 'npm'
# Point to private registry
registry-url: 'https://npm.pkg.github.com'
# Configure npm authentication for private packages
- run: echo "//npm.pkg.github.com/:_authToken=${{ inputs.registry-token }}" >> .npmrc
# Must specify shell in composite actions
shell: bash
# Name this step
name: Configure NPM auth
# Install dependencies using clean install
- run: npm ci --ignore-scripts
# Must specify shell in composite actions
shell: bash
# Name this step
name: Install dependencies
# Run postinstall scripts separately for security visibility
- run: npm rebuild && npm run prepare --if-present
# Must specify shell in composite actions
shell: bash
# Name this step
name: Run build preparation
---
# .github/workflows/checkout-worker-ci.yml
# Caller workflow that uses both reusable workflow and composite action
name: Checkout Worker CI
# Trigger on push to main
on:
# Run on pushes to main
push:
# Only the main branch
branches: [main]
# Define jobs
jobs:
# Build job uses the composite action
build:
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Build steps
steps:
# Check out the code
- uses: actions/checkout@v4
# Use the composite action to set up toolchain
- uses: ./.github/actions/setup-toolchain
# Pass required inputs
with:
# Use Node.js 20
node-version: '20'
# Pass the registry token as an input
registry-token: ${{ secrets.NPM_TOKEN }}
# Run tests after toolchain is ready
- run: npm test
# Build the Docker image
- run: docker build -t registry.example.com/checkout-worker:sha-${{ github.sha }} .
# Deploy job calls the reusable workflow
deploy-staging:
# Depends on build passing
needs: build
# Call the reusable deploy workflow
uses: ./.github/workflows/reusable-deploy.yml
# Pass required inputs
with:
# Specify the service name
service-name: checkout-worker
# Deploy to staging first
environment: staging
# Use the commit SHA as the image tag
image-tag: sha-${{ github.sha }}
# Pass required secrets
secrets:
# Forward the kubeconfig secret
KUBE_CONFIG: ${{ secrets.KUBE_CONFIG }}
# Forward the registry token
REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}💡
Interview Tip
A junior engineer typically conflates reusable workflows and composite actions, saying something like 'they both let you share code between workflows.' While technically true, this misses the fundamental architectural difference. Emphasize that reusable workflows operate at the job level with their own runners, secrets context, and environment protections, making them ideal for standardizing entire pipelines. Composite actions operate at the step level on the caller's runner, making them ideal for packaging common step sequences. Discuss the practical decision: if you need environment approvals or multi-job orchestration, use reusable workflows. If you need a portable toolchain setup or a reusable validation step, use composite actions. Mention the nesting depth limit of four levels for reusable workflows and the fact that composite actions cannot access secrets directly — they must receive them as inputs.
◈ Architecture Diagram
┌─────────────────────────────────────────────────────┐ │ Caller Workflow (checkout-worker-ci) │ │ │ │ ┌───────────────────────────────────────────────┐ │ │ │ Job: build (runs on caller's runner) │ │ │ │ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │ │ Step: actions/checkout@v4 │ │ │ │ │ └───────────────┬─────────────────────────┘ │ │ │ │ ↓ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │ │ Step: Composite Action │ │ │ │ │ │ ┌───────────────────────────────────┐ │ │ │ │ │ │ │ setup-node (same runner) │ │ │ │ │ │ │ ├───────────────────────────────────┤ │ │ │ │ │ │ │ configure npm auth (same runner) │ │ │ │ │ │ │ ├───────────────────────────────────┤ │ │ │ │ │ │ │ npm ci (same runner) │ │ │ │ │ │ │ └───────────────────────────────────┘ │ │ │ │ │ └───────────────┬─────────────────────────┘ │ │ │ │ ↓ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │ │ Step: npm test (same runner) │ │ │ │ │ └─────────────────────────────────────────┘ │ │ │ └───────────────────────────────────────────────┘ │ │ │ │ │ ↓ │ │ ┌───────────────────────────────────────────────┐ │ │ │ Job: deploy-staging │ │ │ │ uses: reusable-deploy.yml │ │ │ │ │ │ │ │ ┌──────────────────┐ ┌───────────────────┐ │ │ │ │ │ Job: validate │→ │ Job: deploy │ │ │ │ │ │ (own runner) │ │ (own runner) │ │ │ │ │ └──────────────────┘ └───────────────────┘ │ │ │ └───────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘
💬 Comments
⚡
Quick Answer
Matrix builds use the 'strategy.matrix' key to define variables that GitHub Actions expands into multiple parallel job runs. You define dimensions like OS, language version, or architecture, and GitHub creates a Cartesian product of all combinations, running each as a separate job with its own runner. Include/exclude rules let you fine-tune which combinations actually execute.
Detailed Answer
Think of matrix builds like a quality assurance lab testing a new phone case. You need to verify it fits multiple phone models (iPhone 15, Pixel 8, Galaxy S24) in multiple colors (black, clear, blue), and the lab runs all nine combinations simultaneously on different workbenches. Each workbench independently verifies one specific combination. If the clear Galaxy S24 case fails, you know exactly which combination broke without halting the other eight tests. The matrix strategy in GitHub Actions works identically — defining dimensions and letting the system expand them into parallel test runs.
The matrix strategy is configured under 'strategy.matrix' within a job definition. You declare one or more variables, each with a list of values. GitHub computes the Cartesian product: if you specify 3 operating systems and 4 Node.js versions, you get 12 parallel jobs. Each job receives the matrix values via the 'matrix' context — for example, ${{ matrix.os }} and ${{ matrix.node-version }}. You can use 'include' to add specific combinations with extra variables (like a particular compiler flag only needed on Windows), and 'exclude' to remove unwanted combinations (like skipping Node.js 14 on the ARM runner because it is unsupported).
Internally, the GitHub Actions orchestrator evaluates the matrix definition before any jobs run. It expands the Cartesian product, applies excludes, merges includes, and creates individual job entries in the workflow run. Each matrix job is a fully independent job with its own runner — they do not share filesystems or state. The 'fail-fast' flag (true by default) tells the orchestrator to cancel all in-flight matrix jobs if any single job fails, which saves compute minutes but can hide failures in other combinations. Setting 'fail-fast: false' ensures every combination runs to completion, giving you a complete picture. The 'max-parallel' key throttles how many matrix jobs run concurrently, which is essential when you have limited self-hosted runners or are hitting API rate limits from parallel integration tests.
In production, matrix builds are indispensable for libraries and services that must work across multiple environments. A payment processing library might test against Node.js 18, 20, and 22 on Ubuntu, Windows, and macOS — that is 9 combinations catching platform-specific bugs like path separator issues or missing native dependencies. For Docker-based services like order-service, you might matrix across CPU architectures (amd64, arm64) to produce multi-arch images. Teams often combine matrix builds with reusable workflows: the reusable workflow defines the standard test pipeline, and each calling repository provides its own matrix values as inputs. This pattern ensures consistent testing methodology while allowing project-specific customization.
The biggest gotcha with matrix builds is cost explosion. A matrix of 3 operating systems, 4 language versions, and 3 database versions yields 36 parallel jobs — each consuming runner minutes. On GitHub-hosted runners, macOS minutes are billed at 10x the Linux rate, so a 36-job matrix with macOS can be shockingly expensive. Another common mistake is not realizing that 'include' entries do not just add combinations — they can also extend existing combinations with additional variables. If an include entry matches an existing matrix combination on all specified keys, it adds the extra variables to that combination rather than creating a new one. Finally, artifact naming in matrix builds requires attention: if multiple matrix jobs upload artifacts with the same name, they overwrite each other. Always include matrix variables in artifact names like 'build-${{ matrix.os }}-${{ matrix.node }}'.
Code Example
# .github/workflows/order-service-matrix.yml
# Multi-platform testing workflow for order-service
name: Order Service Matrix CI
# Trigger on pull requests and pushes to main
on:
# Run on pull requests targeting main
pull_request:
# Target the main branch
branches: [main]
# Also run on pushes to main
push:
# Only the main branch
branches: [main]
# Define jobs
jobs:
# Matrix test job across platforms and versions
test:
# Use the OS from the matrix
runs-on: ${{ matrix.os }}
# Define the matrix strategy
strategy:
# Do not cancel other jobs if one fails
fail-fast: false
# Limit to 6 concurrent jobs to control costs
max-parallel: 6
# Define the matrix dimensions
matrix:
# Test on three operating systems
os: [ubuntu-latest, windows-latest, macos-latest]
# Test against three Node.js versions
node-version: [18, 20, 22]
# Exclude Node 18 on macOS (unsupported combo)
exclude:
# Skip this specific combination
- os: macos-latest
# Node 18 has native module issues on macOS ARM
node-version: 18
# Add extra variables for specific combinations
include:
# Add a coverage flag for the primary test environment
- os: ubuntu-latest
# Only run coverage on Node 20
node-version: 20
# Enable coverage reporting for this combo
coverage: true
# Add experimental Node.js 23 on Ubuntu only
- os: ubuntu-latest
# Test next major version
node-version: 23
# Mark as experimental so failure is acceptable
experimental: true
# Continue on failure for experimental builds
continue-on-error: ${{ matrix.experimental || false }}
# Set environment variables for all steps
env:
# Use the matrix node version in the environment
NODE_VERSION: ${{ matrix.node-version }}
# Steps for the test job
steps:
# Check out the repository code
- uses: actions/checkout@v4
# Set up Node.js from the matrix
- uses: actions/setup-node@v4
# Configure Node.js version
with:
# Use the matrix-specified version
node-version: ${{ matrix.node-version }}
# Cache npm dependencies
cache: 'npm'
# Install dependencies cleanly
- run: npm ci
# Name this step
name: Install dependencies
# Run tests with optional coverage flag
- run: npm test ${{ matrix.coverage && '-- --coverage' || '' }}
# Name this step
name: Run test suite
# Upload coverage only when the coverage flag is set
- if: matrix.coverage == true
# Use the coverage upload action
uses: actions/upload-artifact@v4
# Configure artifact upload
with:
# Include OS and node version in artifact name
name: coverage-${{ matrix.os }}-node${{ matrix.node-version }}
# Upload the coverage output directory
path: coverage/
# Keep artifacts for 14 days
retention-days: 14
# Multi-architecture Docker build job
docker-build:
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Define architecture matrix
strategy:
# Define the matrix
matrix:
# Build for two CPU architectures
platform: [linux/amd64, linux/arm64]
# Steps for Docker build
steps:
# Check out the repository
- uses: actions/checkout@v4
# Set up QEMU for multi-arch builds
- uses: docker/setup-qemu-action@v3
# Name this step
name: Set up QEMU for cross-compilation
# Set up Docker Buildx for advanced builds
- uses: docker/setup-buildx-action@v3
# Name this step
name: Set up Docker Buildx
# Build the Docker image for the target platform
- uses: docker/build-push-action@v5
# Configure the build
with:
# Use the repository context
context: .
# Target the matrix platform
platforms: ${{ matrix.platform }}
# Do not push, just build to verify
push: false
# Tag with platform-specific identifier
tags: registry.example.com/order-service:${{ github.sha }}
# Cache Docker layers for faster builds
cache-from: type=gha
# Store cache for subsequent builds
cache-to: type=gha,mode=max💡
Interview Tip
A junior engineer typically describes matrix builds as 'running tests on different versions' without explaining the mechanics. Demonstrate deeper understanding by explaining that GitHub computes the Cartesian product of all matrix dimensions before job execution, and each resulting combination runs as a fully independent job with its own runner. Discuss the cost implications: three operating systems times four versions is twelve jobs, and macOS runners cost ten times more than Linux. Explain the difference between 'exclude' (removes from the Cartesian product) and 'include' (adds or extends combinations), because many engineers confuse the two. Mention 'fail-fast: false' for getting complete test results across all combinations, and discuss 'continue-on-error' for experimental builds that should not block the pipeline. Highlight the artifact naming trap where matrix jobs overwrite each other's artifacts if names are not unique.
◈ Architecture Diagram
┌─────────────────────────────────────────────────────────┐
│ Matrix Strategy Definition │
│ os: [ubuntu, windows, macos] │
│ node: [18, 20, 22] │
│ exclude: [macos + 18] │
│ include: [ubuntu + 20 + coverage] │
└────────────────────────┬────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ Cartesian Product → 9 - 1 + 1 = 9 jobs │
└────────────────────────┬────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ ┌─────────────────┐ ┌─────────────────┐ ┌───────────┐ │
│ │ ubuntu + node18 │ │ ubuntu + node20 │ │ ubuntu │ │
│ │ Runner 1 │ │ Runner 2 │ │ + node22 │ │
│ │ │ │ + coverage:true │ │ Runner 3 │ │
│ └─────────────────┘ └─────────────────┘ └───────────┘ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌───────────┐ │
│ │ windows + 18 │ │ windows + 20 │ │ windows │ │
│ │ Runner 4 │ │ Runner 5 │ │ + 22 │ │
│ │ │ │ │ │ Runner 6 │ │
│ └─────────────────┘ └─────────────────┘ └───────────┘ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ macos + node20 │ │ macos + node22 │ (macos+18 │
│ │ Runner 7 │ │ Runner 8 │ excluded) │
│ └─────────────────┘ └─────────────────┘ │
│ ┌─────────────────┐ │
│ │ ubuntu + node23 │ (experimental │
│ │ Runner 9 │ continue-on-error) │
│ └─────────────────┘ │
│ Parallel Execution Pool │
└─────────────────────────────────────────────────────────┘💬 Comments
⚡
Quick Answer
GitHub Actions provides encrypted secrets at repository, environment, and organization levels, accessible via ${{ secrets.NAME }}. Environments add deployment protection rules including required reviewers, wait timers, and branch restrictions. Secrets are masked in logs, never exposed in forks' pull requests, and should follow least-privilege principles with OIDC federation replacing long-lived credentials where possible.
Detailed Answer
Managing secrets in CI/CD is like handling the keys to a bank vault. You do not give every employee the master key — instead, you issue role-specific access cards (scoped secrets), require two-person authorization for the vault room (environment protection rules), rotate the cards regularly (secret rotation), and install cameras that blur the card numbers in footage (log masking). GitHub Actions implements all these layers, and understanding how they compose is critical for a secure pipeline.
GitHub encrypts secrets at rest using libsodium sealed boxes and only decrypts them at runtime on the runner. Secrets exist at three scopes: organization (shared across repos via access policies), repository (available to all workflows in the repo), and environment (only available when a job targets that specific environment). When scopes overlap, the most specific wins — an environment secret named API_KEY overrides a repository secret with the same name. Secrets are injected as environment variables or interpolated via ${{ secrets.NAME }}, and the runner's log processor automatically masks any value matching a known secret, replacing it with '***'. However, this masking is best-effort — if you base64-encode a secret or split it across multiple log lines, the mask fails.
Internally, the secrets delivery mechanism works through a secure channel between GitHub's control plane and the runner agent. When a job starts, the orchestrator evaluates which secrets the job is entitled to based on its environment, repository, and organization membership. It encrypts the relevant secrets with the runner's session key and transmits them over TLS. On the runner, secrets exist only in memory and are purged after the job completes. For fork pull requests, repository secrets are deliberately withheld to prevent exfiltration by malicious PRs — only the GITHUB_TOKEN with limited permissions is available. The 'pull_request_target' trigger, which runs in the context of the base branch, does have access to secrets, but using it carelessly with code from the PR creates a critical injection vulnerability.
In production environments, the gold standard is eliminating static secrets entirely using OIDC (OpenID Connect) federation. GitHub Actions can mint short-lived OIDC tokens containing claims about the workflow, repository, and branch. Cloud providers like AWS, GCP, and Azure validate these tokens and issue temporary credentials — no stored secrets needed. For secrets that must remain static (API keys, license keys), implement rotation via GitHub's API, store them at the environment level with required reviewers for production, and use organization-level secrets for shared infrastructure credentials. Environment protection rules add human approval gates, wait timers (useful for blue-green deployments), and branch restrictions ensuring only the main branch can deploy to production. Combine this with deployment branch policies and the deployment status API for full audit trails.
The most dangerous gotcha is the 'pull_request_target' trigger combined with an explicit checkout of the PR's head — this gives the PR's untrusted code access to all repository secrets. Another common mistake is logging secrets indirectly: running 'curl -v' with an Authorization header will print the secret in verbose output before the masker can catch it. Environment variables containing secrets should never be passed to untrusted scripts or actions without vetting. Also, the GITHUB_TOKEN's default permissions vary by repository settings — in newer repos it defaults to read-only, but in older repos it may still have broad write permissions. Always explicitly declare the minimum permissions needed using the 'permissions' key at the workflow or job level.
Code Example
# .github/workflows/payments-api-deploy.yml
# Secure deployment workflow with environment protection
name: Payments API Secure Deploy
# Trigger on push to main and manual dispatch
on:
# Run on pushes to main
push:
# Only the main branch
branches: [main]
# Allow manual trigger with environment selection
workflow_dispatch:
# Define manual trigger inputs
inputs:
# Let the user choose the target environment
environment:
# Describe the input
description: 'Target deployment environment'
# Must be provided
required: true
# Dropdown selection
type: choice
# Available environment options
options:
# Staging environment
- staging
# Production environment
- production
# Set minimum permissions for the GITHUB_TOKEN
permissions:
# Read repository contents
contents: read
# Required for OIDC token generation
id-token: write
# Allow updating deployment status
deployments: write
# Define all jobs
jobs:
# Job to run security scanning
security-scan:
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Steps for security scanning
steps:
# Check out the code
- uses: actions/checkout@v4
# Run secret scanning to catch leaked credentials
- run: grep -rn 'AKIA\|password\s*=\|api_key\s*=' src/ && exit 1 || echo 'No secrets found in code'
# Name the step
name: Scan for hardcoded secrets
# Deploy to staging environment
deploy-staging:
# Depends on security scan passing
needs: security-scan
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Target the staging environment with its protection rules
environment:
# Use the staging environment
name: staging
# Set the deployment URL
url: https://staging.payments.example.com
# Steps for staging deployment
steps:
# Check out the code
- uses: actions/checkout@v4
# Authenticate to AWS using OIDC — no stored secrets needed
- uses: aws-actions/configure-aws-credentials@v4
# Configure OIDC-based authentication
with:
# Specify the IAM role to assume via OIDC
role-to-assume: arn:aws:iam::123456789012:role/payments-api-staging-deploy
# Set the AWS region
aws-region: us-east-1
# Use the GitHub OIDC provider
role-session-name: gha-payments-staging-${{ github.run_id }}
# Login to Amazon ECR using the OIDC credentials
- uses: aws-actions/amazon-ecr-login@v2
# Name this step
name: Login to Amazon ECR
# Build and push the Docker image
- run: |
docker build -t ${{ secrets.ECR_REGISTRY }}/payments-api:${{ github.sha }} .
docker push ${{ secrets.ECR_REGISTRY }}/payments-api:${{ github.sha }}
# Name the step
name: Build and push Docker image
# Deploy to EKS staging cluster
- run: |
aws eks update-kubeconfig --name payments-staging --region us-east-1
kubectl set image deployment/payments-api app=${{ secrets.ECR_REGISTRY }}/payments-api:${{ github.sha }}
kubectl rollout status deployment/payments-api --timeout=300s
# Name this step
name: Deploy to staging EKS
# Deploy to production with manual approval
deploy-production:
# Depends on staging deployment succeeding
needs: deploy-staging
# Only run for pushes to main or manual production trigger
if: github.ref == 'refs/heads/main'
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Target the production environment (has required reviewers)
environment:
# Use the production environment
name: production
# Set the production URL
url: https://payments.example.com
# Steps for production deployment
steps:
# Check out the code
- uses: actions/checkout@v4
# Authenticate to AWS using OIDC for production
- uses: aws-actions/configure-aws-credentials@v4
# Configure OIDC auth for production role
with:
# Use the production IAM role
role-to-assume: arn:aws:iam::123456789012:role/payments-api-prod-deploy
# Production region
aws-region: us-east-1
# Session name for audit trail
role-session-name: gha-payments-prod-${{ github.run_id }}
# Login to ECR
- uses: aws-actions/amazon-ecr-login@v2
# Name this step
name: Login to Amazon ECR
# Deploy to production EKS with canary strategy
- run: |
aws eks update-kubeconfig --name payments-production --region us-east-1
kubectl set image deployment/payments-api app=${{ secrets.ECR_REGISTRY }}/payments-api:${{ github.sha }}
kubectl rollout status deployment/payments-api --timeout=600s
# Name this step
name: Deploy to production EKS
# Verify deployment health
- run: |
HEALTH=$(curl -s -o /dev/null -w '%{http_code}' https://payments.example.com/health)
if [ "$HEALTH" != "200" ]; then echo 'Health check failed' && exit 1; fi
# Name this step
name: Post-deployment health check💡
Interview Tip
A junior engineer typically says 'just put secrets in GitHub settings and use ${{ secrets.NAME }}' without considering the layered security model. Stand out by explaining the three secret scopes (organization, repository, environment) and how precedence works when names collide. Discuss why OIDC federation is superior to static secrets — it eliminates secret rotation burden and limits blast radius through short-lived tokens. Bring up the 'pull_request_target' vulnerability: if your workflow checks out PR code with 'actions/checkout@v4' using 'ref: ${{ github.event.pull_request.head.sha }}' under pull_request_target, an attacker's PR code runs with full secret access. Explain environment protection rules as the mechanism for human-in-the-loop approval gates and branch restrictions that prevent feature branches from deploying to production.
◈ Architecture Diagram
┌─────────────────────────────────────────────────────┐
│ Secret Scopes │
│ │
│ ┌───────────────────────────────────────────────┐ │
│ │ Organization Secrets │ │
│ │ Shared across repos via access policies │ │
│ │ ┌──────────────────────┐ │ │
│ │ │ DOCKER_REGISTRY_URL │ │ │
│ │ │ SONAR_TOKEN │ │ │
│ │ └──────────────────────┘ │ │
│ └───────────────────────────────────────────────┘ │
│ ↓ (inherited by repos) │
│ ┌───────────────────────────────────────────────┐ │
│ │ Repository Secrets │ │
│ │ Available to all workflows in this repo │ │
│ │ ┌──────────────────────┐ │ │
│ │ │ ECR_REGISTRY │ │ │
│ │ │ SLACK_WEBHOOK │ │ │
│ │ └──────────────────────┘ │ │
│ └───────────────────────────────────────────────┘ │
│ ↓ (overridden by env secrets) │
│ ┌───────────────────────────────────────────────┐ │
│ │ Environment: staging Environment: prod │ │
│ │ ┌────────────────────┐ ┌────────────────────┐ │ │
│ │ │ AWS_ROLE_ARN │ │ AWS_ROLE_ARN │ │ │
│ │ │ DB_CONNECTION │ │ DB_CONNECTION │ │ │
│ │ └────────────────────┘ └────────────────────┘ │ │
│ │ Protection: none Protection: │ │
│ │ ┌────────────────────┐ │ │
│ │ │ Required reviewers │ │ │
│ │ │ Wait timer: 15min │ │ │
│ │ │ Branch: main only │ │ │
│ │ └────────────────────┘ │ │
│ └───────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────┐
│ OIDC Federation Flow │
│ │
│ GitHub Actions ──→ Mint OIDC Token ──→ AWS STS │
│ (id-token: write) (short-lived JWT) (AssumeRole)│
│ ↓ │
│ Temp Credentials │
│ (15 min TTL) │
└─────────────────────────────────────────────────────┘💬 Comments
⚡
Quick Answer
GitHub Actions caching uses the actions/cache action to store and restore dependency directories (node_modules, .m2, pip cache) across workflow runs using content-addressable keys derived from lockfiles. Cache hits skip expensive install steps. Optimization also includes Docker layer caching, parallel jobs, conditional path filtering, artifact reuse between jobs, and incremental builds to reduce overall pipeline duration.
Detailed Answer
Caching in CI is like a chef's mise en place — the prep work of washing, chopping, and measuring ingredients before service begins. Without it, every dinner service (workflow run) starts from raw ingredients (downloading and compiling every dependency from scratch). With proper mise en place (caching), most of the prep is already done and you only re-prep what changed — a new spice (updated package) means re-measuring just that ingredient while everything else stays ready. GitHub Actions caching provides this pre-staged starting point for your builds.
The actions/cache action works with three parameters: path (what to cache), key (how to identify the cache), and restore-keys (fallback keys for partial matches). When a job starts, the action computes the cache key — typically a hash of the lockfile like 'deps-linux-${{ hashFiles('package-lock.json') }}'. It queries GitHub's cache storage API for an exact match. On a hit, the cached directory is downloaded and extracted, skipping the install step entirely. On a miss, it falls back to restore-keys prefix matching to find the most recent partial match, which still saves time because only changed packages need updating. After the job completes, if the exact key was not found initially, the current directory state is uploaded as a new cache entry.
Under the hood, GitHub stores caches in Azure Blob Storage, scoped to the repository and branch. Caches are immutable once created — a key can never be updated, only replaced when the key changes. The cache is accessible to all branches, but a branch can only restore caches created by itself or its parent branch (including the default branch), preventing cache poisoning between unrelated branches. The total cache storage per repository is 10 GB, managed via LRU eviction — caches not accessed within 7 days are automatically purged. Each individual cache entry has a maximum size of approximately 10 GB. The cache download and upload use concurrent chunked transfers for performance, and the action compresses the directory using zstd (or gzip as fallback) before upload.
Beyond dependency caching, production optimization involves multiple strategies. Docker layer caching via 'cache-from: type=gha' in docker/build-push-action stores intermediate layers in GitHub's cache, dramatically speeding up image builds when only application code changes. Path-based triggers ('on.push.paths') prevent entire workflows from running when irrelevant files change. Splitting workflows into smaller, focused pipelines (lint, test, build, deploy) with job dependencies lets unaffected stages complete quickly. Using 'actions/setup-node' with its built-in cache option simplifies the common case. For monorepos, tools like 'dorny/paths-filter' determine which packages changed and skip unchanged ones. Artifact passing between jobs with actions/upload-artifact avoids rebuilding in later stages. Incremental compilation with tools like turborepo or nx caches build outputs per-package.
The primary gotcha is cache key design. Using a key too broad (like 'deps-linux') means the cache never updates when dependencies change, leading to stale node_modules and mysterious build failures. Using a key too specific (including the run ID) means you never get cache hits. The sweet spot is hashing the lockfile, giving you exact matches when dependencies are unchanged and natural invalidation when they change. Another trap is caching node_modules directly instead of the npm cache directory — node_modules contains platform-specific binaries that may not work if the runner OS changes. The recommended approach is caching '~/.npm' and running 'npm ci', which reinstalls from the cache. Also beware that cache restores in matrix builds share the same keys by default, causing race conditions where multiple matrix jobs try to save the same cache key simultaneously — only one succeeds.
Code Example
# .github/workflows/checkout-worker-optimized.yml
# Optimized CI workflow with comprehensive caching
name: Checkout Worker Optimized CI
# Trigger on pushes and PRs to main
on:
# Run on pushes to main
push:
# Only the main branch
branches: [main]
# Only when relevant files change
paths: ['src/**', 'package*.json', 'Dockerfile']
# Run on PRs targeting main
pull_request:
# Only PRs against main
branches: [main]
# Define all jobs
jobs:
# Detect which parts of the codebase changed
changes:
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Expose outputs for downstream jobs
outputs:
# Whether source code changed
src: ${{ steps.filter.outputs.src }}
# Whether Docker-related files changed
docker: ${{ steps.filter.outputs.docker }}
# Steps for change detection
steps:
# Check out the code
- uses: actions/checkout@v4
# Detect which paths changed
- uses: dorny/paths-filter@v3
# Give this step an ID for output reference
id: filter
# Configure path filters
with:
# Define filter patterns
filters: |
src:
- 'src/**'
- 'tests/**'
- 'package*.json'
docker:
- 'Dockerfile'
- '.dockerignore'
# Test job with aggressive caching
test:
# Depends on change detection
needs: changes
# Only run if source files changed
if: needs.changes.outputs.src == 'true'
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Steps for testing with caching
steps:
# Check out the repository
- uses: actions/checkout@v4
# Set up Node.js with built-in npm caching
- uses: actions/setup-node@v4
# Configure Node.js and caching
with:
# Use Node.js 20
node-version: '20'
# Enable built-in npm cache
cache: 'npm'
# Cache the Cypress binary separately (large download)
- uses: actions/cache@v4
# Configure Cypress cache
with:
# Cache the Cypress binary directory
path: ~/.cache/Cypress
# Key based on package-lock changes
key: cypress-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
# Fallback to any Cypress cache on this OS
restore-keys: |
cypress-${{ runner.os }}-
# Cache Jest transform results for faster reruns
- uses: actions/cache@v4
# Configure Jest cache
with:
# Cache Jest's transform cache directory
path: /tmp/jest_rs
# Key includes source hash for invalidation
key: jest-${{ runner.os }}-${{ hashFiles('src/**') }}
# Fallback to previous Jest cache
restore-keys: |
jest-${{ runner.os }}-
# Install dependencies (uses npm cache from setup-node)
- run: npm ci
# Name this step
name: Install dependencies
# Run unit tests with cached Jest transforms
- run: npm test -- --cacheDirectory=/tmp/jest_rs
# Name this step
name: Run unit tests
# Upload test results as artifacts for later jobs
- uses: actions/upload-artifact@v4
# Configure artifact upload
with:
# Name the test results artifact
name: test-results
# Upload the results directory
path: test-results/
# Keep for 7 days
retention-days: 7
# Docker build with layer caching
docker-build:
# Depends on change detection and test passing
needs: [changes, test]
# Only run if Docker files changed or src changed
if: needs.changes.outputs.docker == 'true' || needs.changes.outputs.src == 'true'
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Steps for Docker build
steps:
# Check out the code
- uses: actions/checkout@v4
# Set up Docker Buildx for advanced caching
- uses: docker/setup-buildx-action@v3
# Name this step
name: Set up Docker Buildx
# Build Docker image with GitHub Actions cache backend
- uses: docker/build-push-action@v5
# Configure the Docker build
with:
# Use the repo root as build context
context: .
# Do not push, build only
push: false
# Tag with the commit SHA
tags: registry.example.com/checkout-worker:${{ github.sha }}
# Use GitHub Actions cache for Docker layers
cache-from: type=gha
# Save Docker layers to GitHub Actions cache
cache-to: type=gha,mode=max
# Load the image into the local Docker daemon
load: true
# Verify the built image runs correctly
- run: docker run --rm registry.example.com/checkout-worker:${{ github.sha }} node --version
# Name this step
name: Verify Docker image💡
Interview Tip
A junior engineer typically knows about actions/cache but cannot explain the key design strategy or cache scoping rules. Demonstrate expertise by explaining the three-part cache mechanism: exact key match first, then restore-keys prefix fallback, then fresh install if nothing matches. Discuss why hashing the lockfile is the sweet spot for cache keys — it provides automatic invalidation when dependencies change without being so specific that caches never hit. Explain the branch scoping rule where feature branches can restore caches from the default branch but not from other feature branches, which prevents cache poisoning. Mention the 10 GB per-repository limit with LRU eviction, and the common mistake of caching node_modules directly instead of the npm cache directory. For bonus points, discuss Docker layer caching with 'type=gha' and how path-based triggers prevent unnecessary workflow runs entirely.
◈ Architecture Diagram
┌──────────────────────────────────────────────────────┐
│ Cache Lookup Flow │
│ │
│ Step 1: Compute cache key │
│ key: deps-linux-${{ hashFiles('package-lock.json') }}│
│ restore-keys: deps-linux- │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ Cache Storage (10 GB per repo, LRU eviction) │ │
│ │ │ │
│ │ ┌──────────────────────┐ ┌──────────────────┐ │ │
│ │ │ deps-linux-abc123 │ │ deps-linux-def456│ │ │
│ │ │ (2 days old) │ │ (5 days old) │ │ │
│ │ └──────────┬───────────┘ └──────────────────┘ │ │
│ └────────────┼───────────────────────────────────┘ │
│ ↓ │
│ ┌────────────────────────────────────────────────┐ │
│ │ Match Logic │ │
│ │ │ │
│ │ Exact key match? ──→ Yes ──→ Cache HIT │ │
│ │ │ (skip npm ci) │ │
│ │ ↓ No │ │
│ │ restore-keys prefix? ──→ Yes ──→ Partial HIT │ │
│ │ │ (fast npm ci) │ │
│ │ ↓ No │ │
│ │ Cache MISS ──→ Full install from registry │ │
│ └────────────────────────────────────────────────┘ │
└──────────────────────┬───────────────────────────────┘
↓
┌──────────────────────────────────────────────────────┐
│ Post-Job Cache Save │
│ │
│ Was exact key found? ──→ Yes ──→ Skip (immutable) │
│ │ │
│ ↓ No │
│ Compress with zstd ──→ Upload new cache entry │
│ (path: ~/.npm) (key: deps-linux-abc123) │
└──────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────┐
│ Branch Scoping Rules │
│ │
│ main ──────────────────────────────────────────→ │
│ │ (caches accessible to all branches) │
│ ↓ │
│ feature-a ──→ Can restore from: main, feature-a │
│ feature-b ──→ Can restore from: main, feature-b │
│ feature-a ──→ Cannot restore from: feature-b │
└──────────────────────────────────────────────────────┘💬 Comments
⚡
Quick Answer
A GitHub Actions CI/CD pipeline for Kubernetes typically runs lint and test jobs, builds a Docker image pushed to a container registry, updates Kubernetes manifests with the new image tag, and applies them using kubectl or a GitOps tool like ArgoCD. The pipeline uses environment protection rules for staged rollouts, OIDC for cloud authentication, and includes health checks and automated rollback on deployment failure.
Detailed Answer
Deploying to Kubernetes via GitHub Actions is like an assembly line in a car factory. Raw materials (source code) enter the line, go through quality inspection stations (lint, test, security scan), get assembled into a finished vehicle (Docker image), receive a VIN number (image tag), and roll off the line to the showroom (Kubernetes cluster). If a defect is found during the final road test (health check), the recall process (rollback) kicks in automatically. The entire line is automated, but certain checkpoints (environment approvals) require a human sign-off before the car ships to customers.
The pipeline structure follows a standard flow: source checkout, dependency installation, linting, unit and integration testing, Docker image build and push, manifest update, deployment, and verification. The Docker image is tagged with the git SHA for traceability — you can always trace a running container back to the exact commit that produced it. The image is pushed to a container registry (ECR, GCR, GHCR, or DockerHub), and then Kubernetes manifests are updated to reference the new image tag. For simple setups, kubectl directly applies the manifests. For mature teams, a GitOps approach commits the new image tag to a config repository that ArgoCD or Flux watches, providing an auditable deployment history and easy rollback via git revert.
Internally, the deployment step authenticates to the Kubernetes cluster using either a kubeconfig stored as a secret or, preferably, OIDC federation with the cloud provider's managed Kubernetes service (EKS, GKE, AKS). The workflow calls 'aws eks update-kubeconfig' or 'gcloud container clusters get-credentials' to configure kubectl. The deployment uses 'kubectl apply' or 'kubectl set image' to update the deployment resource, then 'kubectl rollout status' blocks until all pods are running the new version. Under the hood, Kubernetes performs a rolling update — creating new pods with the new image while gradually terminating old pods, maintaining availability throughout. The 'maxSurge' and 'maxUnavailable' settings in the deployment spec control the rollout speed and minimum availability.
Production pipelines add several critical layers. Environment protection rules in GitHub require manual approval before production deployments. Canary deployments route a small percentage of traffic to the new version before full rollout, using service mesh features or Kubernetes-native canary controllers. The pipeline includes a smoke test step that verifies critical endpoints return expected responses after deployment. If the smoke test fails, an automatic rollback step runs 'kubectl rollout undo'. Notifications via Slack or Teams inform the team of deployment status. For multi-cluster deployments (like deploying to regional clusters), a matrix strategy can parallelize the rollout across clusters while maintaining per-cluster health verification.
A key gotcha is using 'latest' as the Docker image tag — Kubernetes may not pull the new image if it sees the tag already exists locally due to imagePullPolicy defaults. Always use unique tags like the git SHA. Another trap is not setting resource limits in the Kubernetes deployment, causing the new pods to be evicted under memory pressure during rollout. The rollout status command can also time out silently if you do not set an explicit '--timeout' flag, making your pipeline appear to succeed when the deployment is actually stuck. Finally, ensure your service account has only the minimum RBAC permissions needed — a common mistake is granting cluster-admin to the CI service account, which violates least privilege and could be catastrophic if credentials are compromised.
Code Example
# .github/workflows/order-service-k8s-deploy.yml
# Complete CI/CD pipeline deploying order-service to Kubernetes
name: Order Service K8s Deploy
# Trigger on push to main
on:
# Run on pushes to main
push:
# Only the main branch
branches: [main]
# Only when relevant files change
paths: ['src/**', 'Dockerfile', 'k8s/**', 'package*.json']
# Set minimum GITHUB_TOKEN permissions
permissions:
# Read repository contents
contents: read
# Required for OIDC token minting
id-token: write
# Allow writing packages to GHCR
packages: write
# Prevent concurrent deployments
concurrency:
# Group by workflow name
group: deploy-order-service
# Do not cancel in-progress deploys
cancel-in-progress: false
# Define all pipeline jobs
jobs:
# Job 1: Lint and static analysis
lint:
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Lint steps
steps:
# Check out the code
- uses: actions/checkout@v4
# Set up Node.js with caching
- uses: actions/setup-node@v4
# Configure Node.js
with:
# Use Node.js 20
node-version: '20'
# Enable npm caching
cache: 'npm'
# Install dependencies
- run: npm ci
# Name this step
name: Install dependencies
# Run ESLint across the project
- run: npm run lint
# Name this step
name: Run ESLint
# Run TypeScript type checking
- run: npm run typecheck
# Name this step
name: TypeScript type check
# Job 2: Run unit and integration tests
test:
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Use PostgreSQL service container for integration tests
services:
# Define a PostgreSQL service
postgres:
# Use PostgreSQL 16 image
image: postgres:16
# Set environment variables for the container
env:
# Set the database password
POSTGRES_PASSWORD: testpass
# Create the test database
POSTGRES_DB: order_service_test
# Map container port to host
ports:
# Map PostgreSQL default port
- 5432:5432
# Health check to wait for PostgreSQL readiness
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
# Test steps
steps:
# Check out the code
- uses: actions/checkout@v4
# Set up Node.js
- uses: actions/setup-node@v4
# Configure Node.js
with:
# Use Node.js 20
node-version: '20'
# Enable npm caching
cache: 'npm'
# Install dependencies
- run: npm ci
# Name this step
name: Install dependencies
# Run unit tests with coverage
- run: npm test -- --coverage
# Name this step
name: Run unit tests
# Set database URL for integration tests
env:
# Connection string for the service container
DATABASE_URL: postgresql://postgres:testpass@localhost:5432/order_service_test
# Upload test coverage as artifact
- uses: actions/upload-artifact@v4
# Configure artifact
with:
# Name the coverage artifact
name: test-coverage
# Upload coverage directory
path: coverage/
# Job 3: Build and push Docker image
build-image:
# Depends on lint and test passing
needs: [lint, test]
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Output the image tag for downstream jobs
outputs:
# Expose the full image reference
image-ref: ${{ steps.meta.outputs.tags }}
# Expose the image digest for verification
digest: ${{ steps.build.outputs.digest }}
# Build steps
steps:
# Check out the code
- uses: actions/checkout@v4
# Set up Docker Buildx for advanced features
- uses: docker/setup-buildx-action@v3
# Name this step
name: Set up Docker Buildx
# Login to GitHub Container Registry
- uses: docker/login-action@v3
# Configure registry login
with:
# Use GitHub Container Registry
registry: ghcr.io
# Authenticate as the GitHub Actions bot
username: ${{ github.actor }}
# Use the GITHUB_TOKEN for authentication
password: ${{ secrets.GITHUB_TOKEN }}
# Generate Docker metadata (tags and labels)
- uses: docker/metadata-action@v5
# Give this step an ID for output reference
id: meta
# Configure metadata generation
with:
# Target image name in GHCR
images: ghcr.io/${{ github.repository }}/order-service
# Generate tags: SHA, branch name, and latest
tags: |
type=sha,prefix=sha-
type=ref,event=branch
type=raw,value=latest,enable={{is_default_branch}}
# Build and push the Docker image
- uses: docker/build-push-action@v5
# Give this step an ID for digest output
id: build
# Configure the build
with:
# Use the repository root as context
context: .
# Push to the registry
push: true
# Apply the generated tags
tags: ${{ steps.meta.outputs.tags }}
# Apply the generated labels
labels: ${{ steps.meta.outputs.labels }}
# Use GitHub Actions cache for Docker layers
cache-from: type=gha
# Save layers to cache with max mode
cache-to: type=gha,mode=max
# Build for amd64 architecture
platforms: linux/amd64
# Job 4: Deploy to staging
deploy-staging:
# Depends on image being built
needs: build-image
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Target the staging environment
environment:
# Use the staging environment
name: staging
# Link to the staging URL
url: https://staging.orders.example.com
# Staging deploy steps
steps:
# Check out the code for K8s manifests
- uses: actions/checkout@v4
# Authenticate to AWS using OIDC
- uses: aws-actions/configure-aws-credentials@v4
# Configure OIDC auth
with:
# Assume the staging deploy role
role-to-assume: ${{ secrets.AWS_STAGING_ROLE_ARN }}
# Set the AWS region
aws-region: us-east-1
# Configure kubectl for the staging EKS cluster
- run: aws eks update-kubeconfig --name order-staging-cluster --region us-east-1
# Name this step
name: Configure kubectl for staging
# Update the image tag in the Kubernetes manifest
- run: sed -i "s|IMAGE_TAG|sha-${GITHUB_SHA::7}|g" k8s/deployment.yml
# Name this step
name: Update manifest image tag
# Apply the Kubernetes manifests
- run: kubectl apply -f k8s/
# Name this step
name: Apply K8s manifests to staging
# Wait for the rollout to complete
- run: kubectl rollout status deployment/order-service --timeout=300s
# Name this step
name: Wait for rollout completion
# Run smoke tests against staging
- run: |
for i in 1 2 3 4 5; do
STATUS=$(curl -s -o /dev/null -w '%{http_code}' https://staging.orders.example.com/health)
if [ "$STATUS" = "200" ]; then echo 'Health check passed' && exit 0; fi
sleep 10
done
echo 'Health check failed after 5 attempts' && exit 1
# Name this step
name: Smoke test staging deployment
# Rollback if smoke test failed
- if: failure()
# Undo the last rollout on failure
run: kubectl rollout undo deployment/order-service
# Name this step
name: Rollback staging on failure
# Job 5: Deploy to production with approval
deploy-production:
# Depends on staging deployment succeeding
needs: [build-image, deploy-staging]
# Run on latest Ubuntu
runs-on: ubuntu-latest
# Target the production environment with protection rules
environment:
# Use the production environment (requires reviewers)
name: production
# Link to the production URL
url: https://orders.example.com
# Production deploy steps
steps:
# Check out the code
- uses: actions/checkout@v4
# Authenticate to AWS using OIDC for production
- uses: aws-actions/configure-aws-credentials@v4
# Configure OIDC auth for production
with:
# Assume the production deploy role
role-to-assume: ${{ secrets.AWS_PROD_ROLE_ARN }}
# Set the AWS region
aws-region: us-east-1
# Configure kubectl for the production EKS cluster
- run: aws eks update-kubeconfig --name order-prod-cluster --region us-east-1
# Name this step
name: Configure kubectl for production
# Update the image tag in the manifest
- run: sed -i "s|IMAGE_TAG|sha-${GITHUB_SHA::7}|g" k8s/deployment.yml
# Name this step
name: Update manifest image tag
# Apply manifests to production
- run: kubectl apply -f k8s/
# Name this step
name: Apply K8s manifests to production
# Wait for production rollout with longer timeout
- run: kubectl rollout status deployment/order-service --timeout=600s
# Name this step
name: Wait for production rollout
# Comprehensive health check for production
- run: |
for endpoint in /health /health/db /health/cache; do
STATUS=$(curl -s -o /dev/null -w '%{http_code}' "https://orders.example.com${endpoint}")
if [ "$STATUS" != "200" ]; then echo "Failed: ${endpoint}" && exit 1; fi
done
echo 'All health checks passed'
# Name this step
name: Production health checks
# Automatic rollback on any failure
- if: failure()
# Undo the deployment
run: kubectl rollout undo deployment/order-service
# Name this step
name: Rollback production on failure
# Notify team of successful deployment
- if: success()
# Send Slack notification
run: |
curl -X POST -H 'Content-type: application/json' \
--data '{"text":"order-service deployed to production: sha-'"${GITHUB_SHA::7}"'"}' \
${{ secrets.SLACK_WEBHOOK_URL }}
# Name this step
name: Notify team via Slack💡
Interview Tip
A junior engineer typically describes K8s deployment as 'build Docker image, push it, run kubectl apply' which misses the critical production concerns. Demonstrate maturity by structuring your answer around the full pipeline: lint, test with service containers, build and push with layer caching, staged deployment through environments with protection rules, health verification, and automatic rollback. Explain why you tag images with the git SHA rather than 'latest' — it ensures Kubernetes always pulls the new image and provides commit traceability. Discuss OIDC federation for cluster authentication instead of storing kubeconfig as a secret. Mention rollout strategies: rolling updates (default), blue-green via service switching, and canary deployments via service mesh. For bonus points, explain the GitOps alternative where the pipeline updates a config repository rather than running kubectl directly, enabling ArgoCD to reconcile the desired state.
◈ Architecture Diagram
┌──────────────────────────────────────────────────────┐ │ CI/CD Pipeline Flow │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Job:lint │ │ Job:test │ (parallel) │ │ │ ESLint │ │ Jest │ │ │ │ Typecheck│ │ Postgres │ │ │ └─────┬────┘ └─────┬────┘ │ │ └───────┬───────┘ │ │ ↓ │ │ ┌───────────────────────────────────┐ │ │ │ Job: build-image │ │ │ │ ┌─────────┐ ┌─────────────────┐ │ │ │ │ │ Buildx │→ │ Push to GHCR │ │ │ │ │ │ + cache │ │ tag: sha-abc123 │ │ │ │ │ └─────────┘ └─────────────────┘ │ │ │ └──────────────────┬────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────┐ │ │ │ Job: deploy-staging │ │ │ │ environment: staging │ │ │ │ ┌──────────┐ ┌────────┐ ┌──────┐ │ │ │ │ │ OIDC Auth│→│ kubectl│→│Smoke │ │ │ │ │ │ AWS STS │ │ apply │ │ Test │ │ │ │ │ └──────────┘ └────────┘ └──┬───┘ │ │ │ │ │ │ │ │ │ Fail? → Rollback │ │ │ └──────────────────┬────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────┐ │ │ │ Job: deploy-production │ │ │ │ environment: production │ │ │ │ ┌──────────────────────────────┐ │ │ │ │ │ Manual Approval Required │ │ │ │ │ └──────────────┬───────────────┘ │ │ │ │ ↓ │ │ │ │ ┌──────────┐ ┌────────┐ ┌──────┐ │ │ │ │ │ OIDC Auth│→│ kubectl│→│Health│ │ │ │ │ │ AWS STS │ │ apply │ │Check │ │ │ │ │ └──────────┘ └────────┘ └──┬───┘ │ │ │ │ │ │ │ │ │ Fail? → Rollback │ │ │ │ Pass? → Slack Notify │ │ │ └───────────────────────────────────┘ │ └──────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────┐ │ Kubernetes Rolling Update │ │ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ Pod v1 │ │ Pod v1 │ │ Pod v1 │ │ │ │ (running) │ │ (running) │ │ (running) │ │ │ └──────┬─────┘ └──────┬─────┘ └──────┬─────┘ │ │ │ │ │ │ │ ↓ ↓ ↓ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ Pod v2 │ │ Pod v1 │ │ Pod v1 │ │ │ │ (starting) │ │ (running) │ │ (running) │ │ │ └──────┬─────┘ └──────┬─────┘ └──────┬─────┘ │ │ │ │ │ │ │ ↓ ↓ ↓ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ Pod v2 │ │ Pod v2 │ │ Pod v2 │ │ │ │ (running) │ │ (running) │ │ (running) │ │ │ └────────────┘ └────────────┘ └────────────┘ │ └──────────────────────────────────────────────────────┘
💬 Comments
⚡
Quick Answer
Configure the cloud provider to trust GitHub's OIDC issuer, restrict token claims such as repository, branch, tag, or environment, add `permissions: id-token: write` to the deployment job, and use the cloud provider's official login action to exchange the job JWT for a short-lived cloud token.
Detailed Answer
GitHub Actions OIDC removes the need to store long-lived AWS, Azure, GCP, or Vault credentials as GitHub secrets. The workflow receives a short-lived OIDC token only when the job has id-token: write, and the cloud provider exchanges that JWT for a provider-specific access token after validating issuer, audience, subject, and any configured claim conditions.
The important security design is on the cloud side. Do not trust every repository or every branch from an organization. Bind the provider trust policy to predictable claims such as repository, protected branch, tag pattern, or GitHub environment. When environments are involved, use environment protection rules so production tokens cannot be minted by an unreviewed workflow run.
In the workflow, keep permissions minimal: contents: read plus id-token: write for the job that deploys. Use the official cloud login action where available, and avoid passing the OIDC token to custom scripts unless the provider integration requires it. Also log the cloud identity used by the deploy so incident responders can trace changes back to a GitHub run.
Code Example
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
permissions:
contents: read
id-token: write
steps:
- uses: actions/checkout@v4
- name: Cloud login using OIDC
uses: cloud-provider/login-action@v1
- name: Deploy
run: ./deploy.sh💡
Interview Tip
A senior answer emphasizes claim restrictions and environment protection. `id-token: write` only lets the job request a JWT; the cloud trust policy decides whether that JWT can become real cloud access.
◈ Architecture Diagram
GitHub job ↓ OIDC JWT Cloud trust policy ↓ short-lived token Deploy
💬 Comments
⚡
Quick Answer
Use Actions Runner Controller (ARC): ephemeral runner pods scale with queued jobs and are destroyed after each job, giving hosted-like isolation with self-hosted control (network access, custom images, GPUs, cost). The tradeoffs: you own patching and capacity, and self-hosted runners on public repos are dangerous — a fork PR can execute arbitrary code inside your network.
Detailed Answer
ARC runs a controller that watches GitHub's job queue (via runner scale sets) and launches one ephemeral pod per job — the pod registers, runs exactly one job, and is deleted, so state can't leak between jobs. You choose runner images, instance types, and network position (inside the VPC — the usual reason to self-host: reaching private registries, databases for integration tests, or on-prem systems). Scale-to-zero keeps idle cost near nothing. Security calculus: GitHub-hosted runners give you a fresh VM per job, patched by GitHub, with no path into your network — the safest default. Self-hosted flips that: jobs execute inside your perimeter, so treat runner pods as untrusted workloads — dedicated node pools, NetworkPolicies restricting egress to what CI needs, no cluster-admin service accounts, and workload identity (OIDC) instead of static cloud keys. The hard rule: never attach self-hosted runners to public repositories — pull_request from a fork means anyone on the internet can run code on your infrastructure. Docker-in-Docker deserves scrutiny too: prefer rootless builds (BuildKit/kaniko-style) over privileged DinD pods.
Code Example
# ARC runner scale set (values.yaml)
githubConfigUrl: https://github.com/my-org
minRunners: 0
maxRunners: 40
template:
spec:
containers:
- name: runner
image: ghcr.io/my-org/ci-runner:2026.07
resources: {limits: {cpu: '4', memory: 8Gi}}
# jobs: runs-on: arc-linux-amd64💡
Interview Tip
'Ephemeral, one job per pod, then destroyed' is the phrase that matters, plus the hard rule about public repos — that combination shows you understand why ARC exists and what it doesn't fix.
💬 Comments
⚡
Quick Answer
Pull timing data per step from recent runs and diff against a fast month-old run — the regression is usually cache misses (key drift, eviction), dependency growth, runner queueing (not execution) time, or a new step someone added. Fix the dominant term: restore cache hit rate, split/parallelize jobs, or right-size runners.
Detailed Answer
Diagnose with data, not folklore: the run timeline shows per-step durations — export a few fast-vs-slow runs and diff. Common regressions in rough frequency order: (1) cache misses — a lockfile-hash cache key that now never hits because someone changed the key expression, the 10GB repo cache limit evicting your entry, or restore-keys falling back to stale bases that download everything anyway; check the cache step's logs for hit/miss and the cache usage page for evictions; (2) queue time counted as duration — for self-hosted runners, jobs wait for capacity; measure queued-vs-running separately before optimizing execution; (3) dependency creep — node_modules or Docker layers grew; multi-stage builds with registry layer caching (build-push-action with cache-from/cache-to) usually recovers it; (4) an added step — security scans and E2E suites land in the critical path silently; move them to parallel jobs or merge-queue-only workflows; (5) matrix explosion — someone added a dimension and 4 jobs became 24, saturating concurrency. Structural fixes: split lint/test/build into parallel jobs with needs only where true dependencies exist, cache at the right granularity, and for monorepos gate jobs with paths filters so unrelated changes don't run everything.
Code Example
# see hit/miss truthfully
- uses: actions/cache@v4
with:
path: ~/.pnpm-store
key: pnpm-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}
# docker layer cache to registry
- uses: docker/build-push-action@v6
with:
cache-from: type=registry,ref=ghcr.io/org/app:cache
cache-to: type=registry,ref=ghcr.io/org/app:cache,mode=max💡
Interview Tip
Separate queued time from execution time out loud — teams routinely 'optimize' scripts when the actual regression is runner capacity. That distinction reads as real operational experience.
💬 Comments
⚡
Quick Answer
Events trigger workflows; each workflow has jobs that run on isolated runners and contain sequential steps.
Detailed Answer
A workflow (YAML in .github/workflows) runs on events (push, pull_request, schedule, workflow_dispatch). Jobs run in parallel by default on fresh runner VMs and contain steps — shell commands (run) or reusable actions (uses). Each runner is a clean environment, so builds are reproducible; pass data between jobs via artifacts or outputs.
💡
Interview Tip
Draw the hierarchy: event -> workflow -> job(s) -> step(s).
💬 Comments
⚡
Quick Answer
Use needs: to declare a dependency, turning parallel jobs into an ordered pipeline.
Detailed Answer
By default jobs run in parallel. needs: build makes the deploy job start only after build succeeds, and exposes build's outputs. Combine with environment: for gated deploys. Without needs, there's no ordering guarantee.
Code Example
deploy: needs: build runs-on: ubuntu-latest
💡
Interview Tip
Mention that needs also passes job outputs downstream.
💬 Comments
⚡
Quick Answer
A matrix runs the same job across combinations (OS, language versions) in parallel.
Detailed Answer
strategy.matrix expands into one job per combination — e.g. Node 18/20/22 on ubuntu/macos = 6 parallel jobs. fail-fast: false lets all combinations finish so you see every failure. Matrices are ideal for testing library compatibility across versions and platforms.
Code Example
strategy:
fail-fast: false
matrix:
node: [18, 20, 22]💡
Interview Tip
Note fail-fast:false to avoid masking failures.
💬 Comments
⚡
Quick Answer
Use actions/cache with a key derived from a lockfile hash, or the built-in cache option of setup-* actions.
Detailed Answer
actions/cache restores a directory keyed on hashFiles('lockfile') and saves it after the run, skipping re-downloads when the lockfile is unchanged. Many setup actions (setup-node cache: npm) wrap this. Good cache keys are specific enough to be correct but stable enough to hit often.
Code Example
- uses: actions/cache@v4
with:
path: ~/.cache/pip
key: pip-${{ hashFiles('requirements.txt') }}💡
Interview Tip
Explain a good key balances hit-rate vs correctness.
💬 Comments
⚡
Quick Answer
Store secrets in repo/environment settings, reference via ${{ secrets.X }}, and prefer OIDC over long-lived cloud keys.
Detailed Answer
Never hard-code credentials. Environment-scoped secrets plus required reviewers gate prod. Even better, use OIDC (permissions: id-token: write) to exchange a short-lived token with AWS/GCP/Azure, eliminating stored static keys. Set the default GITHUB_TOKEN to least privilege with permissions:.
Code Example
permissions: id-token: write contents: read
💡
Interview Tip
OIDC over static keys is the modern best-practice answer.
💬 Comments
⚡
Quick Answer
Interpolating untrusted input (like a PR title) directly into a run: shell can execute attacker code; pass it via env instead.
Detailed Answer
${{ github.event.pull_request.title }} placed inside a run block is expanded before the shell runs, so a crafted title can inject commands. Mitigate by assigning untrusted values to an env: variable and referencing $VAR in the script, and by pinning third-party actions to a commit SHA and using least-privilege tokens.
💡
Interview Tip
This is a favorite security question — know the env: mitigation.
💬 Comments
⚡
Quick Answer
Tags are mutable; a hijacked tag could run malicious code in your pipeline with access to secrets. A SHA is immutable.
Detailed Answer
uses: some/action@v3 trusts whoever controls that tag. If their account is compromised and they move the tag, your next run executes new code with your secrets. Pinning to a full commit SHA (some/action@<sha>) freezes exactly what runs; use Dependabot to update pins deliberately.
💡
Interview Tip
Mention Dependabot to keep SHA pins fresh.
💬 Comments
⚡
Quick Answer
Reusable workflows call an entire workflow with inputs/secrets; composite actions bundle repeated steps into one action.
Detailed Answer
Define a deploy workflow once and call it per environment with uses: ./.github/workflows/deploy.yml and with:/secrets:. Composite actions package a sequence of steps (action.yml) shared across repos. Both keep pipelines DRY and consistent.
💡
Interview Tip
Distinguish reusable workflow (whole job graph) from composite action (step bundle).
💬 Comments
⚡
Quick Answer
It groups runs so a new run cancels or queues behind superseded ones, preventing pile-ups.
Detailed Answer
concurrency with cancel-in-progress: true cancels an in-flight run when a newer commit arrives on the same ref — useful for fast feedback and to avoid deploying stale commits. Grouping by workflow + ref is the common pattern.
Code Example
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true💡
Interview Tip
Give the deploy use-case: cancel superseded deploys.
💬 Comments
⚡
Quick Answer
workflow_dispatch adds a manual Run button (with inputs); schedule runs on cron.
Detailed Answer
workflow_dispatch is ideal for on-demand deploys or maintenance jobs and can accept typed inputs. schedule uses POSIX cron in UTC (e.g. '0 6 * * *'). Combine with paths: filters on push to skip heavy jobs for docs-only changes.
Code Example
on:
workflow_dispatch:
schedule:
- cron: '0 6 * * *'💡
Interview Tip
Remember schedule cron is UTC.
💬 Comments