Design Resilient Architectures

382 questions

All types382 Multiple choice195 Multiple select187

A gaming studio is launching a multiplayer game where players can acquire, trade, and consume in-game items. The backend application must process these inventory state change events in the exact chronological order they occur for each player. Processing these events out of sequence will result in inventory corruption or item duplication. The game experiences unpredictable spikes in traffic, and the solution must scale to process millions of updates daily while allowing events from different players to be processed concurrently. Which solution meets these requirements with the least operational overhead?

Publish the inventory state change events to a standard Amazon SQS queue, including the player ID as a message attribute. Configure the consumer application to retrieve, sort, and process the messages chronologically.

Publish the inventory state change events to an Amazon SQS FIFO queue, using a single static value as the MessageGroupId to maintain order across the entire application. Configure an AWS Lambda function to consume and process the messages.

Publish the inventory state change events to an Amazon SQS FIFO queue, using the player ID as the MessageGroupId. Configure an AWS Lambda function to consume and process the messages.

Publish the inventory state change events to a standard Amazon SQS queue, enabling content-based deduplication. Configure an AWS Lambda function to consume and process the messages.

Show answer & explanation

Answer: Publish the inventory state change events to an Amazon SQS FIFO queue, using the player ID as the MessageGroupId. Configure an AWS Lambda function to consume and process the messages.

Answer

Publish the inventory state change events to an Amazon SQS FIFO queue, using the player ID as the MessageGroupId, and configure an AWS Lambda function to consume and process the messages.

An Amazon SQS FIFO queue preserves the exact order of messages within a message group. Using the player ID as the MessageGroupId ensures that all inventory events for a specific player are processed in the order they were sent, while allowing events for different players (different MessageGroupIds) to be processed concurrently. Lambda provides a serverless, automatically scaling consumer that requires minimal operational overhead.

Step-by-Step Solution

Identify the system requirement for strict ordering within individual user transaction streams.

Determine that inventory transactions must be processed chronologically per player, but can be processed concurrently across different players.

This establishes the need for a message grouping partition mechanism.

Evaluate Amazon SQS queue options for ordering guarantees.

Select Amazon SQS FIFO queues rather than standard queues, as standard queues do not guarantee first-in, first-out delivery.

To prevent out-of-order execution that would lead to database or inventory state corruption.

Configure the MessageGroupId attribute on the queue.

Map the MessageGroupId to the unique player ID to enable concurrent consumer processing across different players while preserving strict sequence per player.

Using a single static MessageGroupId would bottleneck the queue by serializing all messages, failing the concurrency requirements.

Key Concept

Preserving message ordering within logical groups using Amazon SQS FIFO queues

Alternative Method

An alternative design could use Amazon Kinesis Data Streams with the player ID as the partition key. This guarantees in-order processing per partition (player). However, Kinesis requires manual provisioning of shards, handling shard splits/merges, and managing consumer offset tracking, which results in significantly higher operational overhead compared to the fully serverless Amazon SQS FIFO queue solution.

Estimated Time:2m 0s

Question 342Question →

A healthcare SaaS provider hosts a critical patient portal on AWS. The application tier runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB) in the primary Region (us-east-1). The database tier runs on an Amazon Aurora PostgreSQL DB cluster. The provider wants to implement a cross-region disaster recovery (DR) strategy in a secondary Region (us-west-2). The business SLA mandates a Recovery Time Objective (RTO) of $15\text{ minutes}$ and a Recovery Point Objective (RPO) of $1\text{ minute}$ . The solution must minimize infrastructure costs during normal operations in the primary Region.

Which combination of actions will meet these requirements at the lowest cost? (Select TWO.)

Select all that apply

Configure Amazon Aurora Global Database with a secondary DB cluster in the secondary Region, and configure the secondary DB cluster with zero DB instances under normal operating conditions.

Pre-deploy the Application Load Balancer and the Auto Scaling group in the secondary Region with both the desired and minimum capacity set to

0

, and use a failover script to scale up the instances during a disaster recovery event.

Deploy an Amazon RDS PostgreSQL Read Replica in the secondary Region, and configure Amazon Route 53 latency routing to automatically promote the replica to primary if the primary database becomes unresponsive.

Schedule hourly exports of the DB cluster snapshots to Amazon S3, replicate the snapshots to the secondary Region using S3 Cross-Region Replication (CRR) with the S3 Glacier Flexible Retrieval storage class, and restore the DB cluster from the backup during failover.

Deploy a Warm Standby compute environment in the secondary Region by running EC2 instances at

50\%

capacity on smaller instance types, and configure Route 53 failover routing to dynamically scale up the instance sizes during failover.

Show answer & explanation

Answer: Configure Amazon Aurora Global Database with a secondary DB cluster in the secondary Region, and configure the secondary DB cluster with zero DB instances under normal operating conditions.; Pre-deploy the Application Load Balancer and the Auto Scaling group in the secondary Region with both the desired and minimum capacity set to $0$ , and use a failover script to scale up the instances during a disaster recovery event.

Answer

Configure Amazon Aurora Global Database with a secondary DB cluster containing zero DB instances, and pre-deploy the Application Load Balancer and Auto Scaling group with the capacity set to zero, scaling up the instances and databases via automation during failover.

To satisfy a Recovery Point Objective (RPO) of

1\text{ minute}

and a Recovery Time Objective (RTO) of

15\text{ minutes}

at the lowest cost, a Pilot Light DR pattern is ideal. By leveraging Amazon Aurora Global Database, storage replication is continuous and automatic with sub-second latency, satisfying the

1\text{-minute}

RPO. Keeping the secondary database cluster headless (zero DB instances) under normal conditions ensures zero database compute costs. Pre-deploying the Application Load Balancer and configuring the Auto Scaling group with a desired capacity of

0

ensures zero compute costs for the application tier during normal operations. During a disaster, automated scripts can spin up DB instances in the secondary Region, promote the secondary Aurora cluster, and scale up the Auto Scaling group to launch EC2 instances, recovering the application well within the

15\text{-minute}

RTO.

Step-by-Step Solution

Analyze the database replication and RPO requirement.

To meet the

1\text{-minute}

RPO, continuous physical or logical replication is required. Amazon Aurora Global Database replicates storage updates across Regions with latency of less than

1\text{ second}

, meeting the RPO.

Traditional backup methods like hourly snapshots or S3 backups cannot guarantee a

1\text{-minute}

RPO.

Analyze the database compute and cost requirement.

Configure a secondary DB cluster in the Global Database with zero running DB instances (headless cluster) to eliminate running compute costs during normal operations.

During failover, adding a new DB instance to the secondary cluster and promoting it takes only a few minutes, which is well within the

15\text{-minute}

RTO.

Analyze the application tier compute and cost requirement.

Deploy the Application Load Balancer and Auto Scaling group in the secondary Region with desired capacity set to

0

This Pilot Light strategy incurs zero EC2 running costs under normal conditions. During failover, the Auto Scaling group capacity can be scaled up to launch EC2 instances and receive traffic within the

15\text{-minute}

window.

Key Concept

Disaster recovery (DR) architectures on AWS utilize different patterns (such as Pilot Light and Warm Standby) to balance cost, Recovery Time Objective (RTO), and Recovery Point Objective (RPO). A Pilot Light architecture keeps database replication active (often headless or minimal) and compute resources scaled down to zero, provisioning them dynamically via automated scripts during failover to meet RTOs in the range of tens of minutes while minimizing baseline run costs.

Estimated Time:2m 30s

Question 343Question →

