MLOps in 2026: MLflow, Model Registry and Technical Interview Questions

MLOps interview questions have moved from a niche specialty into a core part of data science and machine learning engineering hiring in 2026. Teams no longer ask only how a model is trained; they probe how it is tracked, versioned, deployed, and monitored once real traffic reaches it. This guide works through the questions that recur in MLOps interviews, grouped by lifecycle stage, with MLflow examples that mirror production setups.

MLOps Interview Questions on the Machine Learning Lifecycle

Q1: What is MLOps and how does it differ from DevOps?

MLOps applies DevOps principles such as automation, CI/CD, and monitoring to machine learning systems, then adds three concerns that traditional software does not have: data versioning, model versioning, and continuous validation against live data distributions. In classic DevOps, code is the only artifact that changes. In MLOps, code, data, and the trained model each version independently, and any of the three can silently degrade output quality without a single line of code changing. The often-cited Hidden Technical Debt in Machine Learning Systems paper makes the point that model code is a small fraction of a real ML system, with data pipelines, monitoring, and configuration dominating the surface area.

Q2: Walk through the stages of a production ML lifecycle.

A strong answer names five stages and the artifact each one produces: data ingestion and validation (a versioned dataset), experimentation (tracked runs with metrics), model registration (a versioned, promotable model), deployment (a serving endpoint or batch job), and monitoring (drift and performance telemetry that feeds back into retraining). Interviewers listen for the feedback loop: monitoring must connect back to experimentation, otherwise the system is a one-way pipeline that rots over time.

Experiment Tracking with an MLflow Tutorial Example

Experiment tracking is the foundation most MLOps questions build on, so an MLflow tutorial answer that shows real logging carries weight. MLflow records parameters, metrics, and artifacts per run, which makes any result reproducible from its run ID.

Q3: How does MLflow tracking capture an experiment, and why does the run ID matter?

Each call to mlflow.start_run() opens a run that logs hyperparameters, metrics, and the serialized model. The run ID is the immutable handle that ties a metric back to the exact code, parameters, and data snapshot that produced it, which is what makes an experiment reproducible months later.

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

The name argument replaces the deprecated artifact_path in MLflow 3.x, a change worth mentioning to show awareness of the current API. Candidates who reference feature and dataset tracking through ML pipeline validation patterns tend to score higher, because reproducibility depends on the whole pipeline, not just the model.

Model Registry 2026: Versioning and Promotion

The MLflow Model Registry turns a run artifact into a governed, promotable object. The biggest recent shift, and a frequent 2026 interview probe, is the move away from named stages.

Q4: How does the MLflow Model Registry promote a model, and what changed in 2026?

Earlier MLflow versions promoted models through fixed stages named Staging, Production, and Archived. MLflow 3.x deprecates those stages in favor of aliases and tags, because a hard-coded stage list could not express real deployment topologies such as champion, challenger, or shadow. An alias is a mutable pointer to one version, so promotion becomes reassigning the alias rather than mutating the model.

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

Because consumers load models:/churn-classifier@champion, a rollback is a single alias reassignment to a previous version, with no redeploy. The official MLflow Model Registry documentation covers alias governance and webhook triggers in depth.

Machine Learning Deployment Patterns and Serving

Deployment questions separate candidates who have shipped models from those who have only trained them. The pattern choice follows the latency budget, not personal preference.

Q5: Compare batch, online, and streaming machine learning deployment.

| Pattern | Latency | Typical use case | Serving surface | |---------|---------|------------------|-----------------| | Batch | Hours to daily | Churn scoring, recommendations refresh | Scheduled job writing to a table | | Online (real-time) | Tens of milliseconds | Fraud checks, ranking at request time | REST or gRPC endpoint | | Streaming | Sub-second, continuous | Anomaly detection on event flows | Consumer on a message queue |

The follow-up almost always asks how to serve the online case. An MLflow model packages its own environment, so serving it is one command against a registry URI.

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: How do blue-green and canary deployments reduce risk for a model rollout?

Blue-green keeps two identical environments and switches all traffic at once after the new model passes checks, giving an instant rollback path. Canary routes a small percentage of traffic to the new version, watches live metrics, then ramps up gradually. For models, canary is usually safer because model quality problems only surface against real inputs, and a canary limits the blast radius to a fraction of users.

Testing and CI/CD for Machine Learning Pipelines

Q7: What does CI/CD test in an ML pipeline that a standard software pipeline does not?

A software CI pipeline runs unit and integration tests on code. An ML pipeline adds data and model tests on top: schema validation on incoming data, distribution checks so a training run does not silently ingest corrupted features, and a model quality gate that fails the build when a candidate scores below the current champion on a fixed holdout set. Continuous delivery for ML therefore promotes a model artifact, not just a container image, and the promotion gate is a metric threshold rather than a green test suite alone. A rigorous pipeline also pins data snapshots and dependency versions so any rerun is deterministic, which is what separates a reproducible build from one that happens to pass today.

Monitoring, Data Drift, and Model Retraining

A deployed model degrades as the world shifts under it, so monitoring questions are where senior signal appears.

Q8: How is data drift detected, and what metric quantifies it?

Data drift means the distribution of production inputs has moved away from the training distribution. The Population Stability Index (PSI) is a common, framework-agnostic measure: it bins a reference distribution, compares production frequencies against those bins, and sums the weighted log differences.

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

Beyond a hand-rolled metric, production teams reach for tooling such as Evidently to track feature drift, target drift, and data quality on a schedule. A complete answer distinguishes data drift (inputs shift) from concept drift (the input-to-output relationship shifts), because the second cannot be caught by watching inputs alone and requires labeled outcomes.

Q9: What should trigger a retraining pipeline?

Time-based retraining on a fixed cadence is the simplest option but wastes compute when nothing has changed and reacts slowly when something breaks. Better triggers are metric-based: retrain when PSI crosses a threshold, when a live evaluation metric drops below a floor, or when a scheduled backtest on freshly labeled data regresses. The retraining job then registers a challenger, which a canary rollout compares against the current champion before any alias is reassigned.

MLOps System Design Interview Questions

Q10: Design a platform that serves hundreds of models with consistent features.

The expected centerpiece is a feature store, which solves training-serving skew by computing features once and serving the identical values to both training and inference. Tools such as Feast provide an offline store for training and a low-latency online store for serving. A full design also names a model registry for versioning, a tracking server for lineage, an orchestrator for pipelines, and a monitoring layer that closes the loop back to retraining. Grounding the answer in real feature work, such as the tradeoffs covered in this feature engineering interview guide, signals hands-on experience rather than diagram recall.

Conclusion

• Frame MLOps as DevOps plus data and model versioning: reproducibility, promotion safety, and monitoring are the three axes interviewers score
• Know the MLflow 3.x API shift: aliases and tags replace deprecated Staging and Production stages, and log_model now takes name instead of artifact_path
• Match deployment pattern to latency budget, and default to canary over blue-green for model rollouts because quality issues only appear against live inputs
• Quantify drift with a concrete metric such as PSI, and distinguish data drift from concept drift, since only one is visible without labels
• Trigger retraining on metrics rather than the calendar, and route the resulting challenger through a canary before reassigning the champion alias
• Name a feature store in any system design answer to close the training-serving skew gap before it is raised as a follow-up