AWS ML Engineer Associate Prep Series — Part 6

MLOps and Automation: SageMaker Pipelines, Model Registry, CI/CD Patterns, Approval Gates, and Reproducibility

Part 5 covered feature engineering — Data Wrangler, Feature Store, and point-in-time correctness. If you've been following along, you can now build features consistently and share them between training and inference.

But there's a gap between "a data scientist can train a good model" and "an organization can deliver a good model to production, repeatedly, without someone manually clicking through the console." That gap is MLOps — and it's where the MLA-C01 exam starts testing your engineering judgment rather than your algorithm knowledge.

The AWS Well-Architected ML Lens sums up the objective in one line: "Automate operations through MLOps and CI/CD." The exam scenarios ask you to connect the ML-specific building blocks (Pipelines, Model Registry, Experiments, Lineage) with the general-purpose AWS CI/CD stack (CodeCommit, CodeBuild, CodeDeploy, CodePipeline) and decide which combination fits the workflow described.

This post covers six tightly connected topics: SageMaker Pipelines, the Model Registry, approval gates and promotion workflows, the AWS CI/CD stack, containers and orchestration (Kubeflow/ECS/ECR vs SageMaker native), and the reproducibility controls that make all of it trustworthy.

1) SageMaker Pipelines: The DAG Backbone of MLOps

SageMaker Pipelines is a purpose-built CI/CD service for machine learning workflows. It lets you define an ML workflow as a directed acyclic graph (DAG) where each node is a step, and then execute that workflow automatically, repeatably, and with full tracking.

The steps

Every pipeline is a chain of step objects. The ones the exam cares about:

Parameters: one pipeline, many runs

A pipeline isn't a hard-coded script. You define parameters — ParameterString, ParameterInteger, ParameterFloat — that are passed in at execution time. The same pipeline definition can run this week with dataset A and next week with dataset B, or the same data with different hyperparameters. This is what makes the pipeline reusable instead of throwaway glue code.

Why the exam cares

Two Well-Architected objectives keep pointing at Pipelines:

• "Establish a model performance evaluation pipeline — SageMaker Pipelines, Model Registry"
• "Enable CI/CD/CT automation with traceability"

Pipelines give you traceability for free: every execution records what ran, on what data, with what parameters, and what artifacts it produced. That's the "T" — continuous training — as well as CI/CD. When a scenario mentions automatic retraining, or a workflow that must run the same steps every time new data arrives, SageMaker Pipelines is the mechanism.

Quick gut check: A team retrains a churn model weekly. Today the data scientist manually runs a processing job, then a training job, then checks the metric in the notebook before updating the endpoint. What's the fix? — SageMaker Pipelines. Define processing → training → evaluation → condition steps in a DAG, parameterize the dataset path and hyperparameters, and trigger it on a schedule or on new data arriving in S3. Every run is tracked, reproducible, and requires no manual handoffs.

2) SageMaker Model Registry: Versioning and Governance

If Pipelines is the assembly line, the Model Registry is the warehouse with the inventory system. It's where trained models get cataloged, versioned, and governed.

What it does:

Model vs model package vs model group

Getting these three straight is worth points:

• A model is the trained artifact — the S3 model files plus the inference container reference.
• A model group is a logical container for related versions, e.g., churn-xgboost.
• A model package is a versioned entry inside a model group — one model group holds many model packages, each carrying its own metadata and approval status.

The exam likes "versioned entry with metadata and approval status" as the correct description of a model package, versus a bare model that's just an artifact.

The canonical flow

The slides show the standard pattern as a four-step loop:

1. Create a Model Group — the home for all versions of this model
2. Create a SageMaker Pipeline — the training/evaluation workflow that produces models
3. Register model versions from each run — every pipeline execution that trains a model registers it (via the RegisterModel step)
4. Add the model group to Model Registry Collections — a curated set of model groups (e.g., "production candidates") that reviewers and CI/CD can act on

The result: every training run — successful or not — leaves a versioned, metadata-rich record. No more "which artifact is this endpoint actually serving?" archaeology.

