hardMultiple ChoiceObjective-mapped
SageMaker Endpoint Autoscaling with Concurrent Requests Metric
A team is deploying a TensorFlow model on a SageMaker real-time endpoint with automatic scaling. They set the scaling policy to target an average CPU utilization of 50%. However, during traffic spikes, the endpoint experiences high latency and 503 errors. The instance type is ml.c5.large. What should the team do to resolve this while minimizing cost?
Quick Answer
CPU utilization is a proxy for load, and it's a lagging one for inference workloads, because a model can be waiting on request queuing or I/O rather than pure computation, so a fleet can already be saturated with requests well before average CPU crosses 50%. That mismatch is why the endpoint keeps producing 503 errors during spikes even though the scaling policy is technically working as configured: it's reacting to the wrong signal. Adding a scaling policy based on concurrent requests per instance ties scaling decisions to what is actually building up on each instance, the request load itself, so new instances launch before saturation causes dropped or rejected requests, and because it targets a specific per-instance threshold rather than a broad average, it avoids over-provisioning the way blindly adding more instances or switching to a larger instance type would. The broader lesson is that when an endpoint scaling policy based on CPU isn't preventing latency spikes or errors, look for a metric that measures request-level saturation, like concurrent requests or invocations per instance, since those track the thing that is actually causing the endpoint to fall behind, and pairing that more responsive metric with the existing instance type is usually the lowest-cost fix available.
⚠ Common exam trap
Test-takers frequently assume larger instances (Option C) are the only way to handle spikes, but the exam tests understanding that scaling policies based on the right metric (concurrent requests) can be more cost-effective and responsive than simply scaling up instance size.
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
✓
Add a scaling policy based on the number of concurrent requests per instance
Scaling based on CPU utilization alone is often insufficient for inference workloads where latency is the primary concern. By adding a scaling policy based on the number of concurrent requests per instance, the team can proactively scale out before CPU saturation occurs, reducing latency and eliminating 503 errors. SageMaker's automatic scaling supports multiple target tracking metrics, and using concurrent requests per instance aligns more closely with the actual demand on the model serving container.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Pre-warm the endpoint by keeping a fixed number of additional instances
Why it's wrong here
Pre-warming is manual and not cost-efficient.
- ✗
Increase the scale-in cooldown period to avoid frequent downsizing
Why it's wrong here
Increasing cooldown would delay scaling in but not help with scaling out during spikes.
- ✗
Change the instance type to a larger one like ml.c5.xlarge to handle the spikes
Why it's wrong here
Larger instances increase cost and may still not handle spikes without scaling out.
- ✓
Add a scaling policy based on the number of concurrent requests per instance
Why this is correct
Concurrent requests metric often provides faster and more accurate scaling for ML endpoints.
Visual reference
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 →
Same concept, more angles
1 more way this is tested on MLA-C01
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A machine learning engineer is deploying a model using SageMaker and needs to ensure that the endpoint can automatically scale based on traffic patterns. Which TWO actions should the engineer take? (Choose two.)
medium- ✓ A.Define a scaling policy using Application Auto Scaling for the SageMaker endpoint variant.
- ✓ B.Set up an Amazon CloudWatch alarm to trigger scaling based on the InvocationsPerInstance metric.
- C.Enable SageMaker Model Monitor to detect data drift.
- D.Configure a multi-model endpoint to serve multiple models.
- E.Use SageMaker batch transform to handle variable traffic.
Why A: SageMaker endpoints use Application Auto Scaling to automatically adjust the number of instances based on traffic. You define a scaling policy (e.g., target tracking, step scaling) that references a CloudWatch metric. Option B is correct because the InvocationsPerInstance metric is a standard SageMaker endpoint metric that reflects the load per instance, and a CloudWatch alarm on this metric can trigger the scaling policy to add or remove instances as traffic changes.
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.