AWS Certified Solutions Architect – Associate — All Questions

A read-heavy application repeatedly runs the same expensive database queries, causing high latency. Which addition most improves read performance with minimal application change?

• a.Increase the RDS instance storage size
• b.Move the database to a larger EBS magnetic volume
• c.Add Amazon ElastiCache to cache frequent query results in memory✓
• d.Enable S3 Transfer Acceleration

ElastiCache (Redis or Memcached) stores frequently accessed query results in memory, serving repeated reads with sub-millisecond latency and offloading the database. Growing storage or using magnetic EBS does not reduce query latency for hot data. S3 Transfer Acceleration speeds S3 uploads and is unrelated to database queries.

A media company serves large video files to a global audience and wants to reduce latency and origin load by caching content near users. Which service should be used?

• a.A larger EC2 instance in one Region
• b.Amazon CloudFront✓
• c.Amazon EFS
• d.An internet gateway

CloudFront is a content delivery network that caches content at edge locations worldwide, lowering latency for global viewers and offloading requests from the origin. A single larger instance still serves from one Region with no edge caching. EFS is regional file storage and an internet gateway only provides connectivity, neither of which delivers a global CDN.

An application needs a fully managed NoSQL database delivering single-digit millisecond latency at any scale, with the option of microsecond reads via an in-memory cache. Which combination fits?

• a.Amazon DynamoDB with DynamoDB Accelerator (DAX)✓
• b.Amazon Aurora Serverless
• c.Amazon Redshift with concurrency scaling
• d.Amazon RDS with a read replica

DynamoDB provides consistent single-digit millisecond latency at scale, and DAX is a purpose-built in-memory cache that reduces read latency to microseconds for eventually consistent reads. RDS and Aurora are relational engines, not NoSQL. Redshift is an analytics data warehouse, not a low-latency operational key-value store.

A company ingests a high-throughput, continuous stream of clickstream data that must be processed in near real time by multiple consumers. Which service is designed for this?

• a.Amazon Kinesis Data Streams✓
• b.Amazon S3 event notifications
• c.Amazon SQS standard queue
• d.Amazon Athena

Kinesis Data Streams is built for high-throughput, ordered, real-time streaming data that multiple consumers can read concurrently while retaining records for replay. SQS is a decoupling queue where a message is typically processed once, not a multi-consumer stream. Athena queries data at rest in S3 and does not ingest live streams.

A latency-sensitive TCP-based application needs to route users over the AWS global network to the nearest healthy Regional endpoint using static anycast IP addresses. Which service provides this?

• a.Amazon CloudFront
• b.Amazon Route 53 weighted routing
• c.AWS Global Accelerator✓
• d.AWS Direct Connect

AWS Global Accelerator provides static anycast IP addresses and routes traffic over the AWS backbone to the closest healthy endpoint, improving performance for TCP/UDP applications. CloudFront is optimized for cacheable HTTP content, not arbitrary TCP endpoints. Direct Connect is a private on-premises link, and weighted DNS does not use the AWS global network for transport.

A web app's images and JavaScript load slowly for international users because they are fetched from S3 in a single Region. What improves performance most?

• a.Move the bucket to One Zone-IA
• b.Enable S3 versioning
• c.Distribute the S3 assets through Amazon CloudFront so they are cached at edge locations near users✓
• d.Serve the assets from a larger EC2 instance

CloudFront caches static assets at edge locations worldwide, so international users are served from a nearby edge instead of the origin Region, cutting latency and origin load. A larger instance still serves from one Region, One Zone-IA is a cost/durability choice unrelated to global latency, and versioning does not affect delivery speed.

A reporting feature sends many read-only queries to an RDS database, and these reads are slowing down transactional writes on the primary. How can read performance scale without impacting writes?

• a.Enable Multi-AZ so the standby serves reads
• b.Add RDS read replicas and direct the reporting queries to them✓
• c.Increase the backup retention period
• d.Take snapshots more often

RDS read replicas offload read-only traffic from the primary, letting reporting queries scale horizontally without affecting write performance. Multi-AZ standbys are for failover and do not serve read traffic, and snapshots or longer backup retention are recovery features, not read-scaling mechanisms.

A DynamoDB-backed application experiences hot read traffic and needs microsecond read latency for repeated key lookups without changing its DynamoDB API calls. What should be added?

