50 CI/CD Interview Questions (With Answers)

CI/CD interviews test your understanding of automation pipelines, deployment strategies, branching models, containerisation, and security. This guide covers the 50 most common questions — with concise answers, real examples, and comparison tables.

Quick reference

Core Concepts

1. What is CI/CD and what does each term mean?

CI/CD is the combined practice of integrating code changes frequently, running automated tests, and delivering or deploying artifacts to environments automatically.

2. What is the difference between Continuous Delivery and Continuous Deployment?

Both require a passing test suite and an artifact promoted through environments.

3. What are the stages of a typical CI/CD pipeline?

Code push → Source → Build → Test → Security scan → Artifact → Deploy staging → Integration test → Manual gate? → Deploy prod → Monitor

4. What is trunk-based development (TBD) vs GitFlow?

Most modern tech companies (Google, Meta, Amazon) use TBD.

5. What is a pipeline artifact?

An artifact is the output of a build stage that downstream stages consume — a compiled binary, a Docker image, a JAR file, or a test report.

Best practices:

• Version artifacts with commit SHA or semantic version.
• Store in an artifact registry (JFrog Artifactory, GitHub Packages, AWS ECR) — not in source control.
• Promote the same artifact through environments (build once, deploy many).
• Never rebuild code in a later stage — this risks environment-specific bugs.

6. What are pipeline triggers?

7. What is a "shift-left" approach in CI/CD?

Shift-left means moving testing and security checks earlier in the development cycle — towards the developer — rather than catching issues late at QA or production.

Examples:

• Run linters and unit tests locally via pre-commit hooks.
• Run SAST in CI on every PR rather than before release.
• Run infrastructure cost estimates in the pipeline before provisioning.

Benefit: bugs and security issues are 10–100× cheaper to fix in development than in production.

8. What is a "deployment pipeline" vs a "CI pipeline"?

A deployment pipeline is the superset — CI is the first section of it.

GitHub Actions

9. What are the core components of a GitHub Actions workflow?

name: CI                          # Workflow name
on: [push, pull_request]          # Trigger events
jobs:                             # One or more jobs
  build:
    runs-on: ubuntu-latest        # Runner
    steps:
      - uses: actions/checkout@v4 # Reusable action
      - run: npm ci               # Shell command
      - run: npm test

10. How do you share data between GitHub Actions jobs?

Jobs run on isolated runners and do not share the filesystem.

Option 1: Artifacts (large files)

- uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: dist/

# In another job:
- uses: actions/download-artifact@v4
  with:
    name: build-output

Option 2: Job outputs (small values)

jobs:
  build:
    outputs:
      version: ${{ steps.ver.outputs.version }}
    steps:
      - id: ver
        run: echo "version=$(cat package.json | jq -r .version)" >> $GITHUB_OUTPUT

  deploy:
    needs: build
    steps:
      - run: echo "Deploying ${{ needs.build.outputs.version }}"

11. How do you handle secrets in GitHub Actions?

1. Store in GitHub Settings → Secrets and Variables → never hardcode in workflow files.
2. Reference with ${{ secrets.MY_SECRET }} — value is masked in logs.
3. Environment secrets scope secrets to specific environments (production, staging).
4. Avoid printing secrets with echo — they may be partially visible in edge cases.

- run: docker login -u ${{ secrets.DOCKER_USERNAME }} -p ${{ secrets.DOCKER_PASSWORD }}

Never commit .env files containing secrets.

12. What are reusable workflows in GitHub Actions?

Reusable workflows let you DRY up common pipeline logic — define once, call from many workflows.

# .github/workflows/docker-build.yml (reusable)
on:
  workflow_call:
    inputs:
      image_name:
        required: true
        type: string
    secrets:
      DOCKER_PASSWORD:
        required: true

# Caller workflow
jobs:
  build:
    uses: ./.github/workflows/docker-build.yml
    with:
      image_name: myapp
    secrets:
      DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}

Also useful: composite actions for reusing steps, and matrix strategy for running jobs across multiple OS/language versions.

