hardMultiple Choice
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 keeps idle instances running permanently, which raises cost without addressing the scaling policy's slow reaction to spikes. It is tempting because pre-warming is the correct choice for latency-sensitive endpoints with predictable, steady baseline traffic where cold starts are unacceptable.
- ✗
Increase the scale-in cooldown period to avoid frequent downsizing
Why it's wrong here
Extending the scale-in cooldown only delays removing instances; it does nothing to add capacity faster during a spike, so latency and 503 errors persist. It is tempting because cooldown tuning is the correct fix when scaling oscillates, repeatedly adding and removing instances.
- ✗
Change the instance type to a larger one like ml.c5.xlarge to handle the spikes
Why it's wrong here
A larger instance raises per-instance capacity but the target-tracking policy still scales on CPU, and idle larger instances cost more, contradicting the cost requirement. It is tempting because vertical scaling is the correct fix when a single instance is genuinely CPU-bound and cannot be split across replicas.
- ✓
Add a scaling policy based on the number of concurrent requests per instance
Why this is correct
Concurrent-requests scaling tracks actual demand rather than CPU, which lags behind request bursts on ml.c5.large. It adds capacity before latency and 503 errors occur, satisfying the responsiveness constraint while avoiding the cost of permanently larger instances.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 665 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: Option A is correct because SageMaker endpoint variants are scaled through Application Auto Scaling, which is the AWS service that registers the SageMaker variant as a scalable target and applies a scaling policy (target-tracking or step scaling) to adjust the desired instance count. Option B is correct because Application Auto Scaling policies are driven by Amazon CloudWatch alarms, and the InvocationsPerInstance metric is the standard SageMaker metric used to scale on traffic per instance. Option C is incorrect because SageMaker Model Monitor detects data drift and quality issues, not traffic-based scaling. Option D is incorrect because multi-model endpoints consolidate multiple models on shared infrastructure to reduce hosting cost, not to autoscale on traffic patterns. Option E is incorrect because batch transform is an offline, batch inference mechanism and does not serve a real-time, autoscaling endpoint.
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.