• a.An ElastiCache for Redis cluster with custom caching code
• b.DynamoDB Accelerator (DAX)✓
• c.Amazon Redshift
• d.A read replica

DAX is a fully managed, in-memory cache built specifically for DynamoDB that delivers microsecond read latency and is API-compatible, so little application change is needed. ElastiCache would require custom caching logic, DynamoDB has no read replicas in that sense, and Redshift is an analytics warehouse, not a low-latency cache.

A stateful web app stores user session data on each instance, so scaling out and instance replacement log users out. What is the best way to share sessions across instances with very low latency?

• a.Store sessions on an EBS volume
• b.Store sessions in an RDS table
• c.Store sessions in S3
• d.Store sessions in Amazon ElastiCache (for example Redis) as a shared external session store✓

Moving session state to a shared in-memory store like ElastiCache for Redis makes the web tier stateless, so any instance can serve any user with sub-millisecond access and no logouts during scaling. S3 and RDS add higher latency for frequent session reads and writes, and an EBS volume cannot be shared concurrently across many instances.

A self-managed transactional database on EC2 needs consistent, very high IOPS with low latency from its block storage. Which EBS volume type is most appropriate?

• a.Throughput Optimized HDD (st1)
• b.Provisioned IOPS SSD (io1/io2)✓
• c.Magnetic (standard)
• d.Cold HDD (sc1)

Provisioned IOPS SSD (io1/io2) lets you specify a high, consistent IOPS level with low latency, which is ideal for I/O-intensive transactional databases. st1 and sc1 are throughput-oriented HDDs for large sequential workloads, and magnetic volumes are a legacy, low-performance option.

Users worldwide upload large files to a single S3 bucket, and uploads from distant Regions are slow. Which feature speeds these long-distance uploads with minimal change?

• a.S3 Transfer Acceleration, which routes uploads through the nearest CloudFront edge✓
• b.S3 Cross-Region Replication
• c.S3 Intelligent-Tiering
• d.A larger origin instance

S3 Transfer Acceleration sends uploads to the nearest CloudFront edge location and then over the optimized AWS backbone to the bucket, speeding long-distance transfers. Cross-Region Replication copies existing objects, Intelligent-Tiering optimizes storage cost, and instance size is irrelevant to S3 uploads.

An image-processing task must run only when files are uploaded to S3, scale instantly from zero to thousands of concurrent executions, and incur no cost when idle. Which compute option fits best?

• a.A single large EC2 instance polling the bucket
• b.A fixed fleet of EC2 instances running continuously
• c.AWS Lambda triggered by S3 events✓
• d.An Auto Scaling group with a minimum of ten instances

Lambda runs code in response to S3 events, scales automatically with the number of uploads, and charges only for execution time, making it ideal for spiky, event-driven processing with no idle cost. Continuously running EC2 fleets or a minimum instance count incur cost while idle and scale more slowly.

A team wants to run containerized microservices that scale with demand but does not want to provision, patch, or manage the underlying EC2 hosts. Which option meets this?

• a.A single EC2 instance running all containers
• b.EC2 instances in an Auto Scaling group running Docker manually
• c.Self-managed Kubernetes on EC2
• d.AWS Fargate as the serverless compute for containers, with ECS or EKS✓

AWS Fargate runs containers without you managing servers or clusters of EC2 hosts, scaling per task and billing for the resources each task uses. Self-managed Kubernetes or manual Docker on EC2 still requires host provisioning and patching, and a single instance cannot scale or provide resilience.

An IoT platform ingests hundreds of thousands of ordered sensor records per second that several analytics consumers must read in real time and replay if needed. Which service is designed for this?

• a.Amazon SQS standard queue
• b.Amazon RDS
• c.Amazon Kinesis Data Streams✓
• d.Amazon SNS

Kinesis Data Streams handles very high-throughput, ordered streaming data, retains records for replay, and lets multiple consumers read the same stream independently. SQS is a decoupling queue without multi-consumer replay of the same messages, SNS is pub/sub notifications, and RDS is a relational database, not a streaming service.

A relational workload has unpredictable, spiky traffic with long idle periods, and the team wants capacity to scale automatically without managing instance sizes. Which option fits best?

• a.A large fixed-size RDS instance running continuously
• b.DynamoDB with provisioned capacity
• c.Redshift
• d.Aurora Serverless v2, which scales database capacity automatically with load✓