An enterprise runs a critical payroll application on AWS in the `us-east-1` Region. The application uses Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB), with an Amazon RDS for PostgreSQL DB instance. The company must design a disaster recovery (DR) strategy in the `us-west-2` Region to protect against a regional outage. The solution must achieve a Recovery Point Objective (RPO) of $5$ minutes and a Recovery Time Objective (RTO) of $10$ minutes while minimizing ongoing running costs. Which strategy should a solutions architect recommend to meet these requirements?

Deploy the EC2 instances and ALB in the secondary Region via AWS CloudFormation, but keep the EC2 instances in a stopped state. Create a cross-region read replica of the RDS DB instance. In the event of a disaster, start the EC2 instances, promote the read replica to primary, and update the DNS records in Route 53.

Enable Multi-AZ deployment on the RDS DB instance, selecting the secondary Region as the standby Availability Zone. Deploy the EC2 instances behind an ALB in the secondary Region. Configure Route 53 to automatically route traffic to the standby DB instance if the primary DB instance in the primary Region becomes unavailable.

Deploy a scaled-down Auto Scaling group of EC2 instances behind an ALB in the secondary Region, and create a cross-region read replica of the RDS DB instance. Configure Amazon Route 53 failover routing with health checks. In the event of a disaster, promote the replica to primary, scale out the EC2 instances, and allow Route 53 to redirect traffic.

Deploy a scaled-down Auto Scaling group of EC2 instances behind an ALB in the secondary Region, and create a cross-region read replica of the RDS DB instance. Configure Amazon Route 53 with a latency routing policy to distribute traffic between the two Regions. In the event of a disaster, promote the read replica to primary.

Show answer & explanation

Answer: Deploy a scaled-down Auto Scaling group of EC2 instances behind an ALB in the secondary Region, and create a cross-region read replica of the RDS DB instance. Configure Amazon Route 53 failover routing with health checks. In the event of a disaster, promote the replica to primary, scale out the EC2 instances, and allow Route 53 to redirect traffic.

Answer

Deploy a scaled-down Auto Scaling group of EC2 instances behind an ALB in the secondary Region, create a cross-region read replica of the RDS DB instance, configure Amazon Route 53 failover routing with health checks, and in a disaster, promote the replica and scale out the compute resources.

The correct strategy is a Warm Standby DR pattern. Deploying a scaled-down but active compute tier in the secondary region ensures that instances are already running and registered with the ALB. In a disaster, the solutions architect only needs to promote the RDS cross-region read replica (which handles the database replication with under

5

minutes of lag to satisfy the RPO) and scale out the EC2 Auto Scaling group. Route 53 failover routing with health checks automatically detects the primary region failure and reroutes traffic, completing the recovery well within the

10

-minute RTO.

Step-by-Step Solution

Evaluate the RPO requirement of

5

minutes.

Amazon RDS cross-region read replicas replicate asynchronously with very low latency (typically seconds or minutes), satisfying the

5

-minute RPO constraint.

Standard backup restoration from snapshots copied across regions fails the RPO constraint as backups are usually taken daily.

Evaluate the RTO requirement of

10

minutes.

A Warm Standby pattern is selected. Scaled-down but running EC2 instances are kept active in the secondary Region, ready to scale out immediately.

A Pilot Light strategy with stopped instances or deploying resources purely from CloudFormation templates during a disaster cannot guarantee recovery and initialization within

10

minutes.

Design the failover routing mechanism using Route 53.

A failover routing policy combined with health checks is configured to dynamically redirect client traffic to the secondary ALB when the primary region becomes unhealthy.

Using latency routing without health checks will not redirect traffic away from the failed primary region.

Key Concept

Disaster Recovery strategies (Warm Standby vs. Pilot Light) and Cross-Region DB Replication

Question 344Question →

A chemical manufacturing plant uses IoT sensors to monitor reactor temperatures and pressure levels. The telemetry updates from each reactor contain a `reactor_id` and a `timestamp` and must be processed in the exact sequence they are generated to prevent incorrect automated safety interventions. The plant needs to distribute these updates to two separate backend applications: a real-time monitoring dashboard and a long-term analytical warehouse. The system must handle message spikes, prevent data loss during backend downtime, and support up to $9,000$ messages per second.

Which combination of steps should a solutions architect take to design this architecture? (Select TWO.)

Select all that apply

Create an Amazon SNS FIFO topic and subscribe two Amazon SQS FIFO queues to the topic, one for each backend application.

Enable high-throughput FIFO mode on the Amazon SQS FIFO queues and configure the telemetry messages to use the `reactor_id` as the message group ID.

Create an Amazon SNS standard topic and subscribe two Amazon SQS standard queues to the topic, configuring the message body with the `reactor_id` to maintain processing order.

Create a single Amazon SQS FIFO queue and configure both backend applications to poll messages concurrently from this queue using the `reactor_id` as a message attribute filter.

Show answer & explanation

Answer: Create an Amazon SNS FIFO topic and subscribe two Amazon SQS FIFO queues to the topic, one for each backend application.; Enable high-throughput FIFO mode on the Amazon SQS FIFO queues and configure the telemetry messages to use the `reactor_id` as the message group ID.

Answer

To support fan-out with message ordering and high throughput, the solutions architect should create an Amazon SNS FIFO topic subscribing two Amazon SQS FIFO queues (one for each backend), enable high-throughput FIFO mode, and use the reactor ID as the message group ID.

To design a resilient, decoupled architecture that maintains message ordering during fan-out, a combination of Amazon SNS FIFO and Amazon SQS FIFO is required. The SNS FIFO topic allows a single publish action to fan out to multiple queues. Each downstream application gets its own SQS FIFO queue, ensuring independent processing, buffering, and resilience against downtime. To handle

9,000

messages per second, high-throughput mode must be enabled on the SQS FIFO queues, and the `reactor_id` must be used as the message group ID to ensure messages from the same reactor are processed in sequence while allowing different reactors to be processed in parallel.

Step-by-Step Solution

Address the multi-application fan-out requirement with strict ordering.

Combine Amazon SNS FIFO and Amazon SQS FIFO queues. SNS FIFO allows fanning out the message stream to multiple downstream subscribers while maintaining the order.

Each backend application must receive all updates. Creating two separate SQS FIFO queues subscribed to a single SNS FIFO topic ensures both applications get a complete copy of the telemetry data independently.

Scale the message ingestion to support

9,000

messages per second.

Enable high-throughput mode on the SQS FIFO queues.

Standard SQS FIFO queues are limited to

300

transactions per second (or

3,000

with batching). High-throughput mode allows scaling to the required

9,000

messages per second.

Group and sequence messages correctly.

Use the `reactor_id` as the message group ID for FIFO processing.

The message group ID determines which messages must be processed sequentially. Using `reactor_id` guarantees ordered delivery within each individual reactor while enabling concurrent processing across different reactors.

Key Concept

Decoupling event-driven architectures with high-throughput ordered message delivery using SNS FIFO and SQS FIFO.

Question 345Question →

A company is deploying a media transcoding service on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The transcoding service listens on TCP port 8085, while the health status endpoint is exposed on TCP port 8086. The architecture must ensure that only healthy instances receive transcoding jobs, and inbound network access to the EC2 instances must be restricted to only the ALB. Which two configurations should the solutions architect implement to meet these requirements?

Select all that apply

Configure the target group to route traffic to port 8085, and explicitly set the health check port to 8086.

Update the security group for the EC2 instances to allow inbound traffic from the security group of the Application Load Balancer on ports 8085 and 8086.