Quick gut check: A team trains XGBoost weekly and keeps model files in an S3 folder named model_v9_final_FINAL. Nobody knows which version is deployed, and rollback means re-downloading an old file. What's the fix? — Model Registry. Create a model group for the churn model, register a new model package from every pipeline run with the evaluation metrics attached, and track approval status per version. Deployment and rollback become selecting an Approved model package instead of hunting through S3.

3) Approval Gates and Promotion Workflows

The Registry manages approval status — but the exam wants to know how models actually move from "trained" to "in production" without a human babysitting every step.

Automatic gates: the Condition step

The simplest approval gate is a ConditionStep inside the pipeline. After evaluation, compare the test metric to a threshold:

• If the evaluation step reports MSE < 0.05 (or accuracy above target), the pipeline branches to RegisterModel and registers the model with a Pending or Approved status.
• If not, the pipeline stops or notifies — no model version gets registered, no deployment happens.

This is the pattern for "evaluate and only register if it meets the bar." The threshold is a parameter, so it's easy to tune per model group.

Human gates: approval with intervention

Not everything should be automatic. For high-stakes models, AWS's reference workflow — the Model Registry approval and promotion workflow with human intervention — inserts a human in the loop:

1. Pipeline trains and registers a model package (status: Pending)
2. A notification goes out — via SNS, a SageMaker Studio task, or an EventBridge rule — to a reviewer
3. The reviewer inspects the model package: metrics, lineage, training config, sample predictions
4. The reviewer approves or rejects the package in the Model Registry
5. On approval, a deployment pipeline (CodePipeline, or a second SageMaker Pipeline) promotes the model to staging, then production

The key insight: approval status is the control point. Pipelines and CI/CD watch the status and act on it — nothing deploys until the status flips to Approved. That separation of "who may approve" from "what gets deployed" is the governance model the exam tests.

Quick gut check: A medical diagnostics model must be reviewed by a senior ML engineer before it can serve traffic, but review shouldn't slow down the weekly retraining cadence. — Keep the training pipeline fully automatic, but have it register each new version with Pending status and notify the reviewer. Promotion to the production endpoint is a separate automated pipeline that only proceeds when the model package's approval status is Approved. Human judgment gates the rollout; automation handles everything else.

4) AWS CI/CD: CodePipeline, CodeBuild, and CodeDeploy

SageMaker gives you ML-specific automation, but the exam also expects you to know the general-purpose CI/CD stack it plugs into — because real MLOps systems use both.

CodePipeline: the orchestration layer

CodePipeline orchestrates the stages of shipping software: Code → Build → Test → Provision → Deploy. It's fully managed and plugs into CodeCommit, CodeBuild, CodeDeploy, Elastic Beanstalk, CloudFormation, GitHub, and third-party tools and custom plugins.

The classic MLOps pattern: a push to a code repository triggers a pipeline whose stages run CodeBuild (build the training/inference container, run unit tests on the training code), then invoke a SageMaker training job or pipeline, then deploy the model via a SageMaker action or CodeDeploy.

CodeBuild: the builder

CodeBuild compiles source code, runs tests, and produces artifacts ready to be deployed — for example, a Docker image pushed to ECR. It's fully managed and serverless (no build servers to maintain), continuously scalable, and pay-as-you-go: you pay only for build time.

CodeDeploy: the deployer

CodeDeploy automates application deployment to EC2 instances and on-premises servers — it's explicitly a hybrid service. Servers must be pre-provisioned with the CodeDeploy Agent, which pulls and applies new versions. This is how you'd update the application that wraps your endpoint, or the instances that run inference outside SageMaker's managed endpoints.

SageMaker Projects: the all-in-one

If you don't want to assemble CodePipeline from parts, SageMaker Projects is Studio's native MLOps solution with CI/CD built in. A project wires together code repositories, SageMaker Pipelines, and deployment infrastructure so the whole lifecycle — build images, prep data and features, train, evaluate, deploy, monitor, update — is automated from day one. The slides describe it as the native path: "Uses code repositories for building & deploying ML solutions; uses SageMaker Pipelines defining steps."

