TL;DR: Traditional CI/CD ships one changing thing (code); ML ships three (code, data, model), so tests become statistical gates instead of pass/fail, deployments bundle the model with its feature pipeline, and a third loop (continuous training) means production can degrade with zero deploys, which makes monitoring the trigger mechanism rather than an afterthought.
How to approach it
This is a screen, usually in the first fifteen minutes, and it's calibrated: the interviewer has heard "you also version the data" two hundred times. Open with the structural difference, in software CI/CD only code changes; in ML, code, data, and the model all change independently, then spend your time on the consequences, because that's where weak candidates run out of material.
A strong answer
Three things change instead of one. A traditional pipeline triggers on a commit, runs deterministic tests, and ships a binary. An ML pipeline has three change vectors: code (training and serving logic), data (the upstream distribution shifts whether or not anyone commits anything), and the model artifact itself. Each needs its own versioning, Git for code, something like Delta Lake snapshots or DVC for data, a model registry for artifacts, and a prediction is only debuggable if you can join all three: "this score came from model version 14, trained on the March snapshot, at commit abc123."
Tests become statistical, not binary. assert add(2,2) == 4 either passes or fails. A model gate is "AUC on the holdout within 0.5 points of the champion, calibration error under 2%, p99 latency under 80ms in the serving container." You're asserting distributions, which means flaky-looking failures are sometimes real signal, and your pipeline needs evaluation gates with thresholds someone consciously chose, plus data validation (schema, null rates, range checks) before training even starts, garbage data that would crash a normal build instead trains a quietly bad model.
There's a third loop: continuous training. CI and CD cover code-triggered changes. ML adds CT, pipelines that retrain on a schedule or on a drift trigger with no human commit at all. That inverts the usual assumption: production can degrade with zero deploys, so monitoring isn't an afterthought, it's the trigger mechanism for the whole pipeline.
"Production degrades with zero deploys" is the claim that sounds like a slogan until you watch the timeline it describes, so walk one:
| Week | What happened | What the dashboards said |
|---|---|---|
| 0 | Fraud model v14 deployed, all gates green | Green |
| 3 | A data vendor silently changes a field encoding; one key feature starts arriving as nulls, imputed to the mean | Green: 200s, 20ms p99, no errors anywhere |
| 3-5 | The model scores every transaction with that feature neutralized; precision decays | Still green; labels have not arrived yet |
| 5 | Chargeback labels land with their usual lag; precision on weeks 3-4 traffic is down hard | The monitoring pipeline pages, not the serving one |
| 5 | Drift detector on the feature (null-rate breach) would have caught it at week 3 | This row is the lesson |
Nobody committed code. Nothing threw an exception. Every conventional health signal stayed green for two weeks of quietly wrong decisions, and the earliest possible alarm was a data monitor, not an HTTP one. That timeline is why the monitoring-to-CT arrow in the diagram below exists, and reciting a version of it is the fastest way to show an interviewer you understand the inversion rather than just repeating it.
Deployment units are bigger. You don't ship the model alone; you ship model + feature pipeline + preprocessing as one versioned bundle, because a rollback that reverts the model but keeps a changed feature definition produces something that was never tested. And "healthy" is redefined: a model can return 200s at 20ms while being statistically wrong, so rollback triggers come from prediction quality, not HTTP errors.
If you've used the AWS stack, ground it: CodePipeline still does code CI, but SageMaker Pipelines owns the training DAG, the Model Registry owns promotion with approval gates, and Model Monitor closes the loop.
The three loops, and how monitoring feeds back into training:
The arrow from monitoring back into training is the part traditional DevOps has no analog for: no human committed anything, yet the pipeline fired.
What interviewers probe next
- "What breaks if you treat a model like a stateless binary?", silent degradation with no deploy event, irreversible rollbacks when features drift apart from the artifact, and on-call staring at green dashboards while precision craters.
- "Do you retrain inside the CI pipeline?", no; training is hours and GPUs, CI is minutes. CI validates code with a smoke-train on sample data; full training runs in the CT pipeline.
- "What's continuous training and what triggers it?", scheduled, drift-triggered (PSI breach on key features), or metric-triggered once delayed labels land; gated by champion/challenger evaluation before promotion.
Common mistakes
Listing "data versioning, model versioning" as nouns with no consequences attached, that's the chatbot answer. Claiming you run full training on every commit (instantly flags you as never having done it). Saying ML tests are "just like unit tests but for models" without mentioning thresholds or statistical gates. And forgetting monitoring entirely, when the honest headline is that in ML, monitoring is upstream of deployment, not downstream.