Stop 15 · Interview PreparationCI/CD & Automation · 1/3

CI/CD Pipeline Design Questions

Part of the DevOps Roadmap

In short

'Design a CI/CD pipeline for 20 microservices' tests whether you think in stages, gates and speed. They want to hear why each step is there, not just tool names.

'Design a CI/CD pipeline for a microservices application' — testing structured thinking about build, test, security, and deployment stages from Phase 6.

The mascot arranges steel serving counters in a line with plates, dal and rice pots.

Think of it like this

Setting up the hostel mess line

A good mess line runs in order: plates first, then dal, rice, sabzi, with a taste check before the food goes out. Put the plates at the end and the whole line jams. Pipeline design is choosing the order of counters so food moves fast and nothing bad reaches the table.

Watch it happen

A pipeline for many services

Detect
Test
Scan
Artifact
Staging
Prod

1/6Only build services whose folders changed. With 20 services, rebuilding all on every commit wastes time.

The big ideas

What you need to know

Speed is a feature

Aim for feedback in about 10 minutes. Caching, parallel jobs and change detection matter more than fancy tools.

Gates where risk is

Required reviews, passing tests and scans before merge. Approval or canary checks before production.

Immutable artifacts

Build once, tag by SHA, promote the same artifact. Never rebuild for production.

Secrets via OIDC

Let the CI job get short-lived cloud credentials through OIDC instead of storing long-lived keys.

See it in code

Walk through the code

yaml
1# Only run the orders pipeline when orders code changes2on:3  push:4    branches: [main]5    paths:6      - "services/orders/**"7      - "libs/shared/**"8jobs:9  test:10    runs-on: ubuntu-latest11    steps:12      - uses: actions/checkout@v413      - uses: actions/setup-node@v414        with: { node-version: 22, cache: npm }15      - run: npm ci && npm test --workspace services/orders

1/3Trigger on pushes to main only.

paths filters are one simple way to do change detection in a monorepo. Tools like Nx or Turborepo do it with a dependency graph.

Save yourself the pain

Common mistakes

Oops

Listing tools: 'Jenkins, SonarQube, Docker, Kubernetes, ArgoCD' and stopping there.

Do this instead

Explain each stage's purpose and what failure there means. Tools are details you mention after.

Oops

Ignoring rollback and database migrations in the design.

Do this instead

Say how a bad release is undone and how schema changes stay backward compatible.

Your mission

Whiteboard a pipeline

~30 min

Quick check

Your pipeline takes 45 minutes and developers are bypassing it. What's the best first fix?

Go deeper

  1. 1Review Phase 6 and practice sketching a full pipeline for a sample scenario.
  2. 2Prepare to discuss deployment strategy choice (blue-green vs canary) and why.
  3. 3Practice explaining how secrets and multiple environments fit into your pipeline design.

More ci/cd & automation at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge