MLA-C01 Deployment and Orchestration of ML Workflows Practice Question

A company wants to deploy a trained XGBoost model for batch inference on a large dataset stored in S3. The inference job should be cost-effective and does not require real-time responses. Which SageMaker inference option should they use?

⚠ Common exam trap

MLA-C01 often tests the cost/latency trade-off between Batch Transform and Asynchronous Inference — candidates pick Asynchronous because it sounds 'batch-like,' but Asynchronous Inference is for near-real-time large-payload requests, not bulk offline scoring.

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

✓

SageMaker Batch Transform

SageMaker Batch Transform is designed for offline, high-throughput inference on large datasets stored in S3, with no persistent endpoint and no real-time requirement. It is the most cost-effective option for this scenario because you pay only for the duration of the batch job.

Answer analysis

Option-by-option breakdown

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

✓
SageMaker Batch Transform
Why this is correct
SageMaker Batch Transform runs inference over large S3 datasets on managed instances that terminate when the job completes, avoiding the cost of a persistently running endpoint. This satisfies the stem's cost-effectiveness requirement and its lack of any real-time response need.
✗
SageMaker real-time endpoint
Why it's wrong here
A real-time endpoint holds compute continuously and returns synchronous responses, so it bills for idle capacity while processing a large S3 dataset that needs no immediate answers. Batch Transform reads from S3 and shuts down after the job. Real-time endpoints suit low-latency interactive predictions.
✗
SageMaker Asynchronous Inference
Why it's wrong here
Asynchronous Inference queues requests and returns results via S3, but it targets large payloads or long processing times needing near-real-time retrieval, not whole-dataset scoring. Batch Transform handles the full S3 dataset cost-effectively. Asynchronous suits requests exceeding synchronous payload limits.
✗
SageMaker Serverless Inference
Why it's wrong here
Serverless Inference scales to zero and suits intermittent, unpredictable traffic with latency tolerance, but it caps payload size and duration, making it unsuitable for scoring a large S3 dataset. Batch Transform processes the entire dataset in one job. Serverless suits spiky, low-volume request patterns.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

MLA-C01 Deployment and Orchestration of ML Workflows Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question