Quick gut check: A team wants a push-to-main trigger that builds their training container, runs tests, launches a SageMaker training pipeline, and deploys the approved model to staging — with everything versioned in git. CodePipeline alone, SageMaker Projects, or CodeDeploy? — SageMaker Projects (or CodePipeline orchestrating CodeBuild + SageMaker actions). CodeDeploy is for deploying to EC2/on-prem servers, not for orchestrating the ML build-test-deploy flow. Projects give you the repo + pipeline + deploy wiring natively in Studio.

5) Containers and Orchestration: Kubeflow, ECS/ECR vs SageMaker Native

MLOps runs on containers, and the exam expects you to know where containers live and who orchestrates them — and when to use the general-purpose stack instead of SageMaker-native tooling.

ECR: where images live

Amazon ECR is the private container registry — the counterpart to Docker Hub. It's the secure home for your training and inference images: build once, push, and reference the URI from SageMaker jobs, ECS, or EKS. ECR also has a public gallery. If a scenario mentions "consistent, versioned container images for training," ECR is the store — and the Well-Architected Lens explicitly lists "reliable packaging patterns to access approved public libraries — ECR, CodeArtifact."

ECS: where containers run

ECS is Amazon's own container platform. Two launch types to know:

• EC2 launch type: you provision and maintain the EC2 instances. Each instance runs the ECS Agent to register with the cluster; AWS starts and stops containers on them.
• Fargate launch type: serverless. You define task definitions (CPU/RAM), AWS runs the tasks, and you scale by adding tasks. No instances to manage.

Supporting details that show up in scenarios: the EC2 Instance Profile lets the ECS agent pull images from ECR and push logs to CloudWatch; the Task Role gives each task its own IAM identity; the Application Load Balancer is the default load balancer for most workloads (NLB only for high throughput or PrivateLink); and EFS volumes give containers shared multi-AZ persistent storage (Fargate + EFS = serverless with persistent data).

Kubeflow: hybrid ML platforms

SageMaker also integrates with Kubernetes-based ML infrastructure. SageMaker Components for Kubeflow Pipelines let you run SageMaker jobs — training, tuning, transform — as steps inside a Kubeflow pipeline. This matters for two scenario types:

• Teams that already run ML platforms on Kubernetes or Kubeflow
• Hybrid workflows: on-premises Kubernetes plus cloud bursting to SageMaker

The comparison

Quick gut check: A company runs Kubeflow on Kubernetes in its own data center and wants to burst training jobs to AWS during peaks, reusing the same pipelines. Replace everything with SageMaker Projects, or integrate? — Integrate with SageMaker Components for Kubeflow Pipelines. It brings SageMaker training and tuning jobs into the existing Kubeflow DAGs, enabling hybrid on-prem + cloud workflows without rebuilding the platform. SageMaker Projects would be the choice for a greenfield, all-in-AWS team.

6) Event-Driven Automation: EventBridge and MWAA

Pipelines don't run themselves. Something has to start them — and the exam expects you to know the trigger mechanisms.

Amazon EventBridge

EventBridge (formerly CloudWatch Events) connects events to actions:

• Schedule rules: cron expressions that trigger a pipeline, Lambda, or Batch job on a timer — e.g., "retrain every Sunday at 2 AM."
• Event pattern rules: react to service events — an S3 object upload (new training data!), a failed CodeBuild job, a CloudTrail API call. This is how "new data arrives → retrain" becomes automatic.

Event sources include EC2 state changes, S3 events, CodeBuild results, Trusted Advisor findings, and CloudTrail. Destinations include Lambda, AWS Batch, ECS tasks, SQS, SNS, Kinesis, Step Functions, CodePipeline, CodeBuild, and SSM. Buses (default, partner, custom) support cross-account resource-based policies, event archiving, and replay.

Amazon MWAA (managed Airflow)

MWAA is a managed Apache Airflow service. Airflow is a batch-oriented workflow tool: workflows are Python code defining a DAG of tasks. MWAA handles the infrastructure — you upload DAGs (zipped with plugins and requirements) to S3, and MWAA picks them up, schedules them, and runs them.

Two facts matter for scenarios:

• Workers and schedulers run as AWS Fargate containers, autoscaling within limits you set, inside your VPC across at least two AZs.
• It integrates broadly — Athena, Batch, EMR, Glue, Lambda, Redshift, S3, and SageMaker — making it a favorite for complex ETL coordination and ML data preparation workflows.

