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 mod

Question

Options

• AUse SageMaker Experiments to facilitate the approval process during model registration.
• BUse SageMaker ML Lineage Tracking on the central model registry. Create tracking entities for
• CUse SageMaker Model Monitor to evaluate the performance of the model and to manage the
• DUse SageMaker Pipelines. When a model version is registered, use the AWS SDK to change the

• A
  2% (1)
• B
  7% (3)
• C
  12% (5)
• D
  79% (33)

Explanation

Option D is correct because SageMaker Pipelines integrates natively with the SageMaker Model Registry, which supports a model approval status workflow (Pending, Approved, Rejected). When a model version is registered, you can use the AWS SDK (update_model_package) to change its approval status to Approved - and configure production endpoints to only deploy models with that approved status, enforcing the manual gate.

Option A is wrong because SageMaker Experiments is designed for tracking and comparing ML runs (metrics, parameters, artifacts) - it has no approval workflow capability.

Option B is wrong because ML Lineage Tracking records the history and provenance of ML artifacts (who used what data/code/model), but it cannot gate or block deployments based on approval status.

Option C is wrong because SageMaker Model Monitor watches already-deployed models for drift and quality degradation - it operates post-deployment, not as a pre-deployment approval mechanism.

Memory tip: Think of the SageMaker services by lifecycle stage - Experiments (track), Lineage (trace history), Pipelines + Model Registry (orchestrate + approve), Model Monitor (watch live). The only service with a built-in approval status field that can block deployment is the Model Registry, which is managed through Pipelines.

No community discussion yet for this question.