AWS MLS-C01: Machine Learning Implementation and Operations Practice Questions

Asynchronous inference is correct because it is specifically designed for requests with large payloads or long processing times (up to 15 minutes), queues requests, and scales down to zero instances when idle, minimizing costs. Real-time inference is wrong because it has a 60-second timeout and is designed for low-latency, synchronous responses — an 8-minute job would time out. Serverless inference is wrong because it also enforces a short invocation timeout (up to 60 seconds) and is suited for sporadic, lightweight workloads. Batch transform is wrong because while it handles large-scale processing, it is designed for offline bulk inference on an entire dataset at once, not for individual requests arriving throughout the day.

SageMaker Inference Recommender is correct because it automatically benchmarks a model across multiple instance types, running load tests and measuring latency, throughput, and cost, then provides recommendations for the optimal instance type and configuration for a given performance/cost target — exactly what is needed for right-sizing. SageMaker Model Monitor is wrong because it monitors production data and model quality (drift, bias, accuracy) — it does not analyze infrastructure performance or recommend instance types. AWS Compute Optimizer for SageMaker is wrong because Compute Optimizer provides rightsizing recommendations for EC2, Lambda, and ECS, but does not natively support SageMaker endpoints — SageMaker Inference Recommender is the correct tool. SageMaker Clarify is wrong because it analyzes bias in data and models and computes feature attributions — it has no role in infrastructure performance analysis or instance type recommendation.

Target tracking policy targeting InvocationsPerInstance is correct because SageMaker exposes InvocationsPerInstance as a CloudWatch metric specifically for auto scaling, and target tracking automatically adjusts capacity to keep the metric at a defined target value, which is the recommended approach for SageMaker endpoints. Step scaling policy targeting CPUUtilization is wrong because while step scaling is valid for some AWS services, SageMaker endpoint auto scaling best practice uses target tracking, and CPUUtilization is not a published SageMaker endpoint metric. Target tracking targeting MemoryUtilization is wrong because MemoryUtilization is not a built-in SageMaker endpoint CloudWatch metric and cannot be used directly for endpoint auto scaling without custom metrics. Scheduled scaling is wrong because it cannot react dynamically to sudden, unpredictable spikes — it only scales at predefined times, which is insufficient for unexpected traffic surges.

SageMaker production variants with variant weights is correct because a SageMaker endpoint can host multiple production variants, each pointing to a different model version, with configurable traffic weights (e.g., 90/10 split). SageMaker automatically routes requests according to those weights, and per-variant CloudWatch metrics enable performance comparison — this is the canonical A/B testing pattern in SageMaker. Multi-model endpoints with weighted routing is wrong because MME dynamically loads models but does not support traffic weighting between model variants; traffic routing to a specific model in an MME is determined by the TargetModel parameter in the request, not automatic weighted splitting. SageMaker Pipelines with a parallel step is wrong because Pipelines orchestrate training/processing workflows — they are not a mechanism for splitting live inference traffic. Two separate endpoints with an Application Load Balancer is wrong because ALB does not natively integrate with SageMaker endpoint invocation semantics, and this unnecessarily complicates what SageMaker handles natively through production variants.

SageMaker Pipelines is correct because it is a purpose-built CI/CD service for ML workflows that natively integrates with SageMaker training, processing, evaluation, Model Registry, and deployment steps. It automatically tracks lineage, supports conditional steps, and is designed for reproducible, auditable ML pipelines with built-in SageMaker integration. AWS Glue Workflows is wrong because Glue Workflows orchestrate ETL jobs (Glue crawlers and jobs), not SageMaker training and evaluation steps, and lacks native ML pipeline primitives. Amazon MWAA is wrong because while Airflow can orchestrate ML workflows, it requires significant custom setup to integrate with SageMaker and does not provide native lineage tracking or Model Registry integration out of the box — SageMaker Pipelines is more appropriate for SageMaker-centric ML pipelines. AWS Step Functions is wrong because while it can orchestrate SageMaker jobs via the SageMaker SDK integration, it lacks the native ML-specific features of SageMaker Pipelines such as automatic experiment tracking, lineage, and direct Model Registry integration.