If you do not automate how you build, test, and deploy machine learning models, you will spend your weekends manually copying files into production and praying nothing breaks. That is why CI/CD for ML exists: it turns a frantic, error-prone process into a reliable, repeatable assembly line that lets you update models without taking your entire application offline.
Jump to a section
A simple way to picture CI/CD for Machine Learning: Automating Model Deployment
A head chef who runs a busy restaurant kitchen. Every time the chef wants to change the menu or fix a broken oven, she used to close the restaurant for two days, cook 50 test batches of the new dish, then cross her fingers as she served it to paying customers. This was slow, risky, and it meant customers ate cold food while she scrambled.
Now imagine she builds a parallel prep kitchen. Every evening, the night crew tests new recipes in that prep kitchen without disturbing the main dining room. They use an automated system: a conveyor belt that takes a raw ingredient, runs it through a set of tests (does it taste right? Is it safe? Does it cook in the required time?), and if it passes, that ingredient gets stored in a temperature-controlled box called the 'staging fridge'. The next morning, the main kitchen simply pulls the pre-tested ingredient from the staging fridge and adds it to the menu. If the night crew's test fails—say the new sauce separates under heat—the conveyor belt automatically stops, alerts the chef on her phone, and the old recipe stays on the menu until the problem is fixed.
This is exactly how CI/CD for machine learning works. The prep kitchen is your development environment, the conveyor belt is your CI/CD pipeline, and the staging fridge is the model registry. The head chef never has to close the restaurant—she rolls out improvements continuously, without ever serving a bad dish.
Let us start with what CI/CD actually means. CI stands for Continuous Integration. CD stands for Continuous Delivery or Continuous Deployment. Together, CI/CD is a set of practices that automates the process of taking code from a developer's laptop and putting it into production where real users can use it.
For machine learning, this is trickier than for regular software because ML has extra pieces: training data, a model file, hyperparameters (the settings you choose before training starts, like how many times the model should learn from the data), and evaluation metrics (numbers that tell you how good your model is, like accuracy or error rate). A CI/CD pipeline for ML must handle all of these.
The core components in AWS are CodePipeline, CodeBuild, and SageMaker. CodePipeline is the orchestrator—it is like a project manager that moves your work from one stage to the next. CodeBuild is the worker that compiles code and runs tests. SageMaker is the service that trains, deploys, and hosts machine learning models.
Here is how these three services fit together to form a CI/CD pipeline:
First, you start with source control. This is a central storage place for your code, data processing scripts, and model definitions. On AWS, this is usually AWS CodeCommit (AWS's own Git service) or GitHub. Whenever a developer pushes a change to the repository—for example, updating the model training script or adding a new data feature—CodePipeline is automatically triggered.
Second, the pipeline runs the Build stage using CodeBuild. CodeBuild reads a configuration file (called buildspec.yml) that tells it what to do. Typical steps include installing Python libraries, running unit tests on your data processing code, and packaging the training script into a container image (a lightweight, portable software package that includes everything the code needs to run). This container is stored in Amazon Elastic Container Registry (ECR).
Third, the pipeline moves to the Deploy stage. This is where SageMaker comes in. The pipeline sends the container image to SageMaker, which starts a training job. SageMaker automatically provisions computing resources, runs your training script, and produces a trained model file. That model file gets saved to an Amazon S3 bucket (a storage service in the cloud).
Fourth, the pipeline optionally runs a model evaluation stage. A separate CodeBuild project loads the trained model, runs it against a held-out test dataset (data the model has never seen before), and checks if the model's performance meets a minimum threshold—for example, accuracy above 90 percent. If the model fails, the pipeline stops and sends an alert. If it passes, the pipeline proceeds.
Fifth, the pipeline deploys the approved model to a SageMaker endpoint (a live, running web service that other applications can call to get predictions). You can set this up as a blue/green deployment, where the new model runs alongside the old one so you can test it with real traffic before fully switching over.
Why does all of this matter? Before CI/CD, deploying a model was a manual process. A data scientist would train a model on their laptop, copy the file to a server, manually restart the server, and pray the model worked. If it broke, users saw errors, and the data scientist had to scramble to roll back. CI/CD automates the entire chain, ensuring every model is built from the same tested code, evaluated consistently, and deployed without manual steps.
For the MLA-C01 exam, you must understand the lifecycle: source -> build -> train -> evaluate -> deploy. You must also know that CodePipeline triggers on changes to your repository, and that SageMaker provides the compute for training and hosting. The exam will ask you to pick the correct combination of services for a given scenario—for example, 'Which service runs the unit tests?' Answer: CodeBuild. Or 'Which service hosts the trained model?' Answer: SageMaker.
Source: Code Commit
A developer pushes updated training code, data processing scripts, or model definition files to a Git repository (CodeCommit or GitHub). This push event triggers the CI/CD pipeline to start.
Build: CodeBuild
CodeBuild reads the buildspec.yml file from the repository. It installs dependencies (e.g., Python libraries), runs unit tests on the data cleaning code, and packages the training code into a Docker container image stored in Amazon ECR.
Train: SageMaker Training Job
CodePipeline passes the container image and training data location to SageMaker. SageMaker provisions computing resources (e.g., an ML instance), runs the training job, and outputs a trained model file to an S3 bucket.
Evaluate: Performance Check
A CodeBuild project or SageMaker Processing job loads the trained model and runs it against a held-out test dataset. It checks a specific metric (e.g., accuracy > 90%). If the metric fails, the pipeline stops and alerts the team.
Deploy: SageMaker Endpoint
The approved model is deployed to a SageMaker endpoint. The pipeline updates the endpoint configuration to point to the new model version. You can use blue/green deployment to shift traffic gradually while monitoring for errors.
Imagine you work for a company called 'FitWear', a clothing retailer that uses a machine learning model to recommend outfits to customers. Currently, a data scientist named Priya trains the recommendation model once every three months. She downloads the latest sales data to her laptop, spends two days cleaning it, trains a new model, uploads the model file to an EC2 server, and manually copies it into the production folder. One time she accidentally uploaded the wrong file, and customers saw completely irrelevant recommendations for a full weekend before she fixed it.
The company asks you to set up CI/CD for this ML model so updates happen automatically and safely. Here is what you, as an IT professional, actually do:
You create a source repository in AWS CodeCommit. You move all the training scripts, data cleaning code, and evaluation code into this repository.
You write a buildspec.yml file for CodeBuild. This file specifies: install Python packages from requirements.txt, run unit tests on the data cleaning function, and if tests pass, build a Docker container image using a Dockerfile provided by Priya.
You configure CodePipeline with three stages: Source (CodeCommit), Build (CodeBuild), and Deploy (SageMaker). You set the pipeline to trigger automatically whenever Priya pushes new code to the 'main' branch.
In the Deploy stage, you tell CodePipeline to call SageMaker to start a training job. You pass in the container image from the Build stage, the training data location in S3, and an output S3 path for the model.
After training, you add a fourth stage called 'Evaluate'. A second CodeBuild project runs a script that loads the new model and tests it against a sample of last month's sales data. The script checks if the model's recommendation click-through rate is above 5 percent. If it is below, the pipeline fails and notifies Priya via email.
Finally, the pipeline deploys the model to a SageMaker endpoint. You set up the endpoint with two variants: the old model at 90% traffic and the new model at 10% traffic. After one day of monitoring, if the new model performs well, you shift all traffic to the new model.
Now, when Priya updates the recommendation algorithm and pushes her code, the pipeline runs automatically overnight. She wakes up to an email saying the model passed evaluation and is live. No manual file copying, no frantic weekend fixes. The IT professional's job shifts from manually deploying to designing, maintaining, and monitoring this automated pipeline.
The MLA-C01 exam tests your ability to design CI/CD pipelines for ML using AWS services. You will not be asked to write YAML files, but you will need to know which service does what and how they fit together. Here are the exact topics the exam focuses on:
Service roles: CodePipeline is the orchestrator (triggers, manages stages). CodeBuild executes commands (runs tests, builds containers). SageMaker trains and hosts models. You must never confuse these.
Source triggers: The exam loves to ask what triggers a pipeline. Answer: a change to the source code repository (e.g., a commit to CodeCommit or a push to a GitHub branch). They might include 'time-based triggers' as a distractor—those are not standard for CI/CD.
Model evaluation gates: A common exam scenario shows a pipeline that deploys a bad model because no evaluation step was included. The correct answer is to add an evaluation stage using CodeBuild or a SageMaker processing job that checks a metric like accuracy or Mean Squared Error (MSE) before deployment.
Deployment strategies: The exam tests blue/green deployment (running two versions simultaneously to compare) and canary deployment (gradually shifting traffic). Know that SageMaker endpoints support both.
Rollback: If a deployed model performs poorly, the correct action is to update the endpoint configuration to point back to the previous model version. This is not automatic—you must design the pipeline to keep the previous model endpoint running or to store model versions in S3.
Traps to avoid:
The exam sometimes offers 'AWS Lambda' as an option for running training code. Lambda has a 15-minute timeout and limited memory—not suitable for ML training. SageMaker is the correct choice.
They may list 'AWS CloudFormation' as a way to deploy models. CloudFormation manages infrastructure (servers, networks), not model deployment directly. Use SageMaker endpoints.
They may suggest 'manual approval' as the only evaluation step. Manual approval is fine for governance, but the exam expects automated evaluation for CI/CD.
Key definitions to memorise: - buildspec.yml: The YAML configuration file that tells CodeBuild what commands to run. - SageMaker endpoint: A live web service that serves predictions from a trained model. - Blue/green deployment: Two identical environments; traffic shifts from the old (blue) to the new (green) version. - Container image: A packaged environment with code and dependencies, stored in Amazon ECR.
CI/CD stands for Continuous Integration and Continuous Delivery, and for ML it automates the process from code commit to model deployment.
CodePipeline is the orchestrator that triggers on source code changes and moves work through stages like build, train, and deploy.
CodeBuild executes commands defined in a buildspec.yml file, including running tests and building Docker container images.
SageMaker is the AWS service that trains ML models, hosts them as endpoints, and supports blue/green and canary deployment strategies.
A model evaluation gate—automated and before deployment—prevents underperforming models from reaching production.
Data drift and concept drift mean ML models must be periodically retrained; CI/CD pipelines should include a scheduled retraining trigger.
Blue/green deployment runs two model versions simultaneously, allowing you to switch traffic gradually and roll back instantly if the new model fails.
These come up on the exam all the time. Here's how to tell them apart.
CodePipeline
Orchestrates the overall workflow across multiple stages
Triggers automatically on source code changes or schedule
Does not run commands or build artifacts itself
CodeBuild
Executes specific build commands defined in buildspec.yml
Compiles code, runs tests, and builds container images
Does not manage stages or coordinate other services
SageMaker Training Job
Runs the model training process using provided data and code
Produces a trained model artifact saved to S3
Is a temporary compute resource that terminates after training
SageMaker Endpoint
Hosts a trained model as a live web service for predictions
Consumes the model artifact from S3 and exposes an API
Is a persistent resource that stays running until deleted
Blue/Green Deployment
Two identical environments run the old and new model versions
Traffic is switched instantly from one version to the other
Simpler to roll back but can cause sudden traffic spikes
Canary Deployment
A small percentage of traffic is routed to the new model first
Traffic is gradually increased to the new model over time
Safer for high-traffic systems but takes longer to complete
Mistake
CI/CD for ML is exactly the same as CI/CD for regular software, just with data instead of code.
Correct
CI/CD for ML has extra steps: data versioning, model training, model evaluation, and model registry. Data can change independently of code, so the pipeline must handle both.
Beginners assume all CI/CD pipelines are identical because the core concepts (source, build, deploy) sound the same. They overlook the unique ML challenges of data drift and model retraining.
Mistake
CodePipeline can train the model directly without needing SageMaker.
Correct
CodePipeline is a workflow orchestrator—it cannot run ML training itself. It delegates training to SageMaker, which provides the necessary compute and libraries.
People see 'pipeline' and think CodePipeline does all the work, but it is just a coordinator. The exam tests this distinction explicitly.
Mistake
Once a model is deployed via CI/CD, you never need to touch it again.
Correct
Models degrade over time due to data drift (changes in real-world data). CI/CD pipelines are designed to retrain and redeploy models on a schedule or when new data arrives.
Beginners hear 'automated' and assume it is 'set and forget'. In reality, ML models require ongoing monitoring and retraining cycles.
Mistake
The evaluation stage is optional and only for 'nice-to-have' quality checks.
Correct
The evaluation stage is critical. In the exam, if a scenario describes a model being deployed that has poor performance, the missing piece is always an automated evaluation gate before deployment.
Newcomers underestimate how often a model can fail silently. They think training always produces a usable model, but bugs in data processing or hyperparameter choices can create garbage.
Mistake
You must use CodeCommit as the source for your CI/CD pipeline.
Correct
CodePipeline supports multiple source providers: CodeCommit, GitHub, GitHub Enterprise, Bitbucket, and Amazon S3. The exam expects you to know this flexibility.
AWS documentation often uses CodeCommit in examples, but beginners assume it is mandatory. The exam tests that you can choose the right source for a given business scenario.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. You do not need to write YAML files. You do need to understand what a buildspec.yml file is used for (defining build commands in CodeBuild).
No. Lambda has a 15-minute runtime limit and limited memory, making it unsuitable for training. SageMaker is the correct service for training ML models.
The pipeline stops and sends an alert (e.g., via Amazon SNS notification). The old model remains in production. You must fix the code or data issue and push a new commit to retrigger the pipeline.
It can do both. You can set the pipeline to trigger on a schedule (e.g., every week) or when new training data arrives in an S3 bucket. This allows automatic retraining of models to adapt to new data.
A model registry stores metadata about each trained model version, such as training date, evaluation metrics, and the S3 path to the model artifact. It is used in the deploy stage to track which model is currently in production.
Yes. The exam may present a scenario requiring a manual approval gate before production deployment (e.g., for compliance). CodePipeline has a 'Manual Approval' stage action that pauses the pipeline until a reviewer approves.
You've finished CI/CD for Machine Learning: Automating Model Deployment. Continue through the MLA-C01 study guide to build a complete picture of the exam.
Done with this chapter?