Aurora Serverless v2 automatically scales compute capacity up and down with demand and suits variable or intermittent relational workloads, avoiding overprovisioning. A fixed large instance wastes capacity when idle, DynamoDB is non-relational, and Redshift is an analytics warehouse rather than an OLTP database.

A tightly coupled HPC application needs the lowest possible network latency and highest throughput between its EC2 instances within a single Availability Zone. Which placement strategy helps?

• a.A spread placement group across AZs
• b.Placing instances in different subnets at random
• c.Distributing instances across multiple Regions
• d.A cluster placement group✓

A cluster placement group packs instances close together within one AZ to provide low-latency, high-throughput networking ideal for tightly coupled HPC workloads. A spread placement group deliberately separates instances for availability, and spreading across Regions or random subnets increases latency.

A data-processing job needs extremely fast, temporary local scratch storage for intermediate files, and the data can be regenerated if it is lost. Which storage option gives the best performance?

• a.A general purpose gp3 EBS volume
• b.EC2 instance store (local NVMe) volumes✓
• c.Amazon S3
• d.Amazon EFS

Instance store provides high-performance local NVMe storage physically attached to the host, ideal for temporary scratch data that can be regenerated, since it is ephemeral and lost when the instance stops. EBS and EFS add network overhead, and S3 is object storage not suited to low-latency scratch I/O.

A real-time multiplayer game uses non-cacheable UDP traffic and needs players routed over the AWS backbone to the nearest healthy Regional endpoint with consistent low latency. Which service fits?

• a.Amazon Route 53 geolocation routing
• b.AWS Global Accelerator✓
• c.Amazon CloudFront
• d.Amazon S3 Transfer Acceleration

AWS Global Accelerator uses static anycast IPs and the AWS backbone to route TCP/UDP traffic to the closest healthy endpoint, improving latency and failover for non-cacheable, protocol-sensitive workloads like real-time games. CloudFront and Transfer Acceleration target cacheable HTTP and S3 content, and geolocation DNS does not provide backbone transport or fast failover.

An API fronted by Amazon API Gateway repeatedly returns the same responses for identical requests, adding load on the backend. Which built-in feature reduces backend calls and latency?

• a.Enable S3 Transfer Acceleration
• b.Increase the Lambda memory
• c.Add a NAT gateway
• d.Enable API Gateway caching for the stage✓

API Gateway response caching stores backend responses for a configurable TTL, so repeated identical requests are served from the cache, reducing backend load and latency. Transfer Acceleration is for S3 uploads, a NAT gateway handles outbound connectivity, and more Lambda memory does not eliminate repeated identical calls.

An in-memory analytics database needs EC2 instances with a very high ratio of RAM to vCPU to hold a large working dataset entirely in memory. Which instance family is the best fit?

• a.General purpose (M family), which offers a balanced but not memory-heavy ratio of resources
• b.Storage optimized (I family), which prioritizes high local NVMe throughput over RAM capacity
• c.Memory optimized (R family)✓
• d.Compute optimized (C family), which is tuned for CPU-bound workloads rather than large memory footprints

Memory optimized R-family instances provide the highest RAM-to-vCPU ratio, ideal for in-memory databases and caches that must keep large datasets resident in memory. Compute optimized C instances favor CPU, storage optimized I instances favor local disk I/O, and general purpose M instances give a balanced ratio that wastes money or underperforms for memory-bound work.

A scientific batch job is entirely CPU-bound, needing sustained high compute throughput per vCPU with modest memory. Which EC2 instance family delivers the best performance for the cost?

• a.Accelerated computing (P family)
• b.Memory optimized (R family), which pays for RAM the workload will not use
• c.Compute optimized (C family)✓
• d.Storage optimized (D family)

Compute optimized C-family instances give the highest sustained CPU performance per vCPU, making them ideal for CPU-bound batch and scientific compute. Memory optimized and storage optimized families spend budget on resources the workload does not need, and GPU-based P instances are for parallel accelerated workloads, not general CPU batch jobs.

A deep-learning team needs to train large neural networks that depend on massive parallel matrix computation. Which EC2 instance family is designed for this?

• a.Accelerated computing (P family)✓
• b.General purpose (T family), which uses burstable credits unsuitable for sustained heavy load
• c.Memory optimized (X family), which maximizes RAM rather than parallel compute
• d.Compute optimized (C family), which accelerates CPU tasks but lacks dedicated training accelerators

