44 CI/CD interview questions with answers

All CI/CD interview questions

• What is CI/CD? What is the difference between CI and CD?

  CI (Continuous Integration): build and test automatically on every push or PR, catching problems while they are still cheap to fix. CD (Continuous Delivery): a green CI deploys to staging automatically, while production still waits on a human approval. Continuous Deployment: straight to production, with…

• What is GitHub Actions? What is the structure of a workflow file?

  GitHub Actions is the CI/CD platform built into GitHub, triggered by events (push, pullrequest, schedule, workflowdispatch). Workflows are YAML under .github/workflows/: on declares the triggers, jobs run in parallel by default (use needs: for sequencing), and each job is a list of steps that are…

• What are Blue-Green deployment and Canary deployment?

• What is a CI/CD pipeline? What steps does a typical frontend pipeline include?

  CI/CD (Continuous Integration / Continuous Deployment) is the automated process for testing and deploying code on every change. A frontend pipeline runs sequentially, cheapest steps first, to fail fast: 1. Lint + format check (fastest). 2. Type check with tsc --noEmit. 3. Unit tests with…

• How do GitLab CI, Jenkins, and CircleCI compare to GitHub Actions?

  All four run CI/CD pipelines from a config file kept in the repo. They differ mainly in which platform they are tied to and who has to operate the machines that run the jobs. GitHub Actions GitLab CI Jenkins CircleCI --------------- Config file .github/workflows/.yml .gitlab-ci.yml…

• What is GitOps? How do ArgoCD and Flux work?

  GitOps is an operating model where the desired state of the cluster is described as YAML in Git, and an agent running inside the cluster continuously pulls Git and adjusts the cluster to match. To change production you open a PR that edits YAML; nobody…

• How do you design a fail-fast CI pipeline that uses time efficiently?

  The principle: cheap tests first, expensive ones last, parallelize hard, cache effectively, and run only the jobs the changed files actually touch. Stage order (cheap → expensive), each running only if the previous one is green: 1. Lint + format check (5-10s) 2. Type check…

• How do you manage secrets in CI/CD securely?

  Never commit a secret to code, .env files included. The right home is the CI's own secret store (GitHub Secrets, GitLab Variables) or a centralized vault (HashiCorp Vault, AWS Secrets Manager). Practices worth following: - CI secrets: GitHub Settings → Secrets and variables → Actions,…

• Rolling, recreate, canary, blue-green deploys: when do you use each?

  The four strategies differ on one question: during a deploy, how do the old and new versions coexist, and how fast can you roll back. Strategy How it runs Downtime Rollback Infra cost Fits ------------------ Rolling Replace old pods with new ones in batches None…

• Build artifacts, immutable images, and semantic versioning in CI/CD?

  A build artifact is the output of the build step (a Docker image, a jar, a zipped bundle). The rule is build once, deploy many: CI builds the artifact exactly once, then that same artifact moves through dev, staging and production. You never rebuild from…

• Trunk-based development vs Git Flow in modern CI/CD?

  Trunk-based development (TBD): everyone merges into main frequently, through branches that live a few hours to a day. Unfinished features still get merged but are hidden behind a feature flag (a runtime on/off switch), so main is always deployable. Git Flow (Vincent Driessen, 2010) uses…

• Pre-commit hooks, lint-staged, husky — client-side vs server-side CI gates?

  Client-side Git hooks (pre-commit, commit-msg, pre-push) run on the developer's machine before a commit or push, so they report problems early. Server-side CI gates run in the pipeline and block the merge. You need both, because client hooks can be skipped with git commit --no-verify,…

• What is chaos engineering, and why deliberately inject failures into a system?

• Where should image vulnerability scanning sit in CI, and what do you do when the scanner reports hundreds of CVEs?

• How do you design a multi-stage CI/CD pipeline? Which jobs run in parallel and which must be sequential?

  Principle: cheap and failure-prone checks first, expensive work later. A common layout: - Stage 1 (parallel): lint, typecheck, unit tests — they only need source and do not depend on each other. - Stage 2: build → produces one artifact (image or bundle). - Stage…

• How should you key a dependency cache in CI? Why hash the lockfile?

  The cache key must change exactly when the dependency set changes. The standard approach: hash the lockfile (pnpm-lock.yaml, package-lock.json, go.sum, poetry.lock). The pnpm store location differs by OS and version, so read it with pnpm store path instead of guessing. With actions/setup-node and cache: pnpm,…

• How do you pass build output from one job to another? How do artifacts differ from caches?

  Each CI job runs on its own runner with its own filesystem — files built in job A do not exist in job B. You move them through an artifact. Core difference: Artifact Cache --------- Purpose Pass results between jobs / keep for download Speed…

• What is a matrix build? When do you need one, and how do you keep it from wasting time?

  A matrix lets you declare one job and have CI fan it out across combinations of variables — each combination runs in parallel on its own runner. That declaration produces 4 jobs. Use it when the product must run on several real environments: a library…

• A 30-minute test suite is blocking the pipeline. How do you parallelize it?

  Split the suite into shards — each runner executes a disjoint slice, then results are merged. Vitest, Jest and Playwright ship a --shard flag, so you do not need to split files yourself. Python is different: pytest-xdist (-n) only runs several processes in parallel on…

