Design High-Performing Architectures: free practice questions

Option B is correct. Reserved Instances provide the lowest per-hour cost for predictable baseline capacity, while Spot Instances are up to 90% cheaper than On-Demand and are well-suited for stateless, fault-tolerant workloads that can tolerate interruptions. Because the app is stateless, Spot interruptions don't cause data loss. Option A uses On-Demand for spikes, which is significantly more expensive than Spot for short, bursty periods. Option C ignores cost optimization and creates a single point of failure without elasticity. Option D using Spot-only is risky: if Spot capacity is unavailable during a spike, the application could become unavailable with no stable baseline.

DynamoDB on-demand capacity mode automatically scales to handle 50,000 writes/second bursts without pre-provisioning, then scales back down during idle periods — ideal for bursty workloads. DAX (DynamoDB Accelerator) provides microsecond-latency in-memory reads for the leaderboard queries, satisfying the sub-10ms read requirement even under millions of concurrent users. CloudFront at the edge can further cache the API responses for read-heavy global traffic. Option A (Kinesis → Lambda → Aurora) would struggle: Aurora Multi-AZ has write throughput limits around 100,000 IOPS shared across concurrent operations; Lambda concurrency limits can create a bottleneck; and Aurora cannot natively serve sub-10ms reads at global scale without significant additional caching architecture. Option C (Firehose → S3 → Athena) is a batch analytics pattern; Athena queries take seconds to minutes — far exceeding the 10ms read requirement. Option D (ElastiCache Redis as primary store) is a common anti-pattern: Redis is not designed as a durable primary database, lacks automatic geo-distribution, and a 'write-behind' pattern to DynamoDB adds complexity and risk of data loss on Redis node failure.

CloudFront caches the thumbnail images at edge locations close to users worldwide, reducing latency dramatically and offloading GET requests from S3 (reducing costs). A long TTL is appropriate since thumbnails rarely change. — Transfer Acceleration speeds up uploads TO S3, not downloads by end users through a CDN; it also doesn't cache content. — Cross-Region Replication copies objects to other buckets but doesn't cache at the edge or reduce per-request latency for arbitrary user locations; it also increases storage costs. — Global Accelerator improves routing to application endpoints (EC2/ALB/NLB) using the AWS backbone, but it does not cache static content like CloudFront does, so it won't reduce S3 GET costs.

A cluster placement group packs instances physically close together within a single AZ, enabling high-bandwidth, low-latency network connections (up to 10 Gbps between instances for supported types, and eligible for enhanced networking / ENA). This is the optimal choice for tightly coupled, latency-sensitive inter-node communication. — Partition placement groups are designed for distributed, fault-tolerant workloads (e.g., Hadoop, Cassandra) where isolation between partitions matters more than raw latency between nodes. — Spread placement groups place each instance on distinct hardware to maximize fault isolation, but they sacrifice network proximity and are limited to 7 instances per AZ. — Distributing across multiple AZs with no placement group increases inter-instance network latency and does not exploit high-bandwidth intra-rack networking.

Option A (Transfer Acceleration) routes uploads through CloudFront edge locations over AWS's optimized backbone network, dramatically reducing latency and improving reliability for global uploads. Option B (multipart upload) is recommended by AWS for objects over 100 MB—it allows parallel uploads of individual parts, automatic retry of failed parts, and the ability to resume interrupted uploads. Option C (changing bucket region) only helps users near one office and doesn't help global users. Option D (Intelligent-Tiering) is a cost-optimization storage class and has no effect on upload performance. Option E is incorrect—S3 bucket policies cannot configure part sizes; multipart upload part sizes are set by the client. Option F (S3 Replication) copies data after a successful upload and does nothing to improve the reliability of the initial upload.