13. How do you parallelise GitHub Actions jobs?

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm test

  lint:
    runs-on: ubuntu-latest
    steps:
      - run: npm run lint

  security-scan:
    runs-on: ubuntu-latest
    steps:
      - run: npm audit

  deploy:
    needs: [unit-tests, lint, security-scan]   # wait for all 3
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

Jobs without needs: run in parallel by default.

14. What is the matrix strategy in GitHub Actions?

The matrix strategy runs the same job across multiple combinations of variables — ideal for cross-platform testing.

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

This example runs 9 jobs (3 OS × 3 Node versions) in parallel.

Jenkins

15. What is a Declarative vs Scripted Jenkins Pipeline?

// Declarative
pipeline {
  agent any
  stages {
    stage('Build') {
      steps { sh 'mvn package' }
    }
  }
  post {
    failure { slackSend message: "Build failed" }
  }
}

16. What are Jenkins Shared Libraries?

Shared Libraries let you define reusable pipeline functions in a separate Git repo, importable by all Jenkinsfiles in the organisation.

shared-library/
├── vars/
│   └── dockerBuild.groovy    # call as dockerBuild(imageName: 'myapp')
├── src/                      # Groovy classes
└── resources/                # Non-Groovy files

// In Jenkinsfile
@Library('my-shared-lib') _
dockerBuild(imageName: 'myapp', tag: env.BUILD_NUMBER)

Benefits: DRY, versioned, tested separately.

17. How does Jenkins handle concurrent builds?

• throttleConcurrentBuilds plugin limits parallel builds of a job.
• disableConcurrentBuilds() in Declarative pipeline queues subsequent builds.
• Agent labels control which node runs a job — prevents resource contention.
• Lockable Resources plugin protects shared environments (e.g., staging) from concurrent deploys.

GitLab CI

18. What is the structure of a .gitlab-ci.yml file?

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  script:
    - npm test

deploy_staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

19. How do GitLab CI rules: differ from only/except?

rules: is the modern, more powerful replacement for only/except.

deploy:
  rules:
    - if: '$CI_COMMIT_TAG'          # Only on tags
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: manual                  # Manual trigger on MR
    - when: never                   # Skip in all other cases

rules: supports if, changes, exists, and when — giving you fine-grained control. only/except only supports simple patterns.

20. What is GitLab Auto DevOps?

Auto DevOps provides a default CI/CD pipeline based on best practices — build, test, code quality, SAST, licence checks, Docker build, container scanning, review apps, and deployment — all with zero configuration.

Triggered by convention (Dockerfile, Heroku Procfile, etc.). Useful for projects without a custom .gitlab-ci.yml.

Deployment Strategies

21. What is a blue-green deployment?

Blue-green keeps two identical production environments: blue (current live) and green (new version). After testing green, traffic is switched instantly.

                    Load Balancer
                   /              \
   [Blue - v1.0]  ←  100% traffic   [Green - v2.0]
                                     ↑ 0% traffic (being tested)

   After switch:
   [Blue - v1.0]  ←  0% traffic    [Green - v2.0]  ← 100% traffic
   (kept as rollback)

Pros: Instant rollback (switch back to blue), zero downtime. Cons: Double infrastructure cost.

22. What is a canary deployment?

A canary gradually shifts traffic to the new version while the rest stays on the old version.

[v2.0]  ←  5% traffic
[v1.0]  ← 95% traffic

After 30 min if metrics healthy:
[v2.0]  ← 25% → 50% → 100%

Pros: Real user traffic validates the new version; blast radius limited if issues found. Cons: Requires weighted routing (load balancer / service mesh), more complex monitoring.

23. What is a rolling deployment?

A rolling update replaces old instances one-by-one (or in batches) until all instances run the new version.

# Kubernetes rolling update config
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # At most 1 pod down at once
      maxSurge: 1         # At most 1 extra pod during update

Pros: No extra infrastructure. Cons: During rollout, both versions are live simultaneously — requires backwards-compatible API changes.

24. What are feature flags and why are they used in CI/CD?

Feature flags (feature toggles) let you deploy code without activating it — the new code path is enabled/disabled by a runtime configuration flag.

if (featureFlags.isEnabled('new-checkout-flow', userId)) {
  return <NewCheckout />;
}
return <OldCheckout />;

