All practice questions

1462 questions

All types1,462 Multiple choice739 Multiple select723

A solutions architect is designing a high-performance web application that stores user session data. The application requires a database solution that can deliver sub-millisecond response times for read operations. Which database solution should the solutions architect implement to meet these performance requirements?

Amazon DynamoDB with DynamoDB Accelerator (DAX)

Amazon DynamoDB with a partition key based on a monotonically increasing timestamp

Amazon RDS for MySQL with a read replica configured as the primary automatic failover target

Amazon DynamoDB configured with provisioned capacity mode to handle highly unpredictable and spiky workloads

Show answer & explanation

Answer: Amazon DynamoDB with DynamoDB Accelerator (DAX)

Answer

Amazon DynamoDB with DynamoDB Accelerator (DAX)

The database solution using Amazon DynamoDB with DynamoDB Accelerator (DAX) is correct because DAX is a fully managed, in-memory cache for DynamoDB that delivers microsecond response times for read-heavy workloads, satisfying the sub-millisecond latency requirement for session data.

Step-by-Step Solution

Analyze the performance and latency requirements of the database.

The application requires sub-millisecond read latency for user session data.

Identifying the target latency helps narrow down database options to in-memory caching solutions.

Evaluate Amazon DynamoDB configurations for sub-millisecond read latency.

Standard DynamoDB latency is single-digit milliseconds, but adding DynamoDB Accelerator (DAX) reduces read latency to microseconds.

DAX provides a fully managed, highly available in-memory cache built specifically for Amazon DynamoDB.

Key Concept

Sub-millisecond caching for DynamoDB

Question 762Question →

A company runs a production database on an Amazon RDS for PostgreSQL DB instance. The application experiences a sudden increase in read traffic, causing high database CPU utilization and increased query latency. The application requires sub-millisecond latency for frequently accessed data, and the overall read load on the primary database must be reduced. Which two actions should a solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Deploy an Amazon ElastiCache cluster to cache frequently accessed query results.

Create Amazon RDS read replicas to offload read traffic from the primary DB instance.

Enable Amazon RDS Multi-AZ deployment and configure the application to direct read queries to the standby DB instance.

Migrate the database to Amazon DynamoDB and define the partition key using a monotonically increasing timestamp.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache cluster to cache frequently accessed query results.; Create Amazon RDS read replicas to offload read traffic from the primary DB instance.

Answer

Deploying an Amazon ElastiCache cluster to cache queries and creating Amazon RDS read replicas to offload read traffic.

To achieve sub-millisecond read latency, caching is required. Deploying an in-memory cache such as Amazon ElastiCache in front of the database stores the results of common queries, serving them extremely quickly. To offload the remaining read traffic from the primary database, Amazon RDS read replicas are used to distribute the read workload horizontally across one or more replica nodes.

Step-by-Step Solution

Analyze the performance requirements: the workload needs to handle high read volume and achieve sub-millisecond latency for frequently accessed data.

Caching is required for sub-millisecond latency, and read scaling is needed for the remaining database read traffic.

Standard relational databases cannot guarantee sub-millisecond latencies under high load, but an in-memory cache can.

Identify the caching layer options.

Amazon ElastiCache is the standard in-memory caching service for RDS that provides sub-millisecond retrieval speeds.

Caching frequently accessed data directly offloads the database and provides the required low latency.

Identify the database scaling options for the remaining read traffic.

Amazon RDS read replicas scale read throughput horizontally.

Read replicas allow the application to route read-only queries away from the primary database instance.

Key Concept

Scaling relational database read performance using in-memory caching and read replicas.

Question 763Question →

A ride-sharing platform needs to design an ingestion pipeline to process GPS location updates from its fleet of vehicles. During peak hours, the system receives approximately $8,000$ write requests per second, with an average payload size of $1.5 \text{ KB}$ per update. The GPS data must be processed in real-time with sub-second latency for immediate routing and ETA calculations. Additionally, the data must be transformed into Parquet format and stored in Amazon S3 for historical analysis. Which architecture meets these requirements with the highest performance and scalability?

Ingest the data using Amazon Kinesis Data Streams configured in On-Demand capacity mode. Process the stream in real-time with a custom consumer application for ETA calculations. Configure Amazon Data Firehose to consume from the same Kinesis stream, transform the data to Parquet format using an AWS Lambda function, and deliver it to an Amazon S3 Standard bucket.

Ingest the data using Amazon Kinesis Data Streams configured in Provisioned capacity mode with

5

shards. Process the stream in real-time with a custom consumer application for ETA calculations. Configure Amazon Data Firehose to consume from the same Kinesis stream, transform the data to Parquet format using an AWS Lambda function, and deliver it to an Amazon S3 Standard bucket.

Ingest the data using a standard Amazon SQS queue to decouple the ingestion layer. Configure the real-time application to poll the queue to compute ETAs, and configure a fleet of EC2 instances to retrieve the messages, transform them to Parquet format, and write them to an Amazon S3 Standard bucket.

7

days.

Show answer & explanation

Answer: Ingest the data using Amazon Kinesis Data Streams configured in On-Demand capacity mode. Process the stream in real-time with a custom consumer application for ETA calculations. Configure Amazon Data Firehose to consume from the same Kinesis stream, transform the data to Parquet format using an AWS Lambda function, and deliver it to an Amazon S3 Standard bucket.

Answer

The correct answer provides an ingestion layer (Amazon Kinesis Data Streams in On-Demand capacity mode) that dynamically scales to handle peak volumes of

8,000

records per second (

12 \text{ MB/s}

). It supports multi-consumer routing: a custom real-time application can query Kinesis directly to keep latency below one second for route modeling, while Amazon Data Firehose consumes the same stream asynchronously to convert payloads to Parquet using AWS Lambda and delivers them to Amazon S3 Standard for long-term historical query optimization.

Step-by-Step Solution

Calculate the peak throughput requirements of the system.

The peak ingestion rate is

8,000

records per second with a payload of

1.5 \text{ KB}

per record, which equates to

12 \text{ MB/s}

