CI/CD Pipeline Interview Questions: GitHub Actions, GitLab CI and Jenkins in 2026

CI/CD pipeline interview questions rank among the most common topics in DevOps hiring rounds in 2026. With GitHub Actions now processing over 71 million jobs per day and shipping parallel step execution in June 2026, GitLab CI reaching version 19 with its native Secrets Manager, and Jenkins still holding a 28% adoption rate, interviewers expect candidates to demonstrate hands-on fluency across all three platforms.

GitHub Actions Workflow Structure and Triggers

GitHub Actions organizes automation around workflows, jobs, and steps. A workflow is a YAML file stored in .github/workflows/ that defines when and how automation runs. Each workflow contains one or more jobs, and each job runs on a separate runner.

A common interview question asks candidates to explain the relationship between on triggers, job dependencies, and the needs keyword.

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

This workflow demonstrates three key concepts: the needs keyword creates a dependency graph between jobs, the matrix strategy enables parallel testing across Node.js versions, and the environment keyword gates deployments behind manual approvals.

GitHub Actions Parallel Steps

GitHub Actions shipped parallel step execution on June 25, 2026, addressing one of the most requested features. Previously, all steps within a job ran sequentially. The new feature introduces four keywords that enable concurrent execution within a single job.

# .github/workflows/parallel-steps.yml
name: Build with Parallel Steps

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci

      # Run lint and typecheck in parallel
      - name: lint
        run: npm run lint
        background: true

      - name: typecheck
        run: npm run typecheck
        background: true

      - wait-all:              # wait for both to complete

      # Or use the parallel shorthand
      - parallel:
          - name: build-frontend
            run: npm run build:frontend
          - name: build-backend
            run: npm run build:backend

      - run: npm run deploy

The background: true keyword starts a step asynchronously and immediately continues to the next step. The wait-all keyword pauses execution until all preceding background steps complete. The parallel keyword provides a shorthand that runs multiple steps concurrently and waits for all to finish before continuing.

Two additional keywords exist: wait targets specific named background steps, and cancel gracefully terminates a background step when no longer needed (useful for stopping long-running services).

GitLab CI Pipeline Configuration with Stages

GitLab CI uses a .gitlab-ci.yml file at the repository root. Unlike GitHub Actions where jobs run independently by default, GitLab CI organizes jobs into stages that execute sequentially, while jobs within the same stage run in parallel.

Interviewers frequently ask candidates to convert a GitHub Actions workflow into a GitLab CI pipeline, or vice versa.

# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # manual gate
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh

Key differences from GitHub Actions: stages enforce execution order globally, the parallel:matrix keyword handles matrix builds, and artifacts:reports:junit integrates test results directly into merge request views.

GitLab 19.0 (May 2026) introduced the Secrets Manager in open beta, providing native secret storage without external services like HashiCorp Vault. GitLab 19.2 (July 2026) made scheduled pipeline execution policies generally available, allowing teams to enforce compliance scans or dependency checks on a fixed cadence across multiple projects from a single policy definition.

Jenkins Declarative Pipeline Syntax

Jenkins uses a Jenkinsfile stored in the repository root. The declarative pipeline syntax, recommended as the default in 2026, provides structured error handling and a clear stage-based layout.

A frequent interview question: explain the difference between declarative and scripted pipelines, and when to use each.

// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // parallel execution
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}

Declarative pipelines enforce structure through required pipeline, agent, and stages blocks. The parallel directive inside a stage runs lint and test simultaneously. The input directive pauses execution for manual approval, similar to GitHub Actions environments and GitLab manual gates. Jenkins requires Java 21 as of January 2026, so pipeline environments must account for this runtime dependency.

Secrets Management Across CI/CD Platforms

Every CI/CD interview includes questions about secrets management. Each platform handles credentials differently, and understanding the security implications matters.

GitHub Actions stores secrets at the repository, environment, or organization level. Secrets are masked in logs automatically, but the current scoping model has limitations. The 2026 security roadmap introduces scoped secrets that bind credentials to explicit execution contexts, addressing the risk of overly broad access.

GitLab CI provides CI/CD variables with protection rules. Protected variables only inject into pipelines running on protected branches or tags. GitLab 19.0 introduced the Secrets Manager, allowing teams to store and reference secrets natively without external vaults. Secrets are scoped to projects or groups and accessible only to jobs that explicitly request them.

Jenkins uses the Credentials plugin with multiple credential types (username/password, SSH key, secret text, certificate). The credentials() helper in declarative pipelines binds secrets to environment variables, and Folder-level credentials scope access to specific projects.

The critical interview answer: never hardcode secrets in pipeline files, always use the platform's native secret management, rotate credentials regularly, and prefer short-lived tokens over long-lived API keys.

Pipeline Optimization and Caching Strategies

Slow pipelines directly impact developer productivity. Interviewers test whether candidates can diagnose and fix performance bottlenecks in CI/CD systems.

Three universal optimization techniques apply across all three platforms:

Dependency caching avoids re-downloading packages on every run. GitHub Actions uses actions/cache or built-in cache support in setup actions. GitLab CI uses cache with a key strategy. Jenkins relies on workspace persistence or the stash/unstash commands.

Parallel execution splits work across multiple runners. GitHub Actions now supports both parallel jobs (matrix strategy) and parallel steps (background/parallel keywords). GitLab CI uses parallel:matrix, and Jenkins uses the parallel directive. The right splitting granularity depends on the project: too many parallel jobs waste runner startup time, too few leave capacity unused.

Conditional execution skips unnecessary stages. All three platforms support this: GitHub Actions with if expressions, GitLab CI with rules, and Jenkins with when directives. A well-designed pipeline skips deployment stages on feature branches and skips lint-only changes from triggering full test suites.

CI/CD Pipeline Security and Supply Chain Protection

Supply chain attacks targeting CI/CD systems increased significantly in 2025, with incidents affecting tj-actions/changed-files and other popular GitHub Actions. Interview questions now regularly probe candidates on hardening strategies.

Pin action versions to specific commit SHAs rather than tags to prevent tag-hijacking attacks:

# .github/workflows/secure.yml
steps:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact commit SHA
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

GitLab CI addresses supply chain concerns through CI/CD components with SLSA Level 1 attestation (available since GitLab 18.1), providing clearer provenance when assembling pipelines from reusable components. Immutable container tags (GitLab 18.2) prevent image replacement after publication.

For Jenkins, the Shared Library mechanism should use a dedicated repository with branch protection, code review requirements, and signed commits. The European Commission launched a Jenkins Bug Bounty Program through YesWeHack, reflecting the platform's critical role in enterprise supply chains.

Cross-Platform Comparison for Interview Preparation

This comparison table covers the most commonly tested differences in interviews. The follow-up question typically asks: "Which platform would you choose for a new project, and why?" The answer depends on existing tooling, team size, compliance requirements, and whether the organization prefers managed infrastructure (GitHub/GitLab) or full control (Jenkins).

Sources

• Actions steps can now be run in parallel (GitHub Changelog, June 2026)
• GitLab 19.0 release notes (GitLab Docs, May 2026)
• GitLab 19.2 release notes (GitLab Docs, July 2026)
• Jenkins Changelog (Jenkins.io, August 2026)
• GitHub Actions 2026 Security Roadmap (GitHub Blog)

Practice these questions hands-on with the CI/CD fundamentals and GitHub Actions interview modules, or explore GitLab CI and Jenkins specific questions. For broader DevOps preparation, the essential DevOps interview questions guide covers the full scope of topics beyond CI/CD.

Key Takeaways for CI/CD Pipeline Interviews

• GitHub Actions parallel steps (background, wait-all, parallel) shipped in June 2026, enabling concurrent execution within a single job while sharing the runner, checkout, and workspace
• GitLab 19.x introduced the native Secrets Manager (open beta, May 2026) and made scheduled pipeline execution policies generally available (July 2026), reducing reliance on external tooling
• Jenkins 2.574+ unbundled core plugins including JUnit and Mailer from the WAR file, requiring explicit installation for instances without update center access
• Secrets management is the most commonly tested security topic across all three platforms: demonstrate knowledge of scoped secrets, protected variables, and credential rotation strategies
• Pipeline optimization through caching, parallelization, and conditional execution applies universally and signals practical production experience to interviewers
• Prepare at least one working pipeline configuration per platform, focusing on real-world patterns rather than toy examples