Configure the target group health check to use the default 'traffic port' setting to verify application availability.

Configure a Network ACL on the EC2 subnets to allow inbound traffic on ports 8085 and 8086 by referencing the security group ID of the Application Load Balancer.

Create an Amazon Route 53 latency routing policy pointing directly to the EC2 instances to balance traffic prior to reaching the load balancer.

Show answer & explanation

Answer: Configure the target group to route traffic to port 8085, and explicitly set the health check port to 8086.; Update the security group for the EC2 instances to allow inbound traffic from the security group of the Application Load Balancer on ports 8085 and 8086.

Answer

Configure the target group to send traffic to port 8085 with the health check port explicitly set to 8086, and configure the EC2 instance security group to allow inbound traffic on both ports from the ALB's security group.

The system requires separate ports for health checks (8086) and transcoding traffic (8085). The target group must be configured with port 8085 for traffic and an explicit override of port 8086 for health checks. Additionally, security groups must allow the ALB to reach the EC2 instances on both ports to perform health checks and forward traffic.

Step-by-Step Solution

Determine the application port configuration.

The application listens on port 8085 and the health endpoint is on port 8086.

This establishes that the traffic and health check ports must be configured differently in the load balancer target group.

Configure target group routing and health checks.

Set the target group port to 8085 and configure the health check configuration to use custom port 8086.

This guarantees that health checks query the correct port and instances are only marked healthy if the health endpoint responds successfully.

Apply security group rules on the EC2 instances.

Allow inbound traffic on ports 8085 and 8086 specifically from the ALB's security group.

This implements the principle of least privilege, ensuring only the ALB can reach the backend instances on the necessary ports.

Key Concept

Decoupling target group health checks and application traffic ports in load balancer configurations combined with security group chaining.

Estimated Time:1m 30s

Question 346Question →

A company hosts an internal inventory management service on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application serves client API traffic on HTTPS port 443. A custom health monitoring agent runs on port 8080 on each EC2 instance. The target group is configured to route client traffic to port 443 and perform health checks on port 8080. The security group of the EC2 instances allows inbound traffic on port 443 from the security group of the ALB. However, the EC2 instances are continually marked as unhealthy by the ALB, and the ASG is repeatedly terminating and replacing them. Which action will resolve this issue and allow the instances to pass the health checks?

Update the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB.

Modify the subnet's Network ACL to allow inbound traffic on port 8080, and rely on the stateful nature of security groups to automatically allow the return traffic.

Configure the target group health check to use the default traffic-port (port 443), expecting the Application Load Balancer to automatically forward the health checks to the health agent on port 8080.

Configure an Amazon Route 53 latency routing policy with active health checks pointing directly to the EC2 instances' Elastic IP addresses to bypass the Application Load Balancer.

Show answer & explanation

Answer: Update the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB.

Answer

Update the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB.

The correct action is to update the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB. Because the Application Load Balancer is configured to perform health checks on a custom port (8080), the security group of the backend EC2 instances must explicitly permit this traffic. If only port 443 is open, the ALB's health check requests to port 8080 will be dropped, marking the instances as unhealthy and prompting the Auto Scaling group to terminate and replace them.

Step-by-Step Solution

Identify the ports used for application traffic and health check traffic.

Application traffic uses HTTPS port 443, while health checks use port 8080.

Understanding the separation of traffic and health ports is critical for configuring access control.

Review the security group rules applied to the EC2 instances.

The current security group only allows inbound traffic on port 443 from the ALB.

Since the ALB sends health check requests on port 8080, these requests are blocked by the security group, causing health check failures.

Add an inbound rule to the EC2 instances' security group.

Inbound TCP traffic on port 8080 is now permitted from the security group of the ALB.

This allows the ALB health check requests to reach the health monitoring agent on the instances, resolving the unhealthy state.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) health check routing and security group configuration.

Question 347Question →

A company runs a REST API service on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an internal Application Load Balancer (ALB). The API service is configured to listen on port 9090, while a dedicated health status endpoint is exposed on port 9095. The security group of the EC2 instances is currently configured to allow inbound TCP traffic on port 9090 from the ALB security group. However, the ALB target group health checks are failing, leading the ALB to mark all instances as unhealthy and prompting the ASG to continuously terminate and replace instances. Which two configurations must a solutions architect implement to resolve the health check failures and prevent unnecessary instance replacements? (Select two.)

Select all that apply

Modify the EC2 instance security group to allow inbound traffic on TCP port 9095 from the security group of the Application Load Balancer.

Update the target group health check configuration to explicitly use port 9095.

Configure the target group health check port settings to use "traffic-port".

Modify the subnet's Network ACL to allow inbound traffic on port 9095, relying on its connection-tracking features to automatically allow the return traffic.

Set up an Amazon Route 53 latency routing policy pointing to the Application Load Balancer to bypass the unhealthy targets.

Show answer & explanation

Answer: Modify the EC2 instance security group to allow inbound traffic on TCP port 9095 from the security group of the Application Load Balancer.; Update the target group health check configuration to explicitly use port 9095.

Answer

Modify the EC2 instance security group to allow inbound traffic on TCP port 9095 from the security group of the Application Load Balancer, and update the target group health check configuration to explicitly use port 9095.

To resolve the health check issues, the solutions architect must ensure that the load balancer can reach the health status endpoint. Because the health status page is served on port 9095 instead of the application traffic port (9090), the target group health check port must be explicitly configured to use port 9095. Additionally, because security groups are stateful, the EC2 instance security group must be updated to allow inbound TCP traffic on port 9095 from the load balancer's security group so that the health probe requests are not blocked at the instance boundary.

Step-by-Step Solution

Analyze target group health check port settings.

By default, the Application Load Balancer performs health checks on the 'traffic-port' (port 9090). Since the health endpoint is on port 9095, the health check port configuration must be changed from 'traffic-port' to port 9095.

This aligns the Application Load Balancer's health check probes with the port where the health status service is running.

Analyze security group rules for the instances.

The current security group only allows inbound traffic on port 9090. A new rule must be added to allow inbound traffic on port 9095 from the ALB security group.

This permits the Application Load Balancer to successfully establish TCP connections to the health status service on port 9095.

Key Concept

ELB Target Group Health Checks and Security Group Rules

Question 348Question →

A company runs a specialized order processing backend application on Amazon EC2 instances. The EC2 instances are in private subnets, managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application receives transaction requests on TCP port 8443. The application exposes a health check endpoint on HTTP port 8080. Currently, the ALB is marking all EC2 instances as unhealthy, and client requests are failing with 502 Bad Gateway errors.

Which two configuration changes are required to resolve this issue and restore service availability? (Select two.)

Select all that apply

Configure the target group health checks to use port 8080 instead of the default traffic port.

Add an inbound rule to the EC2 instances' security group that allows TCP traffic on port 8080 from the security group of the Application Load Balancer.

Update the target group health checks to use the default 'traffic port' setting so the Application Load Balancer can verify target health on port 8443.

Configure a stateless inbound rule on the subnet Network Access Control List (NACL) to permit traffic on port 8080, which automatically overrides the EC2 security group rules.

Configure an Amazon Route 53 latency routing policy to route traffic directly to the public IP addresses of the EC2 instances, bypassing the Application Load Balancer.

Show answer & explanation

Answer: Configure the target group health checks to use port 8080 instead of the default traffic port.; Add an inbound rule to the EC2 instances' security group that allows TCP traffic on port 8080 from the security group of the Application Load Balancer.

Answer

