Over-Provisioning — AWS Machine Learning (MLS-C01)
You provisioned more capacity or redundancy than the scenario required. The exam rewards right-sizing.
ml.p3.8xlarge trains faster. That's the wrong question.
Training jobs that run for hours on a fixed dataset are discrete, interruptible workloads. The scenario specifies cost minimization alongside acceptable training duration. Larger instances compress wall-clock time — and the distractor banks on that feeling like efficiency. The exam expects you to recognize that Spot Instances for SageMaker training jobs absorb interruption gracefully via checkpointing, and that the per-hour savings on a multi-hour run dwarf the inconvenience of a single retry.
The Scenario
A development team needs a database for a new microservice with unknown traffic patterns, starting at approximately 100 reads and 20 writes per second. You choose Multi-AZ RDS PostgreSQL with provisioned IOPS for consistent performance. The correct answer is DynamoDB with on-demand capacity mode. The workload is key-value access (not relational joins), the traffic pattern is unknown (on-demand auto-scales without capacity planning), and the scenario said "new microservice" — meaning requirements will change. Multi-AZ adds cost for availability the scenario never specified. Provisioned IOPS locks you into capacity you may not need.
How to Spot It
- •New workloads with unknown traffic patterns favor on-demand or auto-scaling over provisioned capacity. DynamoDB on-demand charges per request — $1.25 per million reads. At 100 reads/second, that is $10.80/month. A db.r6g.large Multi-AZ RDS instance with provisioned IOPS starts at $400+/month.
- •Multi-AZ is only correct when the scenario requires high availability with automatic failover. Development environments, new microservices, and workloads without SLA requirements do not need Multi-AZ. The exam tests whether you add redundancy that was not requested.
- •Aurora Serverless v2 scales from 0.5 to 128 ACUs — but the minimum 0.5 ACU still costs ~$43/month even at zero traffic. For intermittent workloads, DynamoDB on-demand at $0 idle cost or Aurora Serverless v1 with pause-after-idle may be cheaper.
Decision Rules
Whether to replace a custom SageMaker-hosted ASR model with Amazon Transcribe for a commodity standard-English speech-to-text workload, given that the cost-per-inference reduction mandate and variable call volume make the always-on custom endpoint unjustifiable.
When the speech recognition task covers standard language and does not require a domain-differentiated model, replace the custom SageMaker ASR endpoint with Amazon Transcribe batch transcription to eliminate always-on instance-hour billing, data-labeling cost, and retraining overhead — defaulting to the managed AI service wherever the commodity threshold is met.
Whether to right-size or reserve the provisioned SageMaker endpoint versus replacing the custom TTS model with Amazon Polly's pay-per-character managed service, eliminating idle capacity waste across twenty hours per day and removing ongoing model maintenance costs.
Whether to vertically provision a fixed large instance sized for peak throughput or horizontally scale a managed endpoint via application auto-scaling, given that both the latency SLA and the cost ceiling must be satisfied simultaneously across a variable workload.
Decide whether the observed ML endpoint degradation warrants infrastructure scaling (instance type upgrade or capacity increase) or model-level remediation (drift detection and retraining), given that infrastructure metrics are healthy while prediction accuracy is declining.
Whether to vertically scale to a single large GPU instance that guarantees peak-load headroom at all times (over-provisioning trap) or to right-size with a smaller baseline instance count and a CloudWatch-driven SageMaker auto-scaling policy that expands horizontally during spikes and contracts during off-peak hours.
Domain Coverage
Difficulty Breakdown
Related Patterns