CI/CD-Pipeline Interviewvragen: GitHub Actions, GitLab CI en Jenkins in 2026

CI/CD-pipeline interviewvragen behoren tot de meest voorkomende onderwerpen in DevOps-sollicitatiegesprekken in 2026. Met GitHub Actions dat nu meer dan 71 miljoen jobs per dag verwerkt en in juni 2026 parallelle step-uitvoering heeft uitgebracht, GitLab CI op versie 19 met de native Secrets Manager, en Jenkins met een adoptiegraad van 28%, verwachten interviewers dat kandidaten praktische vaardigheid met alle drie de platformen demonstreren.

GitHub Actions Workflow-Structuur en Triggers

GitHub Actions organiseert automatisering rond workflows, jobs en steps. Een workflow is een YAML-bestand opgeslagen in .github/workflows/ dat definieert wanneer en hoe automatisering draait. Elke workflow bevat een of meer jobs, en elke job draait op een aparte runner.

Een veelgestelde interviewvraag vraagt kandidaten om de relatie tussen on-triggers, job-afhankelijkheden en het needs-keyword uit te leggen.

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

Deze workflow demonstreert drie belangrijke concepten: het needs-keyword creëert een afhankelijkheidsgrafiek tussen jobs, de matrix-strategie maakt parallel testen over Node.js-versies mogelijk, en het environment-keyword beveiligt deployments achter handmatige goedkeuringen.

GitHub Actions Parallelle Steps

GitHub Actions heeft op 25 juni 2026 parallelle step-uitvoering uitgebracht, waarmee een van de meest gevraagde features is geïmplementeerd. Voorheen draaiden alle steps binnen een job sequentieel. De nieuwe feature introduceert vier keywords die gelijktijdige uitvoering binnen een enkele job mogelijk maken.

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

Het background: true-keyword start een step asynchroon en gaat direct door naar de volgende step. Het wait-all-keyword pauzeert uitvoering totdat alle voorgaande background-steps zijn voltooid. Het parallel-keyword biedt een verkorte notatie die meerdere steps gelijktijdig uitvoert en wacht tot alle zijn voltooid voordat wordt doorgegaan.

Twee extra keywords bestaan: wait richt zich op specifieke benoemde background-steps, en cancel beëindigt een background-step netjes wanneer deze niet langer nodig is (nuttig voor het stoppen van langlopende services).

GitLab CI Pipeline-Configuratie met Stages

GitLab CI gebruikt een .gitlab-ci.yml-bestand in de repository-root. In tegenstelling tot GitHub Actions waar jobs standaard onafhankelijk draaien, organiseert GitLab CI jobs in stages die sequentieel worden uitgevoerd, terwijl jobs binnen dezelfde stage parallel draaien.

Interviewers vragen kandidaten vaak om een GitHub Actions workflow naar een GitLab CI-pipeline te converteren, of andersom.

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

Belangrijke verschillen met GitHub Actions: stages dwingen de uitvoeringsvolgorde globaal af, het parallel:matrix-keyword behandelt matrix-builds, en artifacts:reports:junit integreert testresultaten direct in merge request-weergaven.

GitLab 19.0 (mei 2026) introduceerde de Secrets Manager in open beta, waarmee native opslag van secrets mogelijk is zonder externe diensten zoals HashiCorp Vault. GitLab 19.2 (juli 2026) maakte geplande pipeline-uitvoeringsbeleid algemeen beschikbaar, waardoor teams compliance-scans of dependency-checks kunnen afdwingen volgens een vast schema over meerdere projecten vanuit een enkele beleidsdefinitie.

Jenkins Declarative Pipeline Syntax

Jenkins gebruikt een Jenkinsfile in de repository-root. De declaratieve pipeline-syntax, aanbevolen als standaard in 2026, biedt gestructureerde foutafhandeling en een duidelijke stage-gebaseerde indeling.

Een veelgestelde interviewvraag: leg het verschil uit tussen declaratieve en gescripte pipelines, en wanneer welke te gebruiken.

// 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}"
        }
    }
}

Declaratieve pipelines dwingen structuur af door verplichte pipeline-, agent- en stages-blokken. De parallel-directive binnen een stage draait lint en test gelijktijdig. De input-directive pauzeert uitvoering voor handmatige goedkeuring, vergelijkbaar met GitHub Actions environments en GitLab manual gates. Jenkins vereist Java 21 sinds januari 2026, dus pipeline-omgevingen moeten rekening houden met deze runtime-afhankelijkheid.

Secrets Management over CI/CD-Platformen

Elk CI/CD-interview bevat vragen over secrets management. Elk platform behandelt credentials anders, en het begrijpen van de beveiligingsimplicaties is essentieel.

GitHub Actions slaat secrets op op repository-, environment- of organisatieniveau. Secrets worden automatisch gemaskeerd in logs, maar het huidige scoping-model heeft beperkingen. De 2026 security roadmap introduceert scoped secrets die credentials binden aan expliciete uitvoeringscontexten, waarmee het risico van te brede toegang wordt aangepakt.

GitLab CI biedt CI/CD-variabelen met beschermingsregels. Beschermde variabelen worden alleen geïnjecteerd in pipelines die draaien op beschermde branches of tags. GitLab 19.0 introduceerde de Secrets Manager, waardoor teams secrets native kunnen opslaan en refereren zonder externe vaults. Secrets zijn beperkt tot projecten of groepen en alleen toegankelijk voor jobs die ze expliciet aanvragen.

