What is the SageMaker Model Registry and how does it support a governed release process?

Updated Aug 1, 2026

Short answer

The Model Registry versions models into model package groups with metadata, metrics and lineage, and carries an approval status that deployment automation keys off — separating 'a model was trained' from 'a model is approved for production'.

Deep explanation

Without a registry, deployment tends to mean "someone points at an S3 path", which leaves no record of what is running, why it was chosen, or who approved it. The registry makes the model a first-class governed artefact.

Structure: a model package group (e.g. fraud-models) contains ordered model package versions. Each version records the artefact URI, the inference image, supported instance types, evaluation metrics, bias and explainability reports, and an approval status of PendingManualApproval, Approved or Rejected.

Python

1from sagemaker.model_metrics import ModelMetrics, MetricsSource
2
3model_metrics = ModelMetrics(
4    model_statistics=MetricsSource(
5        s3_uri="s3://my-bucket/eval/evaluation.json", content_type="application/json"),
6    bias=MetricsSource(
7        s3_uri="s3://my-bucket/clarify/bias.json", content_type="application/json"),
8    explainability=MetricsSource(
9        s3_uri="s3://my-bucket/clarify/shap.json", content_type="application/json"),
10)
11
12model_package = estimator.register(
13    model_package_group_name="fraud-models",
14    content_types=["application/json"], response_types=["application/json"],
15    inference_instances=["ml.m5.xlarge", "ml.c5.xlarge"],
16    transform_instances=["ml.m5.4xlarge"],
17    model_metrics=model_metrics,
18    approval_status="PendingManualApproval",   # nothing auto-deploys
19    customer_metadata_properties={
20        "training_data_window": "2026-01-01/2026-06-30",
21        "git_commit": "9f3ac21",
22        "owner": "fraud-ml",
23    },
24)

Approval then becomes the deployment trigger:

Python

1sm.update_model_package(
2    ModelPackageArn=arn,
3    ModelApprovalStatus="Approved",
4    ApprovalDescription="Risk review 2026-07-14; AUC 0.842, DPPL within tolerance",
5)

An EventBridge rule listens for the state change and starts the deployment pipeline:

JSON

1{
2  "source": ["aws.sagemaker"],
3  "detail-type": ["SageMaker Model Package State Change"],
4  "detail": {
5    "ModelPackageGroupName": ["fraud-models"],
6    "ModelApprovalStatus": ["Approved"]
7  }
8}

This gives you the property auditors ask for: nothing reaches production without a recorded, attributable approval, and every deployed version traces back to its training job, data and metrics.

Real-world example

An insurer under model-risk regulation registers every candidate with metrics, a Clarify bias report and a model card. A validator reviews and approves in the registry; only then does automation deploy. When a regulator asks which model scored a policy in March and who signed it off, the answer is a registry lookup plus a CloudTrail entry, not an archaeology exercise across notebooks.

Common mistakes

- Registering models with no metrics attached, leaving reviewers nothing to judge.
- Auto-approving at registration, which reduces the registry to a filing cabinet and defeats the control.
- Deploying from `estimator.deploy()` in a notebook, bypassing the registry entirely.
- Using one group for unrelated models
a group should represent one model's lineage over time so versions are comparable.
- Not recording the git commit and data window, so a version cannot be reproduced later.

Follow-up questions

How do you roll back to a previous model version?
What is a SageMaker Model Card and how does it relate to the registry?
How do you promote a model across accounts?

Short answer

Deep explanation

Real-world example

Common mistakes

Follow-up questions

More AWS Machine Learning interview questions