Machine learning operations (MLOps) is the set of practices that takes ML from one-off experiments to reliable systems that keep working in production. It borrows ideas from DevOps, such as automation, version control and monitoring, and adds what's special about models: they depend on data, and they degrade over time. The exam expects you to recognise the core MLOps ideas and the problems each one solves.
Why MLOps Exists
Many ML projects stall after a promising notebook. The model works on a data scientist's laptop, but no one can rebuild it, deploy it safely or tell when it stops working. MLOps fixes this by treating the whole ML lifecycle, from data and training to deployment and monitoring, as a repeatable, automated process that a team shares, instead of a series of manual steps one person remembers.
Experimentation and Tracking
Building a model involves many experiments: different data, features, algorithms and settings. Experiment tracking records what was tried and how each run performed, so the team can compare results and reproduce the best one. Amazon SageMaker AI offers managed MLflow for this. Without tracking, a team can find a great model and then be unable to recreate it.
Repeatable, Scalable Processes
A repeatable process means the same steps produce the same result every time, run by automation rather than by hand. Amazon SageMaker Pipelines lets teams define the workflow (prepare data, train, evaluate, register) so it can run again on new data with one trigger. A model registry, such as SageMaker Model Registry, keeps track of model versions and whether each is approved for production. Automation also makes the system scalable: it can handle more data, more models and more teams without more manual effort.
Technical Debt and Production Readiness
Technical debt is the future cost of shortcuts taken today, such as hard-coded file paths, manual data copies, or untracked model versions. In ML it builds up fast, because code, data and models all change. Production readiness means a model is more than accurate. It's tested, versioned, secured, monitored, documented, and can be rolled back if something goes wrong. MLOps practices pay down debt before it causes failures.
Monitoring and Retraining
A deployed model meets data that slowly changes. Model monitoring detects drift in data and prediction quality. (Amazon SageMaker Model Monitor did this on AWS but is now closed to new customers; AWS points new customers to open-source monitoring tools with Amazon CloudWatch.) When quality drops, retraining updates the model with fresh data. In mature MLOps, a monitoring alert can trigger the same automated pipeline used to build the model in the first place, closing the loop.
On the Exam
| Problem in the scenario | MLOps idea |
|---|---|
| "Can't reproduce last month's best model" | Experiment tracking, versioning |
| "Every retrain is done by hand and takes days" | Repeatable automated pipelines |
| "Don't know which model version is live" | Model registry |
| "Accuracy dropped silently after launch" | Monitoring, then retraining |
| "Quick fixes keep breaking things" | Managing technical debt |
The trap is treating MLOps as a single tool. It's a set of practices, and the scenario's symptom tells you which practice is missing.