mediumMultiple ChoiceObjective-mapped
MLA-C01 SageMakerVariantInvocationsPerInstance Practice Question
A data science team has trained a model using SageMaker and wants to deploy it for real-time inference with automatic scaling based on request latency. The deployment must handle unpredictable traffic spikes without manual intervention. Which combination of SageMaker features should the team use?
⚠ Common exam trap
Candidates may expect a metric that directly measures latency (e.g., SageMakerVariantLatency), but such a metric is not available as a built-in target tracking metric. The SageMakerVariantInvocationsPerInstance metric is the standard choice for latency scaling and is designed to maintain performance under variable load.
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
✓
Create a SageMaker endpoint with an Application Auto Scaling target tracking policy based on the SageMakerVariantInvocationsPerInstance metric
It uses a SageMaker endpoint with an Application Auto Scaling target tracking policy based on the SageMakerVariantInvocationsPerInstance metric. While this metric measures invocations per instance rather than latency directly, it serves as a proxy: high invocations per instance often lead to increased latency, so scaling on this metric helps maintain low latency by distributing load. This approach handles unpredictable traffic spikes automatically, meeting the requirement for latency-aware scaling better than any other option, which lack automatic or latency-based scaling.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a SageMaker endpoint with an Application Auto Scaling target tracking policy based on the SageMakerVariantInvocationsPerInstance metric
Why this is correct
Correct. This combination provides automatic scaling based on invocations per instance, which correlates with latency and handles spikes without manual intervention.
- ✗
Deploy the model on a multi-model endpoint and manually adjust the number of instances via the AWS Management Console
Why it's wrong here
Wrong. Manual adjustment does not provide automatic scaling and cannot handle traffic spikes without intervention.
- ✗
Deploy the model on an Elastic Inference accelerator and use AWS Auto Scaling with a scheduled policy
Why it's wrong here
Wrong. Elastic Inference accelerates model inference but does not scale; scheduled policy is not based on real-time latency.
- ✗
Create a batch transform job with a scheduled Lambda function to trigger scaling
Why it's wrong here
Wrong. Batch transform job is for offline inference, not real-time, and scheduled Lambda does not scale based on latency.
Go deeper
Related to this question
About these practice questions
One of 835 original MLA-C01 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.