CI/CD Interview Questions India 2026: GitHub Actions, Jenkins, and Deployment Strategies

CI/CD concepts:

1. Continuous Integration (CI): CI is the practice of automatically building and testing code every time a change is pushed to the repository. Goal: catch integration problems early (before they accumulate and become expensive to fix). A CI pipeline typically: checks out the code, installs dependencies, runs linters and static analysis, compiles/builds, runs unit and integration tests, builds a Docker image.

2. Continuous Delivery vs Continuous Deployment: Continuous Delivery: every passing build is in a deployable state and can be deployed to production by a human-triggered step (a manual approval gate). Goal: reduce the risk and cost of deployments by making them frequent and routine. Continuous Deployment: every passing build is automatically deployed to production with no human gate. Requires very high test coverage and confidence in the automated checks. Used at companies with a strong DevOps culture (very fast feedback loops from production).

3. Why CI/CD matters: Without CI/CD: infrequent, large, scary deployments; developers work on long-lived branches that diverge from main; integration bugs are found late and are expensive to fix. With CI/CD: small, frequent deployments; problems are found and fixed within hours of introduction; developers merge to main daily; the main branch is always deployable.

4. Key CI/CD metrics: Deployment frequency: how often do you deploy to production? Lead time for changes: how long from code commit to production? Change failure rate: what percentage of deployments cause a production incident? Mean time to recovery (MTTR): how long to recover from a production incident? These are the DORA metrics (DevOps Research and Assessment); high-performing teams deploy multiple times per day with low failure rates and sub-hour MTTR.

GitHub Actions:

1. GitHub Actions concepts: - Workflow: a YAML file under .github/workflows/; triggered by events; defines jobs and steps. - Event/Trigger: on: push (when code is pushed), pullrequest (when a PR is opened/updated), schedule (cron), workflowdispatch (manual trigger with optional inputs). - Job: a set of steps that run on a runner (ubuntu-latest, windows-latest, macos-latest). Jobs run in parallel by default; use needs: [build] to create dependencies between jobs. - Step: one unit of work in a job. Either a pre-built action (uses: actions/checkout@v4) or a shell command (run: npm test). - Runner: the VM or container that runs the job. GitHub-hosted runners are free for public repos; self-hosted runners are used for private repos with specific dependencies.

2. A complete CI workflow example: ```yaml name: CI

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

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

build-and-push: needs: [test] runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' steps: - uses: actions/checkout@v4 - uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - run: docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} . - run: docker push ghcr.io/${{ github.repository }}:${{ github.sha }} ```

3. Secrets and environment variables: Store sensitive values in GitHub Secrets (Settings > Secrets and variables > Actions). Access in workflows: ${{ secrets.MYSECRETNAME }}. Environment files: use $GITHUB_ENV to set environment variables that persist across steps in the same job.

Deployment strategies:

1. Rolling deployment: The default Kubernetes deployment strategy. Replace old pods with new pods gradually (e.g., 25% at a time). At any moment, both old and new versions run in production. Simple; zero downtime; but the old and new versions of the application run simultaneously (both must be backward compatible with the same database schema and APIs).

2. Blue-green deployment: Two identical production environments (Blue = current live; Green = new version). Step 1: deploy the new version to the Green environment and test it. Step 2: switch all traffic from Blue to Green instantly (update the load balancer or DNS). Advantages: instant rollback (switch back to Blue); no mixed-version traffic. Disadvantages: requires double the infrastructure during deployment.

3. Canary deployment: Gradually shift a percentage of traffic from the old version to the new version (e.g., 1% first, then 5%, 10%, 25%, 100%). Monitor error rates and latency at each step; roll back if metrics degrade. More sophisticated than blue-green; allows real production traffic to validate the new version with limited blast radius. Implemented with: Kubernetes traffic splitting (Istio, Argo Rollouts, Flagger), feature flags, or a load balancer with weighted routing.

4. GitOps: GitOps is a deployment approach where the desired state of the infrastructure and applications is stored in Git. The deployment system (ArgoCD, Flux) watches the Git repository; when the repository changes (a new image tag is pushed, a Helm values file is updated), the system automatically applies the changes to the cluster. Benefits: Git is the single source of truth for production state; every change is tracked in Git history; rollbacks are Git reverts. ArgoCD: the most widely adopted GitOps tool at Indian companies using Kubernetes.

CI/CD advanced topics:

1. Jenkins: Jenkins is the most widely used CI/CD tool at Indian IT services companies and large enterprises. It is open-source, self-hosted, and highly customisable with 1,800+ plugins. Jenkins Pipeline: pipelines are defined in a Jenkinsfile (Groovy DSL). Declarative Pipeline syntax: ```groovy pipeline { agent any stages { stage('Build') { steps { sh 'mvn clean package' } } stage('Test') { steps { sh 'mvn test' } } stage('Deploy') { when { branch 'main' } steps { sh 'kubectl apply -f k8s/' } } } } ``` Jenkins vs GitHub Actions: Jenkins is more powerful (full scripting with Groovy, self-hosted agents, complex plugin ecosystem) but requires maintenance of the Jenkins server. GitHub Actions is fully managed, has a simpler YAML DSL, and integrates naturally with GitHub repositories.

2. Pipeline security: - Secret management: store secrets in a vault (HashiCorp Vault, AWS Secrets Manager); inject them into the pipeline at runtime. Never hardcode secrets in the Jenkinsfile or workflow YAML. - Least privilege: CI/CD service accounts should have only the permissions they need (deploy to one namespace, push to one ECR repository; not cluster-admin). - Image scanning: scan Docker images for CVEs in the CI pipeline (Trivy, Snyk, Amazon Inspector) before pushing to the registry. - SAST (Static Application Security Testing): run automated security scans (SonarQube, Semgrep) in the CI pipeline to catch common security vulnerabilities.

3. Monitoring deployments: After deployment, monitor: error rates (application error rate vs baseline), p99 latency, saturation (CPU, memory), traffic (requests per second). Set alerts that automatically roll back if error rate exceeds a threshold (ArgoCD Rollouts supports automated rollback based on Prometheus metrics).