CI/CD Interview Questions: Deep Answers That Actually Impress

# A real-world GitHub Actions CI pipeline for a Node.js service.
# This file lives at .github/workflows/ci.yml in your repository.

name: CI Pipeline — Build, Test, and Lint

# Trigger the pipeline on every push to any branch,
# and on every pull request targeting 'main'.
on:
  push:
    branches: ['**']
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    # Always pin your runner to a specific version so the environment
    # doesn't silently change under you one day.
    runs-on: ubuntu-22.04

    strategy:
      # Test against multiple Node versions to catch compatibility issues early.
      matrix:
        node-version: [18.x, 20.x]

    steps:
      # Step 1: Check out the code at the exact commit that triggered this run.
      - name: Checkout source code
        uses: actions/checkout@v4

      # Step 2: Set up the Node version defined in the matrix above.
      - name: Set up Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          # Cache node_modules based on the lock file so installs
          # are fast on subsequent runs — huge time saver.
          cache: 'npm'

      # Step 3: Install exact dependency versions from package-lock.json.
      # 'ci' (not 'install') is intentional — it fails if lock file is out of sync.
      - name: Install dependencies
        run: npm ci

      # Step 4: Lint BEFORE running tests. Fast feedback on style/syntax errors
      # without waiting minutes for a full test suite to finish.
      - name: Run ESLint
        run: npm run lint

      # Step 5: Run the unit and integration test suite.
      # --coverage flag ensures we track what percentage of code is tested.
      - name: Run tests with coverage
        run: npm test -- --coverage

      # Step 6: Upload the coverage report as a build artefact.
      # This lets you inspect coverage results without re-running the build.
      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report-node-${{ matrix.node-version }}
          path: coverage/
          # Keep artefacts for 14 days — long enough for review, short enough
          # to avoid paying for excessive storage.
          retention-days: 14

# A real GitLab CI pipeline demonstrating proper stage ordering,
# artefact promotion, and environment-gated deployments.
# This is the pattern used in production at mid-to-large engineering teams.

stages:
  - validate      # Fastest checks — fail in under 2 minutes
  - test          # Unit + integration tests
  - security      # Only runs if tests pass — no point scanning broken code
  - build         # Build the Docker image ONCE
  - deploy-staging
  - deploy-production  # Manual gate — human approves production release

variables:
  # Using the Git SHA as the image tag means every build is uniquely
  # identifiable and you can always roll back to an exact commit.
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  STAGING_URL: https://staging.myapp.io

# ─── STAGE: validate ──────────────────────────────────────────────
lint-and-typecheck:
  stage: validate
  image: node:20-alpine
  script:
    - npm ci --quiet
    - npm run lint          # ESLint — catches code style issues
    - npm run typecheck     # TypeScript type errors
  # Cache node_modules between pipeline runs to speed up installs.
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/

# ─── STAGE: test ──────────────────────────────────────────────────
unit-tests:
  stage: test
  image: node:20-alpine
  script:
    - npm ci --quiet
    - npm run test:unit -- --coverage
  # Store the coverage report as an artefact so the security stage
  # and developers can access it without re-running tests.
  artifacts:
    paths:
      - coverage/
    expire_in: 1 week
    reports:
      # GitLab natively renders coverage reports in merge requests.
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

integration-tests:
  stage: test
  image: node:20-alpine
  # Start a real Postgres container alongside the test runner.
  # This is a real database, not a mock — catches SQL bugs mocks miss.
  services:
    - name: postgres:15-alpine
      alias: test-database
  variables:
    POSTGRES_DB: testdb
    POSTGRES_USER: testuser
    POSTGRES_PASSWORD: testpass
    DATABASE_URL: postgresql://testuser:testpass@test-database:5432/testdb
  script:
    - npm ci --quiet
    - npm run migrate:test   # Run migrations against the real test DB
    - npm run test:integration

# ─── STAGE: security ──────────────────────────────────────────────
dependency-audit:
  stage: security
  image: node:20-alpine
  script:
    # Fail the pipeline if any HIGH or CRITICAL vulnerabilities exist.
    # --audit-level high means LOW/MEDIUM issues are warnings, not failures.
    - npm audit --audit-level high
  allow_failure: false  # This is intentional — security is non-negotiable

# ─── STAGE: build ─────────────────────────────────────────────────
build-docker-image:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    # Build the image using the commit SHA as the tag — immutable and traceable.
    - docker build -t $IMAGE_TAG .
    - docker push $IMAGE_TAG
    # Also tag as 'latest' on the main branch only.
    - |
      if [ "$CI_COMMIT_BRANCH" = "main" ]; then
        docker tag $IMAGE_TAG $CI_REGISTRY_IMAGE:latest
        docker push $CI_REGISTRY_IMAGE:latest
      fi
  only:
    - main

# ─── STAGE: deploy-staging ────────────────────────────────────────
deploy-to-staging:
  stage: deploy-staging
  image: bitnami/kubectl:latest
  script:
    # Update the Kubernetes deployment to use the NEW image tag.
    # This is the artefact promotion pattern — same image, new environment.
    - kubectl set image deployment/myapp-staging
        myapp=$IMAGE_TAG
        --namespace=staging
    # Wait up to 3 minutes for the rollout to complete before marking success.
    - kubectl rollout status deployment/myapp-staging
        --namespace=staging
        --timeout=3m
  environment:
    name: staging
    url: $STAGING_URL
  only:
    - main