of write throughput (

8,000 \times 1.5 \text{ KB} = 12,000 \text{ KB/s}

Understanding the numerical throughput bounds helps in selecting the appropriate stream capacity model.

Choose the optimal stream capacity configuration.

Select Kinesis Data Streams in On-Demand capacity mode, which dynamically scales to accommodate the required

12 \text{ MB/s}

and

8,000

write requests per second.

Using a fixed number of provisioned shards (such as

5

shards, which only support up to

5 \text{ MB/s}

and

5,000

records/sec) would lead to write throttling under peak conditions.

Select the consumer patterns for real-time processing and storage delivery.

Connect a real-time consumer application directly to Kinesis Data Streams to handle sub-second latency routing calculations. Simultaneously, attach Amazon Data Firehose to the same stream to run format conversion to Parquet via AWS Lambda, saving the outputs in Amazon S3 Standard.

Kinesis Data Streams allows multiple consumers to process the same stream in parallel, accommodating both real-time analytical calculations and near-real-time batch transformation workflows.

Key Concept

Selecting and sizing ingestion services (Kinesis Data Streams vs. SQS vs. Firehose) to meet strict throughput, ordering, and format transformation performance requirements.

Estimated Time:1m 30s

Question 764Question →

A company hosts its primary web application behind an Application Load Balancer (ALB) in the us-east-1 Region. The company wants to set up a simple disaster recovery strategy where public DNS traffic is automatically redirected to a static error page hosted on an Amazon S3 bucket in the us-west-2 Region if the primary application becomes unavailable. Which Amazon Route 53 routing configuration should a solutions architect implement to meet these requirements?

Configure Route 53 failover routing. Create a primary failover record pointing to the ALB with health checks enabled, and a secondary failover record pointing to the S3 bucket endpoint.

Configure Route 53 latency routing records pointing to both the ALB and the S3 bucket endpoint, relying on Route 53 to automatically route all traffic to the S3 bucket during a primary region outage.

Configure a Route 53 database failover policy that monitors the application's RDS read replica in us-west-2 and automatically redirects all client web traffic to that replica when the primary database fails.

Configure Route 53 with a pilot light routing record that keeps the S3 bucket endpoint inactive and scale-up the bucket's resources only after a CloudWatch alarm triggers a failover event.

Show answer & explanation

Answer: Configure Route 53 failover routing. Create a primary failover record pointing to the ALB with health checks enabled, and a secondary failover record pointing to the S3 bucket endpoint.

Answer

Configure Route 53 failover routing by creating a primary failover record pointing to the ALB with health checks enabled, and a secondary failover record pointing to the S3 bucket endpoint.

The correct answer correctly identifies that a failover routing policy should be used for active-passive disaster recovery. By setting the Application Load Balancer as the primary endpoint and enabling health checks, Route 53 will route traffic to the primary endpoint as long as it is healthy. If the health checks fail, Route 53 automatically redirects incoming DNS queries to the secondary endpoint, which is the Amazon S3 static website.

Step-by-Step Solution

Define the primary and secondary roles for the endpoints.

The Application Load Balancer (ALB) is designated as the primary active resource, and the Amazon S3 bucket static website endpoint is designated as the secondary passive resource.

This establishes the active-passive disaster recovery structure required by the business goal.

Associate health checks with the primary record.

Route 53 monitors the health of the primary ALB.

Route 53 requires health check status to determine when to trigger a failover from the primary resource to the secondary resource.

Configure the routing policy in Route 53.

Create a primary failover alias record pointing to the ALB and a secondary failover alias record pointing to the S3 status/error page.

Failover routing directs traffic to the primary resource when healthy and automatically switches to the secondary resource when the primary fails health checks.

Key Concept

Amazon Route 53 DNS Failover with Active-Passive Architecture

Question 765Question →

A financial services company has a hybrid architecture where their on-premises trading application must securely stream data feeds to a fleet of Amazon EC2 instances in a VPC. The stream requires a sustained throughput of $2\text{ Gbps}$ with minimal latency. Due to tight timelines, they must leverage their existing high-bandwidth internet connection rather than waiting to provision a dedicated fiber line. Additionally, they must ensure the return traffic is allowed dynamically while maintaining strict stateful traffic filtering. Which network architecture should a solutions architect recommend to meet these requirements?

Deploy a single Site-to-Site VPN connection and configure Amazon Route 53 with latency-based routing to dynamically load balance the trading traffic across the VPN tunnels to optimize performance.

Deploy an AWS Transit Gateway and establish multiple AWS Site-to-Site VPN connections using Equal-Cost Multi-Path (ECMP) routing. Configure EC2 security groups to allow the trading traffic, relying on their stateful nature to permit return traffic automatically.

Establish a single AWS Site-to-Site VPN connection with active-active tunnels directly to a Virtual Private Gateway, and configure the on-premises router to load balance traffic across both tunnels to achieve the required

2\text{ Gbps}

throughput.

Deploy an AWS Transit Gateway with multiple VPN connections, and configure stateless Network ACLs on the subnets to bypass security group evaluation to optimize network throughput for the return traffic.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway and establish multiple AWS Site-to-Site VPN connections using Equal-Cost Multi-Path (ECMP) routing. Configure EC2 security groups to allow the trading traffic, relying on their stateful nature to permit return traffic automatically.

Answer

Deploy an AWS Transit Gateway with multiple AWS Site-to-Site VPN connections using Equal-Cost Multi-Path (ECMP) routing, and configure stateful EC2 security groups.

The correct option is the one recommending AWS Transit Gateway with multiple VPN connections and ECMP routing. AWS Site-to-Site VPN tunnels have a hard throughput limit of

1.25\text{ Gbps}

. To scale bandwidth over existing internet connections, multiple VPN connections can be attached to an AWS Transit Gateway with ECMP enabled, allowing traffic to be distributed across up to 50 paths. Utilizing security groups ensures stateful filtering, which automatically allows dynamic return traffic.

Step-by-Step Solution

Evaluate the throughput requirement against VPN tunnel limitations.

The target is

2\text{ Gbps}

, which exceeds the

1.25\text{ Gbps}

maximum limit of a single AWS VPN tunnel.

Identifying the single tunnel bottleneck determines that a multi-tunnel or alternative path is required.

Select the scaling mechanism to aggregate VPN throughput over the internet.

Combine multiple VPN connections using AWS Transit Gateway with Equal-Cost Multi-Path (ECMP) routing.

ECMP on Transit Gateway allows active-active load balancing across multiple tunnels, enabling total throughput to scale past

1.25\text{ Gbps}

Address the traffic filtering and dynamic return traffic requirement.

Utilize stateful EC2 security groups to filter the traffic.

Security groups are stateful and automatically track connections to allow dynamic return traffic, whereas Network ACLs are stateless and would block return traffic unless a broad range of ports is manually opened.

Key Concept

Scaling VPN throughput using AWS Transit Gateway ECMP routing while maintaining stateful traffic filtering.

Question 766Question →

An IoT telemetry platform receives status updates from $500,000$ devices, with each device sending an update every $10$ seconds. A solutions architect is designing an Amazon DynamoDB table to store these updates. The system must support a write volume of $50,000$ writes per second with sub-millisecond latency. The primary query pattern is to retrieve all status updates for a specific day, sorted by the recording timestamp, with a target latency of under $100$ milliseconds.

To meet these requirements, the architect initially designs the table with a partition key of `status_date` (formatted as `YYYY-MM-DD`) and a sort key of `timestamp#device_id`. During load testing, the application experiences write throttling and receives `ProvisionedThroughputExceededException` errors, even though the total provisioned Write Capacity Units (WCUs) are set high enough to handle the workload.

Which database design modification will resolve this bottleneck while meeting the performance and query requirements?

Redesign the table to use `device_id` as the partition key and `timestamp` as the sort key. Create a Global Secondary Index (GSI) with a partition key of `status_date_shard` (combining the date with a calculated hash prefix between

0

and

49

) and a sort key of `timestamp`. Configure the application to query all

50

GSI shards in parallel for a given date and merge the results.

Redesign the table to use `device_id` as the partition key and `timestamp` as the sort key. Create a Global Secondary Index (GSI) with a partition key of `status_date` and a sort key of `timestamp`. Configure the application to query the GSI to retrieve the daily data.

Enable Amazon DynamoDB Accelerator (DAX) for the table, and update the application to write all status updates through the DAX cluster using a write-through caching strategy.

Migrate the database to Amazon RDS for PostgreSQL. To distribute the write workload and prevent bottlenecks on the primary instance, configure the application to send write operations to the RDS Read Replicas, which will automatically sync and failover if the primary instance is overloaded.

Show answer & explanation

Answer: Redesign the table to use `device_id` as the partition key and `timestamp` as the sort key. Create a Global Secondary Index (GSI) with a partition key of `status_date_shard` (combining the date with a calculated hash prefix between $0$ and $49$ ) and a sort key of `timestamp`. Configure the application to query all $50$ GSI shards in parallel for a given date and merge the results.

Answer

Redesign the table to use `device_id` as the partition key and `timestamp` as the sort key, and create a Global Secondary Index (GSI) with a partition key of `status_date_shard` (using a calculated hash prefix between

0

and

49

) and a sort key of `timestamp`, querying all

50

shards in parallel.

The correct answer resolves the bottleneck by distributing base table writes using a high-cardinality partition key (`device_id`) and distributing GSI writes using a sharded partition key (`status_date_shard`). By splitting the GSI partition key into

50

shards, the write rate to any single GSI partition is reduced to

1,000

writes per second, which matches the physical partition throughput limit of DynamoDB. The application can retrieve all data for a specific day by running

50

parallel queries and combining the results.

Step-by-Step Solution

Analyze the write rate and partition limits.

The application requires

50,000

writes per second. A single DynamoDB partition can support a maximum of

1,000

Write Capacity Units (WCUs) per second. Using `status_date` (which is the same for all writes on a given day) as the partition key concentrates all

50,000

writes on a single partition, exceeding the limit by

50

times.

To understand the physical limits causing the ProvisionedThroughputExceededException.

Evaluate the base table partition key design.

Changing the base table partition key to `device_id` distributes the

50,000

writes across

500,000

unique partitions. This results in

0.1

writes per second per partition, which is well below the

1,000

WCU per-partition limit.

To ensure the base table writes are highly distributed and do not cause throttling.

Evaluate the impact of the Global Secondary Index (GSI) partition key.

If a GSI is created with `status_date` as the partition key, all writes are copied to a single GSI partition. When a GSI partition is throttled, the throttling backpressures the base table, causing the write requests on the base table to fail.

To avoid introducing a downstream write bottleneck via the GSI.

Implement write sharding (synthetic keys) on the GSI.

By appending a calculated hash prefix or random suffix from

0

49

to the `status_date`, the GSI partition key is split into

50

distinct keys (e.g., `2026-07-14_0` to `2026-07-14_49`). The

50,000

writes are evenly distributed, resulting in

1,000

writes per second per shard, which is within the

1,000

WCU partition limit.

To satisfy both the high-throughput write requirement and the ability to query all data for a specific day.

Key Concept

DynamoDB write sharding and partition hot-key mitigation for high-performing database designs.

Question 767Question →

A media streaming company is designing a high-performance, real-time video transcoding and distribution network on AWS. The solution requires:

1. A tightly-coupled compute cluster of Amazon EC2 instances to run low-latency, node-to-node video frame analysis.
2. A scalable fleet of EC2 instances behind an Application Load Balancer (ALB) to serve transcoding APIs. The API service runs on port $8080$ , while a lightweight health status daemon runs on port $80$ on the same instances.

Which two actions should the solutions architect take to satisfy these performance and scalability requirements? (Select two.)

Select all that apply

Deploy the video frame analysis EC2 instances within a single Availability Zone using a cluster placement group.

Configure the target group for the API service with port

8080

and override the health check port configuration to use port

80

Deploy the video frame analysis EC2 instances across multiple Availability Zones using a partition placement group to optimize network throughput.

Configure the target group for the API service with port

8080

and keep the health check port set to the default traffic-port setting.

Deploy the video frame analysis EC2 instances using a spread placement group to maximize throughput and minimize network latency.

Show answer & explanation

Answer: Deploy the video frame analysis EC2 instances within a single Availability Zone using a cluster placement group.; Configure the target group for the API service with port $8080$ and override the health check port configuration to use port $80$ .

Answer

Deploy the video frame analysis EC2 instances within a single Availability Zone using a cluster placement group, and configure the target group for the API service with port

8080

and override the health check port configuration to use port

80

Deploying the tightly-coupled video frame analysis instances in a cluster placement group ensures they are placed on physically close hardware within a single Availability Zone, maximizing network throughput and minimizing node-to-node latency. Additionally, overriding the Application Load Balancer's health check port to port

80

ensures that the health checks are routed to the proper health status daemon, while user API traffic continues to be routed to the API service running on port

8080

Step-by-Step Solution

Analyze the networking requirements for the video frame analysis compute cluster.

Identified that low-latency node-to-node communication is required, indicating a need for a cluster placement group within a single Availability Zone.

Only cluster placement groups provide the physical proximity and high-throughput, low-latency network performance needed for tightly-coupled nodes.

Evaluate the Application Load Balancer target group and health check ports.

Determined that the main application serves traffic on port

8080

but the health check daemon listens on port

80

By default, Application Load Balancers perform health checks on the registered traffic port. If left default, the ALB will query port

8080

instead of

80

, resulting in failed health checks.

Select the correct combination of configurations to achieve both low latency and correct health reporting.

Combine the usage of a cluster placement group for performance and a health check port override to port

80

for resilience.

This setup achieves the required network performance characteristics while ensuring the ALB routes traffic correctly to healthy targets.

Key Concept

Aligning EC2 placement groups with workload performance requirements and overriding ELB health check port settings to match custom target application configurations.

Question 768Question →

A gaming company is launching a new web-based multiplayer game. The application's static assets, such as images and audio files, are stored in an Amazon S3 bucket. The game also retrieves leaderboard data and user profile configurations from an Amazon RDS MySQL database, which is experiencing performance degradation due to high read traffic. A Solutions Architect needs to implement a caching strategy to reduce latency for players globally and decrease the load on the origin servers.

Which combination of actions should the Solutions Architect take to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon CloudFront distribution to serve the static assets from the Amazon S3 bucket.

Deploy an Amazon ElastiCache cluster to cache the frequently accessed database query results from the Amazon RDS database.

Configure the Amazon CloudFront distribution with a default Time to Live (TTL) of 0 seconds for all static assets.

Route traffic to the Amazon S3 bucket through a NAT Gateway in a private subnet to cache static assets and reduce data transfer costs.

Implement Amazon Route 53 latency-based routing to cache dynamic database queries at the DNS level.

Show answer & explanation

Answer: Create an Amazon CloudFront distribution to serve the static assets from the Amazon S3 bucket.; Deploy an Amazon ElastiCache cluster to cache the frequently accessed database query results from the Amazon RDS database.

Answer

To meet these requirements, the Solutions Architect should create an Amazon CloudFront distribution to serve the static assets from the S3 bucket, and deploy an Amazon ElastiCache cluster to cache frequently accessed database query results from the RDS database.

The correct strategy combines Amazon CloudFront to cache static files (images, audio) at edge locations close to users and Amazon ElastiCache to cache database queries, reducing latency and reducing the load on the Amazon RDS origin database.

Step-by-Step Solution

Identify the performance bottlenecks for both the static and dynamic components of the application.

Static assets (images/audio) in S3 suffer from latency when accessed globally, and the RDS database suffers from performance degradation due to high read query volume.

Resolving both issues requires separate caching strategies targeted at different layers (CDN caching for S3 static files, in-memory caching for database queries).

Address static asset latency by implementing an edge content delivery network.

Amazon CloudFront is selected to cache static S3 content at global edge locations.

This reduces response latency for global users and offloads get requests from the S3 origin.

Address database query performance by deploying an in-memory cache.

Amazon ElastiCache is selected to store slow, frequent database query results.

In-memory query caching prevents frequent read requests from reaching the Amazon RDS instance directly, optimizing response times.

Key Concept

Multi-tier caching involves using CDN caching (Amazon CloudFront) for edge distribution of static files and in-memory caching (Amazon ElastiCache) for database read optimization.

Question 769Question →

A company runs a logistics and package tracking application on AWS that uses an Amazon RDS for PostgreSQL database. The database must be configured to survive a single Availability Zone (AZ) failure within the Region. The solution must support automatic failover with a Recovery Time Objective (RTO) of less than $2$ minutes and a Recovery Point Objective (RPO) of $0$ (no data loss). Additionally, the company needs to scale read performance for historical tracking queries without affecting the write performance of the primary database. Which configuration will meet these requirements?

Deploy two independent Single-AZ DB instances in different Availability Zones, and configure Amazon Route 53 with a latency routing policy and health checks to automatically route read and write requests to the healthiest instance.

Deploy the database as a Single-AZ DB instance, create an asynchronous Read Replica in a different Availability Zone, and configure the application to manually promote the Read Replica if the primary instance fails.

Deploy the database as an Amazon RDS Multi-AZ DB instance, create one or more Read Replicas in different Availability Zones, and route application read traffic to the replica endpoints.

Deploy the database as a Single-AZ DB instance, and configure a disaster recovery strategy to restore the database from daily automated snapshots to a new instance in a different Availability Zone during a failure event.

Show answer & explanation

Answer: Deploy the database as an Amazon RDS Multi-AZ DB instance, create one or more Read Replicas in different Availability Zones, and route application read traffic to the replica endpoints.

Answer

Deploy the database as an Amazon RDS Multi-AZ DB instance, create one or more Read Replicas in different Availability Zones, and route application read traffic to the replica endpoints.

Deploying the database as an Amazon RDS Multi-AZ DB instance provides synchronous replication to a standby instance in a different Availability Zone, guaranteeing a Recovery Point Objective (RPO) of

0

(no data loss). In the event of an infrastructure failure, Amazon RDS automatically performs a failover to the standby instance, typically in under

60

120

seconds, which satisfies the Recovery Time Objective (RTO) of less than

2

minutes. To scale read performance without impacting the primary writer, one or more Read Replicas can be deployed to handle read-only queries.

Step-by-Step Solution

Select Amazon RDS Multi-AZ DB instance deployment.

Enables synchronous replication to a standby replica in a second Availability Zone.

Synchronous replication guarantees that write operations are committed to both zones before succeeding, satisfying the RPO of

0

(no data loss).

Rely on RDS automatic failover mechanism.

Database failover to the standby instance occurs automatically within

60

120

seconds during an outage.

Automatic failover satisfies the RTO requirement of less than

2

minutes without manual intervention.

Create one or more RDS Read Replicas in different Availability Zones.

Provides dedicated read endpoints for the application to query historical tracking data.

Offloads read-intensive queries from the primary database instance to keep write performance optimal.

Key Concept

High Availability and Read Scaling with Amazon RDS Multi-AZ and Read Replicas

Estimated Time:2m 0s

Question 770Question →

A global logistics network needs to capture telemetry from $500,000$ IoT sensors. During peak delivery windows, the sensors transmit status updates at a combined rate of $95,000$ writes per second. The application requires sub-millisecond latency when querying the most recent status of any specific device. A solutions architect must design a high-performing database layer that scales efficiently and prevents write bottlenecks. Which database architecture should the solutions architect implement to satisfy these performance requirements?

Configure an Amazon DynamoDB table with the device ID as the partition key and the timestamp as the sort key. Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read operations.

Configure an Amazon DynamoDB table with the timestamp as the partition key and the device ID as the sort key. Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read operations.

Configure an Amazon RDS for PostgreSQL database with Multi-AZ enabled. Create three read replicas to handle the read traffic, and configure the application to promote a read replica to the primary role in the event of a failure.

Configure an Amazon DynamoDB table with the device ID as the partition key. Deploy an Amazon ElastiCache for Redis cluster in front of the table to intercept all write operations and asynchronously commit them to the DynamoDB table.

Show answer & explanation

Answer: Configure an Amazon DynamoDB table with the device ID as the partition key and the timestamp as the sort key. Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read operations.

Answer

Configure an Amazon DynamoDB table with the device ID as the partition key and the timestamp as the sort key, and deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read operations.

The correct architecture uses a high-cardinality partition key (device ID) to distribute write traffic evenly across physical partitions, avoiding throttling bottlenecks. Adding DynamoDB Accelerator (DAX) caches read requests, delivering sub-millisecond (microsecond) latency for the application's queries.

Step-by-Step Solution

Analyze write scaling and throughput requirements.

Identified that a relational database like Amazon RDS is not suitable for a

95,000

writes/sec workload without sharding, pointing to Amazon DynamoDB.

To ensure the database can scale horizontally to meet the massive write throughput.

Select the correct partition key strategy for DynamoDB.

Selected the device ID as the partition key because it has high cardinality and distributes writes evenly across partitions.

To prevent write hot-spotting (partition bottlenecks) caused by monotonically increasing keys like timestamps.

Address the sub-millisecond read latency requirement.

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

DAX provides an in-memory, write-through cache that reduces read response times from single-digit milliseconds to microseconds.

Key Concept

Avoiding partition hot-spotting in Amazon DynamoDB by choosing a high-cardinality partition key (device ID instead of a timestamp) and using DAX to achieve sub-millisecond read latency.

Estimated Time:2m 0s

Question 771Question →

A company wants to distribute static media assets to global users with low latency. The assets are currently stored in a primary Amazon S3 bucket. The company also wants to ensure high availability by automatically serving content from a backup S3 bucket in a different region if the primary bucket is unavailable. Which combination of actions should a solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon CloudFront distribution and define an origin group with the primary S3 bucket as the primary origin and the backup S3 bucket as the secondary origin.

Configure origin failover within the CloudFront origin group to route requests to the backup S3 bucket when the primary S3 bucket returns specific HTTP error status codes.

Configure Amazon Route 53 with a latency routing policy to route traffic directly to the nearest S3 bucket.

Deploy AWS WAF to monitor the health of the primary S3 bucket and automatically redirect requests to the backup bucket when errors are detected.

Set the CloudFront Cache-Control max-age header and default Time to Live (TTL) value to zero for all behaviors to force direct client access to the S3 buckets.

Show answer & explanation

Answer: Create an Amazon CloudFront distribution and define an origin group with the primary S3 bucket as the primary origin and the backup S3 bucket as the secondary origin.; Configure origin failover within the CloudFront origin group to route requests to the backup S3 bucket when the primary S3 bucket returns specific HTTP error status codes.

Answer

Create an Amazon CloudFront distribution and define an origin group with the primary S3 bucket as the primary origin and the backup S3 bucket as the secondary origin. Additionally, configure origin failover within the CloudFront origin group to route requests to the backup S3 bucket when the primary S3 bucket returns specific HTTP error status codes.

To achieve both low latency and high availability for static assets, Amazon CloudFront is the recommended solution. By caching assets at global edge locations, CloudFront reduces the latency for end users. To ensure high availability and automatic failover, CloudFront support for origin groups allows configuring a primary and secondary origin. When origin failover is enabled, CloudFront automatically routes requests to the secondary origin (the backup S3 bucket) if the primary origin (the primary S3 bucket) returns configured error codes (such as 500, 502, 503, or 504).

Step-by-Step Solution

Set up a content delivery network to reduce latency for global users by caching content at edge locations close to them.

An Amazon CloudFront distribution is deployed with caching behaviors configured for the static assets.

CloudFront caches content at edge locations, significantly reducing latency compared to direct S3 access.

Establish origin-level resiliency to protect against S3 bucket unavailability or service issues.

An origin group is configured in CloudFront, containing the primary S3 bucket as the primary origin and the backup S3 bucket as the secondary origin.

An origin group allows the mapping of multiple origins to a single distribution behavior for failover purposes.

Configure the automatic transition rules between the primary and secondary origins.

Origin failover is enabled with criteria pointing to specific 5xx HTTP error status codes.

This guarantees that if the primary S3 bucket is unavailable and returns an error code, CloudFront automatically routes the request to the backup S3 bucket without any operational overhead.

Key Concept

CloudFront Origin Groups and Origin Failover

Question 772Question →

A software development company generates application build logs that average $10\text{ MB}$ in size. These logs are stored in an Amazon S3 Standard bucket and are accessed frequently by developers for debugging during the first 14 days. After 14 days, the logs are no longer needed and can be deleted. Which of the following strategies is the most cost-effective?

Retain the logs in Amazon S3 Standard for the entire 14 days, and then delete them using an S3 Lifecycle expiration rule.

Transition the logs to Amazon S3 Standard-IA after 1 day, and then delete them after 14 days using an S3 Lifecycle expiration rule.

Transition the logs to Amazon S3 Glacier Flexible Retrieval immediately, and then delete them after 14 days using an S3 Lifecycle expiration rule.

Transition the logs to Amazon S3 Standard-IA immediately, and then delete them after 7 days using an S3 Lifecycle expiration rule.

Show answer & explanation

Answer: Retain the logs in Amazon S3 Standard for the entire 14 days, and then delete them using an S3 Lifecycle expiration rule.

Answer

Retain the logs in Amazon S3 Standard for the entire 14 days, and then delete them using an S3 Lifecycle expiration rule.

Keeping the logs in Amazon S3 Standard and deleting them after 14 days is the most cost-effective option. Amazon S3 Standard-IA has a minimum storage duration charge of 30 days. Storing data in S3 Standard for 14 days costs less per gigabyte than paying for the 30-day minimum duration of S3 Standard-IA, and it avoids the transition request costs associated with moving data to S3 Standard-IA.

Step-by-Step Solution

Determine the data retention and access needs.

The logs are accessed frequently for 14 days and then deleted.

This establishes that the files are short-lived (14 days) and need active, frequent access during this time.

Evaluate S3 Standard-IA rules and cost impact.

Amazon S3 Standard-IA has a minimum storage duration charge of 30 days.

If files are transitioned to S3 Standard-IA and deleted after 14 days, AWS will still charge for a full 30 days of storage under that tier.

Compare storage costs between Standard and Standard-IA.

Storing data in S3 Standard for 14 days costs approximately

0.0107 per GB (assuming

0.023/GB/month), whereas S3 Standard-IA for the 30-day minimum costs $0.0125 per GB (excluding transition request charges).

Because the Standard-IA minimum storage charge exceeds the cost of storing the data in S3 Standard for the actual 14 days, keeping the data in S3 Standard is the cheaper and simpler option.

Key Concept

S3 Standard-IA Minimum Storage Duration Constraint

Question 773Question →

A financial services firm runs a containerized microservices application deployed on Amazon ECS across three Availability Zones. The container tasks require concurrent read and write access to a shared directory containing transaction log templates. The storage system must provide POSIX-compliant access, scale throughput up to $600 \text{ MB/s}$ during peak trading hours, and support concurrent connections from hundreds of containers. Which configuration options should a solutions architect select to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon Elastic File System (Amazon EFS) and configure it to use Elastic Throughput mode.

Configure the Amazon ECS task definitions to mount the Amazon EFS volume using the EFS volume configuration.

Provision an Amazon EBS gp3 volume and enable Multi-Attach to share the filesystem across all container tasks.

Configure an Amazon EBS io2 volume with Multi-Attach enabled, formatted with a standard ext4 filesystem, and mount it to the tasks.

Deploy a single Amazon EBS io2 Block Express volume and configure the container tasks to access it concurrently using a standard Network File System (NFS) client.

Show answer & explanation

Answer: Create an Amazon Elastic File System (Amazon EFS) and configure it to use Elastic Throughput mode.; Configure the Amazon ECS task definitions to mount the Amazon EFS volume using the EFS volume configuration.

Answer

The solutions architect should create an Amazon Elastic File System (Amazon EFS) configured with Elastic Throughput mode, and mount the Amazon EFS volume inside the Amazon ECS task definitions.

The requirements dictate concurrent, POSIX-compliant read and write access across three Availability Zones with spiky throughput needs. Amazon EFS provides serverless, highly available, shared file systems that can be concurrently mounted by hundreds of container tasks. Configuring it with Elastic Throughput mode allows the throughput to scale dynamically up to

600 \text{ MB/s}

without pre-provisioning capacity. Standard ECS task configurations natively support mounting EFS volumes.

Step-by-Step Solution

Analyze storage needs

Identified requirements for POSIX-compliant shared file storage, high parallel access (hundreds of containers), cross-AZ availability (three Availability Zones), and dynamic throughput scale up to

600 \text{ MB/s}

This rules out single-instance block storage solutions (EBS) and non-POSIX object stores (S3).

Select the appropriate storage service and performance mode

Choose Amazon EFS, which natively supports POSIX compliance, simultaneous multi-AZ access, and select Elastic Throughput mode to dynamically scale throughput to

600 \text{ MB/s}

Elastic Throughput mode automatically adjusts the filesystem's throughput capabilities to handle the application's peak workloads.

Configure task integration

Reference the Amazon EFS volume configuration within the ECS task definition so container tasks can mount the filesystem.

This allows ECS tasks running across any container instance or Fargate host to easily access the shared file system directory.

Key Concept

Selecting and integrating high-performing, scalable, and shared POSIX storage for containerized applications running across multiple Availability Zones.

Question 774Question →

A company runs a high-performance web service deployed across two AWS Regions: us-east-1 and eu-west-1. The company wants to route users to the closest Region to minimize latency, but must automatically stop routing traffic to a Region if its endpoint fails. The solutions architect needs to configure Amazon Route 53 to meet these requirements.

Which combination of Route 53 configurations should the solutions architect implement? (Select TWO.)

Select all that apply

Create latency-based routing records in Route 53 that point to the endpoints in each Region.

Associate a Route 53 health check with each latency record to monitor endpoint availability.

Create failover routing records in Route 53 and set one Region as primary and the other as secondary.

Configure geolocation routing records to automatically route based on the lowest network latency.

Configure Amazon RDS read replicas in the secondary Region to automatically update the DNS records during a failover event.

Show answer & explanation

Answer: Create latency-based routing records in Route 53 that point to the endpoints in each Region.; Associate a Route 53 health check with each latency record to monitor endpoint availability.

Answer

To achieve low latency and high availability, create latency-based routing records in Route 53 for both Regions and associate each record with a Route 53 health check.

To route users to the closest Region to minimize latency, latency-based routing must be used. To ensure that traffic is not routed to an unhealthy Region, Route 53 health checks must be associated with the routing records so that Route 53 can automatically perform DNS failover when an endpoint becomes unhealthy.

Step-by-Step Solution

Select the appropriate routing policy for minimizing user latency.

Create Route 53 latency-based routing records pointing to endpoints in both us-east-1 and eu-west-1.

Latency-based routing measures round-trip time from the user to the AWS Regions and routes traffic to the Region with the lowest latency.

Configure health checks to ensure high availability.

Associate a Route 53 health check with each latency record.

If an endpoint in one Region fails, Route 53 detects the failure via the health check and stops returning that record, routing traffic to the healthy Region instead.

Key Concept

Active-active multi-region high availability with Route 53 latency routing and health checks

Question 775Question →

A media processing company is building a system to process daily video transcoding workloads. The architecture includes a continuous, steady-state orchestration queue worker that runs $24/7$ on Amazon ECS Fargate, and a highly variable fleet of transcoding workers running containerized tasks to process jobs from an Amazon SQS queue. Each transcoding job takes between $5$ to $30$ minutes to complete, can be safely interrupted and retried from the start, and must be completed within $24$ hours of submission. The transcoding tasks retrieve source videos from an Amazon S3 bucket and write the output back to the same bucket. Which combination of purchasing strategies and compute configurations will meet these requirements MOST cost-effectively? (Select TWO.)

Select all that apply

Purchase a

3

-year Compute Savings Plan to cover the baseline usage of the orchestration queue worker running on Amazon ECS Fargate.

Run the transcoding worker tasks on Amazon ECS Fargate using the Fargate Spot capacity provider.

Purchase a

3

-year Compute Savings Plan to cover both the orchestration queue worker and the application's Amazon RDS database instances.

Deploy the transcoding worker logic as AWS Lambda functions configured with maximum timeout to continuously poll and process the SQS queue.

Provision a NAT Gateway in the VPC to route the data transfer of source videos and transcoded files between the private ECS container instances and Amazon S3.

Show answer & explanation

Answer: Purchase a $3$ -year Compute Savings Plan to cover the baseline usage of the orchestration queue worker running on Amazon ECS Fargate.; Run the transcoding worker tasks on Amazon ECS Fargate using the Fargate Spot capacity provider.

Answer

Purchasing a Compute Savings Plan for the orchestration worker and using Fargate Spot for the transcoding tasks provides the most cost-optimized solution.

The correct combination involves purchasing a Compute Savings Plan to cover the predictable, steady-state

24/7

orchestration worker running on ECS Fargate, and running the variable, interruptible video transcoding tasks on ECS Fargate using the Fargate Spot capacity provider to leverage deep discounts.

Step-by-Step Solution

Analyze the workload characteristics of the ECS orchestration worker.

The orchestration worker runs continuously (

24/7

) on ECS Fargate, representing a predictable, steady-state baseline compute workload.

Identifying steady-state compute workloads allows the application of commitment discounts like Savings Plans.

Determine the most cost-effective purchasing model for the steady-state orchestration worker.

3

-year Compute Savings Plan is selected because it applies directly to ECS Fargate and offers significant discounts over On-Demand pricing.

Compute Savings Plans are flexible and cover ECS Fargate compute usage, unlike EC2 Instance Savings Plans which only cover EC2.

Analyze the workload characteristics of the transcoding workers.

The transcoding workers are highly variable, run containerized tasks, process SQS queue messages, and are highly tolerant of interruptions.

Workloads that are stateless, queue-driven, and interruptible are ideal candidates for Spot capacity.

Select the optimal compute and purchasing strategy for the transcoding workers.

Fargate Spot is selected as the capacity provider for these tasks.

Fargate Spot offers spare AWS capacity at steep discounts (up to

70\%

) compared to On-Demand Fargate, perfectly matching the interruptible nature of the transcoding jobs.

Key Concept

Selecting cost-optimized AWS compute models requires matching steady-state workloads to Savings Plans/Reserved Instances and matching interruptible, flexible workloads to Spot instances.

Question 776Question →

A maritime logistics enterprise is designing a highly resilient storage architecture for its shipping manifest processing platform. The platform must store PDF manifest files that are frequently accessed by multiple applications during the first 30 days. To comply with international shipping regulations, these manifests must be kept for 5 years and must be retrievable within 5 minutes in the event of an audit. The solution must support a multi-region disaster recovery strategy with a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 30 minutes. Which storage design meets these requirements?

Store the manifests in Amazon S3 Standard. Configure S3 Cross-Region Replication (CRR) with S3 Replication Time Control (S3 RTC) enabled. Create an S3 Lifecycle policy to transition the manifest objects to Amazon S3 Glacier Flexible Retrieval after 30 days, using Expedited retrievals for audit requests.

Store the manifests in Amazon S3 Standard. Configure standard S3 Cross-Region Replication (CRR) to replicate objects to the secondary region. Create an S3 Lifecycle policy to transition the manifest objects to Amazon S3 Glacier Flexible Retrieval after 30 days, using Standard retrievals for audit requests.

Store the manifests in an Amazon RDS database. Set up cross-region RDS Read Replicas as the primary disaster recovery failover mechanism to meet the RPO and RTO requirements, storing historical documents directly within database tables.

Store the manifests on Amazon EFS file systems. Configure cross-region replication for the EFS file systems. Implement a Pilot Light disaster recovery strategy where recovery EC2 instances in the secondary region are kept shut down, relying on manual scripts to mount the replicated EFS file system during a failover event.

Show answer & explanation

Answer: Store the manifests in Amazon S3 Standard. Configure S3 Cross-Region Replication (CRR) with S3 Replication Time Control (S3 RTC) enabled. Create an S3 Lifecycle policy to transition the manifest objects to Amazon S3 Glacier Flexible Retrieval after 30 days, using Expedited retrievals for audit requests.

Answer

Store the manifests in Amazon S3 Standard, configure S3 Cross-Region Replication (CRR) with S3 Replication Time Control (S3 RTC) enabled, and use an S3 Lifecycle policy to transition objects to Amazon S3 Glacier Flexible Retrieval after 30 days with Expedited retrievals for audits.

The correct solution uses Amazon S3 Standard combined with Cross-Region Replication (CRR) and S3 Replication Time Control (S3 RTC). S3 RTC guarantees that 99% of objects replicate within 15 minutes, directly fulfilling the 15-minute RPO. For the 5-year retention requirement, an S3 Lifecycle policy automates the transition to S3 Glacier Flexible Retrieval after 30 days. To meet the 5-minute audit retrieval requirement, Expedited retrievals are used, which typically complete within 1 to 5 minutes.

Step-by-Step Solution

Select the correct replication mechanism to meet the Recovery Point Objective (RPO) constraint.

Amazon S3 Replication Time Control (S3 RTC) replicates 99% of objects within 15 minutes, satisfying the 15-minute RPO.

Standard Cross-Region Replication (CRR) does not provide a replication time guarantee, meaning replication could take longer than the 15-minute RPO threshold.

Choose the appropriate archival storage tier that satisfies the retrieval speed requirement.

Amazon S3 Glacier Flexible Retrieval with Expedited retrievals provides access to archives within 1 to 5 minutes.

Standard retrievals from Glacier take 3 to 5 hours, which violates the audit retrieval requirement of less than 5 minutes.

Integrate S3 Lifecycle rules to automate cost-efficient and resilient transition.

Create an S3 Lifecycle policy to transition objects from S3 Standard to S3 Glacier Flexible Retrieval after 30 days.

This automates the lifecycle transition, ensuring compliance while optimizing storage costs for the 5-year retention period.

Key Concept

Designing a resilient, multi-region object storage system using S3 Replication Time Control (S3 RTC) and S3 Glacier Expedited retrievals to satisfy strict RPO, RTO, and archival recovery metrics.

Estimated Time:1m 30s

Question 777Question →

A media analytics company collects two types of data from client web applications:

1. Video rendering assets stored under the `/assets/` prefix, which average $85\text{ MB}$ in size. These files are accessed frequently for the first $15\text{ days}$ , rarely accessed after that, and must be retained for $45\text{ days}$ before being deleted.
2. User clickstream telemetry logs stored under the `/telemetry/` prefix, which average $12\text{ KB}$ in size. These logs are analyzed intensively for $10\text{ days}$ , are rarely accessed afterward, and must be retained for $120\text{ days}$ before being deleted.

Which combination of actions should the Solutions Architect implement to achieve the most cost-effective storage solution? (Select TWO.)

Select all that apply

For the `/assets/` prefix, configure an S3 Lifecycle rule to transition objects to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after

15\text{ days}

For the `/telemetry/` prefix, aggregate the clickstream logs into larger archive files (greater than

128\text{ KB}

) before uploading them to Amazon S3, and configure an S3 Lifecycle rule to transition the archives to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after

10\text{ days}

For the `/assets/` prefix, configure an S3 Lifecycle rule to transition objects to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after

25\text{ days}

, and delete them after

45\text{ days}

For the `/telemetry/` prefix, configure an S3 Lifecycle rule to transition the individual clickstream logs to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after

10\text{ days}

For the `/telemetry/` prefix, configure an S3 Lifecycle rule to transition the individual clickstream logs to Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA) after

