MLA-C01 Deployment and Orchestration of ML Workflows Practice Question

An ML platform team must orchestrate a workflow that trains a model, evaluates it against a baseline, and only registers the model if evaluation passes. If evaluation fails, the workflow must notify the data science channel and stop without registering. The team wants the orchestration logic to be expressed as code, versioned in git, and integrated with SageMaker training jobs and Model Registry. Which approach best fits these requirements?

⚠ Common exam trap

The trap here is assuming any general-purpose orchestrator with an if/else can substitute for native SageMaker pipeline gating and Model Registry integration.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Author a SageMaker Pipeline with a Condition step that compares evaluation metrics to the baseline and branches to a RegisterModel step or a Fail step.

SageMaker Pipelines express orchestration as versionable code and include a Condition step for metric-based branching, plus native RegisterModel and Fail steps. This enforces the evaluation gate before registration without custom glue, and the pipeline definition can live in git and be executed reproducibly. It best satisfies the code-as-orchestration, integration, and versioning requirements.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Author a SageMaker Pipeline with a Condition step that compares evaluation metrics to the baseline and branches to a RegisterModel step or a Fail step.
Why this is correct
SageMaker Pipelines are defined as code, can be versioned in git, and natively integrate training jobs, processing jobs, and the Model Registry. A Condition step compares the evaluation metric to the baseline and routes execution to either RegisterModel or a terminal Fail step, enforcing the gate automatically. This expresses the entire orchestration logic declaratively and reproducibly, matching all stated requirements.
✗
Write a Python script on an EC2 instance that calls the SageMaker APIs sequentially and uses if/else statements to decide whether to register.
Why it's wrong here
A hand-rolled script on EC2 is imperative, lacks native retry and state management, and requires you to build logging, error handling, and concurrency yourself. It is not integrated with the Model Registry's approval workflow and is harder to version and audit as orchestration logic. While it can be stored in git, it does not provide the managed pipeline execution semantics the team wants.
✗
Use AWS Glue workflows to chain the training and evaluation jobs and branch on the evaluation result.
Why it's wrong here
AWS Glue workflows are designed for extract-transform-load orchestration with Glue jobs and crawlers, not for SageMaker training jobs or Model Registry operations. Branching on ML evaluation metrics and registering models are not native Glue capabilities, so you would need custom code that reintroduces the same operational burden. This is a mismatched service for ML pipeline orchestration.
✗
Define an AWS Step Functions state machine with a Choice state that inspects evaluation output and calls SageMaker APIs directly.
Why it's wrong here
Step Functions can orchestrate SageMaker jobs and branch on state, but it does not provide native Model Registry integration or pipeline-level lineage and caching. You would write custom integration code for registration and metric comparison, and the pipeline definition is less directly tied to SageMaker artifacts. It is workable but has more glue code and less built-in ML lineage than a SageMaker Pipeline.

Go deeper

MLA-C01 Deployment and Orchestration of ML Workflows Practice Question

Why each option matters

Option-by-option breakdown

Related to this question