Jenkins gebruikt de Credentials-plugin met meerdere credential-types (gebruikersnaam/wachtwoord, SSH-sleutel, geheime tekst, certificaat). De credentials()-helper in declaratieve pipelines bindt secrets aan omgevingsvariabelen, en Folder-level credentials beperken toegang tot specifieke projecten.

Het kritieke antwoord in interviews: nooit secrets hardcoden in pipeline-bestanden, altijd het native secret management van het platform gebruiken, credentials regelmatig roteren, en kortstondige tokens verkiezen boven langlevende API-sleutels.

Pipeline-Optimalisatie en Cachingstrategieën

Trage pipelines hebben directe impact op de productiviteit van ontwikkelaars. Interviewers testen of kandidaten prestatieproblemen in CI/CD-systemen kunnen diagnosticeren en oplossen.

Drie universele optimalisatietechnieken zijn van toepassing op alle drie de platformen:

Dependency caching voorkomt het opnieuw downloaden van packages bij elke run. GitHub Actions gebruikt actions/cache of ingebouwde cache-ondersteuning in setup-actions. GitLab CI gebruikt cache met een key-strategie. Jenkins vertrouwt op workspace-persistentie of de stash/unstash-commando's.

Parallelle uitvoering verdeelt werk over meerdere runners. GitHub Actions ondersteunt nu zowel parallelle jobs (matrix-strategie) als parallelle steps (background/parallel-keywords). GitLab CI gebruikt parallel:matrix, en Jenkins gebruikt de parallel-directive. De juiste opsplitsingsgranulariteit hangt af van het project: te veel parallelle jobs verspillen runner-opstarttijd, te weinig laten capaciteit onbenut.

Conditionele uitvoering slaat onnodige stages over. Alle drie de platformen ondersteunen dit: GitHub Actions met if-expressies, GitLab CI met rules, en Jenkins met when-directives. Een goed ontworpen pipeline slaat deployment-stages over op feature-branches en voorkomt dat lint-only wijzigingen volledige testsuites triggeren.

CI/CD Pipeline-Beveiliging en Supply Chain-Bescherming

Supply chain-aanvallen gericht op CI/CD-systemen namen significant toe in 2025, met incidenten die tj-actions/changed-files en andere populaire GitHub Actions troffen. Interviewvragen behandelen nu regelmatig hardening-strategieën.

Pin action-versies aan specifieke commit-SHA's in plaats van tags om tag-hijacking-aanvallen te voorkomen:

# .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 adresseert supply chain-zorgen door CI/CD-componenten met SLSA Level 1-attestatie (beschikbaar sinds GitLab 18.1), die duidelijkere herkomst bieden bij het samenstellen van pipelines uit herbruikbare componenten. Immutable container-tags (GitLab 18.2) voorkomen image-vervanging na publicatie.

Voor Jenkins moet het Shared Library-mechanisme een dedicated repository gebruiken met branch-bescherming, code review-vereisten en ondertekende commits. De Europese Commissie heeft een Jenkins Bug Bounty-programma gelanceerd via YesWeHack, wat de kritieke rol van het platform in enterprise supply chains weerspiegelt.

Cross-Platform Vergelijking voor Interviewvoorbereiding

Deze vergelijkingstabel dekt de meest geteste verschillen in interviews. De vervolgvraag luidt typisch: "Welk platform zou je kiezen voor een nieuw project, en waarom?" Het antwoord hangt af van bestaande tooling, teamgrootte, compliance-vereisten, en of de organisatie de voorkeur geeft aan beheerde infrastructuur (GitHub/GitLab) of volledige controle (Jenkins).

Bronnen

• Actions steps can now be run in parallel (GitHub Changelog, juni 2026)
• GitLab 19.0 release notes (GitLab Docs, mei 2026)
• GitLab 19.2 release notes (GitLab Docs, juli 2026)
• Jenkins Changelog (Jenkins.io, augustus 2026)
• GitHub Actions 2026 Security Roadmap (GitHub Blog)

Oefen deze vragen hands-on met de CI/CD-fundamenten en de platformspecifieke modules voor GitHub Actions, GitLab CI en Jenkins. De uitgebreide gids essentiële DevOps-interviewvragen behandelt het volledige spectrum aan onderwerpen buiten CI/CD.

Belangrijkste Punten voor CI/CD-Pipeline Interviews

• GitHub Actions parallelle steps (background, wait-all, parallel) zijn uitgebracht in juni 2026, waardoor gelijktijdige uitvoering binnen een enkele job mogelijk is terwijl runner, checkout en workspace worden gedeeld
• GitLab 19.x introduceerde de native Secrets Manager (open beta, mei 2026) en maakte geplande pipeline-uitvoeringsbeleid algemeen beschikbaar (juli 2026), waardoor de afhankelijkheid van externe tooling afneemt
• Jenkins 2.574+ heeft core-plugins zoals JUnit en Mailer uit het WAR-bestand verwijderd, wat expliciete installatie vereist voor instanties zonder toegang tot het update center
• Secrets management is het meest geteste beveiligingsonderwerp over alle drie de platformen: demonstreer kennis van scoped secrets, protected variables en credential-rotatiestrategieën
• Pipeline-optimalisatie door caching, parallellisatie en conditionele uitvoering is universeel toepasbaar en signaleert praktische productie-ervaring aan interviewers
• Bereid minstens één werkende pipeline-configuratie per platform voor, met focus op realistische patronen in plaats van voorbeelden uit handboeken