3.2.5. Model Versioning with SageMaker Model Registry
💡 First Principle: In production ML, you'll train dozens or hundreds of model versions. Without systematic versioning, you can't answer basic operational questions: "Which model is currently serving traffic?" "Which dataset was it trained on?" "What were its evaluation metrics?" SageMaker Model Registry provides these answers—and the exam tests your understanding of its workflow.
Model Registry organizes models into Model Groups (a collection of related model versions, like "fraud-detection-model") and Model Versions (specific trained instances within a group, like v1, v2, v3). Each version tracks:
- Model artifact location (S3 path)
- Training job metadata
- Evaluation metrics
- Approval status (PendingApproval, Approved, Rejected)
- Deployment history
Approval workflows are a key exam topic. In production, a newly trained model shouldn't deploy automatically—it should be reviewed. Model Registry supports status transitions (Pending → Approved → Deployed) that can integrate with CI/CD pipelines. A SageMaker Pipeline can train a model, register it as Pending, and an EventBridge rule can notify a human approver. Only Approved models get deployed.
⚠️ Exam Trap: Model Registry is not the same as SageMaker Experiments. Experiments tracks training runs (hyperparameters, metrics per epoch, comparison charts). Model Registry tracks model artifacts (versioning, approval, deployment). A question about "comparing different training runs" points to Experiments. A question about "managing which model version is in production" points to Model Registry.
Reflection Question: A team has three model versions in the Registry: v1 (deployed, accuracy 88%), v2 (approved, accuracy 91%), and v3 (pending, accuracy 90%). Describe the deployment workflow to move v2 to production and what happens to v1.
