How do you take a machine learning model that works on your laptop and get it to make predictions reliably for thousands of users every day, without constant manual effort? That is the problem that ML pipelines and MLOps solve: they automate the messy, repetitive work of training, testing, and deploying models so that your team can deliver better predictions faster — and that is exactly what the MLS-C01 exam wants you to understand.
Jump to a section
A simple way to picture ML Pipelines and MLOps with SageMaker
When you cook a single meal for yourself, you chop, stir, and season all in one go. But a restaurant kitchen works differently because it needs to serve the same dish consistently to hundreds of customers every day. This is exactly the shift from building one machine learning model on your laptop to running ML pipelines and MLOps with SageMaker in a real company.
In a restaurant kitchen, the head chef first designs a recipe. That recipe is like your Jupyter notebook — the place where you experiment and decide which features to use and which model type works best. Once the recipe is final, the kitchen manager standardises it: every onion must be diced to exactly 5 millimetres, the stock must simmer for precisely 20 minutes. That standardisation is your training pipeline — it turns your experimental code into a repeatable, automated process that always runs the same way.
After the kitchen standardises the recipe, it needs a system to prepare ingredients ahead of time (the data preprocessing step), cook in bulk (the training job), taste-test every batch (model evaluation), and keep the finished dishes warm until they are ordered (model deployment and monitoring). If a customer sends back a dish because it is too salty, the feedback goes to the chef, who adjusts the recipe and triggers the whole pipeline again. This continuous loop of feedback and improvement is exactly what MLOps (Machine Learning Operations) does: it automates the process of retraining and redeploying models so your predictions stay accurate over time, without a human having to babysit every step.
Machine learning pipelines and MLOps (Machine Learning Operations) are the tools and practices that turn a one-off model experiment into a production-ready system. For the MLS-C01 exam, you need to understand how AWS SageMaker makes this possible.
Let us start with the basics. A machine learning pipeline is an automated sequence of steps that takes raw data and ends with a deployed model making predictions. Each step is a modular task: ingesting new data, cleaning it, transforming it (feature engineering), training a model, evaluating its performance, and deploying it to an endpoint. Without a pipeline, a data scientist would have to run each of these steps by hand, which is slow, error-prone, and impossible to scale. With a pipeline, the entire process runs automatically whenever new data arrives or code changes.
MLOps extends this idea by adding the principles of DevOps — the practices that software engineers use to deliver code reliably — to the machine learning lifecycle. MLOps includes version control for your data and model, automated testing, monitoring for model drift (when a model's accuracy declines because the real-world data has changed), and automated retraining. SageMaker Pipelines is the AWS service that lets you build, visualise, and run these pipelines without managing servers. You define each step as a SageMaker processing job, training job, or model creation job, and SageMaker handles the infrastructure.
Here is how a typical SageMaker pipeline works in practice. Imagine you run an e-commerce site and you want to predict which products a customer is likely to buy next. Your pipeline might look like this:
Step 1: Data Ingestion — a SageMaker Processing job pulls the latest clickstream data from an S3 bucket (Simple Storage Service is AWS's cloud storage).
Step 2: Data Preprocessing — another processing job cleans the data, removes missing values, and creates feature columns like 'pages_visited' and 'time_on_site'.
Step 3: Training — a SageMaker Training job runs your algorithm (for example, XGBoost or a neural network) on the processed data and outputs a model file.
Step 4: Evaluation — a processing job runs a test script that compares the model's predictions against known answers and checks metrics like accuracy and precision.
Step 5: Conditional Gate — the pipeline checks if the new model's accuracy is at least 5% better than the current deployed model. If yes, it proceeds; if no, it stops and sends a notification.
Step 6: Model Registration — if the model passes, SageMaker registers it in the SageMaker Model Registry, which keeps a versioned catalogue of all approved models.
Step 7: Deployment — SageMaker deploys the model to a real-time endpoint or a batch transform job so it can start making predictions on new user traffic.
Why does this matter for the exam? The MLS-C01 exam tests your ability to design these pipelines and choose the right SageMaker components. You will see questions about how to chain steps together using the SageMaker SDK (the Python library for building pipelines), how to parameterise inputs so the same pipeline can run with different datasets, and how to set up triggers so the pipeline runs automatically when new data lands in S3. They also love to test the Model Registry: you need to know how to approve, reject, and deploy different model versions from it.
Key SageMaker components you must know for this topic:
SageMaker Pipelines: the service for defining and running multi-step workflows.
Processing jobs: for running custom Python scripts for data preprocessing, feature engineering, or model evaluation.
Training jobs: for running actual model training on managed compute instances.
Model Registry: a central place to store model versions, their metadata (like training metrics and hyperparameters), and their approval status (how many customers saw the model 'pending', 'approved', or 'rejected').
Sagemaker Model: a container that packages your trained model code and artefacts into a deployable unit.
Endpoints: the HTTP endpoints where your model sits and serves predictions to applications.
EventBridge: the AWS service that can watch for new files in S3 and automatically trigger your pipeline.
A common misconception is that a pipeline is just a script that runs sequentially. In reality, SageMaker Pipelines supports conditional branching (like the evaluation step above) and parallel execution, so you could train three different model types simultaneously and then compare them. The exam expects you to understand these capabilities.
Define the pipeline steps
You write a Python script using the SageMaker SDK to define each step as a ProcessingStep, TrainingStep, or CreateModelStep. You specify the inputs, outputs, and the compute resources for each step. This is where you break your ML workflow into modular pieces.
Add conditional branching
Use a ConditionStep to check evaluation metrics — for example, 'if F1_score > 0.85, continue to deployment; else, stop the pipeline'. This prevents bad models from being deployed automatically, which is a key MLOps best practice.
Create the pipeline
You instantiate a Pipeline object with a name and a list of steps. SageMaker validates the pipeline definition and uploads it to the service. No infrastructure to manage — SageMaker handles the compute resources when the pipeline runs.
Run the pipeline manually or on a schedule
You can trigger the pipeline programmatically via the SDK, through the AWS Console, or automatically with EventBridge. When the pipeline runs, SageMaker provisions the necessary compute, executes each step in order, and cleans up resources when done.
Monitor and retry on failures
If a step fails (e.g., data processing runs out of memory), SageMaker logs the error. You can inspect the logs, fix the issue, and retry the failed step without rerunning the entire pipeline. This saves time and is crucial for production reliability.
Register and deploy the approved model
Once the evaluation step passes, the pipeline registers the model in the Model Registry. After manual or automated approval, the pipeline creates a SageMaker Model and deploys it to an endpoint. The endpoint can then serve predictions to your application.
What does an IT professional actually do with ML pipelines and MLOps on SageMaker? Let us walk through a realistic scenario at a mid-sized insurance company.
This company wants to automate the process of approving or denying car insurance claims. A data scientist has built a model on her laptop that predicts whether a claim is fraudulent based on factors like claim amount, driver history, and vehicle age. Now the company needs to make this prediction available to their claims processing system, which handles 10,000 claims per day. Manually retraining the model or re-running experiments every week is impossible.
Here is what the ML engineer does:
Port the data scientist's code into a SageMaker notebook and refactor it into modular Python scripts — one for data cleaning, one for feature engineering, one for training, one for evaluation.
Create a SageMaker Pipeline definition using the SDK. Each script becomes a step: a ProcessingJob for data cleaning, another ProcessingJob for feature engineering, a TrainingJob for model training, a ProcessingJob for evaluation, and finally a CreateModel step followed by a deployment to a real-time endpoint.
Add a conditional step after evaluation: if the new model's F1 score (a metric that balances precision and recall) is above 0.85, proceed to register the model; otherwise, stop the pipeline and email the team.
Register the model in the SageMaker Model Registry with metadata including the training dataset date, the algorithm used (XGBoost), and the evaluation metrics.
Set up an EventBridge rule that watches the S3 bucket where claim data arrives. Every time a new file lands at midnight, EventBridge triggers the pipeline to run automatically.
Deploy the approved model to a SageMaker endpoint. The claims processing system sends a POST request to this endpoint with the claim details and gets back a fraud probability score.
Set up SageMaker Model Monitor to track the model's prediction distribution. If the real-world claim patterns shift (say, a new type of scam emerges), Model Monitor detects that the model's predictions look different from the training data and triggers an alert.
When the alert fires, the ML engineer checks the Model Registry, sees that the last approved model is three months old, and kicks off a new pipeline run manually or via a retraining schedule.
The real daily work involves debugging pipeline failures — like a data processing step that runs out of memory or a model that fails to deploy because the instance type is too small. The engineer uses SageMaker Pipeline's built-in visualisation to see exactly which step failed and inspect the logs. They also spend time tuning the pipeline parameters, such as the instance type and number of instances for each step, to balance cost and speed.
On the exam, you will be asked to interpret these kinds of scenarios. Remember: SageMaker Pipelines is the orchestration layer; Model Registry is the catalogue; Model Monitor is the watchdog.
The MLS-C01 exam dedicates a significant portion of objective 4.2 to ML pipelines and MLOps with SageMaker. Here is exactly what you need to know.
First, the exam loves scenario-based questions where you must choose the correct SageMaker component to accomplish a task. You will see a paragraph describing a business requirement, and then five possible answers that mix up similar-sounding services. The most common trap is confusing SageMaker Pipelines with AWS Step Functions. Both can orchestrate workflows, but SageMaker Pipelines is purpose-built for ML workflows and integrates natively with SageMaker's processing, training, and deployment jobs. If the question mentions 'visualising the pipeline' or 'using SageMaker SDK native integration', pick SageMaker Pipelines. If the scenario involves orchestrating non-ML tasks (like sending an email or calling a third-party API), Step Functions might be better — but the exam almost always expects you to choose SageMaker Pipelines for ML workflows.
Second, the Model Registry is a frequent test topic. You need to know:
The Model Registry stores model versions, their associated metadata (metrics, hyperparameters, training dataset), and their approval status.
The lifecycle states are: 'PendingManualApproval', 'Approved', 'Rejected'. There is no automatic approval — a human or a script must change the status.
You can deploy a specific model version directly from the registry using the 'CreateModel' step in your pipeline.
The registry is crucial for auditability — it gives a complete history of which model was deployed, when, and with what data it was trained.
Third, the exam tests your understanding of pipeline step types and dependencies. Questions might give you a list of steps and ask you to order them correctly or to identify which step can run in parallel with another. Remember that preprocessing steps can often run in parallel if they work on different slices of data, but training and evaluation are typically sequential.
Fourth, watch for questions about automatic pipeline triggering. The exam wants you to know that EventBridge is the standard way to trigger a pipeline from an S3 event (like a new file being uploaded). Even better, SageMaker Pipelines now supports a built-in 'Schedule' feature that lets you run pipelines on a cron schedule (e.g., every day at 2 AM) without writing any custom code. If the question says 'trigger the pipeline once a day at midnight', the answer is EventBridge or SageMaker Pipeline's native scheduling — not a Lambda function that runs on a schedule, though that would also work but is not the most direct answer.
Fifth, the trap of 'manual vs automated' appears often. If the question describes a process where a human must review a new model before deployment, the answer involves Model Registry's manual approval step, not automatic deployment. If the question says 'the team needs to retrain the model automatically every week with the latest data', the correct answer is a scheduled pipeline that ingests new data from S3, retrains, evaluates, and registers the model — all without human intervention.
Finally, memorise these specific exam facts:
SageMaker Pipelines supports parallel execution using 'ParallelismConfiguration'.
You can pass data between steps using JSONPath expressions or Properties files.
Steps can be conditional using 'ConditionStep' that checks a Boolean.
The training step outputs a model artefact stored in S3, which is then consumed by a 'CreateModelStep'.
SageMaker Model Monitor can detect data drift, quality drift, and bias drift — but the exam mostly cares about data drift (when the distribution of incoming data changes).
An ML pipeline automates the sequence of data ingestion, preprocessing, training, evaluation, and deployment so you can deliver models consistently and at scale.
SageMaker Pipelines is the native AWS service for building ML pipelines — it supports conditional steps, parallel execution, and automatic retries.
The SageMaker Model Registry stores versioned models with metadata and approval status, enabling governance and easy rollback if a new model underperforms.
Model drift — when a model's accuracy drops because real-world data changes — is the main reason you need automated retraining pipelines.
EventBridge is the standard way to trigger a SageMaker Pipeline automatically when new data arrives in an S3 bucket.
SageMaker Model Monitor tracks deployed models for data and quality drift and can alert your team when retraining is needed.
A ConditionalStep in a pipeline allows you to only deploy a new model if its accuracy exceeds the current deployed model, preventing regressions.
Each step in a SageMaker Pipeline can use different compute resources (instance types) optimised for the task — for example, GPU instances for deep learning training and CPU instances for preprocessing.
These come up on the exam all the time. Here's how to tell them apart.
SageMaker Pipelines
Purpose-built for ML workflows with native integration for Processing, Training, and Deployment jobs.
Supports pipeline-specific features like model registration and evaluation inside the pipeline.
Steps are defined using the SageMaker SDK and are visualisable in the SageMaker console.
Best for end-to-end ML automation where all steps are SageMaker services.
Handles step-level retry and parallelism directly in the pipeline definition.
AWS Step Functions
General-purpose workflow orchestrator for any AWS service or custom Lambda function.
Requires more custom integration code to handle ML-specific tasks like model deployment.
Defined using Amazon States Language (ASL), not the SageMaker SDK.
Better for workflows that mix ML and non-ML steps, like sending an email or calling a database.
Provides built-in error handling with retries and catch conditions at the state machine level.
SageMaker Model Registry
Provides versioned storage of models with metadata like training metrics and hyperparameters.
Encodes an approval workflow with states: pending, approved, rejected.
Integrates directly with SageMaker Pipelines for registering and deploying from the registry.
Allows rollback to a previous approved version easily from the UI or API.
Supports cross-account access for sharing models between teams.
S3 Bucket with Model Files
Just a bucket storing raw model artefacts—no versioning or metadata management built-in.
No built-in approval workflow; you must build your own with custom scripts or databases.
Not integrated; you would need manual scripting to upload and download model files for deployment.
No easy rollback mechanism unless you have carefully organised your bucket prefixes.
Access control is limited to standard S3 permissions, no model-specific governance.
EventBridge Trigger for Pipeline
EventBridge can watch S3 events and directly start a SageMaker Pipeline execution.
No custom code needed—EventBridge rules are configured with simple pattern matching.
Supports cron scheduling natively for time-based pipeline runs.
EventBridge is a serverless event bus that scales automatically.
Ideal for simple triggers like 'run pipeline when new file lands in S3'.
Lambda Function Trigger for Pipeline
A Lambda function must be written to receive the S3 event and call the SageMaker SDK to start the pipeline.
Requires managing Lambda code, dependencies, and IAM roles specifically for the Lambda function.
Lambda functions can only be triggered by S3 events, not by cron schedules—you would need CloudWatch Events separately.
Lambda has a maximum execution time of 15 minutes, which is irrelevant if it just triggers a pipeline, but adds complexity.
Useful when you need to transform the event data before starting the pipeline, e.g., parsing a CSV file and passing parameters.
Mistake
A SageMaker Pipeline is just a script that runs steps one after another, like a Python function.
Correct
A SageMaker Pipeline is a directed acyclic graph (DAG) that supports conditional branching, parallel execution of steps, and automatic retry on failure.
Beginners often think of pipelines as sequential scripts because that is how they first learn to write code. The exam tests your understanding that pipelines are much more flexible.
Mistake
Once a model is deployed to an endpoint, the pipeline work is done and you never need to run it again.
Correct
MLOps is a continuous cycle. Models degrade over time (concept drift), so pipelines must be triggered periodically or on new data to retrain and redeploy.
This misconception comes from a 'fire and forget' mindset. Beginners do not realise that production ML requires constant maintenance, just like any other software system.
Mistake
You must write custom Lambda functions to run ML steps in SageMaker Pipelines.
Correct
SageMaker Pipelines has built-in step types for processing, training, evaluation, and deployment that handle the underlying compute without needing Lambda.
People familiar with AWS Lambda for general orchestration assume it is needed here, but SageMaker Pipelines has its own native step types that are easier to use and better integrated.
Mistake
The SageMaker Model Registry is only for storing the final deployed model and you do not need to use it if you have a simple pipeline.
Correct
The Model Registry is critical for versioning, auditability, and controlling which model versions are approved for deployment, even in simple pipelines.
Beginners overlook the registry because they think 'I just need the latest model'. The exam emphasises it because real organisations need governance.
Mistake
If a pipeline step fails, you must delete the pipeline and recreate it from scratch.
Correct
SageMaker Pipelines allows you to retry individual failed steps manually or automatically, and you can also update the pipeline definition without deleting it.
This comes from a lack of familiarity with pipeline orchestration tools. In CI/CD systems, failures are handled gracefully, but beginners often expect a brittle system.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, the exam tests your understanding of the SageMaker SDK for Python. You define pipelines by writing Python code that calls SageMaker's SDK classes like Pipeline, ProcessingStep, and TrainingStep.
A Processing Job is a single task for running a script on data. A Pipeline is a multi-step workflow that can include multiple Processing Jobs, Training Jobs, and deployment steps, all orchestrated together.
Yes, SageMaker Pipelines has a built-in scheduling feature where you can set a cron expression directly on the pipeline using the 'Schedule' parameter. EventBridge is also a valid option but the native schedule is simpler.
You can stop a pipeline run manually from the AWS Console or programmatically. SageMaker will cancel any currently running steps and mark the pipeline execution as 'Stopped'. You can then resume by starting a new execution.
Yes, you can create multiple TrainingStep objects that run concurrently. Use the 'ParallelismConfiguration' property in your pipeline definition to control how many steps run at the same time.
No, it is optional but highly recommended. You can deploy a model directly from a pipeline without registering it. However, the Model Registry provides versioning, auditing, and approval workflows that are essential for MLOps governance.
You've finished ML Pipelines and MLOps with SageMaker. Continue through the MLS-C01 study guide to build a complete picture of the exam.
Done with this chapter?