The target group health checks must be configured to use port 8080, and the EC2 instances' security group must allow inbound TCP traffic on port 8080 from the Application Load Balancer's security group.

To resolve the health check failure, the target group's health check configuration must be updated to target the custom port where the health check endpoint is exposed. In addition, the security group attached to the EC2 instances must permit inbound TCP traffic on that health check port from the security group of the Application Load Balancer.

Step-by-Step Solution

Analyze the application port configuration and identify the mismatch.

The application listens on port 8443, but the health check endpoint runs on port 8080. The target group must be modified to query port 8080 for health checks instead of using the default traffic port.

By default, the load balancer health checks query the traffic port (8443), which leads to failures since the health check service is not bound to that port.

Inspect the security group rules between the Application Load Balancer and the EC2 instances.

The EC2 instances' security group must explicitly allow inbound traffic from the Application Load Balancer's security group on port 8080.

Security groups are stateful and block all inbound traffic by default. Even if the target group is correctly pointed to port 8080, the health check requests will be dropped at the instance level if the security group does not permit them.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) health checks and security group integration

Question 349Question →

A digital media publishing company hosts its content management system (CMS) on AWS. The application tier runs on Amazon EC2 instances in an Auto Scaling group, and the database tier uses an Amazon RDS for PostgreSQL DB instance in a Multi-AZ deployment. The company wants to establish a disaster recovery (DR) strategy in a secondary AWS Region with a Recovery Time Objective (RTO) of 20 minutes and a Recovery Point Objective (RPO) of 10 minutes. The strategy must also minimize ongoing running costs. Which two actions should the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Configure an Amazon RDS Cross-Region Read Replica in the secondary Region, and promote it to a standalone primary database instance during a failover event.

Deploy a scaled-down application tier in the secondary Region, and configure Amazon Route 53 with a failover routing policy to redirect traffic during a failover event.

Configure Amazon RDS Multi-AZ replication to synchronously replicate data to a standby instance in the secondary Region to ensure automated database failover.

Back up the database daily to Amazon S3, replicate the backups to the secondary Region, and use an Amazon S3 Glacier Flexible Retrieval lifecycle policy to archive them to minimize storage costs.

Configure Amazon Route 53 with a latency routing policy to automatically route all user traffic to the secondary Region when the primary database is offline.

Show answer & explanation

Answer: Configure an Amazon RDS Cross-Region Read Replica in the secondary Region, and promote it to a standalone primary database instance during a failover event.; Deploy a scaled-down application tier in the secondary Region, and configure Amazon Route 53 with a failover routing policy to redirect traffic during a failover event.

Answer

Configure an Amazon RDS Cross-Region Read Replica in the secondary Region to meet the RPO, and deploy a scaled-down application tier in the secondary Region with Amazon Route 53 failover routing to meet the RTO while minimizing costs.

The combination of configuring an Amazon RDS Cross-Region Read Replica and deploying a scaled-down application tier in the secondary region with Route 53 failover routing satisfies both recovery objectives. The cross-region read replica replicates database changes asynchronously, ensuring the RPO of 10 minutes is met, and can be promoted to primary during failover. The scaled-down application tier maintains a small footprint to minimize ongoing costs, but can scale up rapidly to meet the 20-minute RTO, while Route 53 handles the redirection of client traffic.

Step-by-Step Solution

Analyze the database replication options that satisfy a cross-region RPO of 10 minutes.

RDS Cross-Region Read Replicas replicate data asynchronously with typical lag times of seconds, satisfying the 10-minute RPO. Multi-AZ replication cannot span across regions, and daily backups would fail the RPO.

To identify database configurations capable of keeping data synchronized across regions within the recovery point limit.

Evaluate the recovery strategy for the application tier to meet the 20-minute RTO while minimizing running costs.

A scaled-down application tier in the standby region (Warm Standby) minimizes idle resource costs while allowing the instances to be quickly scaled up to handle the production workload within the 20-minute window.

To select the application recovery tier strategy that satisfies the time objective and cost constraints.

Determine the routing mechanism required to redirect client requests to the secondary region during a disaster.

Amazon Route 53 failover routing policy combined with health checks automatically detects primary region degradation and switches DNS resolution to the standby region. Latency routing does not provide this active-passive behavior.

To orchestrate automated, high-availability DNS redirection to the recovery region.

Key Concept

Disaster recovery (DR) planning requires balancing cost, Recovery Time Objective (RTO), and Recovery Point Objective (RPO). For multi-region recovery, RDS Cross-Region Read Replicas provide low RPO by replicating asynchronously. A Warm Standby deployment pattern (scaled-down active resources) combined with Route 53 failover routing achieves low RTO while minimizing running costs compared to a fully duplicated environment.

Alternative Method

For databases with extremely low RTO and RPO requirements (e.g., RPO near zero, RTO under 1 minute), migrating from RDS PostgreSQL to Amazon Aurora Global Database would be a more performant alternative, though it might increase operational complexity and database licensing costs.

Estimated Time:2m 0s

Question 350Question →

A telehealth company hosts its core patient scheduling application in the us-east-1 Region. The application runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer, and uses an Amazon RDS for PostgreSQL Multi-AZ DB instance. The company needs to design a disaster recovery (DR) strategy in the us-west-2 Region with a Recovery Time Objective (RTO) of 2 hours and a Recovery Point Objective (RPO) of 15 minutes. The solution must minimize cost during normal operations.

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

Select all that apply

Create a cross-region read replica of the RDS DB instance in the us-west-2 Region.

Create an Auto Scaling group in the us-west-2 Region with the desired capacity set to 0, and prepare AWS CloudFormation templates to deploy the Application Load Balancer during a disaster.

Configure the RDS DB instance with multi-region replication and enable automatic synchronous failover to the secondary Region.

Set up an Amazon Route 53 latency routing policy to automatically redirect application traffic to the us-west-2 Region when the primary region is down.

Export database snapshots to Amazon S3 daily, transition them to Amazon S3 Glacier Flexible Retrieval, and restore the database from these snapshots during a failover.

Show answer & explanation

Answer: Create a cross-region read replica of the RDS DB instance in the us-west-2 Region.; Create an Auto Scaling group in the us-west-2 Region with the desired capacity set to 0, and prepare AWS CloudFormation templates to deploy the Application Load Balancer during a disaster.

Answer

The correct strategy is to create a cross-region read replica of the RDS DB instance in the secondary Region, and create an Auto Scaling group in the secondary Region with the desired capacity set to 0 while preparing AWS CloudFormation templates to deploy the Application Load Balancer during a disaster.

Establishing a cross-region read replica allows the database changes to be replicated asynchronously, supporting a low RPO. Setting up the Auto Scaling group with a capacity of 0 and using CloudFormation templates to dynamically deploy load balancing infrastructure ensures no active compute costs are incurred, while maintaining the ability to bring up the environment under the 2-hour RTO limit.

Step-by-Step Solution

Address the Recovery Point Objective (RPO) of 15 minutes for the database layer.

Establish a cross-region read replica of the database in the secondary region.

An RDS Cross-Region Read Replica uses asynchronous replication to keep data synchronized with lag that is typically seconds, comfortably meeting the 15-minute RPO.

Address the Recovery Time Objective (RTO) of 2 hours for the application layer while minimizing costs.

Create an Auto Scaling group in the secondary region with desired capacity set to 0, and write CloudFormation templates for the load balancing infrastructure.

A desired capacity of 0 ensures no EC2 instances are running (and incurring costs) during normal operations. When a disaster is declared, the CloudFormation templates can deploy the Application Load Balancer and the Auto Scaling group can be scaled up within minutes, well within the 2-hour RTO.

