Over-Provisioning — AWS SysOps Administrator (SOA-C03)
You provisioned more capacity or redundancy than the scenario required. The exam rewards right-sizing.
When 'Guaranteed Performance' Is the Wrong Frame
The exam phrases these scenarios as "ensure consistent response times" or "handle peak load." Candidates anchor on Reserved Instances or large instance types because those words signal stability. What the question actually rewards is the option that matches capacity to demand — Auto Scaling groups, Spot with On-Demand fallback, or Lambda — because the workload profile is variable or bursty. The word "consistent" describes the outcome, not the provisioning model.
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 configure two path-specific cache behaviors—CachingOptimized mapped to the S3 origin for /assets/* and CachingDisabled mapped to the ALB origin for /api/*—versus a single default cache behavior with a long TTL that satisfies static caching but over-provisions caching onto the dynamic path, risking stale personalised or transactional responses.
Whether the deployment timeline constraint (72 hours) acts as a hard filter that disqualifies Direct Connect before bandwidth optimization is considered, making Site-to-Site VPN the only viable option when throughput is below the VPN ceiling and time-to-live connectivity is the dominant constraint.
Scope EBS Fast Snapshot Restore to only the single most recent recovery snapshot in the primary Availability Zone rather than enabling it broadly across all retained snapshots and multiple AZs, to satisfy the 30-minute RTO without breaching the cost ceiling.
Whether the stated L3/L4 volumetric attack is already fully mitigated by AWS Shield Standard (automatic, zero incremental cost) — making Shield Advanced subscription or WAF rule deployment unnecessary and constituting over-provisioning under the cost-and-coverage constraint.
Attach AWS WAF exclusively to the CloudFront distribution so that application-layer rules are evaluated at the edge before requests traverse the origin network; attaching WAF to both CloudFront and the ALB is over-provisioning because CloudFront is already the sole public ingress path and dual attachment doubles ACL cost without intercepting any additional threats.
Whether to model the joint-condition page trigger as a single CloudWatch composite alarm referencing two child metric alarms (one SNS action) or as two independent metric alarms each configured with its own SNS topic action.
Whether to absorb burst CPU demand by permanently over-provisioning a fixed large memory-optimized instance or by configuring an Auto Scaling group with a compute-optimized instance family sized to the actual bottleneck metric, satisfying the cost ceiling by paying only for burst capacity when needed.
Whether to absorb burst CPU demand by vertically upsizing to a permanently running oversized instance or by horizontally scaling a right-family (compute-optimized) Auto Scaling group scoped only to burst duration.
Domain Coverage
Difficulty Breakdown
Related Patterns