• The pipeline goes red occasionally and passes on rerun. How do you deal with flaky tests?

  The real problem is not one broken test — it is that the team stops trusting CI: once "red" might be noise, people rerun reflexively and start ignoring genuine failures too. A workable process: 1. Record, do not silently rerun. Every rerun that rescues a…

• How do you block a merge when lint / typecheck / coverage fail? How should the gate be configured?

  The gate lives in branch protection, not in the workflow. The pipeline only reports status; the target branch is what decides "this check must be green to merge". Minimum setup for the main branch: - Enable required status checks and select the exact job names…

• How do you make sure a CI secret never leaks into the logs?

  Secrets belong in the CI secret store (encrypted secrets, GitLab masked variables, Vault) and are injected at runtime as environment variables — never in the repo, private repos included. CI masks secrets in logs automatically, but the mechanism is plain string matching, so it still…

• The same artifact is deployed to dev / staging / production — how do you handle per-environment configuration?

  Build once, deploy many. The artifact (image) must be immutable and contain no environment-specific value; differences are injected at runtime via environment variables / ConfigMaps / a secret store. Why it matters: if each environment rebuilds, what runs in production has never been tested —…

• How do feature flags decouple deploy from release? What are the trade-offs?

  Deploy puts code on the server; release exposes the feature to users. A feature flag separates the two: the code ships to production with the new path off, then is turned on by configuration without another deploy. What you gain: - Merge to main early…

• You deploy to production and find a serious bug. How do you roll back within minutes?

  Restore service first, investigate afterwards. Options in increasing order of risk: 1. Turn off the feature flag if the feature has one — seconds, and it never touches the deploy process. 2. Shift traffic back to the previous version (blue-green keeps the old environment, or…

• Where do database migrations belong in the pipeline — before or after deploying code? How do you avoid downtime?

• Why use OIDC instead of long-lived access keys for CI deployments to the cloud? How does it work?

• What are the risks of running CI on pull requests from forks? How do you make it safe?

• In a monorepo with many services, how do you run only the jobs affected by a change?

• Production deploys need approval, notification, and an audit trail. How do you build that into the pipeline?

• What question does each of logs, metrics and traces answer? Which do you look at first during an incident?

  The three signals answer three different questions and do not replace one another: - Metrics — aggregated numbers over time (requests/s, error rate, latency, CPU). They answer "is something broken, since when, and how badly". Cheap, retained long, but say nothing about one specific request.…

• What is structured logging? How does a correlation (request) id work across services?

  Structured logging emits logs as field-based data (usually JSON) instead of a prose sentence, so the log backend can filter and aggregate by field without fragile regex. Compared with logger.info("payment failed for user u88 after 3021ms"), the query level=error AND gateway=sepay just works; the prose…

• How do you pick the right log level? What must never be written to logs?

  The test for a level: who reads this line and what must they do about it. - ERROR — something broke and a human must act (transaction failed, write to DB rejected). If ERROR fires every minute and nobody acts, the level is being misused.…

• What should a service dashboard contain? How do you arrange it so an on-caller can use it at 3am?

  The goal of an on-call dashboard is not "show every metric" but to answer in 30 seconds: is this service healthy, and if not, where does it hurt. Three tiers, read top to bottom: 1. User-facing (top) — traffic, error rate, p50/p95/p99 latency, and status…

• Logging costs exploded in production. How do you cut them and still be able to debug?

  Log cost scales with volume times retention. Cut in order of impact rather than at random: 1. Drop logs nobody reads. Most of the volume comes from repeated INFO/DEBUG inside hot loops and from access logs that duplicate an existing metric. A line that never…

• Why should `user_id` (or `request_id`) never be a metric label? What is cardinality?

  Cardinality is the number of distinct time series a metric produces. In Prometheus every combination of label values is its own series, stored and indexed separately. The first has route (dozens) times status (a few) → a few hundred series. The second multiplies by the…

• What are the RED and USE methods? When do you use each?

  Two frameworks for choosing metrics; they differ in what they measure. RED — measures a service (the view of whoever sends requests in): - Rate: requests per second. - Errors: count or ratio of failed requests. - Duration: latency distribution (p50/p95/p99). Applies to any API,…

• What problem does OpenTelemetry solve? What are its components?

  Before OpenTelemetry every monitoring vendor shipped its own agent and SDK, so switching vendors meant editing code across every service. OpenTelemetry separates producing the data (instrumentation) from where it is stored and viewed (the backend) via a common standard. Main components: - API + SDK…

• Why alert on symptoms rather than causes? Give a concrete example.

  Symptom-based alerts fire on what users experience: error rate, latency, orders failing. Cause-based alerts fire on internal state: CPU 80%, pod count dropped, cache misses up. Three problems with cause-based alerting: 1. False alarms. 90% CPU during a batch window is normal and users notice…

• What is alert fatigue? How do you reduce it? How does multi-window multi-burn-rate alerting work?

• What decisions does an error budget drive? Can an SLO be 100%?

• How does handling a production incident go? Why does mitigation come before fixing the root cause?

• What is a blameless postmortem? What does a good one contain?

• What sections make up a declarative Jenkinsfile? Write a basic pipeline with build, test and deploy stages.

  A Jenkinsfile is a pipeline written as code and committed with the repo. The declarative style has a fixed skeleton: pipeline wraps everything, agent picks where it runs, stages holds the stage blocks, each stage has steps, and post handles what happens after the run.…