10\text{ days}

Show answer & explanation

Answer: For the `/assets/` prefix, configure an S3 Lifecycle rule to transition objects to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after $15\text{ days}$ .; For the `/telemetry/` prefix, aggregate the clickstream logs into larger archive files (greater than $128\text{ KB}$ ) before uploading them to Amazon S3, and configure an S3 Lifecycle rule to transition the archives to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after $10\text{ days}$ .

Answer

The correct architecture requires transitioning the video assets prefix to Amazon S3 Standard-IA after 15 days, and aggregating the telemetry logs into larger archive files (greater than 128 KB) before uploading them to Amazon S3 and transitioning them to Amazon S3 Standard-IA after 10 days.

The correct strategy uses S3 Standard-IA for large objects (video assets) with a transition window that satisfies the 30-day minimum storage duration (transition at day 15, delete at day 45). For small files (telemetry logs), aggregating them prior to upload avoids the 128 KB minimum capacity charge penalty when they are transitioned to S3 Standard-IA after 10 days.

Step-by-Step Solution

Analyze the lifecycle constraints for the video assets under the `/assets/` prefix.

The files average

85\text{ MB}

(greater than the

128\text{ KB}

S3 Standard-IA limit). If transitioned after

15\text{ days}

and deleted at

45\text{ days}

