AWS SAA-C03: Design High-Performing Architectures Practice Questions

RDS Storage Auto Scaling automatically expands storage when free space is low, with no manual intervention — directly preventing the storage-full event from recurring. Setting a maximum threshold protects against runaway growth. A CloudWatch alarm on FreeStorageSpace provides early warning so the team can monitor trends and act proactively before any threshold is reached, even if auto scaling is enabled. Migrating to Aurora would solve the storage problem (Aurora auto-scales in 10 GB increments) but is a major migration effort with significant operational overhead. Scheduling a Lambda function to check and increase storage manually is operationally complex, error-prone, and can miss rapid storage growth. Increasing storage by 100% immediately provides temporary headroom but is a one-time fix that doesn't prevent future recurrence. Automated backups help with recovery after a failure but do not prevent storage exhaustion.

Amazon RDS Proxy maintains a warm pool of database connections and multiplexes thousands of application-level connections onto a smaller set of actual database connections. This eliminates connection storms during scaling events and improves resilience without changing the database or application significantly. — Aurora Auto Scaling adds read replicas to handle read throughput, but connection storms typically hit the writer endpoint; read replicas don't accept write connections and don't solve the writer connection exhaustion. — Aurora Serverless v2 scales compute capacity (ACUs) but doesn't inherently reduce the number of simultaneous connections from application instances — connection storms can still occur with Serverless v2. — Increasing max_connections raises the database's connection limit but doesn't pool or multiplex connections; under extreme scaling events, you still risk exhausting memory and degrading performance at higher connection counts.

DAX is a fully managed, DynamoDB-compatible in-memory cache that sits directly in front of DynamoDB. It requires minimal code changes — you simply point the DynamoDB SDK to the DAX endpoint instead. It handles hot-key caching transparently and reduces read latency to microseconds, eliminating partition throttling. — ElastiCache for Redis can also cache DynamoDB results effectively, but it requires significant application-level code changes (explicit cache-aside logic, cache invalidation, serialization), which the requirement explicitly wants to avoid. — Increasing RCUs would reduce throttling but does not address the fundamental hot-partition problem (RCUs are distributed across partitions); it is also more expensive and doesn't actually cache reads. — Global tables replicate data across regions for geographic distribution; they do not solve the hot-key throttling problem within a single region.

The recommended EMR cost-optimization pattern is: On-Demand (or Reserved) for the master node (cluster control plane — losing it terminates the cluster) and core nodes (they store HDFS data — losing them can corrupt the cluster), and Spot Instances for task nodes (which only process data and can be replaced without data loss). This yields significant savings on the compute-heavy task tier without risking cluster stability. — Using all On-Demand instances is reliable but misses the cost optimization opportunity. — Using Reserved Instances for the master only while keeping core nodes On-Demand is better than all On-Demand, but task nodes (the largest tier) remain On-Demand, leaving major savings on the table. — Using Spot for master and core nodes risks cluster termination and HDFS data corruption if Spot capacity is reclaimed, which is not acceptable even for non-critical batch jobs.

AWS Lambda with API Gateway is purpose-built for sporadic, unpredictable workloads. Lambda scales automatically from zero to thousands of concurrent executions with no infrastructure management, and you pay only per invocation and duration — making it extremely cost-effective when traffic is low or zero. A 300 ms execution time is well within Lambda's capabilities. — EC2 Auto Scaling has a minimum instance requirement, so you pay for idle capacity during low-traffic periods; it also introduces operational overhead (patching, AMI management). — Fargate containers take seconds to start (cold starts), are not as cost-effective at near-zero traffic, and require more orchestration setup than Lambda for a simple REST API. — ECS on EC2 with Spot Instances adds complexity (instance management, Spot interruption handling) and doesn't scale to zero, making it less cost-efficient for sporadic traffic.