Key Concept

Configuring a Pilot Light disaster recovery strategy on AWS by combining asynchronous database replication with scaled-down compute infrastructure to satisfy RTO and RPO limits cost-effectively.

Question 351Question →

A company runs an inventory tracking application on AWS. The application tier runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. The database tier uses an Amazon RDS for PostgreSQL Multi-AZ deployment. The company wants to establish a disaster recovery (DR) strategy in a secondary AWS Region. The strategy must support a Recovery Point Objective (RPO) of 5 minutes and a Recovery Time Objective (RTO) of 30 minutes, while keeping ongoing replication and idle infrastructure costs to a minimum. Which of the following database and application configurations will meet these requirements?

Configure an Amazon RDS cross-region read replica in the secondary Region. Maintain an Auto Scaling group in the secondary Region with the desired capacity set to 0, and configure an Amazon Route 53 failover routing policy with health checks. In a disaster, promote the read replica to a primary instance, scale up the Auto Scaling group, and let Route 53 redirect traffic.

Configure an Amazon RDS cross-region read replica in the secondary Region. Deploy a Warm Standby architecture by running a minimum number of EC2 instances in the secondary Region's Auto Scaling group to handle baseline traffic. In a disaster, promote the read replica to a primary instance and scale up the Auto Scaling group.

Configure an Amazon RDS cross-region read replica in the secondary Region. Maintain an Auto Scaling group in the secondary Region with the desired capacity set to 0. In a disaster, update the application configuration in the secondary Region to direct all read and write traffic directly to the read replica without promoting it, and scale up the Auto Scaling group.

Configure daily automated exports of the database snapshots to Amazon S3 in the secondary Region, and transition those snapshots to Amazon S3 Glacier Flexible Retrieval. Maintain an Auto Scaling group in the secondary Region with the desired capacity set to 0. In a disaster, retrieve the snapshot from Glacier and restore it to a new RDS instance.

Show answer & explanation

Answer: Configure an Amazon RDS cross-region read replica in the secondary Region. Maintain an Auto Scaling group in the secondary Region with the desired capacity set to 0, and configure an Amazon Route 53 failover routing policy with health checks. In a disaster, promote the read replica to a primary instance, scale up the Auto Scaling group, and let Route 53 redirect traffic.

Answer

The correct option outlines a Pilot Light strategy, which satisfies the 5-minute RPO through RDS cross-region read replica replication and the 30-minute RTO by promoting the replica and scaling up the application tier. Keeping the Auto Scaling group's desired capacity at 0 minimizes ongoing compute costs in the secondary region.

Step-by-Step Solution

Evaluate the disaster recovery objectives (RTO of 30 minutes, RPO of 5 minutes) and the cost constraint.

The target strategy must support database replication with lag under 5 minutes, support application recovery within 30 minutes, and minimize idle infrastructure costs in the secondary region.

Establishes the criteria for selecting the most cost-effective disaster recovery design.

Compare database replication options to meet the 5-minute RPO.

An Amazon RDS cross-region read replica provides continuous, asynchronous replication with lag typically under a few seconds, satisfying the RPO.

Eliminates snapshot-based backup strategies which cannot guarantee a 5-minute RPO.

Determine the application tier deployment strategy to meet the 30-minute RTO and minimize cost.

Keeping an Auto Scaling group in the secondary Region with a desired capacity of 0 ensures no EC2 instances run during normal operations, minimizing cost (Pilot Light). During a disaster, promoting the replica and scaling up the Auto Scaling group can be completed within the 30-minute RTO.

This Pilot Light strategy meets all requirements at a lower cost than a Warm Standby strategy (which runs active instances continuously).

Key Concept

Disaster recovery (DR) strategies on AWS balance Recovery Time Objective (RTO), Recovery Point Objective (RPO), and cost. A Pilot Light strategy uses continuous database replication (such as RDS cross-region read replicas) while keeping application compute resource counts at zero until a failover event occurs, minimizing idle costs while meeting moderate recovery time limits.

Question 352Question →

A company hosts a web service on Amazon EC2 instances in private subnets. The instances are managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The web service is configured to listen on TCP port $8443$ . The ALB target group has its target port set to $8443$ , and the EC2 instances' security group allows inbound traffic on port $8443$ from the ALB's security group. After a recent deployment, the ALB marks all instances in the target group as unhealthy, and clients receive HTTP $502$ (Bad Gateway) errors, even though the application logs confirm that the service is running and healthy on the instances. What is the most likely cause of this issue?

The Network ACL of the private subnet lacks an inbound rule that allows traffic from the security group of the Application Load Balancer.

The security group associated with the EC2 instances is stateless, requiring an explicit outbound rule to allow return traffic back to the Application Load Balancer.

The target group is configured to perform health checks using the default port (HTTP port

80

) rather than port

8443

where the application is listening.

Amazon Route

53

latency routing is misconfigured to route traffic directly to the private IP addresses of the EC2 instances, bypassing the Application Load Balancer.

Show answer & explanation

Answer: The target group is configured to perform health checks using the default port (HTTP port $80$ ) rather than port $8443$ where the application is listening.

Answer

The target group is configured to perform health checks using the default port (HTTP port

80

) rather than port

8443

where the application is listening.

The Application Load Balancer determines target health using the configured health check port. If this is left as the default (typically port

80

) rather than the application's actual listening port (

8443

), the health check probes will fail, leading the load balancer to mark all instances as unhealthy and return HTTP

502

Bad Gateway errors.

Step-by-Step Solution

Analyze the load balancer behavior and the HTTP

502

error.

The HTTP

502

error indicates that the Application Load Balancer is unable to establish a connection with any healthy target instances.

When all backend instances are marked as unhealthy, the Application Load Balancer cannot forward traffic and returns a Bad Gateway error.

Examine the application port configuration versus the health check configuration.

The application listens on port

8443

, and the target group routes traffic to port

8443

, but the health check port is not explicitly specified.

If not specified, the target group's health check defaults to the protocol's default port (

80

for HTTP), which has nothing listening on it.

Verify if other network access configurations are correct.

The EC2 security group allows traffic on port

8443

from the ALB, confirming that standard traffic flow is permitted.

This rules out security groups blocking application traffic on port

8443

, pointing to the health check configuration mismatch as the root cause.

Key Concept

Target Group Health Checks

Question 353Question →

An enterprise application runs on Amazon EC2 instances inside a private subnet. These instances are managed by an Auto Scaling group (ASG) and receive traffic from an Application Load Balancer (ALB). The primary application is configured to listen on port 5000, while a dedicated monitoring daemon on each instance handles status reporting on port 5001. Currently, the target group health checks are targeted at port 5001. The ALB marks all new instances as unhealthy, yet the ASG fails to terminate or replace them. The security group on the EC2 instances is configured to accept inbound TCP connections on port 5000 from the ALB's security group. Which two modifications will resolve these issues and ensure unhealthy instances are automatically replaced? (Select two.)

Select all that apply

Allow inbound TCP traffic on port 5001 from the Application Load Balancer's security group in the EC2 instances' security group

Modify the Auto Scaling group's health check configuration to use Elastic Load Balancing (ELB) health checks instead of EC2 health checks

Add an inbound rule to the subnet's Network Access Control List (NACL) to allow traffic on port 5001, and remove the port 5001 allowance from the security group

Change the target group health check port configuration to port 80 to align with standard HTTP health check protocols

