SageMaker Model Registry for Least Overhead
Case Study A company is building a web-based AI application by using Amazon SageMaker. The application will provide the following capabilities and features: ML experimentation, training, a central model registry, model deployment, and model monitoring. The application must ensure secure and isolated use of training data during the ML lifecycle. The training data is stored in Amazon S3. The company needs to use the central model registry to manage different versions of models in the application. Which action will meet this requirement with the LEAST operational overhead?
Community Insight
This tests knowledge of AWS ML lifecycle tools; the trap is choosing ECR or manual tagging instead of the dedicated Model Registry which handles versioning automatically via Model Groups.
The question asks for the method to manage model versions with minimal operational overhead in Amazon SageMaker. The page establishes that using SageMaker Model Registry with model groups is the correct, native solution compared to external registries.
Learners often choose ECR (Options A or B) because they associate container registries with storage, ignoring that SageMaker has a specific service for model metadata and governance.
Community Discussion (12 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option C is correct because the Amazon SageMaker Model Registry is specifically designed for cataloging, organizing, and tracking machine learning models. By using Model Groups (also known as Model Package Groups), you can organize related models and automatically track their versions without writing custom code or managing external databases. This aligns perfectly with the requirement for the "LEAST operational overhead" as it leverages managed services.Why the Other Options Are Wrong
Options A and B suggest using Amazon Elastic Container Registry (ECR). While ECR stores Docker images, it does not provide the semantic metadata, approval workflows, or lineage tracking required for ML model management. Managing model versions via tags in ECR would require significant custom logic and operational overhead. Option D suggests using unique tags within the registry, but Model Groups are the standard mechanism for organizing and versioning models in SageMaker, making Option C more precise and operationally efficient than ad-hoc tagging.Community Comment Notes
Community consensus strongly supports Option C. As GiorgioGss noted, "Each model package in a Model Group corresponds to a trained model... versions will be 1, 2, 3," highlighting the built-in versioning capability. Another commenter, khchan123, emphasized that "SageMaker Model Registry is specifically designed for managing ML models," confirming its role as the primary tool for this task. Laxma99 also pointed out that this approach "integrates seamlessly with other SageMaker components," reducing complexity.Official Reference
Exam Strategy
When asked about managing ML models, training artifacts, or model governance in AWS, always look for SageMaker-specific services like the Model Registry first. Avoid generic infrastructure services like S3 or ECR unless the question explicitly asks for raw artifact storage rather than metadata management.
Frequently Asked Questions
Why not use ECR for storing model versions?
ECR stores container images, not ML model metadata. It lacks built-in versioning, approval workflows, and lineage tracking provided by the SageMaker Model Registry.
What is the difference between Model Groups and Tags?
Model Groups (Model Package Groups) are a structured way to organize related models and automatically increment version numbers. Tags are simple key-value pairs and do not provide the same organizational or versioning structure.
Related Analysis
Practice All MLA-C01 Questions
Access 115 questions with complete answers and detailed explanations.
View Full MLA-C01 Practice Test →