Accelerated computing P-family instances include high-end GPUs purpose-built for the parallel matrix math in deep-learning training. Burstable T instances throttle under sustained load, and compute or memory optimized families lack the GPUs needed to train large models efficiently.

A scale-out Linux web application recompiled for ARM wants the best price-performance for steady traffic. Which EC2 option should the team choose?

• a.The oldest available x86 instance generation, which lacks the newest performance improvements
• b.Burstable T-family instances relying on CPU credits for a constant workload
• c.AWS Graviton-based instances✓
• d.GPU-accelerated instances, which add cost with no benefit to a standard web tier

AWS Graviton (ARM) instances deliver significantly better price-performance than comparable x86 instances for many scale-out Linux workloads such as web servers. Older x86 generations underperform, burstable T instances are not sized for constant load, and GPU instances add cost that a web tier cannot use.

A web app runs unpredictable, short-lived request handlers that each finish in under a second, with idle gaps between bursts. Which compute model maximizes responsiveness while scaling instantly with demand?

• a.AWS Lambda functions invoked per request✓
• b.A single vertically scaled instance that is resized whenever traffic changes
• c.A fixed fleet of EC2 instances kept running to absorb any burst that might arrive
• d.A container running on one host that queues requests during traffic spikes

AWS Lambda scales automatically to thousands of concurrent short executions and charges only for compute time used, matching spiky sub-second request handlers. A fixed EC2 fleet pays for idle capacity and scales more slowly, a single resized instance is a bottleneck, and a single-host container cannot absorb sudden concurrency.

A team wants to run containerized microservices using the open-source Kubernetes API and tooling, but wants AWS to manage the Kubernetes control plane. Which service fits?

• a.Amazon ECS, which is AWS's proprietary orchestrator and does not expose the Kubernetes API
• b.Amazon EKS✓
• c.Running a self-managed Kubernetes control plane on EC2 instances the team must patch
• d.AWS Lambda, which runs functions rather than long-lived Kubernetes-managed containers

Amazon EKS provides a managed, highly available Kubernetes control plane while letting teams use standard Kubernetes APIs and ecosystem tools. Amazon ECS is AWS's own orchestrator without the Kubernetes API, Lambda is for functions not orchestrated containers, and self-managed Kubernetes shifts control-plane operations back onto the team.

A high-performance computing cluster needs a shared file system delivering hundreds of gigabytes per second of throughput and sub-millisecond latency for thousands of cores. Which storage service is purpose-built for this?

• a.Amazon EFS in General Purpose mode, which targets general workloads rather than extreme HPC throughput
• b.Amazon FSx for Lustre✓
• c.Amazon S3 accessed over the standard object API for each read and write
• d.A single large EBS volume attached to one coordinator instance and shared over NFS

Amazon FSx for Lustre is a high-performance parallel file system built for HPC and machine learning, delivering very high throughput and low latency to many compute nodes, with optional linkage to S3. EFS targets general shared workloads, S3 is object storage not a POSIX HPC file system, and a single EBS volume re-shared over NFS is a bottleneck.

A Windows-based application needs a fully managed shared file system that supports the SMB protocol and integrates with Active Directory. Which service should be used?

• a.Amazon EFS, which provides NFS for Linux clients and does not natively serve SMB with AD integration
• b.An EBS volume formatted with NTFS and attached to a single Windows instance
• c.Amazon S3 exposed as a mounted drive letter through the object API
• d.Amazon FSx for Windows File Server✓

Amazon FSx for Windows File Server is a fully managed native Windows file system that supports SMB and integrates with Active Directory for authentication. EFS serves NFS for Linux, S3 is object storage rather than an SMB share, and a single-instance EBS volume cannot be shared concurrently across many Windows clients.

A database on EC2 needs block storage that sustains a consistent 40,000 IOPS with the lowest, most predictable latency, even during peak load. Which EBS volume type is most appropriate?

• a.Provisioned IOPS SSD (io2)✓
• b.Throughput Optimized HDD (st1), which is optimized for large sequential throughput rather than steady random IOPS
• c.Cold HDD (sc1), a low-cost archival volume with limited IOPS
• d.General Purpose SSD (gp2), whose baseline IOPS depend on volume size and can be less predictable

Provisioned IOPS SSD (io2) lets you specify a high, consistent IOPS level with low, predictable latency, which suits latency-sensitive transactional databases. HDD volumes (st1, sc1) are throughput or archival oriented, and gp2 ties IOPS to size and can be less consistent under sustained heavy random I/O.

