← Back to Infrastructure

CI/CD Pipeline

InfrastructureMidcicd

The Question

What are the stages of a CI/CD pipeline?

What a Strong Answer Covers

  • CI vs CD
  • pipeline stages
  • tool named.

Senior-Level Answer

A CI/CD pipeline automates the path from a code commit to a running production deployment, enforcing quality gates at each stage to catch issues early when they are cheapest to fix.

**Source trigger**: The pipeline starts on a push or pull request event from the version control system (GitHub, GitLab). Branch protection rules require the pipeline to pass before merge.

**Build**: Source code is compiled, transpiled, or containerised. The build artifact should be immutable and environment-agnostic—a Docker image tagged with the commit SHA, or a compiled binary. Build caching (layer caching for Docker, dependency caching for npm/pip) keeps this stage fast.

**Unit and integration tests**: Fast, isolated unit tests run first; slower integration tests (requiring databases, message brokers) run after or in parallel with test containers (Docker Compose, Testcontainers). Code coverage thresholds act as gates.

**Static analysis and linting**: Code style (ESLint, Black), type checking (mypy, TypeScript), and static security analysis (Semgrep, Bandit) catch issues without executing code.

**Security scanning**: Dependency vulnerability scanning (Snyk, Dependabot, Trivy for containers) and SAST (Static Application Security Testing) run here. Findings above a severity threshold block the pipeline.

**Artifact publishing**: The verified image or binary is pushed to a registry (ECR, Artifact Registry, PyPI) tagged with the commit SHA and semantic version. The artifact is immutable from this point—the same artifact is promoted through environments.

**Deploy to staging**: The artifact is deployed to a staging environment that mirrors production topology. Smoke tests and end-to-end tests run against staging. This is the last gate before production.

**Deploy to production**: In Continuous Deployment, this is automatic after staging passes. In Continuous Delivery, a human approval gate precedes it. Production deployments use progressive rollout strategies (blue-green, canary, rolling) with automated rollback on error rate or latency SLO breach.

**Observability gate**: After production deploy, the pipeline monitors error rates and latency for a bake window (5-15 minutes). Automated rollback triggers if thresholds are breached.

The key principle is **fail fast, fail early**—put the fastest and highest-signal checks first. A pipeline that takes 45 minutes to run is one that developers work around rather than wait for.

What Separates a 2/3 from a 3/3

2/3 — Passing but Incomplete

Names six or more stages in correct order with the purpose of each and mentions artifact immutability.

3/3 — Strong Answer

Covers all stages, explains the distinction between CI and CD, discusses progressive deployment strategies, automated rollback, and the fail-fast ordering principle.

Common Mistakes

  • Treating CI and CD as synonymous—CI ends at artifact; CD covers deployment.
  • Not mentioning artifact immutability—rebuilding from source per environment breaks reproducibility.
  • Omitting security scanning as a pipeline stage.
  • Not discussing automated rollback or observability gates after production deploy.

Follow-Up Questions

  • What is the difference between Continuous Delivery and Continuous Deployment? — Delivery: every passing build is deployable, but production deploy requires human approval. Deployment: production deploy is fully automated after tests pass.
  • How do you handle database migrations in a CI/CD pipeline without downtime? — Backward-compatible migrations first (add column, no rename/drop), deploy new code, then remove old schema in a follow-up migration after old code is gone.
  • How would you implement automated rollback in a production deployment? — Monitor error rate and p99 latency post-deploy; if they breach SLOs within the bake window, trigger redeploy of the previous artifact version.
  • Why should the same artifact be promoted through environments rather than rebuilt per environment? — Rebuilding is not reproducible—dependencies can change. The same image ensures what was tested in staging is exactly what runs in production.

Related Questions

  • K8s — Pod vs Deployment
  • K8s — Liveness vs Readiness
  • K8s — ConfigMap vs Secret
  • Helm Chart
  • Docker — Container vs VM

Can You Explain This Cold?

Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.

Get Graded — Free Assessment
GrindQuestionsAITechnical interview assessment
TermsPrivacyAbout