CCNA Design High-Performing Architectures Questions — Page 1 of 2

MCQeasy

A team runs a stateless web app on Amazon EC2 behind an Application Load Balancer. During traffic spikes, new EC2 instances take several minutes to finish bootstrapping before they can receive traffic. Which Auto Scaling configuration most directly reduces the time until additional capacity is available?

A.Increase the ALB target group deregistration delay.

B.Use an Auto Scaling warm pool so pre-initialized instances are ready to enter service.

C.Reduce the Auto Scaling group minimum size to one instance.

D.Replace the Application Load Balancer with a Network Load Balancer.

AnswerB

Warm pools keep instances pre-launched and initialized, which reduces the time needed to add capacity during spikes.

Why this answer

An Auto Scaling warm pool allows you to maintain a pool of pre-initialized instances that are ready to quickly enter the target group and start serving traffic. Instead of waiting for new instances to boot and configure during a scale-out event, the warm pool provides instances that have already completed bootstrapping, drastically reducing the time to additional capacity.

Exam trap

The trap here is that candidates may confuse the deregistration delay (which handles graceful connection draining) with a mechanism to speed up instance readiness, or they may incorrectly assume that reducing the minimum size or switching to a Network Load Balancer will improve scaling speed, when neither addresses the root cause of slow bootstrapping.

Why the other options are wrong

Increasing the deregistration delay only keeps existing connections alive longer; it does not speed up the bootstrapping of new instances, so it does not reduce the time until additional capacity is available.

Reducing the minimum size to one instance does not address the bootstrapping delay; it only lowers the baseline capacity, potentially worsening performance during traffic spikes.

Replacing the ALB with a Network Load Balancer does not address the bootstrapping delay of EC2 instances; NLB operates at layer 4 and does not affect instance initialization time.

Practice this question →

Multi-Selectmedium

A company is designing a high-performance database architecture for an e-commerce platform that experiences rapid spikes in read traffic during flash sales. The database must handle millions of reads per second with sub-millisecond latency. The data is key-value in nature, with a small number of attributes per item. Which three options should be included in the architecture? (Choose three.)

Select 3 answers

.Amazon DynamoDB as the primary database.

.Amazon RDS for MySQL with Multi-AZ and Read Replicas.

.DynamoDB Accelerator (DAX) as an in-memory cache.

.Amazon ElastiCache for Redis with cluster mode enabled.

.Amazon S3 as a primary data store accessed via Select and Range queries.

.Amazon Redshift with auto-scaling for real-time reads.

Why this answer

Amazon DynamoDB is a fully managed NoSQL key-value database that delivers single-digit millisecond latency at any scale, making it ideal for high-traffic e-commerce platforms with key-value data. DynamoDB Accelerator (DAX) is an in-memory cache that sits in front of DynamoDB, reducing read latency to microseconds for millions of reads per second. Amazon ElastiCache for Redis with cluster mode enabled provides a distributed in-memory cache that can offload read traffic from the primary database, further reducing latency and handling spikes during flash sales.

Exam trap

The trap here is that candidates often choose Amazon RDS with Read Replicas for read scaling, but they fail to recognize that relational databases cannot achieve sub-millisecond latency for millions of reads per second, and that DynamoDB with caching layers is the correct high-performance key-value solution.

Practice this question →

MCQmedium

A team serves static assets from an S3 origin through CloudFront. Cache hit ratio is low. Analytics show that requests include an Authorization header (even though the assets are public) and the cache key currently varies on that header, causing CloudFront to treat the same asset as different cache entries. What is the best change to improve cache hit ratio without breaking access controls?

A.Keep Authorization in the CloudFront cache key, but increase the origin response minimum TTL to 1 day.

B.Modify the CloudFront cache policy so the cache key does not include the Authorization header.

C.Switch the S3 origin from the current bucket to a website endpoint to enable automatic caching headers.

D.Enable CloudFront to forward all headers to S3 so origin can decide caching behavior per request.

AnswerB

CloudFront cache hit ratio depends on what constitutes a unique cache key. If Authorization is included, identical public assets requested with different Authorization values will map to different cache objects and reduce reuse. Removing Authorization from the cache key makes those requests share the same edge cache entry, improving hit ratio and reducing origin traffic. Because the scenario states the assets are public, removing Authorization from the cache key does not break access controls (access is not controlled by Authorization at the origin).

Why this answer

The low cache hit ratio is caused by the Authorization header being included in the CloudFront cache key, which creates separate cache entries for the same object even though the assets are public. By modifying the cache policy to exclude the Authorization header, CloudFront will treat all requests for the same asset as identical, dramatically improving the cache hit ratio without affecting access controls because the assets are already public.

Exam trap

The trap here is that candidates may think increasing TTL or changing the origin type will fix caching, when the real issue is the cache key composition—specifically, the Authorization header fragmenting the cache.

How to eliminate wrong answers

Option A is wrong because increasing the minimum TTL does not address the root cause—the cache key still varies on the Authorization header, so separate cache entries will persist and the cache hit ratio will remain low. Option C is wrong because switching to an S3 website endpoint does not change how CloudFront caches based on headers; the cache key is still controlled by the CloudFront cache policy, not the origin type. Option D is wrong because forwarding all headers to S3 would include the Authorization header in the cache key, making the problem worse by further fragmenting the cache.

Practice this question →

MCQeasy

A company runs a stateless web API on Amazon EC2 behind an Application Load Balancer. The team notices that during business hours, the ALB starts queueing requests and the average request latency rises. They want to scale out quickly and reliably based on demand, not CPU alone. Which Auto Scaling approach best matches this requirement?

A.Use a fixed-size Auto Scaling group and increase capacity manually once per hour.

B.Use target tracking scaling based on ALB request count per target.

C.Scale based only on EC2 instance memory utilization, regardless of load.

D.Use step scaling with a single threshold on average network-in bytes.

AnswerB

Target tracking can automatically adjust capacity using ALB load metrics and respond faster.

Why this answer

Target tracking scaling based on ALB request count per target directly measures the load on each instance, allowing the Auto Scaling group to add or remove instances to maintain a target value. This approach scales out quickly and reliably based on actual demand (request queuing and latency), not just CPU, which aligns with the requirement to respond to rising latency and queueing during business hours.

Exam trap

The trap here is that candidates often default to CPU-based scaling (a common but incomplete metric) or memory-based scaling, overlooking that for a stateless web API behind an ALB, request count per target is the most direct indicator of demand and latency issues.

How to eliminate wrong answers

Option A is wrong because manual scaling once per hour cannot react quickly to sudden demand spikes during business hours, leading to continued queueing and latency. Option C is wrong because scaling based solely on memory utilization ignores the actual request load and latency, and a stateless web API may not show memory pressure even when request queueing is high. Option D is wrong because step scaling with a single threshold on average network-in bytes is not directly correlated with request queueing or latency, and network-in can be influenced by factors other than application demand (e.g., large payloads), making it unreliable for scaling based on request count.

Practice this question →

MCQeasy

Based on the exhibit, the team wants to improve application performance without changing the code. Which EC2 instance family should they choose next?

A.Choose a compute-optimized instance family such as C6i to increase CPU performance.

B.Choose a memory-optimized instance family such as R6i to provide more RAM.

C.Choose a storage-optimized instance family such as I4i to improve block storage throughput.

D.Choose a burstable instance family such as T3 to reduce cost and improve performance.

AnswerB

Memory-optimized instances are the best fit when memory pressure is causing slowdowns. The exhibit shows CPU is low while memory is consistently near saturation, which strongly suggests the application needs more RAM rather than more compute. Moving to an R6i family should reduce paging and improve response times without changing the application design.

Why this answer

The exhibit shows that the application is experiencing high memory utilization (e.g., memory pressure or swapping), which degrades performance. Choosing a memory-optimized instance family such as R6i provides more RAM per vCPU, directly addressing the bottleneck without requiring code changes. This improves application performance by reducing or eliminating swap usage and allowing more data to be cached in memory.

Exam trap

The trap here is that candidates often assume 'improving performance' always means faster CPU or storage, but the exhibit’s memory utilization metric directly points to a memory bottleneck, making the memory-optimized family the correct choice despite the lack of explicit code changes.

How to eliminate wrong answers

Option A is wrong because compute-optimized instances (C6i) increase CPU performance, but the exhibit indicates the bottleneck is memory, not CPU; thus, more CPU would not resolve high memory utilization. Option C is wrong because storage-optimized instances (I4i) improve block storage throughput and IOPS, which is irrelevant if the performance issue stems from insufficient RAM rather than disk I/O. Option D is wrong because burstable instances (T3) are designed for workloads with low average CPU usage and can actually degrade performance under sustained high load due to CPU credit exhaustion; they do not address memory constraints and may worsen the problem.

Practice this question →

MCQmedium

Your company needs a high-throughput, low-latency TCP service using a custom binary protocol. Requirements: preserve the original client source IP for rate limiting, keep latency minimal, and use TCP health checks. The current setup uses an Application Load Balancer and performance is inconsistent. Which load balancer choice best meets these requirements?

A.Keep the Application Load Balancer (ALB), because ALBs also preserve client source IP for TCP protocols.

B.Use a Network Load Balancer (NLB) with TCP listeners so traffic stays at Layer 4 and the original source IP is preserved.

C.Use Amazon API Gateway because it preserves client source IP and provides TCP health checks for all protocols.

D.Use Amazon CloudFront with an S3 origin, because CloudFront reduces latency for TCP-based protocols.

AnswerB

NLB is designed for Layer 4 TCP/UDP traffic with very low latency and high throughput. It supports TCP health checks and preserves the original client source IP by default, which enables accurate client-IP-based rate limiting for a custom TCP protocol.

Why this answer

A Network Load Balancer (NLB) operates at Layer 4 and preserves the original client source IP by default, which is essential for accurate rate limiting. Its TCP listeners provide low-latency, high-throughput handling of custom binary protocols, and it supports TCP health checks natively. This directly addresses the performance inconsistency seen with the Application Load Balancer, which operates at Layer 7 and introduces additional processing overhead.

Exam trap

The trap here is that candidates often assume Application Load Balancers preserve client source IP for all protocols, but they only do so for HTTP/HTTPS traffic via the X-Forwarded-For header, not for raw TCP traffic, and they introduce higher latency due to Layer 7 processing.

How to eliminate wrong answers

Option A is wrong because an Application Load Balancer operates at Layer 7 (HTTP/HTTPS) and does not preserve the original client source IP for TCP traffic; it terminates the client connection and re-establishes a new one, so the source IP seen by the backend is the ALB's private IP. Option C is wrong because Amazon API Gateway is a fully managed service for creating RESTful and WebSocket APIs, not a load balancer; it does not support TCP listeners or TCP health checks, and it operates at Layer 7. Option D is wrong because Amazon CloudFront is a content delivery network (CDN) that caches content at edge locations, but it does not support TCP-based custom binary protocols (it works with HTTP/HTTPS and WebSocket) and cannot use an S3 origin for a TCP service; it also does not preserve the original client source IP for TCP traffic.

Practice this question →

Matchinghard

A company runs a stateless application tier behind an Application Load Balancer. Match each observed scaling pattern on the left to the best Auto Scaling strategy or metric on the right.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Scale the Auto Scaling group on ALB RequestCountPerTarget.

Scale on SQS queue depth using a custom CloudWatch metric.

Use scheduled scaling to add capacity before the recurring surge.

Use target tracking on EC2 CPUUtilization.

Why these pairings

Steady increase is best handled by step scaling for gradual adjustments; sudden spikes use simple scaling for immediate action; cyclical patterns benefit from scheduled scaling; consistent low traffic may not need scaling; unpredictable bursts are managed by target tracking to maintain a metric; gradual decrease uses simple scaling to reduce capacity.

Practice this question →

MCQmedium

A high-volume telemetry pipeline writes streaming click events that must be processed by multiple independent consumers. Which service is most appropriate?

A.Amazon Kinesis Data Streams

B.AWS DataSync

C.Amazon EBS

D.Amazon Route 53

AnswerA

Kinesis Data Streams supports high-throughput event ingestion with multiple consumers reading from the stream.

Why this answer

Amazon Kinesis Data Streams is the most appropriate service because it is designed for real-time streaming data ingestion and processing. It can capture and store terabytes of data per hour from hundreds of thousands of sources, such as click events, and allows multiple independent consumers to read and process the same stream concurrently using the Kinesis Client Library (KCL) or enhanced fan-out with dedicated throughput.

Exam trap

The trap here is that candidates may confuse Kinesis Data Streams with simpler messaging services like SQS or SNS, but the key differentiator is that Kinesis supports multiple independent consumers processing the same stream in real-time with replay capability, whereas SQS is designed for point-to-point message delivery and SNS for pub/sub with push-based fan-out.

How to eliminate wrong answers

Option B (AWS DataSync) is wrong because it is a data transfer service for moving large datasets between on-premises storage and AWS services, not for real-time streaming or multiple consumer processing. Option C (Amazon EBS) is wrong because it provides block-level storage volumes for EC2 instances, not a streaming data ingestion or processing capability. Option D (Amazon Route 53) is wrong because it is a DNS web service for domain name resolution and routing, not for handling streaming telemetry data.

Practice this question →

MCQeasy

A system uses multiple AWS Lambda functions behind different event sources. One Lambda occasionally spikes and causes other Lambdas to be throttled due to shared concurrency limits. Which setting best helps ensure the important Lambda keeps capacity during spikes?

A.Increase the function timeout so throttling is less likely.

B.Set Reserved Concurrency for the important Lambda function.

C.Enable Provisioned Concurrency for every Lambda in the account.

D.Reduce the number of IAM policies attached to the Lambda roles.

AnswerB

Reserved concurrency allocates a guaranteed amount of concurrent execution capacity to a specific Lambda. This prevents other functions from consuming all concurrency and throttling the important one. If the reserved limit is reached, only that function is throttled, isolating impact.

Why this answer

Reserved Concurrency guarantees that the important Lambda function always has a set number of concurrent executions available, preventing other functions from consuming the account-level concurrency pool and throttling it during spikes. This setting isolates the function's capacity from shared contention, ensuring its performance remains stable.

Exam trap

The trap here is confusing Provisioned Concurrency (which reduces cold starts) with Reserved Concurrency (which guarantees capacity), leading candidates to pick Option C even though it does not solve the throttling issue.

How to eliminate wrong answers

Option A is wrong because increasing the function timeout does not affect concurrency limits; it only extends the maximum execution duration, which could actually increase the chance of throttling by holding concurrency slots longer. Option C is wrong because Provisioned Concurrency pre-warms environments to reduce cold starts but does not reserve capacity against the shared concurrency limit; it still counts toward the account's total concurrency and does not prevent other functions from consuming the pool. Option D is wrong because reducing IAM policies affects permissions, not concurrency limits; it has no impact on Lambda's throttling behavior.

Practice this question →

MCQmedium

A global video platform serves mostly static images and JavaScript files from an S3 origin. Users in distant countries report slow load times. What should improve performance most? The architecture review board prefers a managed AWS-native control.

A.A larger S3 bucket

B.Amazon CloudFront distribution with the S3 bucket as origin

C.RDS read replicas

D.An EC2 Auto Scaling group in one Region

AnswerB

CloudFront caches content at edge locations close to users, reducing latency.

Why this answer

Amazon CloudFront is a global content delivery network (CDN) that caches static content (images, JavaScript) at edge locations closer to users, drastically reducing latency for distant countries. By using the S3 bucket as the origin, CloudFront offloads requests from S3 and accelerates delivery via HTTP/2, TCP optimizations, and persistent connections. This is the most effective managed AWS-native solution for improving global load times for static assets.

Exam trap