A workload on gp2 volumes needs to independently increase throughput without provisioning a larger volume just to gain performance. Which EBS choice lets IOPS and throughput be configured separately from capacity?

• a.General Purpose SSD (gp3)✓
• b.Cold HDD (sc1) for its low cost per gigabyte
• c.Stay on gp2 and grow the volume size so baseline performance scales with capacity
• d.Magnetic (standard) volumes for their legacy flexibility

gp3 volumes let you provision IOPS and throughput independently of capacity, so you can raise performance without paying for extra unused storage as gp2 requires. gp2 couples baseline performance to size, while sc1 and magnetic volumes are low-performance HDD options unsuitable for this need.

A data-warehouse staging job streams very large files sequentially and needs high throughput per gigabyte at low cost, but does not need high random IOPS. Which EBS volume type fits best?

• a.Cold HDD (sc1), which offers the least throughput of the HDD options
• b.Provisioned IOPS SSD (io2), which is optimized and priced for high random IOPS this job does not need
• c.Throughput Optimized HDD (st1)✓
• d.General Purpose SSD (gp3) configured for maximum random IOPS

Throughput Optimized HDD (st1) is designed for large, sequential, throughput-heavy workloads like log processing and data-warehouse staging at low cost. io2 and gp3 optimize for random IOPS at higher price, and sc1 is a colder, lower-throughput archival HDD.

A machine-learning pipeline needs a temporary high-speed scratch area for shuffle files that are recreated on every run and never need to survive a stop. Which storage gives the highest local throughput?

• a.Amazon S3 accessed through the object API for each intermediate file
• b.EC2 instance store (local NVMe)✓
• c.Amazon EFS mounted from the training instances
• d.A gp3 EBS volume attached over the network to the instance

Instance store provides NVMe storage physically attached to the host for the highest local throughput and lowest latency, ideal for regenerable scratch data that need not persist. EBS and EFS add network overhead, and S3 object access is far too slow for high-churn intermediate shuffle files.

Thousands of small objects in S3 are read at very high request rates, and the team wants maximum request throughput per prefix. What is the recommended design practice?

• a.Store every object under one shared key prefix to simplify listing operations
• b.Enable S3 Versioning, which increases retained versions but does not raise request throughput
• c.Spread objects across multiple key prefixes so requests parallelize across S3 partitions✓
• d.Reduce the number of objects by concatenating them into one very large file that is re-downloaded each time

S3 scales request rate per prefix, so distributing keys across many prefixes lets reads and writes parallelize across partitions for higher aggregate throughput. Concentrating all objects under one prefix limits parallelism, versioning does not add throughput, and merging into one huge file harms selective read performance.

A shared file system mounted by many EC2 instances needs the highest per-operation performance and can tolerate storing data in a single Availability Zone. Which Amazon EFS configuration maximizes performance while cutting latency?

• a.Storing the shared data in S3 and syncing copies to each instance's local disk periodically
• b.EFS One Zone with the Max I/O performance mode where appropriate for the workload's parallelism✓
• c.Replacing EFS with individual EBS volumes on each instance so nothing is shared
• d.EFS Standard across multiple AZs configured for maximum I/O at the cost of higher per-operation latency

Choosing an EFS One Zone class removes cross-AZ latency and cost, and selecting the appropriate performance mode tunes throughput and I/O for the workload. Separate EBS volumes are not shared, and periodically syncing S3 copies introduces staleness and is not a concurrent POSIX file system.

A relational application needs single-digit millisecond query latency for a working set that fits in memory, and repeated identical queries are dominating database CPU. What most improves read performance with the least code change?

• a.Put an ElastiCache layer in front of the database to serve repeated query results from memory✓
• b.Add more storage capacity to the database volume to speed up query execution
• c.Provision a much larger database instance so more queries fit in its buffer pool over time
• d.Convert the relational schema to a NoSQL model to change how queries execute, so it does not satisfy the requirement described in this scenario

ElastiCache stores frequent query results in memory and serves repeated reads with sub-millisecond latency while offloading the database, requiring only modest application changes. Enlarging the instance or its storage does not specifically eliminate repeated identical queries, and rewriting to NoSQL is a major, unnecessary change.

