✅ Q1 — Design a production-grade CI/CD pipeline — what stages must exist?

At minimum: source → build → test → security scan → artifact publish → deploy → verify. I separate CI and CD logically. CI produces versioned immutable artifacts. CD promotes same artifact across environments. Never rebuild per environment.

✅ Q2 — How do you prevent broken code from reaching production automatically?

Use gated pipeline stages — unit tests, integration tests, lint, and security scans must pass before artifact publish. Production deploy requires manual approval or protected branch merge. Also use policy checks and quality gates.

✅ Q3 — Dev team wants direct deploy on every commit to main — do you allow?

Only for non-prod. For production, I require PR + review + checks. Direct commit deploy to prod is high risk. Speed without control creates outages. Balance automation with guardrails.

✅ Q4 — Build works in CI but fails in production runtime — why common?

Environment mismatch — different dependencies, configs, or OS libs. Fix is containerized builds and runtime parity. Build once, run same container everywhere. Avoid environment drift.

✅ Q5 — How do you implement artifact versioning correctly?

Use immutable version tags — commit SHA or semantic version. Store artifacts in registry (ECR/Nexus/Artifactory). Never use “latest” in production deploy. Version must map to exact source commit.

✅ Q6 — What is artifact promotion vs rebuild — which is correct?

Promotion is correct. Same artifact moves from dev → stage → prod. Rebuilding per env risks different binaries. Promotion guarantees consistency and rollback ability.

✅ Q7 — Pipeline is slow because tests take 25 minutes — what do you change?

Split tests into parallel jobs. Run fast tests first, slow tests later. Cache dependencies. Separate smoke vs full regression suites. Don’t block quick feedback with heavy tests every commit.

✅ Q8 — How do you implement rollback in CI/CD design?

Rollback uses previously published artifact version. Deployment step supports version parameter. No rebuild — just redeploy previous version. Store deployment metadata for traceability.

✅ Q9 — How do you handle database migrations safely in pipeline?

Migrations must be versioned and backward compatible. Run migration as separate controlled step. Use expand-contract pattern. Never couple destructive schema change with app deploy blindly.

✅ Q10 — How do you secure secrets in CI/CD pipelines?

Secrets stored in secret manager or CI credential store. Inject at runtime only. Never commit in repo or bake into image. Mask in logs and restrict access by role.

✅ Q11 — How do you support multiple environments with same pipeline?

Same pipeline, different config inputs. Use env-specific variables and values files. Artifact stays same — only config changes. Avoid separate pipeline logic per env.

✅ Q12 — Canary or blue-green — when do you choose which?

Blue-green when you can switch traffic instantly and infra cost is acceptable. Canary when you want gradual exposure and metric-based validation. Canary is safer for high-risk releases.

✅ Q13 — Pipeline triggered twice per commit — debugging steps?

Check webhook duplication and polling overlap. Verify only one trigger type active. Inspect CI server webhook logs. Duplicate triggers waste capacity and cause race deploys.

✅ Q14 — How do you add security scanning into CI/CD without killing speed?

Run fast SAST and dependency scan in CI. Run deeper scans async or nightly. Fail build only on high severity. Security must be integrated, not blocking everything blindly.

✅ Q15 — Biggest CI/CD anti-pattern you’ve seen in real orgs?

Rebuilding artifacts per environment + manual hotfix deploys outside pipeline. That destroys traceability and rollback safety. CI/CD must be single path to production — no side doors.