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, GitLab CI shipping AI-powered pipeline generation, 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.

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 18.11 also introduced CI/CD inputs for merge request pipelines, allowing dynamic parameter overrides per pipeline run.

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 now 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 18.3 added fine-grained CI/CD job token permissions implementing least-privilege principles.

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 uses matrix strategies, 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 recently launched a Jenkins Bug Bounty Program through YesWeHack, reflecting the platform's critical role in enterprise supply chains.

Cross-Platform Comparison for Interview Preparation

| Feature | GitHub Actions | GitLab CI | Jenkins | |---|---|---|---| | Config file | .github/workflows/*.yml | .gitlab-ci.yml | Jenkinsfile | | Execution model | Job-based (parallel by default) | Stage-based (sequential stages) | Stage-based (flexible) | | Runner hosting | GitHub-hosted + self-hosted | GitLab.com shared + self-hosted | Self-hosted only | | Secret storage | Repository/Org/Environment secrets | CI/CD variables (protected) | Credentials plugin | | Matrix builds | strategy.matrix | parallel:matrix | matrix (plugin) | | Manual gates | environment + required reviewers | when: manual | input directive | | Marketplace | 20,000+ Actions on Marketplace | CI/CD Components Catalog | 1,800+ plugins | | AI features | Copilot for Actions (preview) | Duo CI Expert Agent (beta) | Community plugins | | Pricing | Free for public repos, per-minute for private | 400 CI/CD minutes free, then tiered | Free (open source), self-managed |

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).

Practice these questions hands-on with the CI/CD fundamentals and GitHub Actions interview modules, or dive deeper into 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.

Conclusion

• GitHub Actions excels for GitHub-native workflows with its marketplace ecosystem and upcoming parallel steps feature, but pin actions to commit SHAs to mitigate supply chain risks
• GitLab CI provides the tightest integration between CI/CD and security scanning, with SLSA attestation for components and fine-grained job token permissions since version 18.3
• Jenkins remains the most flexible option for organizations needing full infrastructure control, though it requires Java 21 as of January 2026 and carries a higher maintenance burden
• 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