Configure an Amazon Route 53 latency routing policy to route user requests directly to individual EC2 instance IP addresses when they fail load balancer health checks

Show answer & explanation

Answer: Allow inbound TCP traffic on port 5001 from the Application Load Balancer's security group in the EC2 instances' security group; Modify the Auto Scaling group's health check configuration to use Elastic Load Balancing (ELB) health checks instead of EC2 health checks

Answer

Allow inbound TCP traffic on port 5001 from the Application Load Balancer's security group in the EC2 instances' security group, and modify the Auto Scaling group's health check configuration to use Elastic Load Balancing (ELB) health checks instead of EC2 health checks.

The correct options resolve both issues. First, allowing inbound TCP traffic on port 5001 from the Application Load Balancer's security group within the EC2 instances' security group opens the necessary communication path for the load balancer to query the monitoring daemon. Second, configuring the Auto Scaling group to use ELB health checks ensures the Auto Scaling group is aware of health status changes from the load balancer, enabling it to automatically terminate and replace instances that fail the target group health checks.

Step-by-Step Solution

Analyze why the Application Load Balancer is marking instances as unhealthy.

The target group is querying port 5001 for health checks, but the EC2 instances' security group only allows inbound traffic on port 5000. Traffic to port 5001 is being blocked.

Security groups are stateful firewalls at the instance level. An inbound rule must explicitly allow the load balancer to reach the health check port.

Analyze why the Auto Scaling group is not replacing the unhealthy instances.

By default, Auto Scaling groups use EC2 status checks (hardware and system status) to determine instance health. They do not automatically recognize Application Load Balancer target group health check failures.

Changing the health check type to ELB tells the Auto Scaling group to monitor target group health status and replace instances when they are marked unhealthy by the load balancer.

Key Concept

Auto Scaling Group health check types and Elastic Load Balancing target group security group rules.

Question 354Question →

A global e-learning provider hosts its platform on AWS. The application tier runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. The database tier uses an Amazon RDS for MySQL Multi-AZ DB instance. The provider needs to implement a disaster recovery (DR) strategy in a secondary AWS Region. The strategy must support a Recovery Time Objective (RTO) of 3 hours and a Recovery Point Objective (RPO) of 10 minutes, while keeping ongoing replication and infrastructure costs to a minimum.

Which combination of actions will meet these requirements? (Select TWO.)

Select all that apply

Configure an Amazon RDS for MySQL cross-region read replica in the secondary Region, and promote it to a standalone DB instance during a failover event.

Create and copy an Amazon Machine Image (AMI) of the application servers to the secondary Region, and prepare an AWS CloudFormation template to deploy the Application Load Balancer and Auto Scaling group during a failover.

Deploy a scaled-down Auto Scaling group and an Application Load Balancer in the secondary Region that continuously run at minimum capacity.

Configure Amazon Route 53 latency routing to automatically distribute incoming traffic between the application tiers in both Regions.

Take daily Amazon RDS snapshots, copy them to the secondary Region, and store them in Amazon S3 Glacier Flexible Retrieval to restore the database during a failover.

Show answer & explanation

Answer: Configure an Amazon RDS for MySQL cross-region read replica in the secondary Region, and promote it to a standalone DB instance during a failover event.; Create and copy an Amazon Machine Image (AMI) of the application servers to the secondary Region, and prepare an AWS CloudFormation template to deploy the Application Load Balancer and Auto Scaling group during a failover.

Answer

Configure an Amazon RDS for MySQL cross-region read replica in the secondary Region, and promote it during failover. Additionally, create and copy an AMI of the application servers, and use an AWS CloudFormation template to deploy the application tier resources during failover.

To satisfy the 10-minute RPO, continuous or near-continuous replication is required. Amazon RDS cross-region read replicas automatically replicate changes asynchronously with very low latency, typically in seconds, meeting the RPO. To meet the 3-hour RTO while minimizing ongoing costs, a Pilot Light strategy is ideal. Keeping pre-built AMIs and deploying the infrastructure via AWS CloudFormation templates on-demand avoids paying for running compute instances and load balancers during normal operations, yet allows full recovery within the 3-hour timeline.

Step-by-Step Solution

Select a data replication strategy that meets the 10-minute RPO.

Amazon RDS cross-region read replicas use asynchronous replication with very low replication lag (seconds to minutes), satisfying the 10-minute RPO.

Direct backup methods like daily snapshots would violate the 10-minute RPO.

Select a compute strategy that meets the 3-hour RTO while minimizing cost.

Store pre-built AMIs and write AWS CloudFormation templates to provision the load balancer and Auto Scaling group when a disaster is declared.

This Pilot Light strategy avoids any ongoing compute costs for idle servers while allowing full provisioning within the 3-hour window.

Avoid warm standby or active-active configurations to respect the cost constraint.

Do not provision running EC2 instances or load balancers in the secondary region prior to failover.

Running inactive or scaled-down infrastructure incurs unnecessary ongoing costs.

Key Concept

Designing a cost-effective Pilot Light disaster recovery strategy using cross-region database replication and on-demand infrastructure provisioning.

Question 355Question →

A global supply chain logistics platform hosts its fleet scheduling system in the us-east-1 Region. The architecture consists of Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer, and a primary Amazon Aurora PostgreSQL database cluster. The company needs to design a disaster recovery (DR) solution in the us-west-2 Region. The DR solution must achieve a Recovery Time Objective (RTO) of 20 minutes and a Recovery Point Objective (RPO) of 5 minutes while minimizing ongoing running costs. Which two steps should the solutions architect take to meet these requirements?

Select all that apply

Set up an Amazon Aurora Global Database with the primary cluster in the primary Region and a secondary cluster in the disaster recovery Region.

Deploy an Auto Scaling group in the disaster recovery Region with the minimum and desired capacity set to 0, and use a script or AWS CloudFormation to scale out the instances during a failover.

Deploy an Amazon RDS PostgreSQL Read Replica in the disaster recovery Region, and configure the primary Application Load Balancer to automatically route write transactions to the read replica if the primary database becomes unavailable.

Establish a Warm Standby DR solution by running a fully duplicated, active Auto Scaling group with the same instance counts in both Regions and utilizing Route 53 Latency routing.

Perform daily database backups to Amazon S3, transition the backups to S3 Glacier Flexible Retrieval, and restore the database to a new instance in the disaster recovery Region during a failover event.

Show answer & explanation

Answer: Set up an Amazon Aurora Global Database with the primary cluster in the primary Region and a secondary cluster in the disaster recovery Region.; Deploy an Auto Scaling group in the disaster recovery Region with the minimum and desired capacity set to 0, and use a script or AWS CloudFormation to scale out the instances during a failover.

Answer

Configure an Amazon Aurora Global Database with a secondary cluster in the recovery Region, and deploy an Auto Scaling group in the recovery Region with its capacity initialized to 0, scaling it out on-demand during failover.

The correct solution uses a Pilot Light disaster recovery strategy. Setting up an Aurora Global Database ensures asynchronous, sub-second replication to the secondary Region, keeping the database in sync and satisfying the 5-minute RPO. Deploying an Auto Scaling group with minimum and desired capacity set to 0 avoids active compute charges during normal operations, which satisfies the cost minimization constraint. In the event of a disaster, the database can be promoted quickly, and the Auto Scaling group can be scaled out via automation within the 20-minute RTO.

Step-by-Step Solution

Analyze the RTO and RPO requirements alongside the cost minimization constraint.

The RPO of 5 minutes requires active database replication to the secondary Region. The RTO of 20 minutes allows the application tier to be scaled down to zero and started on demand (Pilot Light).