, the total time spent in S3 Standard-IA is

45 - 15 = 30\text{ days}

. This matches the 30-day minimum duration requirement exactly.

Ensures that transitioning to S3 Standard-IA maximizes cost savings without incurring early transition/deletion fees.

Evaluate the storage tiering limitations for the telemetry logs under the `/telemetry/` prefix.

The files are very small (

12\text{ KB}

). Transitioning individual

12\text{ KB}

files to S3 Standard-IA or S3 One Zone-IA causes them to be billed at the

128\text{ KB}

minimum storage size, which increases the billing volume by more than 10 times.

Avoids the S3 Standard-IA and S3 One Zone-IA minimum storage charge size penalty.

Determine the optimal architectural pattern for handling high volumes of small files in S3.

Aggregating the telemetry logs into archives larger than

128\text{ KB}

before upload avoids the size penalty. Once aggregated and uploaded, transitioning them after

10\text{ days}

to S3 Standard-IA for the remaining

110\text{ days}

(out of

120\text{ days}

) is highly cost-effective and avoids early deletion penalties.

Allows small-file data sets to benefit from lower-tier storage rates by consolidating them into larger objects, reducing both storage penalties and request fees.

Key Concept

Cost-Optimized Storage Tiering and Lifecycle Management

Question 778Question →