The trap here is that candidates may confuse scaling storage (larger bucket) or compute (Auto Scaling) with performance improvement, overlooking that latency for static content is primarily a network distance problem solved by a CDN like CloudFront.

How to eliminate wrong answers

Option A is wrong because increasing the S3 bucket size does not improve data transfer speed or reduce latency; S3 performance is independent of bucket size and is limited by the bucket's regional location. Option C is wrong because RDS read replicas are designed for scaling database read traffic, not for serving static files or accelerating HTTP content delivery. Option D is wrong because an EC2 Auto Scaling group in a single Region does not reduce latency for users in distant countries; it only provides regional scalability and fault tolerance, not global edge caching.

Practice this question →

MCQmedium

A DynamoDB table stores device status items. The partition key is deviceId, and the partition distribution is healthy (no single partition dominates). However, during peak periods the application experiences high read latency because many clients repeatedly request the latest status for the same devices. Which action best improves read latency without changing the DynamoDB partitioning model?

A.Add Amazon DAX as a caching layer in front of DynamoDB and route repeated read operations through DAX.

B.Change the partition key to a random value for each request to eliminate hot partitions.

C.Increase write capacity only, because writes generally determine read latency in DynamoDB.

D.Create an additional Global Secondary Index (GSI) and read exclusively from the index to accelerate reads.

AnswerA

Amazon DAX is an in-memory caching layer for DynamoDB that accelerates repeated reads. When many clients request the same items (for example, “latest status” point reads by deviceId), DAX can serve cached responses directly, reducing round trips to DynamoDB and lowering read latency during peak periods.

Why this answer

Amazon DAX is a fully managed, in-memory cache for DynamoDB that provides microsecond read latency. By caching the results of repeated GetItem and Query requests for the same device status items, DAX offloads read traffic from the underlying DynamoDB table, reducing the number of read capacity units consumed and eliminating the latency caused by repeated fetches from disk. This directly addresses the high read latency during peak periods without altering the existing partition key or partitioning model.

Exam trap

The trap here is that candidates may think a GSI can magically speed up reads, but GSIs do not provide caching and still read from the same storage layer, so they do not reduce latency for repeated identical queries.

Why the other options are wrong

Increasing write capacity does not reduce read latency; read latency is affected by read capacity and throttling, not write capacity. The problem is high read demand on the same items, which write capacity cannot address.

Creating a GSI does not reduce read latency for repeated requests to the same items; it only provides an alternate query pattern. The hot partition issue is caused by high read frequency on specific items, which a GSI does not alleviate.

Practice this question →

MCQmedium

A containerized service fleet running on EC2 instances needs to share user-uploaded files and access them with low latency. The workload is bursty: sometimes dozens of instances concurrently read the same directory for short periods, and then traffic drops. Which Amazon EFS configuration best matches these performance needs?

A.Use Amazon EFS General Purpose performance mode and Throughput mode set to Bursting.

B.Use Amazon EFS Max I/O performance mode with Throughput mode set to Provisioned.

C.Use Amazon EFS General Purpose performance mode with Throughput mode set to Provisioned.

D.Use Amazon EFS Max I/O performance mode with Throughput mode set to Bursting.

AnswerA

EFS General Purpose performance mode is designed for latency-sensitive use cases with a broad range of I/O sizes, including typical file-sharing and web-content workloads. Throughput mode Bursting provides baseline throughput and allows throughput to scale up during demand spikes, which matches the pattern of short read bursts from many instances. When traffic drops, the system returns to baseline without requiring you to provision peak throughput for all time.

Why this answer

The workload is bursty with concurrent reads of the same directory, which favors the General Purpose performance mode for its strong consistency and lower latency per operation. The Bursting Throughput mode is ideal for bursty traffic as it allows the file system to accumulate burst credits during idle periods and consume them during high-demand spikes, matching the described pattern without incurring additional costs.

Exam trap

The trap here is that candidates often assume Max I/O is always better for high concurrency, but they overlook that General Purpose mode provides lower latency and stronger consistency for directory-heavy bursty reads, which is the actual requirement.

How to eliminate wrong answers

Option B is wrong because Max I/O performance mode is designed for highly parallelized workloads (e.g., thousands of instances) but sacrifices consistency and can introduce higher per-operation latency, which is not suitable for low-latency access to the same directory. Option C is wrong because Provisioned Throughput mode is intended for steady-state throughput requirements and would waste cost on a bursty workload that could use Bursting mode's credit-based model. Option D is wrong because Max I/O performance mode is not optimal for low-latency, directory-heavy access patterns, and while Bursting mode fits the bursty nature, the combination with Max I/O undermines the low-latency requirement.

Practice this question →

MCQeasy

A customer-facing application has a relational data model and needs frequent complex queries (joins and aggregations), but it also experiences a significant read-heavy workload. Which design choice best improves read performance while keeping relational features?

A.Use DynamoDB with a single partition key and avoid indexes to keep writes simple.

B.Add read replicas to an RDS or Aurora cluster and keep the primary for writes.

C.Store the data in S3 and query it directly from the application without a database.

D.Switch the database to DynamoDB but keep using the same relational SQL queries and joins.

AnswerB

Read replicas offload read operations from the primary database instance, improving read throughput and reducing contention with writes. RDS/Aurora preserve relational capabilities like joins and SQL queries. This is a common and practical way to scale performance for read-heavy workloads without completely changing the data model.

Why this answer

Adding read replicas to an RDS or Aurora cluster offloads read traffic from the primary instance, improving read performance for complex queries (joins and aggregations) while preserving the full relational data model and SQL capabilities. Aurora’s distributed storage layer also allows replicas to serve reads with minimal replication lag, making this the optimal choice for read-heavy workloads that require relational features.

Exam trap

The trap here is that candidates often assume NoSQL (DynamoDB) is always the best choice for read-heavy workloads, overlooking that complex relational queries and joins are not supported, making read replicas on RDS/Aurora the correct relational scaling solution.

Why the other options are wrong

DynamoDB is a NoSQL database that does not support complex joins and aggregations natively, and using a single partition key without indexes would severely limit query flexibility and performance for the required relational queries.

S3 is an object store, not a relational database; it cannot support complex joins, aggregations, or relational queries, making it unsuitable for the application's relational data model and frequent complex queries.

DynamoDB is a NoSQL database that does not support relational SQL queries or joins. Attempting to use relational queries on DynamoDB would fail or require significant application-level workarounds, defeating the purpose of keeping relational features.

Practice this question →

MCQhard

A DynamoDB table for a travel booking site has a partition key based only on the current date. Write throttling occurs during business hours. What is the best design change? The design must avoid adding custom operational scripts.

A.Create a global secondary index with the same date key

B.Move the table to S3 Glacier Instant Retrieval

C.Reduce the table's write capacity

D.Use a higher-cardinality partition key that distributes writes across partitions

AnswerD

A low-cardinality hot partition causes throttling; a better key spreads writes more evenly.

Why this answer

Using a low-cardinality partition key like the current date causes all writes to land on a single partition, leading to throttling. By designing a higher-cardinality key (e.g., combining date with a random suffix or user ID), writes are distributed evenly across partitions, fully utilizing the provisioned write capacity without custom scripts.

Exam trap

The trap here is that candidates may think adding a GSI (Option A) solves the issue, but GSIs inherit the same partition key design flaws and can also throttle independently.

How to eliminate wrong answers

Option A is wrong because a global secondary index (GSI) with the same date key would still concentrate writes on a single partition in the index, replicating the throttling issue. Option B is wrong because S3 Glacier Instant Retrieval is a storage class for infrequently accessed objects, not a replacement for DynamoDB's transactional write throughput, and moving the table would break the application's access pattern. Option C is wrong because reducing write capacity would worsen throttling during business hours, not solve the underlying partition hot-spotting problem.

Practice this question →

Multi-Selecthard

A retail analytics table stores events in Amazon DynamoDB with partition key tenantId and sort key eventTime. During a promotion, one tenant generates most writes and repeatedly polls the same latest-status items, causing throttling on a single partition key and high latency on reads. The business can tolerate read results that are a few seconds stale. Which two changes will most effectively reduce throttling and latency? Select two.

Select 2 answers

A.Introduce write sharding by adding a bounded random suffix to the hot tenant partition key and fan out reads across the shards.

B.Add DynamoDB Accelerator (DAX) in front of the table for the repeated status reads.

C.Keep the same key design and increase only the table’s provisioned RCUs and WCUs.

D.Replace the table reads with a Scan operation to distribute the load across all partitions.

E.Move the table to another Availability Zone so the hot tenant uses a different storage node.

AnswersA, B

Sharding spreads the hot tenant’s traffic across multiple partitions so DynamoDB is no longer forced to serve all writes through one physical partition. Querying across the shard set restores access to the tenant’s data while reducing throttling. This is the standard fix when a single partition key becomes a hot spot.

Why this answer

Write sharding distributes the hot tenant's writes across multiple partitions by appending a bounded random suffix to the partition key, preventing a single partition from throttling. Reads then fan out across all shards and aggregate results, which is acceptable since the business tolerates a few seconds of staleness. This directly addresses the single-partition bottleneck without changing the overall data model.

Exam trap

The trap here is that candidates often assume DAX alone can fix both read and write throttling, but DAX only caches reads and does not address the write-side partition bottleneck that causes throttling in the first place.

Practice this question →

Multi-Selecthard

A media company serves versioned JavaScript and CSS files from Amazon S3 through CloudFront. After each release, the cache hit ratio drops sharply because the same distribution also fronts a personalized API path, and the current cache policy forwards cookies, all query strings, and several headers to every origin request. The static assets already use content-hashed filenames. Which two changes will most directly improve cache hit ratio for the static assets without changing the application behavior? Select two.

Select 2 answers

A.Create a dedicated cache behavior for the static asset path that excludes cookies, query strings, and unneeded headers from the cache key.

B.Keep the content-hashed filenames and send long Cache-Control max-age and immutable headers for the versioned objects.

C.Increase the size of the S3 bucket’s underlying storage to absorb more origin traffic.

D.Add Lambda@Edge logic to append a timestamp to every asset request so updates are always fetched immediately.

E.Disable compression so CloudFront can treat each object as a separate cache entry.

AnswersA, B

Separating the static asset behavior lets CloudFront cache those objects independently from the personalized API. Excluding cookies, query strings, and unnecessary headers prevents cache fragmentation, so many viewers can reuse the same cached object. This is the most direct way to raise hit ratio without altering how the application serves assets.

Why this answer

