TL;DR: MLOps is the same delivery discipline applied to a system with three inputs instead of one: code, data and a trained model. The additions are versioning data and models, evaluating rather than testing, and watching for quality decay after release, since a model degrades while every infrastructure metric stays green.
How to approach it
Resist defining MLOps abstractly. Say what a machine-learning system has that a normal service does not, and let the practices fall out of that. Interviewers asking this want to hear whether you understand why a green pipeline can ship a worse product, which is the difference that actually changes the tooling.
A strong answer
A normal service has one input that changes: code. Deterministic, diffable, testable with assertions, and if the tests pass the behaviour is the behaviour.
A machine-learning system has three. The code, the data it trained on, and the model artifact that came out. Change any one and the behaviour changes. That single fact generates the whole discipline.
Versioning all three together. A deployed model needs to be traceable to the exact training code, the exact dataset snapshot and the hyperparameters. Without that you cannot reproduce it, and when it misbehaves you cannot tell whether the cause was a code change or a data change. In practice this is a model registry holding the artifact plus its lineage, and dataset versioning through a tool or through immutable partitioned storage.
Evaluation instead of tests. There is no assertion that a model is correct. You hold out a test set and measure: accuracy, precision and recall, or for generative systems a scored evaluation suite. The gate is comparative rather than absolute, meaning this candidate is not worse than the model in production on this fixed set, and that comparison is what a promotion decision hangs on. You still need ordinary tests for the code around the model: the feature transforms, the serving path, the input validation.
Training as a pipeline, not a notebook. The path from data to registered model runs on a schedule or a trigger, in an environment that is reproducible, with the run recorded. A model whose provenance is somebody's laptop is not deployable in anything regulated and is barely deployable anywhere else.
Monitoring for decay, which is the one with no DevOps equivalent. A service that is failing shows errors and latency. A model that has become wrong shows nothing: latency is normal, error rate is zero, and the predictions are worse. The world moved and the model did not. So you monitor the inputs for drift (is the distribution of incoming data still like the training data), and the outputs for quality, either through delayed ground truth when it arrives or through proxy signals like user acceptance. This is why people say model quality is not an infrastructure metric.
Feature consistency. The transformation applied at training time and at serving time must be identical, or the model sees inputs shaped differently from the ones it learned on. Training-serving skew is a leading cause of a model that looked fine offline and performs badly in production, and a shared feature pipeline is how you prevent it rather than detect it.
What stays exactly the same is worth saying too: source control, code review, containers, CI, progressive rollout, observability. MLOps is not a parallel universe, it is the same pipeline with two more artifacts to version and one more failure mode to watch for.
What interviewers probe next
"What is the difference between drift and decay?" Drift is the input distribution changing. Decay is the model's performance falling. Drift often causes decay and does not always, so alerting on drift alone produces false alarms and alerting on decay alone is late.
"How do you roll back a model?" Point the serving layer at the previous version in the registry, which should be a config change rather than a rebuild. The reason to keep models as versioned artifacts separate from the image is exactly this.
"Where does LLMOps differ?" Usually no training, so the pipeline centres on prompts, retrieval and the choice of provider. Evaluation gets harder because there is no single correct output, and cost per request becomes a first-class metric in a way it rarely is for a classifier.
Common mistakes
Describing MLOps as CI/CD for models and stopping, which misses data versioning and post-release quality monitoring entirely.
Treating a passing pipeline as proof the model is good, when the pipeline only proves the code ran.
Training in notebooks and deploying the output, so no run is reproducible.
Monitoring only latency and error rate, which stay perfectly healthy while the model gets steadily worse.