A company hosts its primary web application on EC2 instances behind an Application Load Balancer (ALB). To ensure business continuity during an outage, the company configures a static "under maintenance" page in an Amazon S3 bucket. A solutions architect must configure Amazon Route 53 to automatically direct all user traffic to the S3 bucket if the ALB becomes unhealthy. Which Route 53 routing configuration should the solutions architect implement to meet these requirements?

Create a Route 53 failover routing policy. Configure a primary alias record pointing to the ALB with target health evaluation enabled, and a secondary alias record pointing to the S3 bucket.

Create a Route 53 latency routing policy. Configure one record pointing to the ALB and another record pointing to the S3 bucket, allowing Route 53 to route traffic to the resource with the lowest network latency.

Create a Route 53 failover routing policy. Configure a primary record pointing to the application's primary database instance and a secondary record pointing to an RDS read replica for database failover.

Create a Route 53 weighted routing policy. Assign a weight of

100

to the ALB and a weight of

0

to the S3 bucket, then manually update the weights during an outage to achieve warm standby recovery.

Show answer & explanation

Answer: Create a Route 53 failover routing policy. Configure a primary alias record pointing to the ALB with target health evaluation enabled, and a secondary alias record pointing to the S3 bucket.

Answer

Create a Route 53 failover routing policy. Configure a primary alias record pointing to the ALB with target health evaluation enabled, and a secondary alias record pointing to the S3 bucket.