Benefits:

• Dark launch: deploy to production, test with internal users only.
• Progressive rollout: enable for 1% → 10% → 100% of users.
• Kill switch: instantly disable a broken feature without a rollback deploy.
• Decouple deploy from release — the core of continuous deployment.

Tools: LaunchDarkly, Unleash, Flipt, ConfigCat.

25. What is the difference between rollback and roll forward?

Blue-green makes rollback instant (switch traffic back). In Kubernetes, kubectl rollout undo deployment/myapp rolls back to the previous ReplicaSet.

Roll forward is often preferred when the database schema has changed and a rollback would break data integrity.

Docker & Kubernetes in CI/CD

26. How do you build and push a Docker image in a CI pipeline?

# GitHub Actions example
- name: Log in to ECR
  run: aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REGISTRY

- name: Build image
  run: docker build -t $ECR_REGISTRY/myapp:${{ github.sha }} .

- name: Push image
  run: docker push $ECR_REGISTRY/myapp:${{ github.sha }}

Best practices:

• Tag with commit SHA for traceability (never overwrite latest in production).
• Use multi-stage builds to minimise image size and attack surface.
• Scan the image before pushing (Trivy, Snyk, Docker Scout).
• Use a build cache (--cache-from) to speed up builds.

27. How do you deploy to Kubernetes from a CI/CD pipeline?

Approach 1: kubectl apply (push-based)

- name: Deploy to Kubernetes
  run: |
    aws eks update-kubeconfig --region us-east-1 --name my-cluster
    kubectl set image deployment/myapp myapp=$ECR_REGISTRY/myapp:${{ github.sha }}
    kubectl rollout status deployment/myapp

Approach 2: Helm upgrade (recommended for complex apps)

helm upgrade --install myapp ./charts/myapp \
  --set image.tag=$IMAGE_TAG \
  --namespace production \
  --atomic \   # Rollback on failure
  --timeout 5m

Approach 3: GitOps (pull-based — see Q35) The pipeline only updates the image tag in a Git repo; Argo CD or Flux applies the change.

28. What is Docker layer caching and how does it help CI builds?

Docker builds images layer by layer. If a layer's content hasn't changed, Docker reuses the cached layer.

Optimise Dockerfile for caching:

# Install dependencies BEFORE copying source code
# (dependencies change less often than source)
COPY package.json package-lock.json ./
RUN npm ci                     # Cached unless package*.json changes

COPY . .                       # Invalidates only this layer and below
RUN npm run build

In CI, persist the cache:

# GitHub Actions
- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

Proper caching reduces a 5-minute build to under 1 minute for unchanged dependencies.

29. How do you manage environment-specific configuration in Kubernetes deployments?

Never hardcode environment-specific values in the Docker image.

30. What is a Kubernetes readiness probe and why is it important for CI/CD?

A readiness probe tells Kubernetes when a pod is ready to accept traffic.

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3

During a rolling deployment, Kubernetes only routes traffic to new pods that pass the readiness probe. This prevents users from hitting pods that are still starting up. A deployment pipeline that checks kubectl rollout status waits until all pods are ready — providing automated verification of the deployment.

GitOps

31. What is GitOps?

GitOps is an operational model where Git is the single source of truth for both application code and infrastructure state. Changes to production are made by committing to Git — an automated operator reconciles the cluster state to match the Git repo.

32. What are Argo CD and Flux?

Both are Kubernetes-native GitOps operators.

Both support Helm, Kustomize, raw manifests, and automatic sync on Git push.

33. What is the "image update automation" pattern in GitOps?

The CI pipeline builds and pushes a new Docker image → a bot (Flux Image Automation or Argo CD Image Updater) detects the new tag in the registry → commits the updated image tag to the Git repo → the GitOps operator reconciles the cluster.

CI builds myapp:abc123 → ECR
       ↓
Image Automation detects new tag
       ↓
Commits: image: myapp:abc123 → Git repo
       ↓
Argo CD detects Git change → deploys to cluster

Benefits: full audit trail in Git, no pipeline needs direct cluster access.