The architecture needs to support fast recovery but avoid the cost of active compute in the recovery Region.

Address the database layer requirements.

Set up an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2.

Aurora Global Database provides sub-second latency replication, meeting the RPO of 5 minutes, and supports sub-minute failovers to meet the RTO.

Address the compute layer requirements.

Deploy an Auto Scaling group in us-west-2 with minimum and desired capacity set to 0. Use a template or script to scale out compute during failover.

This Pilot Light strategy avoids compute charges in the DR Region during normal operations, satisfying the cost-minimization constraint while allowing instance provisioning within the 20-minute RTO.

Key Concept

Disaster Recovery strategies (specifically Pilot Light) and cross-region replication technologies.

Question 356Question →

A financial firm is deploying a web application on Amazon EC2 instances in private subnets. The instances are managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application is configured to listen on port 8080. After deployment, the ALB is marking all registered EC2 instances as unhealthy. The solutions architect must resolve the health check failures and ensure the architecture is secure and resilient. Which combination of actions should the solutions architect take to resolve this issue? (Select two.)

Select all that apply

Update the ALB target group health check settings to explicitly use port 8080.

Configure the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB.

Modify the target group to perform health checks on port 80, expecting the operating system to automatically forward the probes to port 8080.

Change the Network ACL of the private subnet to stateful mode to automatically permit ephemeral port return traffic for the health checks.

Set up an Amazon Route 53 Latency routing policy targeting the individual private IP addresses of the EC2 instances to bypass the ALB's health checks.

Show answer & explanation

Answer: Update the ALB target group health check settings to explicitly use port 8080.; Configure the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB.

Answer

Update the ALB target group health check settings to explicitly use port 8080, and configure the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB.

To resolve the health check issues, the target group's health check configuration must be modified to query port 8080 where the application is listening, and the EC2 security group must allow inbound traffic on port 8080 from the ALB security group to allow the probes to succeed.

Step-by-Step Solution

Analyze the service configuration and identify the application port.

The application listens on port 8080, which is different from the default port 80.

By default, an Elastic Load Balancing target group performs health checks on the default port of the target group. If the target group defaults to port 80 but the application listens on port 8080, health checks will fail.

Ensure network connectivity between the Application Load Balancer and the EC2 instances.

The EC2 instances' security group must permit inbound TCP traffic on port 8080 from the ALB's security group.

Security groups are stateful firewalls. Allowing inbound traffic on the custom port from the load balancer security group allows the health check requests (and client traffic) to reach the instances.

Key Concept

ELB health check configuration and target group security integration

Question 357Question →

A Software-as-a-Service (SaaS) company hosts a document collaboration application in the us-east-1 Region. The application tier runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. User documents are stored in an Amazon S3 bucket, and metadata is stored in an Amazon Aurora MySQL-Compatible DB cluster. The company needs to implement a disaster recovery (DR) plan in the us-west-2 Region. The solution must achieve a Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective (RPO) of 15 minutes while minimizing ongoing infrastructure costs. Which solution meets these requirements most cost-effectively?

Enable Amazon S3 Cross-Region Replication (CRR) to replicate document files to us-west-2. Create an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2 with zero DB instances. Pre-configure the Application Load Balancer and the Auto Scaling group in us-west-2 with a desired capacity of zero. Configure Amazon Route 53 failover routing with health checks.

Establish a warm standby environment in us-west-2 by maintaining a scaled-down Auto Scaling group with a minimum capacity of one EC2 instance and a running secondary Aurora DB instance. Use Amazon Route 53 latency routing to automatically redirect user sessions to the secondary region during a failover event.

Create hourly snapshots of the Aurora DB cluster and copy them to us-west-2. Store the application deployment templates in an S3 bucket configured to transition objects immediately to S3 Glacier Flexible Retrieval. Upon disaster declaration, retrieve the templates to deploy the infrastructure and restore the database from the copied snapshot.

Configure a cross-region Aurora Read Replica in us-west-2 to serve as the immediate database failover target. Deploy the EC2 application tier at full capacity in us-west-2 to ensure immediate availability. Use Amazon Route 53 simple routing to direct a portion of the write traffic to the read replica to keep it synchronized.

Show answer & explanation

Answer: Enable Amazon S3 Cross-Region Replication (CRR) to replicate document files to us-west-2. Create an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2 with zero DB instances. Pre-configure the Application Load Balancer and the Auto Scaling group in us-west-2 with a desired capacity of zero. Configure Amazon Route 53 failover routing with health checks.

Answer

The correct solution represents a Pilot Light DR strategy, which is the most cost-effective way to meet a 4-hour RTO and 15-minute RPO. Amazon S3 Cross-Region Replication (CRR) and Amazon Aurora Global Database provide continuous, low-latency replication that satisfies the 15-minute RPO. Aurora Global Database supports having zero running DB instances in the secondary region cluster, and the EC2 Auto Scaling group can be configured with a capacity of zero. During a failover event, the DB instances are created, the Auto Scaling group is scaled up, and Route 53 failover routing directs traffic to the secondary region. This process completes well within the 4-hour RTO and incurs zero compute cost during normal operation.

Step-by-Step Solution

Determine the optimal disaster recovery pattern based on the RTO and RPO constraints.

An RTO of 4 hours suggests that a Pilot Light strategy is appropriate because compute resources (EC2 and Aurora DB instances) do not need to run continuously and can be provisioned or scaled up during failover.

This minimizes ongoing costs while easily meeting the generous 4-hour recovery window.

Choose replication mechanisms that satisfy the 15-minute RPO.

S3 Cross-Region Replication (CRR) and Aurora Global Database both replicate data continuously and asynchronously with sub-minute latency.

This ensures that data loss in the event of a disaster remains well under the 15-minute RPO limit.

Select the correct database and application configuration for Pilot Light.

Aurora Global Database allows the secondary DB cluster to have zero DB instances, eliminating compute costs. Similarly, pre-configured Auto Scaling groups can have their desired capacity set to zero.

This ensures zero compute expenses in the recovery region during normal operations, achieving the most cost-effective architecture.

Key Concept

Designing a Pilot Light disaster recovery strategy using S3 Cross-Region Replication and Aurora Global Database with zero-instance secondary clusters to meet recovery objectives cost-effectively.

Question 358Question →

A public transit ticketing platform hosts its core application in the us-west-2 Region. The database tier runs on an Amazon RDS for MySQL Multi-AZ DB instance. The company needs to design a disaster recovery (DR) plan in the us-east-1 Region. The DR strategy must achieve a Recovery Point Objective (RPO) of less than 15 minutes and a Recovery Time Objective (RTO) of less than 30 minutes, while keeping costs as low as possible.

Which TWO configurations should a solutions architect implement to meet these requirements? (Select TWO.)

Select all that apply

Create a cross-region read replica of the RDS DB instance in the us-east-1 Region.

Deploy a scaled-down application tier in the us-east-1 Region, and configure Amazon Route 53 failover routing with health checks.

Configure an Amazon Route 53 latency-based routing policy to automatically redirect database and application traffic to the us-east-1 Region during an outage.

Enable Amazon RDS Multi-AZ replication across both the us-west-2 and us-east-1 Regions to automate database failover.

Export daily database snapshots to Amazon S3 Glacier Flexible Retrieval in the us-east-1 Region, and restore the database during a failover event.

Show answer & explanation

Answer: Create a cross-region read replica of the RDS DB instance in the us-east-1 Region.; Deploy a scaled-down application tier in the us-east-1 Region, and configure Amazon Route 53 failover routing with health checks.