Pipelines vs MWAA: the decision rule

Quick gut check: A data platform team needs a workflow that pulls data from Redshift, runs Glue jobs, then triggers a SageMaker training job — using the team's existing Airflow experience. SageMaker Pipelines or MWAA? — MWAA. The workflow spans multiple AWS services beyond ML, and the team already knows Airflow. SageMaker Pipelines would fit a workflow that's primarily SageMaker steps; MWAA's SageMaker operators handle the cross-service case cleanly.

7) Reproducibility, Lineage, and Continuous Training

Automation is only as valuable as your ability to answer three questions about any model in production: what data trained it, how was it trained, and why is this version the one serving traffic?

SageMaker Experiments

Experiments let you organize, capture, compare, and search your ML jobs. Every run records parameters, metrics, and artifacts — so comparing 50 hyperparameter trials (or auditing one) is a lookup, not a forensic exercise. The Lens lists Experiments among "model improvement strategies" alongside HPO and AutoML, and as the tool for "optimize training and inference instance types."

Lineage tracking

SageMaker ML Lineage Tracking records the relationships between artifacts — dataset → processing job → training job → model → endpoint. Together with Pipelines, Studio, Feature Store, and Model Registry, it's the Lens's recommended "lineage tracker system." When a scenario asks how to prove which data produced a given model, or to audit a model after an incident, lineage tracking is the answer.

Version control discipline

The Lens is explicit: "Create tracking and version control mechanisms — SageMaker Model Registry, store notebooks in git, SageMaker Experiments." Notebooks in git, containers in ECR, models in the Registry, features in the Feature Store — every layer of the stack has a versioned home.

Rollback and continuous training

Two more Lens patterns round out the picture:

• Rollback: "Protect against data poisoning threats — SageMaker Clarify, rollback with SageMaker Model Registry & Feature Store." Because every deployment is a versioned model package fed by point-in-time-correct features (Part 5), rolling back is re-deploying the previous Approved version.
• Continuous training (CT): "Establish an automated re-training framework — SageMaker Pipelines" and "Retrain only when necessary — Model Monitor, Pipelines." Pipelines make CT a scheduled or event-triggered pipeline run; Model Monitor (Part 7) decides when retraining is actually warranted.

Quick gut check: An auditor asks which training data and which hyperparameters produced the model currently serving production. — SageMaker Lineage Tracking plus Model Registry metadata. Lineage walks artifact-to-artifact (dataset → job → model → endpoint), and the registered model package carries the training config and metrics as metadata. Experiments covers the comparison view; the Registry + Lineage cover the audit trail.

Putting It All Together

Here's how the pieces fit in a realistic MLOps workflow:

A team stores training code in a git repository (CodeCommit). A push to main triggers a SageMaker Project — or a CodePipeline — whose stages build the container with CodeBuild and push it to ECR.

An EventBridge rule fires when new customer data lands in S3 (event pattern) — and a weekly cron also fires the same SageMaker Pipeline. The pipeline runs processing, training, and evaluation steps; a ConditionStep compares the evaluation metric to a threshold. Models that pass are registered in the Model Registry with metadata (metrics, lineage, config) and Pending status.

A reviewer gets an SNS notification, inspects the model package in Studio, and approves it. The deployment pipeline detects the Approved status and promotes the model to a staging endpoint, then to production using the canary rollout from Part 4. Every artifact — code, container, features, model, config — is versioned, so rollback means selecting the previous Approved model package, and any audit question can be answered from lineage tracking.

When the model drifts, Model Monitor (Part 7) detects it and triggers the same pipeline to retrain — continuous training with traceability, all the way down.

What to remember for the exam