Security (DevSecOps)

34. What is the difference between SAST, DAST, and SCA?

Tools: Semgrep / SonarQube (SAST), OWASP ZAP / Burp (DAST), Snyk / Dependabot (SCA).

35. How do you prevent secrets from being committed to version control?

Prevention (before commit):

• git-secrets, detect-secrets, or gitleaks as pre-commit hooks.
• .gitignore for .env files.
• IDE plugins (GitGuardian, Spectral).

Detection (after commit):

• gitleaks or truffleHog in CI pipeline to scan history.
• GitHub secret scanning (built-in for public/private repos on GitHub Enterprise).

Response (if leaked):

1. Rotate the secret immediately.
2. Remove from history using git filter-repo (not git rebase — it's unreliable).
3. Assume the secret was compromised from the moment it was pushed.

36. What is the principle of least privilege in CI/CD?

Every pipeline job should have only the minimum permissions needed:

• Service account for deploying to Kubernetes needs deploy RBAC role, not cluster-admin.
• AWS IAM role for S3 upload needs s3:PutObject on one bucket, not s3:*.
• GitHub Actions job deploying to staging should not have production secrets.
• Use OIDC federated identity (GitHub Actions → AWS, GCP, Azure) instead of long-lived credentials.

# GitHub Actions OIDC with AWS — no static credentials
permissions:
  id-token: write
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
    aws-region: us-east-1

37. What is container image scanning and why does it matter in CI/CD?

Container images often include OS packages and libraries with known vulnerabilities (CVEs). Scanning finds these before deployment.

# Trivy — scan before pushing
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest

Best practice: fail the pipeline on HIGH or CRITICAL CVEs with no available fix exception.

Pipeline Best Practices

38. How do you cache dependencies in a CI pipeline?

Caching avoids re-downloading dependencies on every run.

# GitHub Actions — cache node_modules
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

Key on the lockfile hash — cache is invalidated only when dependencies actually change.

39. What is a "build once, deploy many" strategy?

Build the Docker image once in CI, tag it with the commit SHA, push to a registry, then promote the same image through environments by re-tagging or by referencing the SHA.

Build: myapp:abc1234  ← created once
         ↓
Deploy to staging: myapp:abc1234
         ↓ (tests pass)
Promote to production: myapp:abc1234 (same image — no rebuild)

Why? Ensures what you tested is exactly what runs in production. Rebuilding from source for each environment risks environment-specific bugs.

40. What is "infrastructure as code" (IaC) in the context of CI/CD?

IaC means defining infrastructure (servers, databases, networks, DNS) in version-controlled configuration files, applied automatically by the pipeline.

Git push to infra repo
       ↓
CI: terraform plan → post diff as PR comment → human approves
       ↓
CD: terraform apply → infrastructure updated

41. What is "environment promotion" in a CI/CD pipeline?

Environment promotion is the process of advancing a build artifact through a sequence of environments: dev → staging → production.

Build artifact v1.2.3
  → deploy to dev     → automated tests pass
  → promote to staging → integration tests + QA sign-off
  → promote to prod    → canary → 100%

The artifact itself doesn't change — only the environment configuration differs. Promotion is triggered automatically (based on test results) or manually (human approval gate).

42. How do you prevent a broken pipeline from blocking the team?

• Run fast tests first — fail immediately on unit test failure before running slow integration tests.
• Separate blocking from non-blocking jobs — linting failure shouldn't block deployment if it's a style check (mark non-blocking with continue-on-error: true).
• Feature branch pipelines should run CI only — not deploy.
• Pipeline ownership: assign flaky tests to a team; don't let them be permanently ignored.
• Notifications: Slack/Teams alert for failed main branch builds — treat it as P1.

Monitoring & Rollback

43. What deployment health checks do you monitor after a release?

Monitoring these during the canary phase allows automated rollback if thresholds are breached.

44. What is an automated rollback and when does it trigger?

An automated rollback reverts to the previous deployment when health checks fail after a deployment.

# Kubernetes — Helm with automatic rollback on failure
helm upgrade --atomic myapp ./chart \
  --set image.tag=$NEW_TAG \
  --timeout 5m   # rolls back if pods fail to become Ready within 5 min

Triggers:

• Pod fails readiness probe repeatedly.
• Error rate exceeds threshold (Argo Rollouts, Spinnaker).
• Canary analysis fails (traffic weighted back to stable).

Manual rollback command: kubectl rollout undo deployment/myapp.

45. What is Argo Rollouts and how does it extend Kubernetes deployments?

Argo Rollouts is a Kubernetes controller that adds advanced deployment strategies to native Deployments.

Features:

• Canary with weighted traffic splitting.
• Blue-green with automatic traffic promotion.
• Analysis runs: query Prometheus/Datadog metrics during rollout; fail and roll back if thresholds breached.

spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - analysis:
            templates:
              - templateName: success-rate   # Prometheus query
        - setWeight: 100

Advanced Topics

46. What is the difference between a monorepo and polyrepo CI/CD pipeline?

In monorepos, only build and test packages affected by a change using tools like nx affected, turbo run build --filter=..., or bazel query deps.

47. What is a self-hosted CI runner and when would you use one?

A self-hosted runner is a machine you manage that executes CI jobs — as opposed to cloud-provided VMs (GitHub-hosted, GitLab SaaS runners).

Use self-hosted when:

• You need GPU for ML model training.
• Compliance requires code never to leave your network.
• Builds require access to private internal resources (databases, registries, on-prem).
• Cost — cloud runners are expensive at scale; self-hosted EC2/GCP VMs can be 5–10× cheaper.
• Large jobs that exhaust cloud runner disk/memory.

Considerations: you are responsible for security hardening, updates, and scaling.

48. What are the challenges of CI/CD for microservices?

49. What is "compliance as code" in a CI/CD context?

Compliance as code enforces regulatory and security requirements automatically in the pipeline — rather than through manual audits.

Examples:

• Open Policy Agent (OPA) or Conftest: validate Kubernetes manifests and Terraform plans against policy rules.
• Checkov: static analysis of IaC for security misconfigurations.
• Policy gates: block deployment if a Docker image runs as root, a port is exposed unnecessarily, or a Terraform plan would open a security group to 0.0.0.0/0.

# OPA/Conftest in CI
conftest test ./k8s-manifests/ --policy ./policies/

50. What is the "four key metrics" framework for measuring CI/CD performance?

The DORA metrics (from the Accelerate book) measure software delivery performance:

Use these metrics to quantify the ROI of CI/CD investment and guide pipeline improvements.

Common mistakes

CI/CD tools comparison

CI/CD vs related concepts

FAQ

Q: Should every company practice Continuous Deployment? No. Regulated industries (healthcare, finance), low-deployment-frequency enterprises, or teams with insufficient test coverage should use Continuous Delivery (manual gate) instead. Earn Continuous Deployment by first achieving high test coverage and monitoring confidence.

Q: What is the difference between a build pipeline and a release pipeline? A build pipeline compiles and tests code; a release pipeline takes the build artifact and deploys it to environments. In practice, modern CI/CD tools combine both in one workflow, but conceptually they are separate concerns.

Q: How do you handle database migrations in CI/CD? Run migrations before deploying the new application code. Use expand-contract (additive schema changes first, then remove old columns after old code is gone). Tools: Flyway, Liquibase, Alembic, Prisma Migrate. Never run destructive migrations without a backup.

Q: Can you use CI/CD with monorepos? Yes. Use affected-detection tools (Nx, Turborepo, Bazel) to only build and test packages changed by the commit. Combine with path-based pipeline triggers (paths: in GitHub Actions) to limit which jobs run.

Q: What is the "pipeline as code" principle? Define your pipeline configuration in a file checked into the same repository as the application (Jenkinsfile, .github/workflows/*.yml, .gitlab-ci.yml). This makes pipeline changes reviewed, versioned, and rolled back with the same process as application code.

Q: GitHub Actions vs Jenkins — which should I choose? GitHub Actions for greenfield projects — zero infrastructure overhead, native GitHub integration, large marketplace. Jenkins for organisations with complex Shared Library investments, self-hosted requirements, or legacy pipelines where migration cost is high.