Creating a dedicated cache behavior for the static asset path (e.g., /static/*) allows you to configure a cache policy that excludes cookies, query strings, and unneeded headers from the cache key. Since the static assets use content-hashed filenames, they are immutable and do not vary by user-specific attributes. By removing these variables from the cache key, CloudFront can serve the same cached object to all users, drastically improving the cache hit ratio.

Exam trap

The trap here is that candidates may think that content-hashed filenames alone guarantee high cache hit ratios, but they overlook that the shared cache policy forwarding cookies and query strings creates many unique cache keys for the same static file, negating the benefit of hashed filenames.

Practice this question →

MCQhard

A media archive needs low-latency full-text search across product descriptions and filtered attributes. Which managed service is most suitable? The design must avoid adding custom operational scripts.

A.AWS Config

B.Amazon OpenSearch Service

C.Amazon EFS

D.Amazon SQS

AnswerB

OpenSearch is designed for search and analytics over indexed text and structured fields.

Why this answer

Amazon OpenSearch Service is the correct choice because it provides managed, low-latency full-text search capabilities with support for filtering on structured attributes (e.g., product categories, price ranges). It indexes JSON documents and exposes a RESTful API for search queries, eliminating the need for custom operational scripts while meeting the media archive's requirements.

Exam trap

The trap here is that candidates might confuse AWS Config's resource tracking or EFS's file storage with search capabilities, overlooking that OpenSearch Service is the only managed option purpose-built for full-text search and filtering.

How to eliminate wrong answers

Option A is wrong because AWS Config is a service for auditing and evaluating resource configurations against compliance rules, not for full-text search or indexing product descriptions. Option C is wrong because Amazon EFS is a scalable NFS file system for shared storage, not a search engine; it cannot perform low-latency full-text queries across text content. Option D is wrong because Amazon SQS is a managed message queue for decoupling application components, not a search or indexing service, and it does not support querying stored data.

Practice this question →

MCQhard

Based on the exhibit, which storage choice best matches the workload requirements?

A.Use io2 EBS volumes because they provide the highest durable block storage performance.

B.Use instance store NVMe for the temporary processing workspace.

C.Use Amazon EFS for the workspace so the temporary files survive instance replacement.

D.Use S3 as the working directory and read and write the intermediate files directly there.

AnswerB

Instance store fits a high-IOPS scratch workload where data can be lost safely and rebuilt from S3. The benchmark shows extremely low latency and very high random I/O performance, which is ideal for intermediate transcode files. Because the job can be retried from the source object, persistence is not needed on the local workspace.

Why this answer

Instance store NVMe volumes provide temporary, ephemeral block storage directly attached to the EC2 instance, offering extremely low latency and high throughput for temporary processing workspaces. Since the workload requires a temporary workspace where data does not need to persist beyond the instance lifecycle, instance store is the optimal choice because it avoids the cost and overhead of durable storage while delivering the highest performance for scratch data.

Exam trap

The trap here is that candidates often choose durable storage options like EBS or EFS because they are familiar and seem 'safer,' failing to recognize that the workload explicitly requires a temporary workspace where data does not need to persist, making instance store the most performant and cost-effective choice.

How to eliminate wrong answers

Option A is wrong because io2 EBS volumes are designed for durable, persistent block storage with high IOPS and durability, which is unnecessary and cost-inefficient for temporary processing data that does not require persistence. Option C is wrong because Amazon EFS is a durable, shared file system that persists across instance replacements, which contradicts the requirement for a temporary workspace where files should not survive instance replacement. Option D is wrong because using S3 as a working directory for intermediate files introduces significant latency and throughput limitations due to S3's object storage API and eventual consistency model, making it unsuitable for high-frequency read/write operations in a temporary processing workspace.

Practice this question →

MCQhard

Based on the exhibit, which design change is the best way to reduce the observed read latency for this DynamoDB-backed service?

A.Add a DynamoDB Accelerator (DAX) cluster in front of the table and send repeated read traffic through it.

B.Increase the on-demand table limits so DynamoDB can automatically absorb more traffic.

C.Create a global secondary index on tenantId to distribute the load across more partitions.

D.Move the dashboard data into S3 and use Lambda functions to read it on demand.

AnswerA

DAX is designed to accelerate repeated eventually consistent reads from DynamoDB by caching hot items in memory. The exhibit shows one tenant driving most of the reads and the same dashboard items being requested repeatedly within a short window, which is an excellent fit for DAX. It reduces latency and offloads the hot key without requiring a schema redesign.

Why this answer

Adding a DynamoDB Accelerator (DAX) cluster in front of the table reduces read latency by providing an in-memory cache that serves repeated read requests with microsecond response times, bypassing the need to read from the underlying DynamoDB table's SSD storage. This directly addresses the observed latency issue for frequently accessed data, as DAX is optimized for read-heavy workloads and supports eventual and strong consistency reads.

Exam trap

The trap here is that candidates confuse increasing throughput capacity (Option B) with reducing latency, not realizing that DynamoDB's storage latency is fixed and that caching (DAX) is the correct solution for repeated read-heavy workloads.

How to eliminate wrong answers

Option B is wrong because increasing on-demand table limits does not inherently reduce read latency; on-demand scaling handles throughput capacity but does not improve the per-request latency of DynamoDB's storage layer. Option C is wrong because creating a global secondary index (GSI) on tenantId distributes read load across partitions but does not cache data; it still requires reading from DynamoDB's storage, which does not reduce latency for repeated reads. Option D is wrong because moving dashboard data to S3 and using Lambda to read it on demand introduces additional latency from S3 GET requests and Lambda cold starts, which is typically slower than DynamoDB's single-digit millisecond reads, especially for repeated access patterns.

Practice this question →

Multi-Selecthard

A latency-sensitive video platform uploads large files to S3 from users around the world. Which two features can improve upload performance? The architecture review board prefers a managed AWS-native control.

Select 2 answers

A.S3 Object Lock

B.S3 Transfer Acceleration

C.S3 multipart upload

D.S3 Inventory

AnswersB, C

Transfer Acceleration uses optimized edge paths into AWS for long-distance S3 transfers.

Why this answer

S3 Transfer Acceleration (B) uses AWS edge locations to accelerate uploads over long distances by routing traffic through the AWS global network, reducing latency and packet loss compared to the public internet. Multipart upload (C) improves performance by splitting large files into smaller parts that can be uploaded in parallel, increasing throughput and allowing retries of individual parts without restarting the entire upload.

Exam trap

The trap here is that candidates may confuse S3 Transfer Acceleration with CloudFront or think multipart upload is only for reliability, not performance, while overlooking that both features are managed AWS-native controls that directly address latency and throughput for large file uploads.

Practice this question →

MCQeasy

A compute workload uses temporary scratch space for intermediate results (reproducible), and it can tolerate data loss if the instance is terminated. The workload benefits from very high local I/O throughput. Which storage option is the best fit for the scratch data?

A.Amazon EBS General Purpose (gp3) volumes to persist intermediate results across reboots.

B.Amazon EFS for a shared file system between multiple instances.

C.Instance store for local temporary files that can be lost when the instance stops.

D.Amazon S3 for scratch data so it is always durable and accessible from anywhere.

AnswerC

Instance store is designed for temporary high-performance local storage and is acceptable when loss is tolerable.

Why this answer

Instance store volumes provide very high local I/O throughput because they are physically attached to the host server, making them ideal for temporary scratch data that is reproducible and can tolerate loss. Since the workload explicitly accepts data loss on instance termination and does not require persistence across reboots, instance store is the best fit for this use case.

Exam trap

The trap here is that candidates often choose EBS gp3 (Option A) because they assume all block storage is persistent and high-performance, overlooking the fact that instance store offers even higher local throughput and is explicitly designed for temporary, loss-tolerant workloads.

Why the other options are wrong

Amazon EFS provides a shared file system, but the question specifies scratch data for a single instance that benefits from very high local I/O throughput. EFS is network-attached and has higher latency than local storage, making it unsuitable for high local I/O needs.

Amazon S3 is designed for durable, highly available object storage with high latency, not for high local I/O throughput scratch space. It cannot provide the very high local I/O performance required for temporary scratch data.

Practice this question →

MCQmedium

A global mobile game backend serves mostly static images and JavaScript files from an S3 origin. Users in distant countries report slow load times. What should improve performance most? The architecture review board prefers a managed AWS-native control.

A.RDS read replicas

B.Amazon CloudFront distribution with the S3 bucket as origin

C.A larger S3 bucket

D.An EC2 Auto Scaling group in one Region

AnswerB

CloudFront caches content at edge locations close to users, reducing latency.

Why this answer

Amazon CloudFront is a global content delivery network (CDN) that caches static content (images, JavaScript) at edge locations close to users, drastically reducing latency. By using the S3 bucket as the origin, CloudFront offloads requests from S3 and serves cached objects from the nearest edge, which directly addresses slow load times for distant users. This is a managed AWS-native service that aligns with the architecture review board's preference.

Exam trap

The trap here is that candidates may think increasing S3 bucket size or using RDS replicas can improve static content delivery, but the core issue is geographic latency, which only a CDN like CloudFront can solve by caching content at edge locations.

How to eliminate wrong answers

Option A is wrong because RDS read replicas are designed to offload read traffic from a relational database, not to accelerate delivery of static files stored in S3; they have no effect on S3 latency. Option C is wrong because increasing the S3 bucket size does not improve data transfer speed or reduce latency; S3 performance is independent of bucket size and is limited by regional endpoints. Option D is wrong because an EC2 Auto Scaling group in a single Region does not provide geographic distribution; users in distant countries would still experience high latency connecting to that single Region, and it adds unnecessary compute overhead for serving static content.

Practice this question →

MCQmedium

A high-volume analytics dashboard writes streaming click events that must be processed by multiple independent consumers. Which service is most appropriate?

A.Amazon Route 53

B.Amazon EBS

C.Amazon Kinesis Data Streams

D.AWS DataSync

AnswerC

Kinesis Data Streams supports high-throughput event ingestion with multiple consumers reading from the stream.

Why this answer

Amazon Kinesis Data Streams is the most appropriate service because it is designed for real-time streaming data ingestion and can be consumed by multiple independent consumers in parallel. Each shard within a Kinesis stream supports up to 5 read transactions per second and a total data read rate of 2 MB per second, allowing multiple consumer applications to process the same stream of click events concurrently without interfering with each other.

Exam trap

The trap here is that candidates often confuse Amazon Kinesis Data Streams with Amazon SQS or Amazon SNS, but SQS is a message queue for decoupled point-to-point communication and SNS is a pub/sub notification service, neither of which natively supports multiple independent consumers processing the same stream of data with replay capability.

How to eliminate wrong answers

Option A is wrong because Amazon Route 53 is a DNS web service that translates domain names to IP addresses and does not ingest or process streaming data. Option B is wrong because Amazon EBS provides block-level storage volumes for EC2 instances and cannot natively support multiple independent consumers reading a continuous stream of events. Option D is wrong because AWS DataSync is a data transfer service for moving large datasets between on-premises storage and AWS services, not for real-time streaming event processing.

Practice this question →

MCQmedium

Your company currently uses an Application Load Balancer (ALB) in front of a service that receives a large number of TCP and UDP packets (including UDP-based telemetry). During load tests, you need to support both TCP and UDP traffic at high throughput while keeping stable IP endpoints for a downstream firewall allowlist. Which change best meets these requirements?

A.Switch to a Network Load Balancer (NLB) configured for TCP/UDP, and use Elastic IPs to provide stable endpoint IP addresses for allowlisting.

B.Keep the ALB and add an AWS WAF Web ACL to improve throughput and add static IP support.

C.Replace the ALB with an API Gateway REST API to support UDP because API Gateway can forward UDP packets.

D.Use an Auto Scaling group with multiple EC2 instances and no load balancer to avoid any networking bottlenecks.

AnswerA

NLB operates at Layer 4 and supports both TCP and UDP. For stable IP allowlists, you can associate Elastic IP addresses with the NLB so the load balancer exposes consistent IPs (as opposed to relying on dynamic addresses). This combination directly satisfies protocol support and stable endpoint requirements.

Why this answer

A Network Load Balancer (NLB) operates at Layer 4 and can handle both TCP and UDP traffic natively, unlike an ALB which only supports HTTP/HTTPS and cannot forward UDP packets. By assigning Elastic IPs to the NLB, you provide stable, static IP endpoints that can be added to a downstream firewall allowlist, meeting both the protocol and throughput requirements.

Exam trap

The trap here is that candidates assume an ALB can handle all traffic types because it is the most commonly used load balancer, but they forget that ALB is strictly Layer 7 and cannot process UDP packets, making the NLB the only correct choice for mixed TCP/UDP workloads requiring static IPs.

How to eliminate wrong answers

Option B is wrong because an ALB cannot handle UDP traffic (it only supports HTTP/HTTPS and WebSocket), and AWS WAF does not add static IP support or improve throughput for Layer 4 traffic. Option C is wrong because API Gateway REST APIs do not support UDP traffic; they only handle HTTP/HTTPS and WebSocket protocols. Option D is wrong because removing the load balancer eliminates the stable IP endpoint required for the firewall allowlist and introduces a single point of failure, while also not addressing the need for high-throughput TCP/UDP handling with a consistent front-end IP.

Practice this question →

MCQhard

Based on the exhibit, which change best reduces latency during peak traffic without overprovisioning the fleet?

A.Replace the instances with a larger instance family so each server has more headroom.

B.Change the Auto Scaling policy to target tracking on ALB RequestCountPerTarget.

C.Use scheduled scaling to add instances only during the business hours peak window.

D.Replace the ALB with a Network Load Balancer to reduce request latency.

AnswerB

RequestCountPerTarget matches the actual demand reaching each instance and scales capacity before the thread pool saturates. Because CPU is still low, CPU-based scaling would react too late or not at all. Target tracking on request count helps keep queue depth and latency down while avoiding unnecessary overprovisioning during quieter periods.

Why this answer

Using a target tracking scaling policy on ALB RequestCountPerTarget dynamically adjusts the fleet size based on the actual number of requests each instance receives. This ensures that during peak traffic, additional instances are added only when needed, reducing latency by distributing the load without overprovisioning. It directly addresses the goal of minimizing latency during spikes while maintaining cost efficiency.

Exam trap

The trap here is that candidates confuse reducing latency with scaling the fleet, often choosing a load balancer change (Option D) or a static instance upgrade (Option A) instead of recognizing that dynamic scaling based on per-target request count is the correct method to handle peak traffic without overprovisioning.

Why the other options are wrong

Replacing instances with a larger family increases headroom but does not dynamically adjust capacity based on actual traffic patterns, leading to overprovisioning during off-peak hours and not specifically addressing latency during peak traffic.

Scheduled scaling adds instances only during a fixed time window, but peak traffic may vary day-to-day or occur outside business hours, leading to either underprovisioning or overprovisioning. It does not dynamically adapt to actual traffic patterns.

Replacing the ALB with a Network Load Balancer reduces latency at the network layer but does not address the root cause of latency during peak traffic, which is insufficient compute capacity. The question asks for a change to reduce latency without overprovisioning, and NLB does not affect the fleet's ability to handle request load.

Practice this question →

MCQeasy

A web service runs on an Auto Scaling group (ASG). The team updates configuration (AMIs, environment variables) in a Launch Template and wants new instances created during scale-out to use the latest Launch Template version. What should the architect do?

A.Leave the ASG attached to the previous Launch Template version so scale-out is stable.

B.Set the ASG to use the latest Launch Template version and optionally start an instance refresh for existing instances.

C.Manually SSH into each new instance and reconfigure it after it launches.

D.Move the configuration changes into a security group rule so the ASG updates them automatically.

AnswerB

ASG scale-out uses the configured Launch Template version at instance launch time. Switching the ASG to the latest version ensures new instances are consistent. An instance refresh helps apply changes to running instances safely and predictably.

Why this answer

The Auto Scaling group can be configured to use the latest version of a launch template by specifying the `$Latest` version. This ensures that any new instances launched during scale-out automatically use the most recent configuration. Additionally, an instance refresh can be initiated to update existing instances to the latest template version without manual intervention.

Exam trap

The trap here is that candidates may think the ASG automatically updates existing instances when the launch template is updated, but in reality, only new instances launched after the update use the new version unless an instance refresh is explicitly triggered.

How to eliminate wrong answers

Option A is wrong because leaving the ASG attached to a previous launch template version means new instances will not receive the updated configuration, defeating the purpose of updating the template. Option C is wrong because manually SSHing into each new instance is not scalable, violates infrastructure-as-code principles, and is error-prone in an auto-scaling environment. Option D is wrong because security group rules control network traffic, not instance configuration (such as AMIs or environment variables), and cannot propagate launch template changes.

Practice this question →

Multi-Selecthard

A distributed analytics engine runs 12 EC2 instances in one Availability Zone. The nodes exchange thousands of tiny messages per second and must keep jitter as low as possible. The current design launches the instances across multiple placement groups and uses general-purpose burstable instances. Which two changes will most directly lower east-west network latency and variability? Select two.

Select 2 answers

A.Move all instances into a cluster placement group.

B.Use instance families that provide high network bandwidth and support enhanced networking.

C.Spread the instances across three Availability Zones for better fault tolerance.

D.Front the nodes with an Application Load Balancer to balance the internal messages.

E.Store the messages on EBS volumes so the nodes avoid network communication.

AnswersA, B

Cluster placement groups pack instances closely together in a single Availability Zone, which minimizes network distance and improves latency consistency. This is the best placement strategy when the workload is highly chatty and needs very low jitter between nodes. It directly targets east-west performance.

Why this answer

A cluster placement group provides a low-latency, high-bandwidth network connection by placing instances in a single Availability Zone within the same logical rack or cluster. This minimizes the physical distance and network hops between instances, directly reducing east-west latency and jitter for the thousands of tiny messages per second.

Exam trap

The trap here is that candidates often confuse 'fault tolerance' (spreading across AZs) with 'performance' (cluster placement group), or they mistakenly think a load balancer can optimize internal node-to-node traffic, when in fact it adds latency and is designed for client-facing traffic.

Practice this question →

MCQmedium

A media processing service runs ECS tasks in multiple Availability Zones. Each task must read and write the same shared filesystem with low latency because tasks stream intermediate artifacts to other tasks. The team currently mounts an EBS volume per task, and cross-AZ tasks frequently cannot see each other’s files. Which option best resolves the shared filesystem requirement while supporting high-performing access?

A.Keep using EBS, but attach the same EBS volume to tasks in multiple Availability Zones using EBS multi-attach so all tasks share the filesystem.

B.Use Amazon EFS with mount targets in each Availability Zone so all tasks mount a common NFS filesystem over the AWS network.

C.Use Amazon S3 for the intermediate artifacts and rely on S3 event notifications to emulate POSIX file operations.

D.Switch to instance store on each task and use SQS messages between tasks to copy intermediate artifacts.

AnswerB

EFS is designed for shared, NFS-like file storage that can be mounted concurrently from compute resources across multiple Availability Zones. By creating mount targets in each AZ used by the ECS tasks, you enable low-latency network access patterns so tasks can read and write the same shared filesystem reliably.

Why this answer

Amazon EFS provides a fully managed, shared NFS filesystem that can be mounted concurrently by ECS tasks across multiple Availability Zones with low latency. It supports POSIX file operations, making it ideal for streaming intermediate artifacts between tasks. EFS mount targets in each AZ ensure local access, meeting the requirement for high-performing shared storage.

Exam trap

The trap here is that candidates may assume EBS multi-attach works across Availability Zones, but it is strictly limited to a single AZ and requires specific instance types, making it unsuitable for multi-AZ shared filesystem requirements.

Why the other options are wrong

EBS multi-attach does not support attaching a single volume to instances across different Availability Zones; it only works within a single AZ. Therefore, cross-AZ tasks cannot share the same EBS volume.

S3 does not provide a POSIX-compliant shared filesystem with low-latency file locking and immediate consistency needed for streaming intermediate artifacts between tasks; it is an object store, not a filesystem.

Instance store is ephemeral and not shared across tasks, so tasks in different AZs cannot access a common filesystem. SQS message copying adds latency and complexity, failing the low-latency shared filesystem requirement.

Practice this question →

MCQeasy

A media company uses CloudFront in front of an S3 bucket origin for video thumbnails. They want to prevent users from bypassing CloudFront and accessing the S3 bucket directly, while still allowing CloudFront to fetch objects. What is the best option?

A.Keep the bucket public and rely on signed cookies for all thumbnail requests.

B.Use CloudFront Origin Access Control (OAC) or Origin Access Identity (OAI) and update the bucket policy to allow only CloudFront.

C.Enable S3 static website hosting so users access thumbnails directly from the S3 website endpoint.

D.Set S3 bucket permissions to allow all IAM users and block access only by using a WAF rule at CloudFront.

AnswerB

OAC/OAI ensures only CloudFront can access the bucket while keeping the bucket private.

Why this answer

CloudFront Origin Access Control (OAC) or Origin Access Identity (OAI) allows you to restrict direct access to an S3 bucket by configuring the bucket policy to grant read permissions only to the CloudFront distribution's service principal. This ensures that users can only retrieve thumbnails through CloudFront, leveraging its caching and security features, while blocking any direct S3 requests.

Exam trap

The trap here is that candidates often think signed cookies or URLs alone are sufficient to secure direct S3 access, but they forget that those mechanisms only control access through CloudFront and do not restrict the S3 bucket's public endpoint unless the bucket policy explicitly denies direct access.

Why the other options are wrong

Keeping the bucket public allows anyone with the S3 URL to access thumbnails directly, bypassing CloudFront. Signed cookies control access via CloudFront but do not prevent direct S3 access, so this fails to meet the requirement.

Enabling S3 static website hosting exposes the S3 bucket via its website endpoint, allowing users to bypass CloudFront and access thumbnails directly, which violates the requirement to prevent direct access.

WAF rules at CloudFront can block certain requests but do not prevent direct access to the S3 bucket; users could still bypass CloudFront and access the bucket directly if the bucket policy allows it.

Practice this question →

MCQeasy

An ECS service runs on EC2 capacity. During peak traffic, tasks frequently wait for available container instances. The team wants faster scale-out for the underlying EC2 capacity when tasks increase. What is the best first architectural step?

A.Tune the container health check settings so tasks stop failing and stay running.

B.Use an ECS capacity provider (or Auto Scaling integration) to scale the EC2 instances based on ECS demand.

C.Pin all tasks to a single Availability Zone to reduce placement overhead.

D.Switch the tasks to run only on Fargate so EC2 scaling is no longer relevant.

AnswerB

When ECS tasks need compute, capacity must scale at the EC2 layer so there are enough container instances to place tasks. Integrating ECS with an Auto Scaling capacity provider allows the cluster to scale out in response to pending tasks. This reduces waiting time and improves responsiveness under load.

Why this answer

An ECS capacity provider (or Auto Scaling integration) directly links ECS task-level demand to EC2 instance scaling. When tasks are pending due to insufficient container instances, the capacity provider triggers a scale-out event on the Auto Scaling group, adding EC2 instances to accommodate the workload. This is the most efficient architectural step to reduce placement delays during peak traffic.

Exam trap

The trap here is that candidates may confuse task-level scaling (e.g., Service Auto Scaling) with infrastructure-level scaling, and incorrectly assume that tuning health checks or placement strategies will resolve a capacity shortage caused by insufficient EC2 instances.

Why the other options are wrong

Tuning health check settings does not address the root cause of tasks waiting for EC2 capacity; it only affects task stability, not instance availability.

Pinning tasks to a single Availability Zone does not address the root cause of insufficient EC2 capacity; it actually reduces fault tolerance and may increase placement constraints, making scaling slower.

Switching to Fargate eliminates EC2 scaling concerns but does not address the existing EC2 capacity scaling issue; the question specifically asks for faster scale-out of underlying EC2 capacity, not a migration to a different compute type.

Practice this question →

MCQeasy

Based on the exhibit, which AWS feature should the team use to minimize network latency between EC2 instances that exchange messages very frequently?

A.Use a spread placement group to maximize instance separation across hardware.

B.Use a cluster placement group to place instances close together.

C.Use a partition placement group to distribute instances across many partitions.

D.Use multiple Auto Scaling groups to spread traffic across more subnets.

AnswerB

A cluster placement group is designed for workloads that need very low network latency and high packet-per-second performance between instances. The exhibit describes frequent small-message traffic and a need for the lowest possible latency, which makes a cluster placement group the right choice. It keeps instances physically close in the AWS network for faster communication.

Why this answer

A cluster placement group is the correct choice because it groups EC2 instances within a single Availability Zone with low-latency, high-bandwidth networking, achieving single-digit millisecond latency between instances. This is ideal for applications that exchange messages very frequently, as it minimizes network hops and maximizes throughput.

Exam trap

The trap here is that candidates may confuse placement group types, incorrectly assuming a spread or partition group reduces latency when they actually prioritize fault isolation over network performance.

How to eliminate wrong answers

Option A is wrong because a spread placement group maximizes instance separation across distinct hardware to reduce correlated failures, which increases network latency and is unsuitable for high-frequency messaging. Option C is wrong because a partition placement group distributes instances across logical partitions to isolate failures in large distributed systems, but it does not optimize for low latency between instances. Option D is wrong because using multiple Auto Scaling groups to spread traffic across more subnets increases network hops and latency, counteracting the goal of minimizing latency.

Practice this question →

MCQmedium

A media processing pipeline uses EBS-backed storage for an application that performs sustained random I/O with low latency requirements. During peak processing windows, the team sees increased read latency and occasional timeouts at the application layer. They need predictable, high IOPS performance rather than best-effort throughput. Which EBS configuration choice is most appropriate?

A.Use gp2 volumes and rely on burst credits to handle peak random I/O latency requirements.

B.Use io1 or io2 EBS volumes configured with a high provisioned IOPS value, and attach them to EBS-optimized instances.

C.Use standard HDD (st1) volumes, because they provide high throughput and will reduce latency automatically.

D.Use S3 instead of EBS for random I/O latency reduction without changing the application.

AnswerB

io1/io2 are designed for predictable, low-latency IOPS for sustained I/O workloads. By provisioning a sufficient IOPS level, you improve consistency during peak windows. Using EBS-optimized instances ensures the instance-to-EBS bandwidth and I/O performance are adequate so the instance does not become the bottleneck before EBS can deliver the provisioned IOPS.

Why this answer

Io1 and io2 volumes are provisioned IOPS SSD volumes designed for sustained, predictable high IOPS performance, which directly addresses the application's need for low-latency random I/O during peak loads. Attaching them to EBS-optimized instances ensures dedicated network bandwidth for EBS traffic, eliminating contention and preventing timeouts.

Exam trap

The trap here is that candidates may choose gp2 (Option A) assuming burst credits will cover peak loads, but they fail to recognize that sustained peak I/O exhausts credits, leading to performance degradation, whereas provisioned IOPS volumes guarantee consistent performance regardless of duration.

How to eliminate wrong answers

Option A is wrong because gp2 volumes rely on burst credits that can be exhausted during sustained peak I/O, leading to throttled performance and increased latency, not predictable high IOPS. Option C is wrong because st1 volumes are HDD-based and optimized for sequential throughput, not random I/O; they cannot provide low latency or high IOPS for random access patterns. Option D is wrong because S3 is an object storage service with higher latency and no support for low-latency random I/O; it cannot replace EBS for block-level access without significant application changes.

Practice this question →

Multi-Selectmedium

A media company is designing a high-performance architecture to serve video content to users worldwide. The solution must minimize latency for end users and reduce the load on the origin servers. The video files are stored in an Amazon S3 bucket. Which three options should be combined to meet these requirements? (Choose three.)

Select 3 answers

.Use Amazon CloudFront as a content delivery network (CDN) with the S3 bucket as the origin.

.Enable S3 Transfer Acceleration on the bucket to speed up uploads.

.Configure CloudFront to use Regional Edge Caches to improve cache hit ratios for less popular content.

.Use Amazon ElastiCache for Memcached to cache video metadata at the edge.

.Enable S3 default encryption using AWS KMS to improve data transfer performance.

.Implement origin shield in CloudFront to reduce the number of requests sent to the S3 origin.

Why this answer

Amazon CloudFront as a CDN with the S3 bucket as the origin minimizes latency by caching video content at edge locations worldwide, serving users from the nearest edge. This reduces load on the origin S3 bucket by handling requests at the edge. Regional Edge Caches further improve cache hit ratios for less popular content by caching it at regional locations, reducing the need to fetch from the origin.

Origin shield in CloudFront consolidates requests from multiple edge locations into a single request to the S3 origin, significantly reducing the number of direct requests and lowering origin load.

Exam trap

The trap here is that candidates may confuse S3 Transfer Acceleration (which optimizes uploads) with CloudFront (which optimizes downloads), or think that ElastiCache can be used as a CDN for video content, when it is actually an in-memory cache for application data, not for serving static files at the edge.

Practice this question →

Multi-Selecthard

A serverless checkout API uses AWS Lambda behind API Gateway. Every weekday at 09:00 UTC, marketing triggers a predictable surge. The first few minutes after each surge show cold-start latency, but traffic volume is forecastable and the business wants stable p95 latency. Which two changes should the team implement? Select two.

Select 2 answers

A.Publish a Lambda version and attach provisioned concurrency to an alias that points to that version.

B.Use Application Auto Scaling scheduled actions to raise provisioned concurrency before 09:00 UTC and lower it afterward.

C.Increase the Lambda timeout so the function has more time to initialize during the spike.

D.Double the memory size during the spike without changing the concurrency model.

E.Move the function into more Availability Zones so the platform can spread cold starts across regions.

AnswersA, B

Provisioned concurrency keeps execution environments initialized and ready to serve requests, which is the correct way to reduce cold starts. Using an alias tied to a published version is the standard deployment pattern for managing that setting safely. This directly improves p95 latency during predictable bursts.

Why this answer

Provisioned concurrency keeps a specified number of Lambda execution environments initialized and ready to respond immediately, eliminating cold starts for predictable traffic patterns. By publishing a Lambda version and attaching provisioned concurrency to an alias pointing to that version, the team ensures that the surge at 09:00 UTC is handled without cold-start latency, stabilizing p95 latency.

Exam trap

The trap here is that candidates often confuse increasing Lambda timeout or memory with solving cold-start latency, but these settings do not pre-warm execution environments; only provisioned concurrency (and optionally scheduled scaling) directly eliminates cold starts for predictable surges.

Practice this question →

MCQeasy

A retail analytics app uses Amazon RDS for PostgreSQL. Read traffic is growing, and the database CPU spikes mainly due to SELECT-heavy workloads. Writes are less frequent, and the app can tolerate eventually consistent reads for the reports. What is the most appropriate AWS-native way to improve read performance with minimal application changes?

A.Create an RDS read replica and point the reporting queries to the replica endpoint.

B.Switch the cluster to DynamoDB without redesigning the data model.

C.Enable S3 event notifications to trigger a Lambda function after each write to the database.

D.Replace the RDS instance class with a smaller size to reduce cost and improve performance.

AnswerA

Read replicas offload reads from the primary and can speed up SELECT-heavy workloads with minimal changes.

Why this answer

Creating an RDS read replica is the most appropriate AWS-native solution because it offloads SELECT-heavy read traffic from the primary database instance to a separate read-only replica, reducing CPU spikes on the primary. The application can tolerate eventually consistent reads for reports, which aligns with the natural replication lag of RDS read replicas (typically sub-second). This requires minimal application changes—only updating the reporting queries to point to the replica endpoint—and leverages PostgreSQL's built-in streaming replication.

Exam trap

The trap here is that candidates may confuse read replicas with Multi-AZ deployments, thinking Multi-AZ improves read performance, but Multi-AZ only provides failover redundancy and does not offload read traffic—the standby is not accessible for reads.

How to eliminate wrong answers

Option B is wrong because switching to DynamoDB without redesigning the data model would require significant application changes (e.g., adapting from relational to NoSQL schema, handling partition keys, and losing SQL query capabilities), which contradicts the requirement for minimal application changes. Option C is wrong because enabling S3 event notifications to trigger a Lambda function after each write does not directly improve read performance on the database; it adds asynchronous processing overhead and does not offload SELECT queries from the RDS instance. Option D is wrong because replacing the RDS instance class with a smaller size would reduce CPU capacity, worsening performance under the existing SELECT-heavy workload, and does not address the root cause of CPU spikes.

Practice this question →

Multi-Selecthard

A partner integration sends a custom binary TCP protocol to a service running on EC2 instances in private subnets. The partners require static endpoint IPs for allowlisting, and the application must see the original client source IP for rate limiting. Which two changes best fit the protocol and network requirements? Select two.

Select 2 answers

A.Replace the Application Load Balancer with a Network Load Balancer.

B.Use a TCP listener on the load balancer instead of an HTTP or HTTPS listener.

C.Put the service behind API Gateway REST API and use Lambda integration.

D.Use CloudFront to cache the binary packets at edge locations.

E.Terminate the traffic with an Amazon RDS proxy to stabilize the connections.

AnswersA, B

A Network Load Balancer is the right choice for TCP traffic and low-latency forwarding at layer 4. It also supports static IP behavior that is important for partner allowlisting. This directly matches the custom binary protocol and source-IP requirement.

Why this answer

A Network Load Balancer (NLB) is required because it supports TCP traffic natively at Layer 4, which is necessary for a custom binary TCP protocol that cannot be interpreted by an Application Load Balancer (ALB) at Layer 7. Additionally, an NLB preserves the original client source IP address by default when used with targets in private subnets, meeting the requirement for rate limiting based on the client IP. Static IP addresses can be assigned to the NLB via Elastic IPs, satisfying the partner's need for static endpoint IPs for allowlisting.

Exam trap

The trap here is that candidates often assume an Application Load Balancer can handle any TCP traffic because it supports TCP listeners, but ALB only supports HTTP/HTTPS at Layer 7 and cannot process custom binary protocols, while NLB is the correct choice for non-HTTP TCP traffic with static IP and client IP preservation requirements.

Practice this question →

MCQmedium

A distributed system needs extremely low network latency between a set of EC2 instances running the same workload. The team wants the instances to be placed as close together as AWS allows to reduce round-trip time. Which placement strategy should the architect use?

A.Use a Cluster placement group for the instances that must communicate frequently over low latency.

B.Use a Spread placement group across multiple Availability Zones to maximize fault tolerance.

C.Use the default placement strategy without specifying a placement group.

D.Use a placement group of type Partition to ensure independent failure of each instance.

AnswerA

Cluster placement groups are designed to place instances close together within a single Availability Zone to minimize network latency. They are the right choice when nodes require high intercommunication performance, such as distributed processing or tightly coupled systems. The scenario’s goal of minimizing round-trip time aligns with the Cluster placement group behavior. It’s also an EC2-native placement option focused on performance.

Why this answer

A Cluster placement group is the correct choice because it places instances in a single Availability Zone within the same rack or logical cluster, providing the lowest possible network latency and maximum throughput (up to 10 Gbps for single-flow traffic) between instances. This is ideal for tightly coupled, latency-sensitive workloads like HPC or real-time distributed systems.

Exam trap

The trap here is that candidates often confuse the purpose of placement groups: Cluster is for low latency and high throughput, Spread is for fault tolerance across hardware, and Partition is for large distributed systems needing failure isolation, but only Cluster guarantees physical proximity.

How to eliminate wrong answers

Option B is wrong because a Spread placement group spreads instances across distinct hardware racks or Availability Zones, which increases latency and is designed for fault tolerance, not low latency. Option C is wrong because the default placement strategy does not guarantee proximity; instances may be placed on different racks or AZs, leading to higher latency. Option D is wrong because a Partition placement group spreads instances across multiple partitions (each with separate racks) to isolate failures, but does not minimize latency between instances within the same partition.

Practice this question →

MCQmedium

A high-volume telemetry pipeline writes streaming click events that must be processed by multiple independent consumers. Which service is most appropriate? The architecture review board prefers a managed AWS-native control.

A.Amazon Kinesis Data Streams

B.AWS DataSync

C.Amazon EBS

D.Amazon Route 53

AnswerA

Kinesis Data Streams supports high-throughput event ingestion with multiple consumers reading from the stream.

Why this answer

Amazon Kinesis Data Streams is the correct choice because it is a fully managed, AWS-native service designed for real-time streaming data ingestion and processing. It supports multiple independent consumers via enhanced fan-out, which provides each consumer with a dedicated throughput of up to 2 MB/sec per shard, ensuring that high-volume click events can be processed concurrently without contention.

Exam trap

The trap here is confusing batch data transfer services (DataSync) or storage services (EBS) with real-time streaming, leading candidates to overlook Kinesis Data Streams' native support for multiple independent consumers via enhanced fan-out.

How to eliminate wrong answers

Option B (AWS DataSync) is wrong because it is a data transfer service for moving large datasets between on-premises storage and AWS, not a real-time streaming pipeline. Option C (Amazon EBS) is wrong because it provides block-level storage volumes for EC2 instances, not a streaming data ingestion or processing capability. Option D (Amazon Route 53) is wrong because it is a DNS and domain name resolution service, completely unrelated to streaming telemetry data.

Practice this question →

MCQeasy

A retail API uses EC2 instances behind an ALB. CPU is consistently high during peak traffic, and request latency rises. What should be configured?

A.Auto Scaling policy based on an appropriate CloudWatch metric

B.S3 Object Lock

C.A VPC endpoint for CloudWatch only

D.Disable health checks

AnswerA

Auto Scaling adds capacity when load increases and removes it when load falls.

Why this answer

An Auto Scaling policy based on an appropriate CloudWatch metric (such as CPUUtilization or ALBRequestCountPerTarget) dynamically adds or removes EC2 instances to match demand. This directly addresses the high CPU and rising latency by distributing the load across more instances, preventing performance degradation during peak traffic.

Exam trap

The trap here is that candidates may confuse operational features (like S3 Object Lock or VPC endpoints) with scaling mechanisms, or mistakenly think disabling health checks improves performance, when in fact it degrades reliability and latency.

How to eliminate wrong answers

Option B is wrong because S3 Object Lock is a data protection feature for Amazon S3 objects (preventing deletion or overwriting) and has no relevance to scaling compute resources or reducing request latency. Option C is wrong because a VPC endpoint for CloudWatch only enables private connectivity to CloudWatch APIs (e.g., for publishing metrics or logs) but does not scale EC2 capacity or reduce latency. Option D is wrong because disabling health checks would cause the ALB to continue routing traffic to unhealthy instances, worsening latency and potentially causing failures; health checks are essential for maintaining a reliable target group.

Practice this question →

MCQmedium

You run a web application on an EC2 Auto Scaling group behind an Application Load Balancer (ALB). During scheduled traffic spikes, new instances launch but customers occasionally see 5xx errors for the first few minutes after scale-out. Operational logs show instances need ~4 minutes to warm up (load caches and initialize dependencies). ALB target health becomes healthy only after this warm-up. Which change most directly improves performance during spikes by reducing the time to serve traffic after scaling?

A.Configure a larger ALB deregistration delay so that old targets remain longer before termination.

B.Use an Auto Scaling warm pool so instances are pre-initialized and ready to register quickly when the ASG scales out.

C.Increase the number of desired instances immediately without using scaling policies, and then rely on manual reconfiguration.

D.Switch from ALB to NLB so instances become reachable sooner without waiting for health checks.

AnswerB

With a warm pool, Auto Scaling can launch and keep a set of instances in a pre-initialized state (for example, instances are already booted and have completed parts of startup/initialization as supported by warm pool behavior). When scaling triggers, these instances can transition to service faster and begin registering with the ALB. Because your bottleneck is that instances take ~4 minutes to become truly ready, warming them ahead of time most directly reduces the gap between scale-out and customer-ready capacity (and therefore reduces 5xx occurrences while waiting for targets to pass ALB health checks).

Why this answer

B is correct because a warm pool pre-initializes instances (e.g., loading caches and dependencies) before they are added to the Auto Scaling group. When the ASG scales out, these pre-warmed instances can be quickly moved into service, bypassing the ~4-minute warm-up delay and reducing the window for 5xx errors.

Exam trap

The trap here is that candidates may think NLB bypasses health checks entirely, but in reality NLB still requires health checks to mark targets as healthy, and the application warm-up delay remains the bottleneck.

How to eliminate wrong answers

Option A is wrong because increasing the deregistration delay keeps old targets alive longer, which does not help new instances serve traffic faster; it only delays termination of existing instances. Option C is wrong because manually setting desired instances without scaling policies is not automated and does not address the root cause of warm-up latency during spikes. Option D is wrong because switching to NLB does not eliminate the need for health checks or application warm-up; NLB health checks are still required and instances still need time to become healthy, so 5xx errors would persist.

Practice this question →

MCQmedium

A telemetry pipeline uses RDS MySQL and receives many read-only reporting queries that slow down the primary database. What should the architect add?

A.Multi-AZ standby and route reads to the standby

B.RDS read replica and route reporting queries to it

C.S3 lifecycle policy

D.A larger NAT gateway

AnswerB

Read replicas offload read traffic from the primary instance.

Why this answer

RDS Read Replicas are designed specifically to offload read-heavy workloads from the primary database. By creating a read replica and routing the reporting queries to it, the primary database is freed from processing these read-only queries, reducing contention and improving overall performance. This is the most cost-effective and architecturally appropriate solution for read scaling in RDS MySQL.

Exam trap

The trap here is confusing Multi-AZ standby (which is for failover, not read scaling) with a read replica, leading candidates to incorrectly choose Option A.

How to eliminate wrong answers

Option A is wrong because a Multi-AZ standby is for high availability and disaster recovery, not for read scaling; the standby does not accept read traffic unless a failover occurs. Option C is wrong because S3 lifecycle policies manage object storage tiers and expiration, which have no relevance to offloading database read queries. Option D is wrong because a larger NAT gateway increases outbound internet bandwidth for private subnets, but does not address database read performance or query offloading.

Practice this question →

MCQeasy

A company serves public JavaScript and CSS files from S3 using CloudFront. After a frontend change, customers report a low CloudFront cache hit ratio. Requests now include an Authorization header, but these assets do not require authentication. The CloudFront distribution is configured such that Authorization is included in the cache key. Which change best maximizes cache reuse?

A.Include the Authorization header in the cache key so responses vary correctly

B.Use a CloudFront Cache Policy that excludes Authorization from the cache key

C.Disable caching and always fetch from S3

D.Forward all headers and cookies to the origin to improve correctness

AnswerB

Because the assets are public and do not depend on Authorization, excluding Authorization from the cache key allows all users to share the same cached objects. This reduces cache fragmentation and increases cache hit ratio.

Why this answer

Excluding the Authorization header from the cache key ensures that all users, regardless of their authentication token, receive the same cached object. Since the static assets (JavaScript/CSS) do not require authentication, including Authorization in the cache key creates multiple cache entries for the same file, drastically reducing the cache hit ratio. A CloudFront cache policy that omits Authorization from the cache key maximizes reuse while still allowing the header to be forwarded to the origin if needed.

Exam trap

The trap here is that candidates may assume including the Authorization header is necessary for correctness, but for public static assets, excluding it from the cache key is the correct way to maximize cache reuse without affecting delivery.

How to eliminate wrong answers

Option A is wrong because including the Authorization header in the cache key would cause CloudFront to cache separate copies for each unique token value, which is exactly the problem that reduces the cache hit ratio. Option C is wrong because disabling caching entirely would increase latency and origin load, violating the goal of maximizing cache reuse. Option D is wrong because forwarding all headers and cookies to the origin would not only include unnecessary Authorization values but also further fragment the cache, worsening the hit ratio and adding overhead.

Practice this question →

Multi-Selectmedium

An order lookup API repeatedly reads the same few items from DynamoDB. The application can tolerate slightly stale data for a few seconds, and the team wants the lowest-latency design with minimal application changes. Which two changes should they make? Select two.

Select 2 answers

A.Put Amazon DynamoDB Accelerator (DAX) in front of the table.

B.Use eventually consistent reads where the application can tolerate slightly stale data.

C.Switch all access to strongly consistent reads for faster results.

D.Increase the item size so fewer requests are needed.

E.Replace the table with Amazon EBS volumes mounted on EC2 instances.

AnswersA, B

DAX is an in-memory cache for DynamoDB reads, so repeated lookups for the same keys can be served with much lower latency than direct table reads. It is especially effective for hot-item access patterns like order lookups, product metadata, and profile reads.

Why this answer

Amazon DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB that provides microsecond read latency, which is ideal for repeated reads of the same few items. Since the application can tolerate slightly stale data, DAX's default write-through caching with a TTL of 5 minutes ensures low latency without requiring application code changes beyond adding the DAX client.

Exam trap

The trap here is that candidates may think strongly consistent reads are always faster, but they actually have higher latency and cannot be cached by DAX, making them unsuitable for this low-latency, minimal-change requirement.

Why the other options are wrong

Strongly consistent reads have higher latency and consume more read capacity units than eventually consistent reads, so switching to them would increase latency, not reduce it.

Increasing item size does not reduce the number of read requests for the same few items; it may increase read costs and latency due to larger data transfer.

EBS volumes do not provide a managed, low-latency caching layer for DynamoDB; they require significant application changes to migrate from DynamoDB to a self-managed database, contradicting the 'minimal application changes' requirement.

Practice this question →

MCQhard

Based on the exhibit, a static asset distribution site uses Amazon CloudFront with an S3 origin. The assets are versioned by filename, but the cache hit ratio remains low after each release. Which CloudFront change is the best way to improve cache reuse without changing the origin objects?

A.Keep the current cache key and increase the S3 bucket's storage class.

B.Remove Authorization and unnecessary query strings from the CloudFront cache key.

C.Disable the CloudFront cache so every request is served directly from S3.

D.Switch the origin from Amazon S3 to an Application Load Balancer.

AnswerB

Versioned static assets do not need Authorization in the cache key, and arbitrary query strings can destroy cache efficiency. Excluding those fields lets CloudFront reuse the same cached object across many viewers.

Why this answer

Removing Authorization headers and unnecessary query strings from the CloudFront cache key ensures that multiple requests for the same versioned asset (e.g., style.v2.css) share a single cached object, regardless of user-specific headers or irrelevant query parameters. This directly increases the cache hit ratio without modifying the origin objects, as CloudFront will serve the same cached response for identical cache keys.

Exam trap

The trap here is that candidates may think increasing storage class or switching to an ALB improves caching, but the real issue is the cache key composition—specifically, unnecessary headers or query strings fragmenting the cache—which is solved by adjusting the CloudFront cache key settings.

How to eliminate wrong answers

Option A is wrong because changing the S3 bucket's storage class (e.g., to S3 Standard-IA or Glacier) has no effect on CloudFront's cache key or cache hit ratio; it only affects storage cost and retrieval latency, not caching behavior. Option C is wrong because disabling the CloudFront cache would force every request to go directly to the S3 origin, eliminating all caching benefits and increasing latency and origin load, which is the opposite of improving cache reuse. Option D is wrong because switching the origin from S3 to an Application Load Balancer (ALB) introduces unnecessary complexity and does not address the cache key issue; the ALB would still require the same cache key optimization to improve cache hits, and it would not inherently improve cache reuse.

Practice this question →

MCQhard

Based on the exhibit, what is the best change to improve read performance without increasing write latency on the primary database?

A.Create an RDS read replica and direct the reporting queries to the replica endpoint.

B.Convert the DB instance to Multi-AZ so the primary can serve more reads.

C.Increase the primary instance class to a larger size and keep all traffic on one writer.

D.Migrate the reporting workload to DynamoDB to gain faster reads.

AnswerA

A read replica offloads the long-running read-only reports from the primary database, which preserves write performance and reduces read latency for the reporting workload. Because the business accepts slightly stale report data, the asynchronous replication delay is acceptable. This is the most direct and AWS-native way to separate read pressure from writes.

Why this answer

Creating an RDS read replica offloads read-heavy reporting queries from the primary database instance, improving read performance without adding any write latency to the primary. The replica operates asynchronously, so writes on the primary are not blocked or delayed by the replica's lag. This is the standard AWS solution for scaling read traffic on RDS.

Exam trap

The trap here is that candidates confuse Multi-AZ with read scaling, assuming the standby instance can serve reads, when in fact Multi-AZ only provides failover redundancy and the standby is not accessible for read operations.

How to eliminate wrong answers

Option B is wrong because Multi-AZ is designed for high availability and automatic failover, not for scaling read capacity; the standby instance cannot serve reads directly. Option C is wrong because increasing the instance class would improve both read and write performance, but it does not isolate the reporting workload, so it could still increase write latency under heavy read load. Option D is wrong because migrating to DynamoDB is an architectural change that would require application rewrites and does not directly address improving read performance on the existing primary database without increasing write latency.

Practice this question →

Multi-Selecthard

A nightly video rendering pipeline runs on Linux EC2 instances and is compatible with ARM64. The jobs are CPU-bound, checkpoint frequently, and can resume if interrupted. The business wants the best throughput per dollar for the batch window. Which two changes should the team make? Select two.

Select 2 answers

A.Use AWS Graviton-based instances for the render workers.

B.Run the workers in an Auto Scaling group with Spot Instances for interruption-tolerant capacity.

C.Use a single large x86 instance with On-Demand pricing to avoid interruptions.

D.Replace the batch workers with a Lambda function to eliminate instance management.

E.Move the workload to a spread placement group to increase cost efficiency.

AnswersA, B

Graviton instances are ARM-based and often deliver better price-performance than comparable x86 instances for CPU-bound workloads. Because the application is already compatible with ARM64, the team can adopt Graviton without rewriting the pipeline. That improves throughput per dollar while keeping the same batch-processing model.

Why this answer

AWS Graviton-based instances use ARM64 architecture, which is explicitly compatible with the video rendering pipeline. They offer up to 40% better price-performance compared to comparable x86 instances for CPU-bound workloads, directly improving throughput per dollar. This makes option A correct for maximizing cost efficiency.

Exam trap

The trap here is that candidates may overlook the compatibility requirement with ARM64 and choose a single large x86 instance for simplicity, or mistakenly think Lambda can handle long-running CPU-bound tasks, missing the cost and throughput benefits of Graviton and Spot Instances.

Practice this question →

MCQmedium

A read-heavy media archive repeatedly queries the same product catalogue data from DynamoDB with millisecond latency requirements. Which service can reduce read latency and table load? The design must avoid adding custom operational scripts.

A.DynamoDB Accelerator (DAX)

B.Amazon Kinesis Data Firehose

C.AWS Glue Data Catalog

D.S3 Transfer Acceleration

AnswerA

DAX is an in-memory cache for DynamoDB that reduces read latency for suitable access patterns.

Why this answer

DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB that delivers microsecond read latency, reducing the load on the underlying DynamoDB tables by serving repeated queries from its cache. This directly addresses the read-heavy media archive's millisecond latency requirements without requiring custom operational scripts, as DAX is fully managed and integrates seamlessly with existing DynamoDB API calls.

Exam trap

The trap here is that candidates may confuse DAX with other caching services like ElastiCache, but DAX is purpose-built for DynamoDB and requires no application code changes, whereas ElastiCache would need custom scripts to manage cache invalidation and data population.

How to eliminate wrong answers

Option B (Amazon Kinesis Data Firehose) is wrong because it is a streaming data ingestion service for loading data into data stores like S3 or Redshift, not a caching layer for reducing DynamoDB read latency or table load. Option C (AWS Glue Data Catalog) is wrong because it is a metadata repository for ETL jobs and data discovery, not a low-latency cache for DynamoDB queries. Option D (S3 Transfer Acceleration) is wrong because it speeds up uploads to S3 over long distances using edge locations, but it does not cache DynamoDB data or reduce read latency for repeated queries.

Practice this question →

MCQmedium

A serverless API built with AWS Lambda serves latency-sensitive requests. The team observes intermittent slow responses during traffic ramp-ups and expects some users to hit the API immediately after a period of inactivity. Which configuration best reduces cold-start latency during these ramp-ups?

A.Enable Lambda provisioned concurrency on a published alias used by the API, and set a minimum provisioned concurrency greater than zero.

B.Increase the Lambda function’s memory setting; cold starts will always be eliminated regardless of traffic patterns.

C.Switch the Lambda runtime to a newer language version and remove any VPC configuration so the function never cold starts.

D.Set an API Gateway stage variable to "warm" the function at request time, which forces immediate initialization.

AnswerA

Provisioned concurrency keeps a defined number of Lambda execution environments initialized and ready behind a specific alias. When traffic ramps up—especially after inactivity—invocations can use pre-initialized environments, reducing or eliminating cold starts for those requests.

Why this answer

Lambda provisioned concurrency keeps a specified number of execution environments initialized and ready to respond immediately, eliminating cold starts for those invocations. By setting a minimum provisioned concurrency greater than zero on the alias used by API Gateway, the function remains warm even after periods of inactivity, ensuring consistent low latency during traffic ramp-ups.

Exam trap

The trap here is that candidates confuse provisioned concurrency with reserved concurrency, or assume that increasing memory or changing runtime settings can fully eliminate cold starts, when only provisioned concurrency guarantees pre-warmed execution environments for latency-sensitive workloads.

How to eliminate wrong answers

Option B is wrong because increasing memory reduces cold-start duration but does not eliminate cold starts; they still occur after inactivity. Option C is wrong because switching runtimes or removing VPC configuration does not prevent cold starts; VPC-enabled functions have additional cold-start overhead, but all Lambda functions can cold start regardless of runtime or VPC settings. Option D is wrong because API Gateway stage variables are static configuration values, not mechanisms to warm functions; they cannot force initialization at request time.

Practice this question →

MCQmedium

A analytics dashboard uses RDS MySQL and receives many read-only reporting queries that slow down the primary database. What should the architect add? The team wants the control to be enforceable during normal operations.

A.S3 lifecycle policy

B.RDS read replica and route reporting queries to it

C.Multi-AZ standby and route reads to the standby

D.A larger NAT gateway

AnswerB

Read replicas offload read traffic from the primary instance.

Why this answer

B is correct because an RDS read replica is designed to offload read-heavy workloads from the primary database instance. By routing reporting queries to the read replica, the primary database is freed from processing these read-only requests, improving overall performance. This solution is enforceable during normal operations as the read replica is always available for reads, unlike a Multi-AZ standby which is not accessible for reads.

Exam trap

The trap here is confusing a Multi-AZ standby (which is not readable) with a read replica (which is readable), leading candidates to incorrectly choose C thinking the standby can serve reads.

How to eliminate wrong answers

Option A is wrong because an S3 lifecycle policy manages object transitions and expirations in S3, not database query routing or read offloading. Option C is wrong because a Multi-AZ standby is a synchronous replica used only for failover and is not accessible for read queries during normal operations; routing reads to it would fail. Option D is wrong because a larger NAT gateway increases outbound internet capacity for private subnets, which does not address database read performance or query routing.

Practice this question →

MCQeasy

Based on the exhibit, which Amazon EFS performance mode is the best fit for this workload?

A.Use General Purpose performance mode for low-latency access.

B.Use Max I/O performance mode to optimize for the highest possible latency tolerance.

C.Use One Zone storage class to increase metadata speed.

D.Use Provisioned Throughput mode because it is the only performance mode available.

AnswerA

General Purpose is the best EFS performance mode when the priority is low latency for small file operations. The exhibit describes a moderate number of clients and latency-sensitive metadata access, which matches the strengths of General Purpose. It is the usual choice for most applications unless the workload specifically needs very large-scale parallel throughput.

Why this answer

The General Purpose performance mode is the best fit for this workload because it provides the lowest latency for file operations, which is critical for latency-sensitive applications such as web serving, content management, and development environments. EFS General Purpose mode is optimized for workloads where consistent low-latency access is required, making it the default and recommended choice for most use cases.

Exam trap

The trap here is that candidates confuse performance modes (General Purpose vs. Max I/O) with throughput modes (Bursting vs. Provisioned) or storage classes (Standard vs.

One Zone), leading them to select options that address throughput or availability rather than latency requirements.

Why the other options are wrong

Max I/O performance mode is designed for high throughput and can handle high I/O, but it does not optimize for latency tolerance; it actually has higher latency variability compared to General Purpose mode, making it unsuitable for a workload requiring low-latency access.

One Zone storage class is a storage class, not a performance mode; it does not affect metadata speed. Metadata performance is determined by the performance mode (General Purpose or Max I/O), not the storage class.

Provisioned Throughput mode is not a performance mode; it is a throughput setting available within General Purpose or Max I/O performance modes. The question asks for a performance mode, and Provisioned Throughput is not one of the two performance modes (General Purpose and Max I/O).

Practice this question →

MCQeasy

Your application uses ElastiCache Redis as a cache for user profiles stored in DynamoDB. You must ensure that when a profile is updated, subsequent reads see the latest value quickly. Which cache strategy is generally the best fit for this requirement?

A.Write to DynamoDB only, and never update or invalidate the Redis cache.

B.Use a cache-aside approach with TTL plus explicit invalidation after writes.

C.Cache only for reads, and do not fetch from DynamoDB when a key is missing.

D.Rely on eventual consistency of Redis replication to propagate updates to all nodes.

AnswerB

A cache-aside (lazy loading) pattern reads from cache first; if missing/expired, it fetches from the source of truth. After an update, explicitly invalidating or updating the cached entry ensures subsequent reads quickly reflect changes. TTL provides protection against missed invalidations while invalidation accelerates correctness after writes.

Why this answer

The cache-aside (lazy loading) pattern with TTL plus explicit invalidation ensures that after a write to DynamoDB, the stale Redis entry is removed, forcing the next read to fetch the updated profile from DynamoDB and repopulate the cache. This minimizes the window of inconsistency while keeping cache management simple and efficient for user profile workloads.

Exam trap

The trap here is that candidates may confuse cache-aside with write-through or write-behind patterns, or assume that Redis replication alone can solve cache consistency, when in fact explicit invalidation is required to ensure reads see the latest value after a write to the primary data store.

Why the other options are wrong

This option never updates or invalidates the cache, so after a profile update in DynamoDB, the Redis cache still serves stale data until the TTL expires, violating the requirement that subsequent reads see the latest value quickly.

This option fails because if a key is missing in the cache, the application never fetches the profile from DynamoDB, so stale or missing data persists indefinitely, violating the requirement that subsequent reads see the latest value quickly.

Redis replication is asynchronous, so relying on eventual consistency does not guarantee that subsequent reads see the latest value quickly after a write. This strategy can lead to stale reads until replication completes.

Practice this question →

MCQhard

Based on the exhibit, which change will most improve the CloudFront cache hit ratio for the static assets while still serving the same files to all users?

A.Create a custom cache policy that includes only the v query string and excludes cookies.

B.Enable Origin Shield and keep the current cache behavior unchanged.

C.Move the static assets to individual presigned URLs for each viewer.

D.Increase the CloudFront default TTL to 24 hours while continuing to forward all cookies and query strings.

AnswerA

This removes unnecessary cache-key fragmentation. Since all users receive identical static files, forwarding user-specific cookies and irrelevant query strings destroys cache reuse. Keeping only the version parameter preserves correct object variation while allowing many more requests to hit the same cached object at the edge.

Why this answer

Static assets (e.g., images, CSS, JS) are typically served identically to all users, so forwarding a unique query string like 'v' for versioning still allows CloudFront to cache a single object per version. By excluding cookies and other query strings, you prevent cache fragmentation caused by irrelevant variations, directly improving the cache hit ratio. This custom cache policy ensures that requests for the same 'v' value are served from the edge cache rather than forwarded to the origin.

Exam trap

The trap here is that candidates assume increasing TTL or enabling Origin Shield will fix a low cache hit ratio, when the real issue is cache key fragmentation caused by forwarding all cookies and query strings.

Why the other options are wrong

Enabling Origin Shield reduces origin load and improves latency but does not affect the cache hit ratio when query strings and cookies are still forwarded, as they cause cache fragmentation.

Using presigned URLs for static assets would not improve cache hit ratio because each presigned URL is unique per viewer, preventing CloudFront from caching and serving the same object to multiple users.

Forwarding all cookies and query strings prevents CloudFront from caching responses effectively because each unique combination creates a separate cache entry, reducing the cache hit ratio.

Practice this question →

MCQmedium

A analytics dashboard uses an Application Load Balancer in one Region. Global users need lower network latency to the application without caching dynamic responses. What should be considered? The design must avoid adding custom operational scripts.

A.AWS Global Accelerator

B.S3 Cross-Region Replication

C.AWS Backup cross-Region copy

D.CloudFront only with long TTLs

AnswerA

Global Accelerator routes traffic over the AWS global network to improve performance for TCP/UDP applications without relying on caching.

Why this answer

AWS Global Accelerator uses the AWS global network to route traffic from edge locations to the optimal regional endpoint, reducing latency and jitter for global users. It does not cache content, making it ideal for dynamic responses that cannot be cached. The service requires no custom scripts, as it integrates directly with the Application Load Balancer via a static IP address or DNS name.

Exam trap

The trap here is that candidates often confuse Global Accelerator with CloudFront, assuming both are for caching, but Global Accelerator does not cache content and is specifically designed for non-cacheable, dynamic traffic requiring low latency and fast failover.

How to eliminate wrong answers

Option B (S3 Cross-Region Replication) is wrong because it replicates objects across S3 buckets in different regions, but it does not reduce network latency for dynamic application traffic; it is designed for data redundancy and disaster recovery, not for real-time request routing. Option C (AWS Backup cross-Region copy) is wrong because it copies backup data across regions for compliance or disaster recovery, and it has no impact on live application latency or traffic routing. Option D (CloudFront only with long TTLs) is wrong because CloudFront caches content at edge locations, which violates the requirement to avoid caching dynamic responses; long TTLs would serve stale data, and disabling caching would negate the latency benefit, while custom scripts would be needed to bypass caching for dynamic content.

Practice this question →

MCQhard

A DynamoDB table for a travel booking site has a partition key based only on the current date. Write throttling occurs during business hours. What is the best design change? The architecture review board prefers a managed AWS-native control.

A.Create a global secondary index with the same date key

B.Move the table to S3 Glacier Instant Retrieval

C.Reduce the table's write capacity

D.Use a higher-cardinality partition key that distributes writes across partitions

AnswerD

A low-cardinality hot partition causes throttling; a better key spreads writes more evenly.

Why this answer

Using a low-cardinality partition key like the current date causes all writes to land on a single partition, leading to throttling. By choosing a higher-cardinality partition key (e.g., combining date with a user ID or booking ID), writes are distributed evenly across multiple partitions, leveraging DynamoDB's internal partitioning to handle the throughput. This is a managed, AWS-native design change that resolves hot partition issues without additional services.

Exam trap

The trap here is that candidates often confuse a GSI as a solution for write performance, when in fact GSIs only help with read query patterns and do not alleviate write hot spots on the base table.

How to eliminate wrong answers

Option A is wrong because creating a global secondary index (GSI) with the same date key does not solve the write throttling; GSIs have their own write capacity and inherit the same hot partition problem from the base table's partition key. Option B is wrong because moving the table to S3 Glacier Instant Retrieval is not a managed AWS-native control for DynamoDB write throttling; S3 is a different storage service and cannot replace DynamoDB's real-time transactional write capabilities. Option C is wrong because reducing the table's write capacity would worsen throttling during business hours, as it lowers the maximum allowed writes per second, directly contradicting the need to handle high write demand.

Practice this question →

MCQhard

Based on the exhibit, which storage design best supports the application servers' shared working directory requirement?

A.Mount Amazon EFS on every EC2 instance and use it as the shared workspace.

B.Attach one gp3 EBS volume to each instance and synchronize the files with cron jobs.

C.Store the artifacts in S3 and have each node read them directly from S3 as a filesystem.

D.Use instance store on each instance because it provides the fastest local file access.

AnswerA

EFS provides shared, persistent, POSIX-compliant file access across multiple EC2 instances and Availability Zones. That matches the requirement that all nodes see the same workspace immediately and that files survive instance replacement. It is the right choice when the application needs a common filesystem rather than an object store or local-only disk.

Why this answer

Amazon EFS provides a fully managed, NFS-based shared file system that can be mounted concurrently on multiple EC2 instances across multiple Availability Zones. This directly satisfies the requirement for a shared working directory where all application servers can read and write files simultaneously without additional synchronization overhead.

Exam trap

The trap here is that candidates often confuse object storage (S3) with shared file storage, assuming S3 can serve as a drop-in replacement for a POSIX filesystem, but S3 lacks file locking, atomic renames, and low-latency metadata operations required for a shared working directory.

Why the other options are wrong

Synchronizing files with cron jobs introduces latency and inconsistency, failing to provide a real-time shared working directory as required by the application servers.

Using S3 as a filesystem (e.g., via s3fs) introduces latency and consistency issues that are unsuitable for a shared working directory requiring low-latency, POSIX-compliant file operations across multiple EC2 instances.

Instance store provides temporary, block-level storage that is physically attached to the host, but data is lost if the instance is stopped or terminated. It cannot serve as a persistent shared working directory across multiple EC2 instances.

Practice this question →

MCQhard

A DynamoDB table for a retail API has a partition key based only on the current date. Write throttling occurs during business hours. What is the best design change?

A.Use a higher-cardinality partition key that distributes writes across partitions

B.Create a global secondary index with the same date key

C.Reduce the table's write capacity

D.Move the table to S3 Glacier Instant Retrieval

AnswerA

A low-cardinality hot partition causes throttling; a better key spreads writes more evenly.

Why this answer

Using a partition key based solely on the current date creates a 'hot partition' because all writes for that day target the same partition, leading to throttling. A higher-cardinality partition key (e.g., combining date with a unique attribute like user ID or order ID) distributes write traffic evenly across multiple partitions, allowing DynamoDB to utilize its full throughput capacity and eliminating throttling.

Exam trap

The trap here is that candidates may think a GSI can solve write throttling, but GSIs only help with read patterns and do not redistribute write load on the base table.

How to eliminate wrong answers

Option B is wrong because creating a global secondary index (GSI) with the same date key does not change the base table's partition key; writes still target the same hot partition, so throttling persists. Option C is wrong because reducing the table's write capacity would worsen throttling, not solve it, as the issue is uneven distribution, not insufficient total capacity. Option D is wrong because S3 Glacier Instant Retrieval is an object storage service for archival data, not a transactional database; it cannot support DynamoDB's low-latency read/write operations or query patterns.

Practice this question →

Multi-Selecthard

A serverless checkout API runs on AWS Lambda behind API Gateway. Traffic spikes are predictable every weekday at 09:00 UTC, and p95 latency jumps for the first few minutes after each deployment because execution environments are cold. The team wants to reduce this startup impact without changing the API contract. Which changes should they make? Select three.

Select 3 answers

A.Configure provisioned concurrency on the production Lambda alias during the busy windows.

B.Initialize SDK clients and other reusable objects outside the handler so they are created once per execution environment.

C.Reduce the deployment package size and remove unnecessary layers to shorten function initialization.

D.Replace provisioned concurrency with reserved concurrency because reserved concurrency keeps instances warm.

E.Increase the function timeout so the first request has more time to warm up.

AnswersA, B, C

Correct. Provisioned concurrency keeps a pool of pre-initialized execution environments ready to handle invocations, which directly reduces cold-start latency. Using an alias allows the team to manage production traffic separately from development or canary versions and to schedule capacity for the predictable weekday peak.

Why this answer

Provisioned concurrency initializes a specified number of execution environments in advance, so when traffic spikes at 09:00 UTC, the Lambda function is already warm and can serve requests without cold start latency. This directly addresses the p95 latency jump after deployment without altering the API contract.

Exam trap

The trap here is confusing reserved concurrency (which only limits concurrency) with provisioned concurrency (which pre-warms instances), leading candidates to incorrectly select reserved concurrency as a solution for cold starts.

Practice this question →

MCQhard

Based on the exhibit, an application runs on Amazon Aurora MySQL. The writer instance is frequently near 85% CPU while the reader instance is under 20% CPU. Application traces show that most of the database traffic is read-only SELECT queries, but the code currently sends all queries to the writer endpoint. What should the solutions architect recommend to improve performance with the smallest functional change?

A.Increase the writer instance size and keep all traffic on the writer endpoint.

B.Point read-only database traffic to the Aurora reader endpoint and keep writes on the writer endpoint.

C.Convert the cluster to a Multi-AZ RDS PostgreSQL deployment to get automatic failover and better read performance.

D.Enable cross-Region read replicas so SELECT queries are routed to a remote Region for improved performance.

AnswerB

This directly uses the cluster’s read scale-out capability. The reader endpoint distributes read traffic across replicas, reducing load on the writer and increasing read throughput without changing schema or database engine.

Why this answer

The Aurora reader endpoint distributes read-only traffic across all available reader instances, offloading the writer instance and reducing its CPU utilization. Since the application traces show most traffic is read-only SELECT queries, this change requires only modifying the connection string for reads while keeping writes on the writer endpoint, making it the smallest functional change.

Exam trap

The trap here is that candidates may think increasing instance size (Option A) is the simplest fix, but they overlook the fact that Aurora's architecture is designed to offload reads to reader instances, which is a more cost-effective and scalable solution with minimal code change.

How to eliminate wrong answers

Option A is wrong because increasing the writer instance size does not address the root cause—the writer is overloaded with read traffic that could be handled by readers—and it incurs higher cost without leveraging Aurora's built-in read scaling. Option C is wrong because converting to RDS PostgreSQL Multi-AZ does not provide the same read scaling as Aurora readers; Multi-AZ only provides a standby for failover, not active read offloading, and it requires a full migration. Option D is wrong because cross-Region read replicas introduce significant latency for read queries and are intended for disaster recovery or global read scaling, not for reducing CPU on the local writer instance.

Practice this question →

MCQmedium

A DynamoDB-backed event processing system experiences throttling during a promotion. All events are written and read using the same partition key value (tenantId = "ACME"). The workload is time-ordered per tenant, and the application can tolerate slight reordering across partitions. Which design change will most directly increase throughput and reduce hot-partition throttling?

A.Increase the table's provisioned capacity (read/write units) to handle the promotion peak.

B.Change the partition key to include an additional sharding attribute derived from a hash of eventId.

C.Enable DAX caching for all reads but keep the same partition key and item layout.

D.Switch the table to eventually consistent reads for queries to lower read throttling.

AnswerB

When all traffic targets one partition key value, that partition becomes the bottleneck regardless of total table capacity. Adding a shard/salt attribute to the partition key (for example, tenantId + shardId where shardId = hash(eventId) mod N) spreads writes across multiple partition key values, increasing partition-level parallelism. Because the scenario allows slight reordering across partitions, losing strict single-partition time ordering is acceptable while improving throughput and reducing throttling.

Why this answer

Adding a sharding attribute derived from a hash of eventId allows writes and reads to be distributed across multiple partition keys, breaking the single hot partition caused by using tenantId='ACME' for all operations. DynamoDB's throughput is limited per partition, so distributing the load across many partitions directly reduces throttling without changing the application's tolerance for slight reordering.

Exam trap

The trap here is that candidates often assume increasing provisioned capacity (Option A) is the universal fix for throttling, but AWS specifically tests the understanding that DynamoDB's per-partition throughput limits require a sharding strategy to distribute load across partitions.

How to eliminate wrong answers

Option A is wrong because simply increasing provisioned capacity does not resolve the hot-partition issue; the single partition key (tenantId='ACME') still caps throughput at 3000 RCU/1000 WCU per partition, so throttling persists regardless of total table capacity. Option C is wrong because DAX caching only reduces read load on the table, but writes (which are the primary source of throttling during a promotion) still hit the same hot partition, and DAX does not help with write throttling. Option D is wrong because eventually consistent reads only reduce read costs and latency, but they do not address the root cause of throttling—the single partition bottleneck—and have no effect on write throttling.

Practice this question →

MCQmedium

A mobile game backend uses Amazon Aurora. The workload has many short-lived database connections from Lambda functions, causing connection storms. What should be added?

A.An internet gateway

B.S3 Select

C.RDS Proxy

D.A larger Route 53 hosted zone

AnswerC

RDS Proxy pools and manages database connections, improving scalability for serverless and bursty workloads.

Why this answer

RDS Proxy is the correct solution because it sits between Lambda functions and the Aurora database, pooling and reusing database connections. This prevents connection storms by reducing the overhead of establishing new connections for each short-lived Lambda invocation, and it also helps manage IAM authentication for Lambda functions without storing database credentials.

Exam trap

The trap here is that candidates may think scaling the database (e.g., increasing instance size) is the answer, but the question specifically targets connection management, not compute or storage capacity, and RDS Proxy is the AWS-managed service designed exactly for this use case.

How to eliminate wrong answers

Option A is wrong because an internet gateway is used to enable VPC-to-internet communication, not to manage database connection pooling or reduce connection storms. Option B is wrong because S3 Select is a service for retrieving subsets of data from objects in S3 using SQL-like expressions, and it has no role in database connection management. Option D is wrong because a larger Route 53 hosted zone increases the number of DNS records you can host but does not affect database connection handling or reduce connection storms.

Practice this question →

MCQeasy

A new feature stores user events in DynamoDB. Each event must be fetched by user_id and sorted by event_time. The team expects many different users and wants to avoid a single hot partition. Which partition key design is best?

A.Use a constant partition key value (for example, partition_key='events') and store user_id as an attribute.

B.Use user_id as the partition key and event_time as the sort key.

C.Use event_time as the partition key and user_id as an attribute to query later.

D.Use a randomly generated UUID as the partition key and query by user_id using a full table scan.

AnswerB

Using user_id as the partition key spreads data across many partitions based on user distribution. event_time as the sort key supports efficient range queries and retrieving events in time order per user. This design matches the stated access pattern and reduces hot partition likelihood.

Why this answer

Using `user_id` as the partition key ensures each user's events are stored in a separate partition, distributing the workload evenly and avoiding hot partitions. Adding `event_time` as the sort key allows DynamoDB to efficiently retrieve events for a given user in sorted order using a Query operation, which is both fast and cost-effective.

Exam trap

The trap here is that candidates may choose a constant partition key (Option A) thinking it simplifies queries, but they overlook that DynamoDB's scalability depends on partition key cardinality, and a single partition key creates a bottleneck that defeats the purpose of a NoSQL database.

How to eliminate wrong answers

Option A is wrong because using a constant partition key value (e.g., `'events'`) forces all data into a single partition, creating a hot partition that throttles performance and defeats the purpose of DynamoDB's distributed architecture. Option C is wrong because using `event_time` as the partition key scatters events across partitions without grouping by user, so fetching all events for a specific user would require a costly full table scan or a Scan with a filter, which is inefficient and not sorted. Option D is wrong because a randomly generated UUID partition key distributes writes well but makes it impossible to query by `user_id` without a full table scan, as DynamoDB cannot query across partitions without knowing the exact partition key values.

Practice this question →

MCQhard

Based on the exhibit, which design change is the best way to reduce the observed read latency for this DynamoDB-backed service?

A.Add a DynamoDB Accelerator (DAX) cluster in front of the table and send repeated read traffic through it.

B.Increase the on-demand table limits so DynamoDB can automatically absorb more traffic.

C.Create a global secondary index on tenantId to distribute the load across more partitions.

D.Move the dashboard data into S3 and use Lambda functions to read it on demand.

AnswerA

Why this answer

Adding a DynamoDB Accelerator (DAX) cluster in front of the table reduces read latency by providing an in-memory cache for repeated read traffic. DAX delivers microsecond response times for eventually consistent reads, which directly addresses the observed latency issue without requiring application-level caching or table redesign.

Exam trap

The trap here is that candidates often assume increasing capacity limits (Option B) or adding indexes (Option C) will solve latency issues, but they fail to recognize that latency is a caching problem, not a throughput or partitioning problem, and that DAX is the AWS-native solution for DynamoDB read-heavy workloads with repeated access patterns.

Why the other options are wrong

Increasing on-demand table limits does not reduce read latency; it only prevents throttling. The observed latency is likely due to repeated reads of the same hot data, which DAX caching addresses directly.

A GSI on tenantId does not reduce read latency for repeated reads of the same data; it only helps with query flexibility. The observed latency is likely due to hot partitions or throttling, which DAX's caching directly addresses.

Moving dashboard data to S3 and using Lambda to read it on demand would likely increase read latency due to cold starts and S3's higher latency for small, frequent reads compared to DAX. It also adds complexity and cost without addressing the root cause of high read latency on DynamoDB.

Practice this question →

MCQmedium

A media platform runs a CPU-heavy thumbnail generation workload on an EC2 Auto Scaling group using t3.large instances. During peak traffic, p95 processing time increases significantly even though average CPU remains around 40–50%. CloudWatch also shows CPU credit depletion behavior. Which change will most directly improve performance predictability for this workload?

A.Increase the t3.large maximum CPU credits and keep the Auto Scaling group using the same burstable instance type.

B.Change the Auto Scaling group instance type to a compute-optimized family (for example, c7i) to provide steady CPU performance.

C.Add a placement group to the existing t3.large instances so they are packed close together for lower latency between nodes.

D.Switch the workload to run on Lambda with the same logic so invocations automatically scale without instance selection changes.

AnswerB

Compute-optimized instances are designed for consistently high CPU performance and do not rely on a burst-credit model. Switching to a steady-performance family removes the credit-depletion/throttling pattern that is driving the p95 latency spikes under sustained load.

Why this answer

The t3.large instances rely on CPU credits for burst performance, and when credits are exhausted, CPU performance is throttled to the baseline (e.g., 30% for t3.large). This causes unpredictable processing times during peak traffic, even if average CPU is moderate. Switching to a compute-optimized family like c7i provides dedicated, consistent CPU performance without credit-based throttling, directly improving predictability for CPU-heavy thumbnail generation.

Exam trap

The trap here is that candidates assume 'CPU credit depletion' can be fixed by increasing credits or scaling out, but the real issue is that burstable instances are fundamentally unsuitable for sustained CPU-heavy workloads, and only switching to a non-burstable instance type (e.g., compute-optimized) guarantees predictable performance.

How to eliminate wrong answers

Option A is wrong because increasing maximum CPU credits (which is not a configurable parameter; t3 instances have a fixed credit earning/balance limit) would only delay throttling, not eliminate it, and the workload would still face unpredictable performance once credits are depleted. Option C is wrong because placement groups optimize network latency between instances (e.g., for tightly coupled workloads like HPC), but the issue here is CPU credit exhaustion, not network latency. Option D is wrong because Lambda has a 15-minute execution timeout and limited CPU allocation per invocation (proportional to memory), making it unsuitable for long-running, CPU-heavy thumbnail generation; it also introduces cold start latency and does not inherently solve the CPU credit problem.

Practice this question →

Multi-Selectmedium

A DevOps team is designing a high-performance CI/CD pipeline to build and test code changes. The pipeline needs to scale to handle hundreds of concurrent builds, with fast build times and minimal idle compute cost. The builds are containerized and require consistent, reproducible environments. Which three options should be used to meet these requirements? (Choose three.)

Select 3 answers

.Use AWS CodeBuild with a large number of concurrent build projects.

.Use self-managed Jenkins on EC2 Spot Instances to reduce costs.

.Use AWS CodePipeline to orchestrate the build, test, and deploy stages.

.Use AWS CodeBuild with pre-built Docker images cached in Amazon ECR.

.Use Amazon EC2 Auto Scaling with a custom AMI for build agents.

.Use Amazon S3 as a cache store for CodeBuild to speed up dependency download.

Why this answer

AWS CodePipeline is the correct orchestration service to define and manage the CI/CD pipeline stages (build, test, deploy) in a serverless, highly available manner. Pre-built Docker images cached in Amazon ECR ensure consistent, reproducible environments and drastically reduce build times by avoiding image rebuilds. Using Amazon S3 as a cache store for CodeBuild allows storing and retrieving dependency caches (e.g., Maven .m2, npm node_modules) across builds, minimizing download times and speeding up the pipeline.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing self-managed or auto-scaling options (like Jenkins or EC2 Auto Scaling) instead of recognizing that AWS managed services (CodePipeline, CodeBuild, ECR, S3) provide the required scalability, speed, and cost efficiency with far less operational overhead.

Practice this question →

MCQeasy

Based on the exhibit, which EBS volume type should the team use to meet the performance need at lower cost than overprovisioning capacity?

A.Use gp3 and provision the needed IOPS independently of volume size.

B.Use sc1 because it is optimized for infrequent access and large objects.

C.Use st1 because it provides high throughput for streaming data.

D.Use standard magnetic storage because it is compatible with all EC2 instances.

AnswerA

gp3 is the best fit because it lets you provision IOPS and throughput separately from volume size. The exhibit shows the workload needs around 10,000 IOPS and experiences queue buildup on gp2. With gp3, the team can raise performance without unnecessarily increasing storage capacity, which is usually more cost-effective for this kind of database workload.

Why this answer

The gp3 volume type allows you to provision baseline performance of 3,000 IOPS and 125 MiB/s regardless of volume size, and you can independently increase IOPS up to 16,000 and throughput up to 1,000 MiB/s without needing to add more storage capacity. This decoupling of performance from size means you can meet the required IOPS at a lower cost compared to gp2, where performance scales with volume size and often forces overprovisioning of capacity to achieve the needed IOPS.

Exam trap

The trap here is that candidates assume all EBS volume types require overprovisioning capacity to achieve higher IOPS, overlooking gp3's ability to independently scale performance from storage size, which is a key differentiator tested on the SAA-C03 exam.

How to eliminate wrong answers

Option B is wrong because sc1 (Cold HDD) is designed for infrequently accessed, large sequential workloads with a maximum throughput of 250 MiB/s and very low IOPS (tens), making it unsuitable for workloads requiring consistent IOPS performance. Option C is wrong because st1 (Throughput Optimized HDD) is optimized for high-throughput, sequential streaming data (e.g., big data, log processing) and cannot provide the low-latency, random IOPS that gp3 delivers. Option D is wrong because standard magnetic storage (previous generation) offers very low IOPS (approximately 100 IOPS per volume) and is not cost-effective for any performance-sensitive workload, nor is it compatible with all modern EC2 instance types (e.g., Nitro-based instances do not support it).

Practice this question →

MCQeasy

Based on the exhibit, what change best reduces Lambda cold-start impact for a predictable user-upload workflow?

A.Set a reserved concurrency limit for the function to protect it from throttling.

B.Enable provisioned concurrency for the function.

C.Increase the function timeout to give more time for initialization.

D.Move the function to a larger memory setting only to eliminate all initialization time.

AnswerB

Provisioned concurrency keeps a pre-initialized pool of Lambda execution environments ready to respond immediately. The exhibit shows long init duration after inactivity, which is the classic symptom of cold starts affecting user experience. Because the traffic pattern is predictable during launches, provisioned concurrency is the most direct way to reduce startup latency and smooth response times.

Why this answer

Provisioned concurrency initializes a specified number of execution environments in advance, so when a user upload triggers the Lambda function, there is no cold-start delay. This directly addresses the predictable, user-upload workflow by ensuring warm containers are ready to handle requests immediately.

Exam trap

The trap here is confusing reserved concurrency (which limits concurrency to prevent throttling) with provisioned concurrency (which pre-warms instances to eliminate cold starts), leading candidates to choose a throttling protection mechanism instead of a cold-start mitigation solution.

Why the other options are wrong

Reserved concurrency limits protect a function from throttling by other functions, but they do not reduce cold-start latency. Cold starts occur when a new execution environment is initialized, and reserved concurrency does not pre-warm instances.

Increasing memory reduces initialization time but does not eliminate it; cold starts still occur. The question asks to 'best reduce' cold-start impact, and provisioned concurrency (option B) keeps functions initialized and ready, which is more effective than merely speeding up initialization.

Practice this question →

MCQeasy

A.Tune the container health check settings so tasks stop failing and stay running.

B.Use an ECS capacity provider (or Auto Scaling integration) to scale the EC2 instances based on ECS demand.

C.Pin all tasks to a single Availability Zone to reduce placement overhead.

D.Switch the tasks to run only on Fargate so EC2 scaling is no longer relevant.

AnswerB

Why this answer

An ECS capacity provider (or Auto Scaling integration) directly links ECS task-level demand to EC2 instance scaling. When tasks are pending due to insufficient container instances, the capacity provider triggers a scale-out event on the Auto Scaling group, adding EC2 instances to accommodate the workload. This is the most direct and efficient architectural step to reduce the wait time for available container instances during peak traffic.

Exam trap

The trap here is that candidates may think tuning health checks (Option A) or switching to Fargate (Option D) are simpler fixes, but the question specifically asks for the best first architectural step to scale EC2 capacity faster, which is directly addressed by the capacity provider integration.

How to eliminate wrong answers

Option A is wrong because tuning health check settings does not address the root cause of insufficient EC2 capacity; it only affects task lifecycle management, not the number of available container instances. Option C is wrong because pinning tasks to a single Availability Zone increases risk of failure and does not solve the capacity shortage; placement overhead is negligible compared to the lack of instances. Option D is wrong because switching to Fargate is a migration, not an architectural step for the existing EC2-based service, and it does not address the immediate need for faster scale-out of the underlying EC2 capacity.

Practice this question →

MCQmedium

A startup runs an HTTP/2 API that also supports WebSocket connections. They need path-based routing to separate microservices (for example, /api/* to Service A and /metrics/* to Service B) and want TLS terminated at the load balancer. Which AWS option best meets these requirements while maintaining high request performance?

A.Use an Amazon NLB and configure target groups with HTTP health checks and listener rules for path-based routing.

B.Use an Amazon ALB with HTTP/2 support, WebSocket upgrades enabled, and listener rules for host/path-based routing.

C.Use Amazon API Gateway with a single backend integration and rely on the client to route requests to different microservices.

D.Use Amazon CloudFront without an ALB, and route requests to microservices using only custom origin headers.

AnswerB

An ALB supports Layer 7 features needed here: it can terminate TLS on an HTTPS listener, evaluate HTTP host/path routing rules, and it supports WebSocket by allowing HTTP Upgrade behavior through the ALB to the targets. ALBs also support HTTP/2 on HTTPS listeners, which helps maintain high request performance.

Why this answer

An Application Load Balancer (ALB) natively supports HTTP/2, WebSocket upgrades, and path-based routing via listener rules. It terminates TLS at the load balancer, offloading encryption from backend services, and maintains high performance for both HTTP/2 and WebSocket traffic. This makes ALB the correct choice for the startup's requirements.

Exam trap

The trap here is that candidates may confuse NLB's Layer 4 capabilities with ALB's Layer 7 features, incorrectly assuming NLB can handle path-based routing or WebSocket upgrades, when in fact it cannot inspect application-layer data.

Why the other options are wrong

NLB does not support path-based routing or HTTP/2; it operates at Layer 4 and cannot inspect HTTP paths or handle WebSocket upgrades natively.

API Gateway does not natively support WebSocket connections with path-based routing to separate microservices; it would require custom integration logic and cannot directly route to different services based on path patterns like /api/* and /metrics/*.

CloudFront does not natively support WebSocket connections or path-based routing to separate microservices based on URL paths like /api/* and /metrics/*; it is a CDN, not a load balancer with those routing capabilities.

Practice this question →

MCQeasy

A team runs a latency-sensitive service on EC2 and needs consistent, low-latency block storage for a database. The application requires predictable performance and should be fast for random reads/writes. Which EBS volume type is the best choice?

A.EBS st1 (throughput optimized HDD)

B.EBS gp3 (general purpose SSD)

C.EBS sc1 (cold HDD)

D.EBS magnetic (legacy magnetic)

AnswerB

gp3 is designed for a broad range of general-purpose workloads with solid low-latency performance. It supports random I/O patterns and offers predictable performance for many latency-sensitive applications. It is a common best-fit choice when you need balanced performance without specialized throughput-focused characteristics.

Why this answer

B is correct because gp3 is a general-purpose SSD that provides consistent, low-latency performance for random read/write operations, making it ideal for latency-sensitive databases. It offers a baseline of 3,000 IOPS and 125 MB/s throughput, with the ability to independently scale IOPS up to 16,000 and throughput up to 1,000 MB/s, ensuring predictable performance without the burst-bucket limitations of gp2.

Exam trap

The trap here is that candidates often confuse throughput-optimized HDDs (st1) with low-latency needs, mistakenly thinking 'throughput' implies fast performance, when in fact HDDs are unsuitable for random I/O and latency-sensitive workloads.

Why the other options are wrong

EBS st1 is a throughput-optimized HDD volume designed for large, sequential workloads, not for low-latency random reads/writes required by a database.

EBS sc1 (cold HDD) is designed for infrequently accessed, cold data with low throughput requirements, not for low-latency, high-performance random reads/writes needed by a database.

Practice this question →

MCQmedium

A read-heavy document portal repeatedly queries the same product catalogue data from DynamoDB with millisecond latency requirements. Which service can reduce read latency and table load? The team wants the control to be enforceable during normal operations.

A.Amazon Kinesis Data Firehose

B.S3 Transfer Acceleration

C.DynamoDB Accelerator (DAX)

D.AWS Glue Data Catalog

AnswerC

DAX is an in-memory cache for DynamoDB that reduces read latency for suitable access patterns.

Why this answer

DynamoDB Accelerator (DAX) is an in-memory cache specifically designed for DynamoDB that can reduce read latency from single-digit milliseconds to microseconds, while offloading read traffic from the underlying table. This directly addresses the read-heavy workload and millisecond latency requirements, and the team can enforce its use during normal operations by configuring the application to route reads through the DAX cluster endpoint.

Exam trap

The trap here is that candidates may confuse DAX with ElastiCache (which is a general-purpose cache but not DynamoDB-native) or assume that S3 Transfer Acceleration can improve DynamoDB read performance, when in fact DAX is the only AWS service purpose-built to cache DynamoDB reads with sub-millisecond latency.

How to eliminate wrong answers

Option A is wrong because Amazon Kinesis Data Firehose is a streaming data ingestion service for loading data into data lakes and analytics tools, not a caching layer for DynamoDB reads. Option B is wrong because S3 Transfer Acceleration speeds up uploads to S3 over long distances using AWS edge locations, but it does not cache DynamoDB query results or reduce table load. Option D is wrong because AWS Glue Data Catalog is a metadata repository for ETL jobs and data lake schemas, not a read cache for DynamoDB.

Practice this question →

MCQmedium

A web API runs on an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). During traffic spikes, users experience request timeouts even though CPU stays below 40%. After investigation, you find the ASG often has too few healthy targets to handle the current request rate. Which change will best improve responsiveness during spikes?

A.Keep the ASG scaling policy based on CPU utilization, but increase the ASG min capacity by 50%.

B.Create a target tracking scaling policy using an ALB metric such as RequestCountPerTarget or TargetResponseTime.

C.Enable EC2 detailed monitoring for one-minute granularity and keep CPU scaling.

D.Switch to scaling based on the ASG network out bytes metric only, ignoring ALB response metrics.

AnswerB

Target tracking with an ALB performance metric scales based on the same layer where the problem is observed (requests/latency through the ALB). As traffic spikes, RequestCountPerTarget and/or TargetResponseTime increase; the scaling policy then increases the ASG desired capacity so the ALB has more healthy targets to distribute requests to. That reduces queuing/latency and helps prevent timeouts without waiting for CPU to rise.

Why this answer

The issue is that the ASG has too few healthy targets to handle the request rate, even though CPU is low. A target tracking scaling policy based on RequestCountPerTarget or TargetResponseTime directly aligns scaling with the ALB's view of demand, ensuring the ASG adds instances when request rates spike, regardless of CPU utilization. This addresses the root cause—insufficient capacity to serve incoming requests—rather than relying on a metric (CPU) that does not reflect the bottleneck.

Exam trap

The trap here is that candidates assume CPU utilization is always the best scaling metric, but AWS explicitly tests that ALB-level metrics (RequestCountPerTarget, TargetResponseTime) are more appropriate when the bottleneck is request throughput rather than compute load.

How to eliminate wrong answers

Option A is wrong because increasing the ASG min capacity only raises the baseline number of instances, but does not make the scaling policy responsive to traffic spikes; the ASG will still scale based on CPU, which remains low, so it will not add instances during spikes. Option C is wrong because enabling detailed monitoring (1-minute granularity) improves the frequency of metric data but does not change the fact that CPU utilization is not the correct metric to trigger scaling for this request-rate bottleneck. Option D is wrong because switching to scaling based solely on ASG network out bytes ignores the ALB's request-level metrics, which are more directly correlated with the user-observed timeouts and healthy-target deficit.

Practice this question →

MCQhard

A Lambda-based travel booking site has unpredictable traffic spikes and users see latency caused by cold starts. The function must respond consistently during expected campaign windows. What should be configured?

A.Provisioned concurrency during campaign windows

B.A larger deployment package

C.CloudTrail data events

D.Reserved concurrency only

AnswerA

Provisioned concurrency keeps execution environments initialized and reduces cold-start latency.

Why this answer

Provisioned concurrency initializes a specified number of execution environments in advance, eliminating cold starts for those instances. During campaign windows, this ensures consistent sub‑millisecond latency because the function is always warm and ready to handle requests immediately.

Exam trap

The trap here is that candidates confuse reserved concurrency (a limit) with provisioned concurrency (a pre‑warming mechanism), assuming any concurrency setting solves cold starts, when only provisioned concurrency actively eliminates them.

How to eliminate wrong answers

Option B is wrong because a larger deployment package increases the time needed to download and initialize the code, making cold starts worse, not better. Option C is wrong because CloudTrail data events record API activity for auditing and do not affect Lambda execution latency or concurrency. Option D is wrong because reserved concurrency only caps the maximum number of concurrent executions for a function to prevent it from consuming all available concurrency in an account; it does not pre-warm instances or reduce cold starts.

Practice this question →

MCQmedium

A site serves static assets (JS/CSS) through CloudFront from an S3 origin. After a recent frontend change, CloudFront shows a cache hit ratio below 20%. In CloudFront access logs, requests to the same asset URL path differ by a query parameter named rnd (a random value appended by the app on every request). The origin content is identical regardless of rnd. What is the best CloudFront configuration change to restore effective caching?

A.Increase the origin response Cache-Control max-age header on S3 so CloudFront caches longer even with different rnd values.

B.Create a custom CloudFront Cache Policy that does not include the rnd query parameter in the cache key (whitelist only required parameters, or forward no query strings).

C.Disable compression on CloudFront so the response body is identical byte-for-byte and cache hits improve.

D.Switch the origin from S3 to an ALB so CloudFront can cache based on ALB target health checks instead of the query string.

AnswerB

CloudFront caching effectiveness depends on the cache key. Since rnd does not change the content returned by the S3 origin, excluding rnd from the cache key allows many requests for the “same” asset to map to the same cached object. This removes cache fragmentation and restores a higher hit ratio without changing application content correctness.

Why this answer

The rnd query parameter makes each request appear unique to CloudFront, causing a cache miss for every request even though the underlying content is identical. By creating a custom cache policy that either forwards no query strings or whitelists only required parameters, CloudFront will ignore the rnd parameter when computing the cache key, allowing it to serve cached responses and dramatically improve the cache hit ratio.

Exam trap

The trap here is that candidates often think increasing cache duration (Option A) or disabling compression (Option C) will fix cache misses, when the real issue is that the query parameter is being included in the cache key, making every request unique.

How to eliminate wrong answers

Option A is wrong because increasing Cache-Control max-age only tells the browser and edge how long to cache the response, but it does not change the cache key; CloudFront still treats URLs with different rnd values as distinct objects, so each request will be a cache miss. Option C is wrong because disabling compression does not affect the cache key; CloudFront already caches compressed and uncompressed versions separately based on the Accept-Encoding header, and the issue here is the query string, not compression. Option D is wrong because switching to an ALB does not solve the query-string-based cache key problem; CloudFront would still see different rnd values as different cache keys, and ALBs are not designed to improve CloudFront caching behavior.

Practice this question →

Multi-Selectmedium

A company is designing a high-performance web application that serves static and dynamic content to a global user base. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The static assets are stored in an S3 bucket. Which three architecture decisions will improve performance and reduce latency for users? (Choose three.)

Select 3 answers

.Place the EC2 instances in a single Availability Zone to reduce network latency.

.Use Amazon CloudFront to cache both static and dynamic content at edge locations.

.Integrate the ALB with AWS Global Accelerator to route traffic over the AWS global network.

.Use a larger EC2 instance type with higher network bandwidth, such as the c5n or m5n family.

.Enable S3 Transfer Acceleration on the bucket for faster downloads.

.Use an Amazon RDS Multi-AZ database for read replicas to offload read traffic.

Why this answer

Amazon CloudFront caches both static and dynamic content at edge locations, reducing latency by serving content from locations closer to users. AWS Global Accelerator improves performance by routing traffic over the AWS global network instead of the public internet, reducing jitter and latency. Larger EC2 instance types like c5n or m5n provide higher network bandwidth, which reduces network bottlenecks for high-traffic applications.

Exam trap

The trap here is that candidates may confuse S3 Transfer Acceleration as a solution for faster downloads, when it only accelerates uploads, or think Multi-AZ RDS provides read scaling, when it is for failover only.

Practice this question →

Multi-Selecthard

An application uses Amazon Aurora MySQL. CloudWatch shows the writer instance near 85% CPU while the only reader instance averages 15% CPU. Trace logs show that all SELECT statements still target the writer endpoint. The workload is read-heavy, and the application already tolerates eventual consistency for reads. Which two changes will best increase total read throughput without a schema redesign? Select two.

Select 2 answers

A.Point read-only queries to the Aurora reader endpoint instead of the writer endpoint.

B.Add one or more additional Aurora Replicas and distribute read traffic across them.

C.Convert the cluster to a single-AZ RDS MySQL instance to reduce replication overhead.

D.Replace the writer endpoint with the instance endpoint of the primary node to speed up SELECT queries.

E.Add Amazon ElastiCache and move all database writes into the cache layer.

AnswersA, B

The reader endpoint is intended for read-only traffic and automatically distributes connections across Aurora Replicas. Redirecting SELECT statements away from the writer immediately reduces CPU pressure on the writer and uses the unused read capacity already available in the cluster. This is the fastest, lowest-risk way to improve read throughput without changing the schema or the application data model.

Why this answer

The Aurora reader endpoint is designed to distribute read-only connections across all available Aurora Replicas, offloading SELECT queries from the writer instance. Currently, all SELECT statements target the writer endpoint, causing the writer's CPU to be at 85% while the reader instance is underutilized at 15%. By redirecting read traffic to the reader endpoint, the writer's CPU load decreases, and the existing reader instance can handle more read throughput without any schema changes.

Exam trap

The trap here is that candidates may think adding more reader instances alone solves the problem, but they must first redirect read traffic away from the writer endpoint—otherwise, the new replicas remain idle and the writer remains overloaded.

Practice this question →