1. SageMaker Pipelines is the ML-specific CI/CD backbone: a DAG of steps (Processing, Training, Tuning, Condition, RegisterModel, CreateModel, Transform) with parameters for reusability. It covers CI, CD, and CT — any scenario about automatic, traceable retraining points at Pipelines.
2. The Model Registry is versioning + governance: model (artifact) vs model group (logical container) vs model package (versioned entry with metadata and approval status). Register from every pipeline run via RegisterModel, and let approval status be the control point for deployment. Rollback = re-deploying a previous Approved package.
3. Approval gates come in two flavors: automatic (ConditionStep threshold on evaluation metrics) and human (Pending → review → Approved/Rejected, with notification via SNS/EventBridge and promotion only on approval). High-stakes models keep the human gate; routine models automate it.
4. The general CI/CD stack plugs into SageMaker: CodePipeline orchestrates (Code → Build → Test → Provision → Deploy), CodeBuild builds (pay per build time), CodeDeploy deploys to EC2/on-prem with the agent. SageMaker Projects bundles all of this natively in Studio.
5. Reproducibility is a stack property, not a feature: git for notebooks, ECR for containers, Registry for models, Lineage Tracking for artifact relationships, Experiments for capture/compare/search. And for orchestration choices: ECS/ECR and Kubeflow Components for hybrid/container-native teams, EventBridge for event triggers, MWAA for complex multi-service DAGs.

Practice questions

Work through these before Part 7. The goal is to reason through the trade-off.

1. A team retrains a fraud model every night with a script that runs preprocessing, training, and a manual accuracy check in a notebook. Recently a run with bad data was deployed by accident. What two changes give them traceability and an automatic quality bar? — Replace the manual flow with a SageMaker Pipeline containing Processing, Training, Evaluation, and a ConditionStep that only registers the model (via RegisterModel) when accuracy exceeds the threshold. Store all code in git, register model packages with metadata, and use Lineage Tracking so every deployed version maps back to its dataset, job, and parameters.

2. A pipeline evaluates a new loan-default model and finds test AUC below the required 0.90. What happens in a properly gated pipeline, and what happens if the gate is missing? — With the gate, the ConditionStep fails the run, no model package is registered (or it's registered as Rejected), and nobody is notified of a new candidate. Without the gate, the model still gets registered and could be deployed to production despite failing the quality bar — the exact failure mode that audits catch.

3. A healthcare team's compliance policy requires a senior ML engineer to manually review every model version before production traffic. The weekly retraining pipeline should keep running unattended. What's the design? — The pipeline registers each new version with Pending status and notifies the reviewer via SNS/SageMaker Studio. Promotion to production is a separate automated pipeline that deploys only when the model package's approval status is Approved. Automation handles everything except the review decision.

4. A company runs all ML training in a Kubernetes platform on-premises and wants to burst to AWS during peak demand without rebuilding their workflow tooling. SageMaker Projects, SageMaker Components for Kubeflow Pipelines, or a new CodePipeline? — SageMaker Components for Kubeflow Pipelines. It adds SageMaker training, tuning, and transform jobs as steps inside the existing Kubeflow DAGs, enabling hybrid on-prem + cloud workflows. SageMaker Projects and CodePipeline would mean rebuilding around AWS-native tooling, discarding the existing platform investment.

5. A data engineering team needs to coordinate a nightly workflow: query Redshift, run Glue transforms, then trigger a SageMaker training job — and they already write Airflow DAGs today. Should they move to SageMaker Pipelines? — No — use Amazon MWAA. The workflow spans multiple services (Redshift, Glue, SageMaker), which is exactly MWAA's strength, and the team's existing Airflow DAGs port directly. SageMaker Pipelines is the better fit when the workflow is primarily SageMaker steps; MWAA's SageMaker operators handle the mixed case with less rework.

Closing

MLOps is where machine learning stops being a science experiment and becomes an engineering discipline. The exam rewards you for knowing which automation layer does what: SageMaker Pipelines for ML workflows, Model Registry for governance, CodePipeline/CodeBuild/CodeDeploy for the general CI/CD flow, EventBridge and MWAA for triggers and orchestration, and Lineage/Experiments for the audit trail that makes automation trustworthy.

Once you can trace a model from a git push, through build, pipeline, evaluation, approval, and deployment — and prove at every step what happened — you've got this domain locked down.

Part 7 will cover Monitoring, Drift, and Retraining — SageMaker Model Monitor, data and model quality baselines, drift detection, alerting, and human-in-the-loop checks.