# ─── STAGE: deploy-production ─────────────────────────────────────
deploy-to-production:
  stage: deploy-production
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/myapp-production
        myapp=$IMAGE_TAG
        --namespace=production
    - kubectl rollout status deployment/myapp-production
        --namespace=production
        --timeout=5m
  environment:
    name: production
    url: https://myapp.io
  # 'when: manual' is the Continuous Delivery pattern.
  # Remove this line to switch to Continuous Deployment.
  when: manual
  only:
    - main

# Kubernetes manifests demonstrating a canary release pattern.
# Scenario: We have v1.2.0 running in production and want to gradually
# roll out v1.3.0 to 10% of users first.

# ─── STABLE DEPLOYMENT (v1.2.0) — receives 90% of traffic ────────
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service-stable
  namespace: production
  labels:
    app: payment-service
    track: stable
spec:
  # 9 replicas for stable means 90% of traffic goes here
  # when combined with 1 canary replica.
  replicas: 9
  selector:
    matchLabels:
      app: payment-service
      track: stable
  template:
    metadata:
      labels:
        app: payment-service
        track: stable
    spec:
      containers:
        - name: payment-service
          image: registry.mycompany.io/payment-service:v1.2.0
          ports:
            - containerPort: 3000
          # Readiness probe ensures traffic only routes to pods
          # that have fully started up — critical for zero-downtime deploys.
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10

---

# ─── CANARY DEPLOYMENT (v1.3.0) — receives 10% of traffic ────────
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service-canary
  namespace: production
  labels:
    app: payment-service
    track: canary
spec:
  # 1 replica for canary = 1/(9+1) = 10% of all traffic.
  # To increase the canary's share, scale this up and stable down.
  replicas: 1
  selector:
    matchLabels:
      app: payment-service
      track: canary
  template:
    metadata:
      labels:
        app: payment-service
        track: canary
    spec:
      containers:
        - name: payment-service
          image: registry.mycompany.io/payment-service:v1.3.0
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10

---

# ─── SERVICE — routes to BOTH stable and canary pods ─────────────
apiVersion: v1
kind: Service
metadata:
  name: payment-service
  namespace: production
spec:
  # Selector matches BOTH deployments because both have label app: payment-service.
  # Kubernetes distributes traffic proportionally to the number of matching pods.
  # 9 stable pods + 1 canary pod = 90%/10% traffic split automatically.
  selector:
    app: payment-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000

# ─── ROLLBACK COMMAND (run if canary metrics look bad) ────────────
# kubectl scale deployment payment-service-canary --replicas=0 -n production
# That's it. Traffic instantly returns 100% to stable. No config changes needed.

# ─── PROMOTE COMMAND (run if canary looks healthy after 30 mins) ──
# kubectl scale deployment payment-service-stable --replicas=0 -n production
# kubectl scale deployment payment-service-canary --replicas=10 -n production
# Then update stable's image to v1.3.0 and set canary back to 0.

# Demonstrating secure secrets injection using HashiCorp Vault
# in a GitHub Actions pipeline. This is the pattern used in
# production at security-conscious engineering organisations.

name: Secure Deploy Pipeline

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-22.04
    # Grant this job permission to request an OIDC token from GitHub.
    # OIDC lets Vault verify the job's identity WITHOUT a stored secret —
    # this eliminates the 'secret to access the secrets manager' chicken-and-egg problem.
    permissions:
      id-token: write
      contents: read

    steps:
      # Pin by SHA, not tag. Tags are mutable and can be hijacked.
      # This specific SHA corresponds to actions/checkout@v4 at a known-good state.
      - name: Checkout source code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

      # Authenticate to Vault using GitHub's OIDC token.
      # No static credentials stored anywhere — Vault validates the GitHub JWT
      # and checks the job's repository and branch against its policy.
      - name: Authenticate to HashiCorp Vault via OIDC
        uses: hashicorp/vault-action@d1720f055e0635fd932a1d2a48f87a666a57906c
        with:
          url: https://vault.mycompany.io
          method: jwt
          role: github-actions-deploy
          # Request only the secrets this specific job actually needs.
          # Principle of least privilege — don't fetch ALL secrets, just these.
          secrets: |
            secret/data/production/database DB_HOST | DATABASE_HOST ;
            secret/data/production/database DB_PASSWORD | DATABASE_PASSWORD ;
            secret/data/production/aws AWS_ACCESS_KEY_ID | AWS_ACCESS_KEY_ID ;
            secret/data/production/aws AWS_SECRET_ACCESS_KEY | AWS_SECRET_ACCESS_KEY

      # The secrets are now available as environment variables for this job.
      # They are NEVER written to disk or printed in logs.
      - name: Run database migrations
        run: npm run migrate:production
        env:
          # Reference the injected secrets by the names Vault mapped them to.
          DATABASE_URL: postgresql://${{ env.DATABASE_HOST }}/productiondb
          DATABASE_PASSWORD: ${{ env.DATABASE_PASSWORD }}

      - name: Deploy to AWS ECS
        run: |
          # Configure AWS CLI with the short-lived credentials from Vault.
          # These credentials typically expire in 1 hour — far safer than
          # long-lived static keys stored in GitHub Secrets.
          aws ecs update-service \
            --cluster production-cluster \
            --service payment-service \
            --force-new-deployment \
            --region eu-west-1
        env:
          AWS_ACCESS_KEY_ID: ${{ env.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ env.AWS_SECRET_ACCESS_KEY }}
          AWS_DEFAULT_REGION: eu-west-1

      # Always confirm the deployment completed successfully.
      # Don't assume ECS accepted the update — verify it rolled out.
      - name: Wait for ECS deployment to stabilise
        run: |
          aws ecs wait services-stable \
            --cluster production-cluster \
            --services payment-service \
            --region eu-west-1
          echo "Deployment confirmed stable at $(date -u)"