Git, CI/CD Pipelines & Release Safety — Interview Questions

How to use this lesson

Senior CI/CD answers are about flow, safety and feedback:

• trunk-based or short-lived branches;
• automated quality gates;
• immutable artifacts promoted across environments;
• progressive delivery;
• fast, rehearsed rollback.

Tools change; the principles don't.

Q1. How do you resolve conflicts in a large Git rebase?

Short answer:

• Prevent them: rebase often (small, frequent syncs with main), keep branches short-lived, and split big refactors from feature work.
• During the rebase:
  • git rebase main stops at each conflicting commit;
  • resolve commit by commit (the context is smaller), git add, then git rebase --continue;
  • use git rebase --abort to bail out safely.
• Tools:
  • git rerere (reuse recorded resolutions: git config rerere.enabled true), which replays your earlier resolutions when the same conflict recurs;
  • a good 3-way merge tool (IntelliJ, git mergetool);
  • git log -p --merge and git diff --diff-filter=U to understand both sides;
  • -X ours|theirs strategy options for bulk, mechanical conflicts (with care).
• Alternatives when it's too painful: squash the branch first (fewer commits to replay), or merge main into the branch instead of rebasing (it keeps the history, with one conflict resolution).
• After resolving: build and test before pushing, and git push --force-with-lease (never a plain --force) for shared branches, after coordinating with the teammates.

Learn it in depth → CI/CD Pipeline System

Q2. How do you handle large binary files in Git?

Short answer: Git stores every version of every file in full history, so large binaries (models, media, datasets, JARs) bloat the repository, and slow clones forever. Options:

• Git LFS (Large File Storage): the Git repository stores small pointer files, and the content lives on an LFS server (GitHub, GitLab, Artifactory), downloaded on checkout. Configure it with git lfs track "*.psd" (committed in .gitattributes).
• Don't version build outputs: publish artifacts to Nexus, Artifactory or a container registry instead.
• Use object storage (S3) with versioned references for datasets and ML models (or DVC).
• Partial clone or sparse checkout for huge monorepos.
• Clean up a bloated history with git filter-repo (or BFG). This rewrites the history, so coordinate a force-push, and ask everyone to re-clone.

Q3. What's the best way to enforce code quality in Git workflows?

Short answer: Automate the gates, and make the path to merge the only path to production:

• Branch protection on main:
  • required pull requests;
  • required status checks (build, tests, coverage threshold, static analysis, security scans);
  • required reviews (CODEOWNERS for critical areas);
  • linear history or squash merges;
  • signed commits, if required;
  • no direct pushes or force-pushes.
• Pre-commit hooks (formatting with Spotless or google-java-format, lint, secret scanning with gitleaks) for fast local feedback. Don't rely on them alone, since they're bypassable. CI re-checks everything.
• CI checks:
  • unit and integration tests;
  • SonarQube quality gates (new-code coverage, bugs, smells, duplications);
  • SAST (Semgrep, CodeQL);
  • dependency scanning (Dependabot, Snyk, OWASP);
  • licence checks;
  • ArchUnit rules;
  • API breaking-change checks.
• Review culture: small PRs, PR templates, and automated reviewers for style, so humans focus on design.
• Conventional commits, plus automated changelogs and versioning (semantic-release).

Q4. How do you trigger builds on GitHub or GitLab pull requests?

Short answer:

