MLA-C01 Deployment and Orchestration of ML Workflows Practice Question
A company uses SageMaker Pipelines to orchestrate their ML workflow. They notice that if a pipeline step fails due to a transient error (e.g., a brief network issue), the entire pipeline fails and they must manually rerun from the beginning. They want to automatically retry failed steps a few times before failing. What should they do?
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
✓
Configure a RetryPolicy in the pipeline step definition to specify the number of retry attempts and backoff
SageMaker Pipelines supports retry policies for steps. By setting a RetryPolicy in the step definition with a maximum number of retry attempts, the pipeline will automatically retry the step on failure. The other options do not achieve automatic retry within the pipeline: Step Functions would require rebuilding the pipeline, Lambda cannot retry pipeline steps, and CreatePipelineExecution does not handle retries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a Lambda function to catch step failures and re-invoke the step
Why it's wrong here
This would require custom code and does not integrate seamlessly with Pipelines.
- ✗
Use the CreatePipelineExecution API with a flag to ignore failures
Why it's wrong here
There is no such flag; failures require manual intervention without retry policies.
- ✓
Configure a RetryPolicy in the pipeline step definition to specify the number of retry attempts and backoff
Why this is correct
SageMaker Pipelines supports RetryPolicy to automatically retry steps on failure.
- ✗
Use AWS Step Functions to orchestrate the workflow instead of SageMaker Pipelines
Why it's wrong here
Switching to AWS Step Functions is an unnecessary architectural change, as SageMaker Pipelines natively provides configuration options for automatic step-level retries to handle transient failures directly within its workflow definition. While Step Functions offers robust error handling and retry capabilities, it is a general-purpose serverless orchestrator. It would be a suitable choice if the requirement was to orchestrate complex workflows integrating a diverse range of AWS services beyond the scope of a dedicated ML pipeline, where its state machine model offers greater flexibility.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This MLA-C01 question is part of Courseiva's 835-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This MLA-C01 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the MLA-C01 exam.