The correct option is the one that recommends configuring a Route 53 failover routing policy with a primary alias record pointing to the ALB (health evaluation enabled) and a secondary alias record pointing to the S3 bucket. Failover routing allows Route 53 to route traffic to the primary resource when it is healthy, and switch to the secondary resource when the primary is unhealthy. Setting 'Evaluate Target Health' to Yes on the alias record enables Route 53 to automatically check the health of the ALB.

Step-by-Step Solution

Identify the high availability pattern required.

The requirement is active-passive disaster recovery where traffic automatically fails over from a primary application load balancer to a backup static S3 bucket.

This establishes that the Route 53 failover routing policy is the correct choice.

Configure the primary endpoint routing and health checks.

Configure a primary failover record as an Alias record pointing to the ALB with 'Evaluate Target Health' enabled.

Evaluating target health ensures that Route 53 automatically monitors the health of the ALB without needing a custom Route 53 health check.

Configure the secondary endpoint routing.

Configure a secondary failover record pointing to the S3 static website endpoint.

This provides the failover destination where Route 53 will route traffic when the primary endpoint is determined to be unhealthy.

Key Concept

Route 53 active-passive failover routing policy dynamically routes traffic to a secondary standby endpoint when the primary endpoint becomes unhealthy, determined via target health evaluation.