• GitHub Actions: workflow triggers on: pull_request: { branches: [main], paths: ['orders/**'] } (plus push to main). Required checks are configured in branch protection. For forks, understand the difference between pull_request and pull_request_target (the latter has secrets, so don't check out untrusted code with it).
• GitLab CI: rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" (merge request pipelines), and merged-results pipelines.
• Jenkins: Multibranch Pipelines or organisation folders, with the GitHub or Bitbucket branch source plugin (webhooks give automatic PR builds, with status reported back to the PR).
• Optimise: path filters in monorepos (build only the affected modules), concurrency groups to cancel superseded runs, and merge queues, which test the merged result before landing.

Q5. How do you configure a Jenkins pipeline? How do you secure secrets in Jenkins? How do you parallelise stages?

Short answer:

• Declarative vs scripted: a declarative Jenkinsfile (pipeline { agent … stages { stage { steps } } post { … } }) is structured, validated and readable, and it's the recommended option. Scripted (Groovy node {}) is flexible, but harder to maintain. Put the pipeline in the repository (pipeline as code), and share logic through shared libraries.
• Secrets:
  • store them in the Jenkins Credentials store, or better, an external vault (HashiCorp Vault, AWS Secrets Manager plugins);
  • inject them with withCredentials([...]) or environment { TOKEN = credentials('id') }, so they're masked in the logs;
  • scope the credentials per folder or job;
  • never echo secrets, and avoid them in the Groovy string interpolation that ends up in the logs;
  • use short-lived OIDC-based cloud credentials where possible;
  • restrict who can edit Jenkinsfiles and credentials, and audit it.
• Parallel stages:

stage('Checks') {
    parallel {
        stage('Unit tests')       { steps { sh './mvnw -B test' } }
        stage('Static analysis')  { steps { sh './mvnw -B spotbugs:check checkstyle:check' } }
        stage('Dependency scan')  { steps { sh './mvnw -B org.owasp:dependency-check-maven:check' } }
    }
}

Use failFast true to stop the siblings on failure, and separate agents to spread the load.

Q6. How do you implement rolling deployments from Jenkins (or any CI tool)?

Short answer: Don't script the rollout in Jenkins itself. Let the platform do rolling updates, and have the pipeline trigger and verify them:

• Kubernetes:
  1. the pipeline builds and pushes an immutable image (tagged with the Git SHA);
  2. it updates the Deployment (kubectl set image, helm upgrade, or better, a GitOps commit to the environment repository);
  3. the Deployment's RollingUpdate strategy (maxUnavailable: 0, maxSurge: 25%) plus readiness probes roll the pods gradually;
  4. the pipeline waits on kubectl rollout status, runs smoke tests, and checks metrics. On failure, it runs kubectl rollout undo (or reverts the GitOps commit).
• VMs or ASGs: instance refresh, or deploying to batches behind a load balancer with health checks (for example, AWS CodeDeploy rolling configurations).
• Progressive delivery: Argo Rollouts or Flagger for canary analysis against Prometheus metrics, with automatic promotion or rollback.

Q7. What are GitHub Actions, and how do they differ from Jenkins?

Short answer:

• GitHub Actions: CI/CD built into GitHub. YAML workflows in .github/workflows, triggered by repository events (push, PR, release, schedule, workflow_dispatch), running jobs on GitHub-hosted or self-hosted runners, composed from reusable actions in the marketplace. It integrates natively with PRs, checks, OIDC to cloud providers (no stored cloud keys), environments with approval rules, and secrets.
• Jenkins: a self-hosted automation server, with a huge plugin ecosystem, highly customisable (Groovy pipelines, shared libraries), and SCM-agnostic. But you run and patch it, plugins cause upgrade friction, it has a security surface, and scaling agents is your job.
• The choice: Actions (or GitLab CI) for GitHub-centric teams wanting low operational overhead. Jenkins for complex on-premises or legacy integrations, air-gapped environments, or deep customisation.

Q8. How do you create a reusable workflow in GitHub Actions?

Short answer: Define a workflow with on: workflow_call, declaring inputs, secrets and outputs, then call it from other workflows (in the same or other repositories) with uses: org/repo/.github/workflows/java-ci.yml@v1. For step-level reuse, write composite actions (action.yml, with runs.using: composite). Version them with tags, and keep them in a central "platform" repository.

# .github/workflows/java-ci.yml (reusable)
on:
  workflow_call:
    inputs:
      java-version: { type: string, default: '21' }
    secrets:
      SONAR_TOKEN: { required: true }
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with: { distribution: temurin, java-version: ${{ inputs.java-version }}, cache: maven }
      - run: ./mvnw -B verify
# Caller:
# jobs:
#   ci:
#     uses: shop/platform/.github/workflows/java-ci.yml@v1
#     secrets: inherit

Q9. How do you trigger jobs conditionally in GitHub Actions?

Short answer:

• Event filters: on.push.branches, paths/paths-ignore (monorepos), tags.
• Job and step conditions: if: github.ref == 'refs/heads/main', if: contains(github.event.pull_request.labels.*.name, 'deploy-preview'), if: failure()/always()/success().
• Job dependencies: needs:, with outputs from earlier jobs (for example, a change-detection job using dorny/paths-filter, which sets outputs that other jobs check).
• Environments: environment: production, with required reviewers and wait timers as a manual approval gate.
• Matrix exclusions, and workflow_dispatch inputs for manual runs.

Q10. How do you cache dependencies in GitHub Actions to speed builds up?

Short answer:

• actions/setup-java with cache: maven or cache: gradle caches ~/.m2/repository or ~/.gradle/caches, keyed by the hash of pom.xml/*.gradle* files.
• actions/cache, for custom paths, with explicit key and restore-keys (a fallback prefix).
• Gradle: gradle/actions/setup-gradle (it caches smartly, and supports the remote build cache and configuration cache).
• Docker layers: docker/build-push-action with cache-from/cache-to: type=gha (or a registry cache).
• Hygiene: avoid caching huge or volatile directories, bust the cache on lockfile changes, and remember the cache size limits (about 10 GB per repository, with LRU eviction).

Q11. How do you set up test coverage, or SonarQube scans, in GitHub Actions?

Short answer:

- run: ./mvnw -B verify jacoco:report            # tests + JaCoCo XML
- name: SonarQube / SonarCloud scan
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}      # PR decoration
  run: ./mvnw -B sonar:sonar -Dsonar.projectKey=shop_orders -Dsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml

• The fetch depth matters: actions/checkout with fetch-depth: 0 gives accurate new-code detection and blame.
• Enforce the Quality Gate: -Dsonar.qualitygate.wait=true fails the job if the gate fails, and branch protection requires the check.
• Alternatives or extras: Codecov (coverage comments on PRs), and JaCoCo's check goal with minimum ratios.
• Scope: gate on new-code coverage (for example ≥ 80%), rather than on legacy totals.

Q12. What is release gating?

Short answer: Automated or manual checkpoints that a release must pass before it progresses to the next environment or to more traffic:

• Build gates: tests, coverage, static analysis, and security scans (SAST, SCA, container scanning, with no critical CVEs), licence compliance, SBOM generation, signature verification.
• Pre-deploy gates: contract tests (can-i-deploy with Pact), migration checks, change approvals for regulated systems, change-freeze windows.
• Post-deploy or progressive gates: smoke tests, SLO-based canary analysis (error rate, latency, business KPIs compared with the baseline), and automatic promotion or rollback (Argo Rollouts, Flagger, Spinnaker/Kayenta).
• Feature-flag gates: a gradual exposure of the new functionality.

Good gates are fast, objective and automated. Manual approvals are kept for the genuinely risky or regulated steps.

Q13. What is infrastructure as code (IaC)? What is GitOps?

Short answer:

• Infrastructure as code: infrastructure (networks, clusters, databases, IAM, DNS) is defined in version-controlled files, and provisioned by tools: Terraform/OpenTofu, Pulumi, AWS CloudFormation/CDK, Bicep, Crossplane. The benefits:

  • reproducible, reviewable, auditable changes (PRs);
  • consistent environments;
  • drift detection;
  • disaster recovery by re-applying;
  • modules and reuse.

  Practices:

  • remote state with locking;
  • plan-in-PR, apply after review;
  • policy as code (OPA, Sentinel, Checkov);
  • small blast-radius stacks;
  • secrets never kept in state or in plain text.

• GitOps: Git is the single source of truth for the desired state of deployments and configuration. An agent in the cluster (Argo CD, Flux) continuously reconciles the live state with Git: it pulls changes, applies them, and reverts drift. Deployments become Git commits (pull requests to an environment repository), rollback is git revert, and there's a full audit history. CI builds images, and updates the image tags in the GitOps repository (Argo CD Image Updater or Renovate). The cluster credentials stay inside the cluster (a pull model), which improves security.

Learn it in depth → Infrastructure as Code Awareness

Q14. How do you verify changes once they're deployed to production?

Short answer:

• Automated smoke tests of the critical journeys (login, search, checkout) against production, right after the deployment (synthetic monitoring runs them continuously too).
• Health and readiness checks passing, and no error-rate or latency regression: compare the golden signals and business KPIs (orders per minute, payment success rate) with the baseline, on dashboards, by version label.
• A canary analysis window, before full rollout.
• Log and trace checks for new error signatures.
• Feature flags to expose the new functionality gradually, and verify it with a subset of users.
• Alerts tied to SLOs, with the on-call engineer watching during the release.
• Manual checks or UAT only for things that are hard to automate (or regulated sign-offs).

Q15. You discover a critical bug shortly after deployment. How do you roll back quickly and safely?

Short answer: Be prepared before the incident:

• Immutable, versioned artifacts (images tagged with the SHA), so rollback is "redeploy the previous version": kubectl rollout undo, helm rollback, a GitOps git revert, blue-green traffic switched back, or an automated canary abort. Target minutes.
• Feature flags: turn off the faulty feature instantly, without any deployment, which is often the fastest mitigation.
• Backward-compatible database changes (expand/contract), so the old code still works with the new schema. Never ship a migration that makes rollback impossible, and roll forward with a fix if the data has already changed irreversibly.
• Kafka and events: consumers tolerate the old and new formats, and the replay or compensation plans are documented.

The process:

1. declare an incident;
2. mitigate first (roll back, or switch the flag off);
3. communicate (status updates);
4. verify recovery with metrics;
5. then fix forward through the normal pipeline (with a regression test);
6. run a blameless postmortem, with actions: better tests, canary thresholds, alerting.

Learn it in depth → Deployment Strategies

Follow-up questions this topic invites — and their answers

Q: Trunk-based development or Git Flow? A: Trunk-based development (short-lived branches, and merging to main at least daily, with feature flags) enables continuous delivery, and reduces merge pain. Git Flow's long-lived develop and release branches suit scheduled, versioned releases (packaged software, mobile) better than continuously deployed services.

Q: What is a merge queue? A: A system (GitHub merge queue, GitLab merge trains, Bors) that tests each PR combined with the PRs ahead of it before merging, so main never breaks because of two individually green PRs that conflict semantically.

Q: How do you keep CI fast as the codebase grows? A: Parallelise jobs, cache dependencies and builds (Gradle remote cache), build only what changed (affected modules), split slow integration or e2e suites into separate or nightly jobs, quarantine flaky tests, and use bigger runners where it pays off.

Q: What's the difference between continuous delivery and continuous deployment? A: Continuous delivery means every change is deployable (automated pipeline to production-ready, with a manual release decision). Continuous deployment automatically deploys every change that passes the pipeline to production.