A leaderboard feature needs an in-memory data store that natively supports sorted sets, atomic counters, and pub/sub messaging. Which ElastiCache engine should be chosen?

• a.ElastiCache for Memcached, which is a simple multi-threaded key-value cache without sorted sets or pub/sub
• b.Amazon Redshift, a data warehouse intended for large analytical queries rather than real-time counters
• c.Amazon RDS, a relational database that does not provide native in-memory leaderboard structures
• d.ElastiCache for Redis✓

ElastiCache for Redis supports rich data structures such as sorted sets (ideal for leaderboards), atomic counters, and pub/sub, all in memory. Memcached is a simpler key-value cache lacking these structures, RDS is relational, and Redshift is an analytics warehouse, none of which fit real-time leaderboard needs.

A dynamic API serves personalized responses that should not be cached, but its TLS handshakes and long round-trip times slow distant users. How can CloudFront still improve performance for this non-cacheable content?

• a.By storing each personalized response at the edge and returning identical content to every user
• b.By terminating connections at the edge and routing over the AWS backbone to the origin, reducing latency even with caching disabled✓
• c.By replacing the origin entirely so requests never reach the application servers, which makes it a poor fit for this particular workload
• d.It cannot help at all, because CloudFront only benefits static, cacheable content

Even with caching disabled, CloudFront terminates the client TLS connection at a nearby edge and forwards requests over the optimized AWS backbone to the origin, cutting round-trip latency for dynamic content. It does not (and must not) cache personalized responses or replace the origin application.

A DynamoDB-backed product catalog is read far more than it is written, and hot items are read millions of times per second, exceeding acceptable latency. Which addition delivers microsecond reads with minimal code change?

• a.Add DynamoDB Accelerator (DAX) in front of the table✓
• b.Add read replicas to the DynamoDB table to spread the read load across copies
• c.Front DynamoDB with a self-managed Redis cluster and write custom cache-population and invalidation logic
• d.Migrate the catalog to Amazon Redshift to serve the high read volume

DAX is a fully managed, DynamoDB-API-compatible in-memory cache that delivers microsecond read latency for hot items with little application change. A self-managed Redis layer requires custom caching logic, DynamoDB does not use read replicas that way, and Redshift is an analytics warehouse, not a low-latency key-value cache.

A relational OLTP application must scale reads across up to fifteen low-latency replicas and fail over in seconds, using a database that stores six copies of data across three Availability Zones. Which engine best fits?

• a.A self-managed PostgreSQL cluster on EC2 with manually configured streaming replicas
• b.Amazon Aurora✓
• c.Amazon Redshift, an analytical data warehouse not intended for OLTP replica scaling
• d.Amazon DynamoDB, a NoSQL key-value store rather than a relational OLTP engine

Aurora is MySQL- and PostgreSQL-compatible, supports up to fifteen low-latency read replicas, stores six copies of data across three AZs, and fails over in seconds. DynamoDB is NoSQL, Redshift is analytics, and a self-managed EC2 cluster would require building the replication and failover Aurora provides natively.

A globally distributed application needs a relational database with a primary write Region and secondary Regions serving reads with roughly one-second replication lag and fast cross-Region disaster recovery. Which option provides this natively?

• a.Amazon DynamoDB, which is not a relational engine for this SQL workload
• b.Manually configured cross-Region replication scripts running on EC2 database hosts
• c.Amazon Aurora Global Database✓
• d.A single-Region RDS instance with nightly snapshots copied to another Region

Aurora Global Database replicates a primary Region to secondary Regions with typically sub-second lag, provides local low-latency reads, and enables fast cross-Region failover. Snapshot copies give higher RPO, DynamoDB is not relational, and hand-built replication adds operational burden Aurora already solves.

A complex analytics workload runs large aggregations and joins over petabytes of structured data using SQL, and query performance on the operational database is unacceptable. Which purpose-built service should handle these analytics?

• a.Amazon DynamoDB, a NoSQL key-value store not designed for large multi-table analytical joins
• b.Amazon Redshift✓
• c.Amazon ElastiCache, an in-memory cache rather than an analytical query engine
• d.Amazon RDS for MySQL running the same queries on a larger single instance

Amazon Redshift is a columnar, massively parallel data warehouse built for fast SQL analytics over very large datasets, offloading heavy aggregations from operational databases. DynamoDB and ElastiCache are not analytical query engines, and a larger single RDS instance still struggles with petabyte-scale warehouse queries.