Question 779Question →

An inventory management application for a retail chain stores real-time stock levels in an Amazon DynamoDB table. The table schema uses `StoreID` as the partition key and `ItemSKU` as the sort key. During a promotional event, a few flagship stores experience a sudden, massive surge in sales, resulting in write requests to those specific store partition keys exceeding $2,500$ writes per second. The application encounters `ProvisionedThroughputExceededException` errors, although the table's total provisioned write capacity is largely underutilized. Which strategy should a solutions architect implement to resolve this database performance bottleneck with minimal impact on latency?

Enable DynamoDB Auto Scaling for the table and switch the capacity mode to On-Demand to automatically provision additional capacity during spikes.

Append a calculated hash or a random integer suffix to the StoreID partition key during write operations, and update the application query logic to read across the sharded partition keys.

Recreate the table using ItemSKU as the partition key, and create a Global Secondary Index (GSI) with StoreID as the partition key to support store-specific queries.

Migrate the database to an Amazon Aurora PostgreSQL Multi-AZ cluster, and configure the application to distribute the write load across the reader endpoints.

Show answer & explanation

Answer: Append a calculated hash or a random integer suffix to the StoreID partition key during write operations, and update the application query logic to read across the sharded partition keys.

Answer

Adjust the write path to append a calculated hash or a random integer suffix to the partition key (write sharding), and query across the sharded keys to distribute the load.