Answer

Create a cross-region read replica of the RDS DB instance in the us-east-1 Region, and deploy a scaled-down application tier in the us-east-1 Region with Amazon Route 53 failover routing and health checks.

To meet the 15-minute RPO, the database must replicate continuously to the secondary region. An RDS cross-region read replica meets this requirement by replicating data asynchronously with very low latency. To meet the 30-minute RTO, the database replica can be promoted to a standalone primary instance in minutes. To minimize costs, the application tier should be kept scaled down (Pilot Light pattern) and only scaled up when a failover is initiated. Amazon Route 53 failover routing with health checks handles the redirection of user traffic to the secondary region during a disaster.

Step-by-Step Solution

Select a database replication method that meets the RPO of less than 15 minutes.

Using an Amazon RDS cross-region read replica provides asynchronous data replication across regions, which typically keeps replication lag under a few minutes, meeting the 15-minute RPO.

Asynchronous replication to a cross-region read replica provides a cost-effective, low-lag copy of the database in the recovery region.

Choose a compute deployment model that minimizes costs and supports the 30-minute RTO.

Pre-deploying a scaled-down (Pilot Light) application tier in us-east-1 ensures that the core resources exist and can be scaled up rapidly via Auto Scaling groups or instance resizing during a disaster.

A Pilot Light pattern avoids the cost of running a full-capacity environment continuously while still meeting the RTO.

Configure DNS routing to handle traffic redirection during failover.

Setting up Amazon Route 53 failover routing policies associated with health checks allows the architect to redirect client traffic to the secondary region once the database is promoted and the application tier is scaled up.

Failover routing provides the mechanism to switch active user traffic to the backup site when the primary region is unavailable.

Key Concept

Disaster recovery planning using a cross-region Pilot Light strategy with Amazon RDS cross-region read replicas and Amazon Route 53 failover routing to meet strict RTO/RPO objectives while minimizing idle resource costs.

Question 359Question →

A financial technology company is designing a ledger application that processes account transaction logs. When an account transaction occurs, the details must be sent to two separate downstream systems: a ledger auditing service and an account balance update service. Both downstream systems must process the transaction events in the exact chronological order in which they were generated for each account to ensure ledger accuracy. The architecture must be decoupled and resilient to temporary downstream service outages. Which combination of steps should a solutions architect recommend to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon SNS FIFO topic to receive and distribute the transaction events.

Create two Amazon SQS FIFO queues and subscribe them to the SNS FIFO topic, with one queue dedicated to each downstream service.

Create a standard Amazon SNS topic and subscribe two standard Amazon SQS queues to it to distribute the transaction events.

Create two standard Amazon SQS queues and configure the transaction generator to write to both queues simultaneously using parallel client-side threads.

Configure both downstream services to pull events from a single shared Amazon SQS FIFO queue.

Show answer & explanation

Answer: Create an Amazon SNS FIFO topic to receive and distribute the transaction events.; Create two Amazon SQS FIFO queues and subscribe them to the SNS FIFO topic, with one queue dedicated to each downstream service.

Answer

Creating an Amazon SNS FIFO topic to receive the events and subscribing two Amazon SQS FIFO queues to the topic (one for each downstream service) provides a decoupled, resilient, and ordered event distribution system.

To achieve both event fan-out (sending the same transaction to multiple services) and chronological ordering, the architecture must use Amazon SNS FIFO paired with Amazon SQS FIFO. An SNS FIFO topic preserves the ordering of messages and can fan them out to multiple SQS FIFO queues. Each downstream service must have its own dedicated SQS FIFO queue to ensure both services receive every transaction message independently without competing. The SQS queues also buffer messages, decoupling the producer from the consumers and ensuring resilience during downstream service outages.

Step-by-Step Solution

Select a message distribution service that supports ordering and fan-out.

Amazon SNS FIFO is chosen because standard SNS does not guarantee ordering, which is a key requirement for ledger transactions.

An SNS FIFO topic ensures that message ordering is maintained and allows fanning out the same message to multiple subscriber queues.

Select consumer queues that support ordering and resilience.

Two Amazon SQS FIFO queues are chosen, with one dedicated to each downstream service.

SQS FIFO queues preserve the strict order of messages published by the SNS FIFO topic and buffer messages to protect downstream services during high traffic or downtime.

Verify fan-out topology versus shared queue topology.

Each service must have its own queue subscribed to the SNS FIFO topic rather than sharing a single queue.

A single shared queue would result in competing consumers where each transaction is processed by only one of the services instead of both.

Key Concept

Fanning out ordered messages to multiple downstream systems using Amazon SNS FIFO and Amazon SQS FIFO queues.

Question 360Question →

A ride-hailing platform is designing an event-driven system to process trip status updates (such as requested, accepted, in-progress, and completed). These updates must be processed in the exact chronological sequence they are generated for each individual trip to ensure accurate customer billing and driver payouts. The status updates must be delivered to two separate backend services: a billing service and a real-time analytics service. The architecture must be decoupled, highly available, and handle traffic spikes dynamically.

Which combination of steps should a solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon SNS FIFO topic, and subscribe two Amazon SQS FIFO queues to the topic.

Publish the trip status updates to the SNS FIFO topic using the unique trip ID as the message group ID.

Create a standard Amazon SNS topic, and subscribe two standard Amazon SQS queues to the topic.

Configure an AWS Lambda function to run continuously in a loop to poll the status updates and process them sequentially for both services.

Write the trip status updates to an Amazon DynamoDB table using a sequential, monotonically increasing timestamp as the partition key.

Show answer & explanation

Answer: Create an Amazon SNS FIFO topic, and subscribe two Amazon SQS FIFO queues to the topic.; Publish the trip status updates to the SNS FIFO topic using the unique trip ID as the message group ID.

Answer

Create an Amazon SNS FIFO topic and subscribe two Amazon SQS FIFO queues to it, then publish the status updates to the SNS FIFO topic using the trip ID as the message group ID.

To achieve both decoupling (fan-out) and strict chronological ordering per trip, the architect must use Amazon SNS FIFO and Amazon SQS FIFO. By subscribing two separate SQS FIFO queues (one for billing, one for analytics) to the SNS FIFO topic, the system fans out the updates to both services independently. Using the unique trip ID as the message group ID ensures that events for any single trip are processed in order, while allowing updates across different trips to run in parallel, maximizing throughput during spikes.

Step-by-Step Solution

Determine how to broadcast trip status updates to both backend services without coupling.

Amazon SNS is chosen to fan out incoming trip status updates to multiple downstream destinations.

Publishing events to an SNS topic allows multiple independent subscriber queues to receive copies of the same event.

Select the appropriate queue and topic types to guarantee chronological ordering.

Configure an SNS FIFO topic and SQS FIFO queues, and publish messages using the trip ID as the message group ID.

FIFO configurations guarantee that messages within the same group are processed in the exact order they are received, while the trip ID ensures serialization is restricted per trip rather than across the entire platform.

Exclude alternatives that introduce bottlenecks or cost inefficiencies.

Avoid standard queues (which do not guarantee ordering), continuous Lambda loops (which inflate run-time costs), and monotonic keys in DynamoDB (which create hot partitions).

This guarantees a decoupled, resilient, cost-effective, and highly performant architecture that scales with traffic spikes.

Key Concept

Decoupled fan-out with ordering preservation using SNS FIFO and SQS FIFO queues.

PreviousPage 18 / 20Next

Design Resilient Architectures

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

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

Alternative Method

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