The correct option is to implement write sharding by appending a suffix to the partition key. A single partition key in DynamoDB can only support up to

1,000

WCUs per second. By appending a suffix (e.g., `StoreID_1`, `StoreID_2`), the writes for a single store are distributed across different physical partitions, resolving the hot partition throttling.

Step-by-Step Solution

Analyze the cause of the performance degradation.

Throttling occurs because writes to a single partition key value (a specific flagship `StoreID`) exceed

2,500

writes per second, which violates DynamoDB's physical limit of

1,000

Write Capacity Units (WCUs) per second per partition.

Even if the overall table has sufficient capacity, a single hot partition key cannot exceed the single-partition limit.

Evaluate the impact of Global Secondary Indexes (GSIs).

Moving the hot key to a GSI does not solve the issue, as GSI writes will still be throttled and cause backpressure on the base table.

DynamoDB tables require successful GSI replication to avoid throttling the base table writes.

Evaluate capacity mode adjustments.

Switching to On-Demand capacity or enabling Auto Scaling increases total table limits but does not lift the physical single-partition throughput limit.

The partition-level capacity limit is a physical architectural boundary in DynamoDB.

Formulate a sharding strategy.

Add a suffix (e.g., `StoreID_1` to `StoreID_N`) to the partition key during writes to distribute the data across multiple partitions, and query across all suffixes.

This spreads the write workload of a single store across multiple partitions, allowing throughput to scale linearly.

Key Concept

DynamoDB partition design and write sharding to overcome partition limits.

Estimated Time:2m 0s

Question 780Question →

An enterprise application utilizes an Amazon Aurora PostgreSQL database cluster for transactional operations and an Amazon DynamoDB table for user session state. During peak traffic periods, the Aurora database experiences high latency on read queries, while the DynamoDB table encounters throttling on a small group of frequently accessed user profiles. Which two configurations should a solutions architect implement to optimize database performance? (Select TWO.)

Select all that apply

Create Amazon Aurora Read Replicas to offload read traffic from the primary database instance

Enable Amazon DynamoDB Accelerator (DAX) to cache frequently accessed user profiles

Redesign the DynamoDB partition key to use a monotonically increasing creation timestamp

Configure Aurora Read Replicas as the primary disaster recovery failover mechanism for write traffic

Show answer & explanation

Answer: Create Amazon Aurora Read Replicas to offload read traffic from the primary database instance; Enable Amazon DynamoDB Accelerator (DAX) to cache frequently accessed user profiles

Answer

Creating Amazon Aurora Read Replicas and enabling Amazon DynamoDB Accelerator (DAX) are the correct configurations to optimize the performance.

Creating Amazon Aurora Read Replicas allows the application to redirect read traffic from the primary writer database instance, reducing latency. Additionally, enabling Amazon DynamoDB Accelerator (DAX) introduces an in-memory cache that resolves read throttling on frequently accessed keys (hot keys).

Step-by-Step Solution

Analyze the read latency issue on the Amazon Aurora PostgreSQL database.

Identify that read operations are saturating the primary writer instance, indicating a need to scale read capacity.

Creating Aurora Read Replicas offloads read traffic from the primary writer instance, lowering read latency.

Analyze the read throttling issue on the Amazon DynamoDB table.

Identify that a subset of frequently accessed keys (hot keys) is causing performance bottlenecks.

Enabling Amazon DynamoDB Accelerator (DAX) provides an in-memory cache that intercepts reads for popular keys, preventing throttling and offering microsecond response times.

Key Concept

Scaling read capacity with database replicas and using in-memory caching for key-value databases to handle hot keys.

PreviousPage 39 / 74Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept