Design Resilient Architectures

382 questions

All types382 Multiple choice195 Multiple select187

A company hosts a microservice on Amazon EC2 instances inside private subnets. The instances are managed by an Auto Scaling group (ASG) behind a public Application Load Balancer (ALB). The microservice is configured to listen on TCP port 8080. The ALB target group is configured to send health check requests to the instances on port 8080. After a security audit, a network engineer modified the custom network access control list (network ACL) associated with the private subnets. Shortly after, the ALB target group health checks began failing, marking all EC2 instances as unhealthy. The security group associated with the EC2 instances correctly allows inbound traffic on port 8080 from the ALB's security group. Which action should the solutions architect take to resolve this issue and restore service availability?

Modify the target group health check configuration to query port 80 instead of port 8080 to align with the Application Load Balancer's public listener.

Add an outbound rule to the EC2 instances' security group that explicitly allows return traffic to the Application Load Balancer on ephemeral ports.

Update the subnet network ACL to allow outbound traffic on ephemeral ports (1024-65535) to the load balancer's subnets.

Create an Amazon Route 53 Latency routing policy pointing directly to the EC2 instances' private IP addresses to bypass the load balancer's health checks.

Show answer & explanation

Answer: Update the subnet network ACL to allow outbound traffic on ephemeral ports (1024-65535) to the load balancer's subnets.

Answer

Update the subnet network ACL to allow outbound traffic on ephemeral ports (1024-65535) to the load balancer's subnets.

The correct solution is to allow outbound ephemeral port traffic in the private subnets' network ACL. Because network ACLs are stateless, allowing inbound traffic on port 8080 is not enough; the return traffic from the instances back to the load balancer (which uses ephemeral ports as source ports) must be explicitly permitted in the outbound rules.

Step-by-Step Solution

Analyze the health check failure context.

The application is running on port 8080, and the instance security groups correctly allow inbound traffic on port 8080 from the ALB. The health checks started failing immediately after network ACL modifications.

To narrow down the root cause to the stateless network ACL layer.

Evaluate how stateless network ACLs process health check traffic.

The ALB initiates TCP connections to the EC2 instances on port 8080 using ephemeral source ports (1024-65535). Because network ACLs are stateless, return traffic from the EC2 instances to the ALB must be explicitly allowed on these ephemeral ports.

To determine the required rule to allow the health check responses to return to the ALB.

Select the configuration change that addresses the stateless nature of network ACLs.

Adding an outbound rule to the private subnet network ACL allowing ephemeral port traffic to the ALB subnets restores health check traffic flow.

To establish successful health check validation and make the instances healthy in the target group.

Key Concept

ELB health checks require appropriate configuration of security groups and stateless Network ACLs (NACLs) to ensure bidirectional communication.

Question 142Question →

A shipping company is designing a system to process telemetry reports from IoT sensors installed on cargo containers. The sensors publish reports containing temperature, humidity, and location data. The processing application must handle messages asynchronously. To prevent data corruption, reports for each individual cargo container must be processed in the exact order they are received. Reports that fail to process after 5 attempts must be quarantined for investigation. Which TWO options should the solutions architect implement to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon SQS FIFO queue to buffer the reports, using the cargo container ID as the message group ID to preserve order.

Configure an Amazon SQS FIFO dead-letter queue (DLQ) to capture messages that fail to process after multiple retries.

Use an Amazon SQS Standard queue to buffer the reports to ensure high throughput while preserving chronological order.

Configure an Amazon S3 Glacier vault to act as the dead-letter queue to store failed reports for immediate, low-latency analysis.

Direct the telemetry reports to an AWS Lambda function running continuously as a daemon to handle long-running container session logic.

Show answer & explanation

Answer: Create an Amazon SQS FIFO queue to buffer the reports, using the cargo container ID as the message group ID to preserve order.; Configure an Amazon SQS FIFO dead-letter queue (DLQ) to capture messages that fail to process after multiple retries.

Answer

The solutions architect should create an Amazon SQS FIFO queue, using the cargo container ID as the message group ID to preserve order, and configure an Amazon SQS FIFO dead-letter queue (DLQ) to capture failed messages.

To ensure reports for each cargo container are processed in the exact order they are received, an Amazon SQS FIFO queue is required. Using the container ID as the message group ID ensures that messages within the same container group are processed sequentially, while allowing parallel processing across different containers. Additionally, configure an Amazon SQS FIFO dead-letter queue (DLQ) to handle processing failures. A FIFO queue requires a FIFO DLQ to maintain order and receive quarantined messages after the specified retry limit is reached.

Step-by-Step Solution

Identify the ordering requirements of the system.

Since the reports must be processed in the exact order they were received per container, a First-In-First-Out (FIFO) messaging mechanism is required.

Standard message queues do not guarantee FIFO order, which could lead to processing telemetry data out of sequence.

Determine the message grouping strategy.

Use the container ID as the Message Group ID within the SQS FIFO queue.

This guarantees sequential processing for messages within the same container group while allowing concurrent processing across different container IDs.

Design the error handling and quarantine mechanism.

Configure an SQS FIFO dead-letter queue (DLQ) as the target for the redrive policy of the main queue.

Messages that fail to process after 5 attempts are automatically sent to the DLQ, satisfying the quarantine requirement without blocking the rest of the queue.

Key Concept

Decoupling message processing while maintaining message ordering using SQS FIFO queues and handling failures using Dead-Letter Queues (DLQs).

Question 143Question →

An online auction platform operates its primary application in the eu-west-1 Region. The architecture consists of an Application Load Balancer (ALB), an Auto Scaling group of Amazon EC2 instances, and an Amazon RDS for MySQL database. The company needs to design a disaster recovery (DR) strategy in the eu-central-1 Region. The DR plan must support a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 2 hours while minimizing ongoing running costs. Which strategy should a solutions architect recommend to meet these requirements?

Deploy a scaled-down but running application tier in the secondary region, consisting of an Application Load Balancer and an Auto Scaling group with a minimum capacity of 1. Configure a cross-region Amazon RDS Read Replica in the secondary region. In a disaster recovery event, promote the Read Replica and scale out the Auto Scaling group.

Configure Amazon RDS Multi-AZ replication to replicate the database to the secondary region. Set up an Amazon Route 53 latency routing policy to automatically fail over and direct user traffic to the secondary region during an outage.

Configure a cross-region Amazon RDS Read Replica in the secondary region. Store the application tier infrastructure as AWS CloudFormation templates in the secondary region, maintaining the Auto Scaling group with a desired capacity of zero. In a disaster recovery event, promote the Read Replica to a standalone DB instance and deploy the CloudFormation templates to provision the compute resources.

Create snapshots of the Amazon RDS DB instance every 15 minutes, copy them to the secondary region, and immediately transition them to Amazon S3 Glacier Flexible Retrieval to minimize storage costs. In a disaster recovery event, initiate a standard retrieval of the snapshot to restore the database.

Show answer & explanation

Answer: Configure a cross-region Amazon RDS Read Replica in the secondary region. Store the application tier infrastructure as AWS CloudFormation templates in the secondary region, maintaining the Auto Scaling group with a desired capacity of zero. In a disaster recovery event, promote the Read Replica to a standalone DB instance and deploy the CloudFormation templates to provision the compute resources.

Answer

The correct strategy represents a Pilot Light architecture. By utilizing a cross-region Amazon RDS Read Replica, database updates are constantly replicated to the DR region, satisfying the 15-minute RPO. Maintaining the compute resources (ALB and EC2 Auto Scaling group) as CloudFormation templates and keeping the Auto Scaling group desired capacity at zero minimizes running costs since there are no active computing charges. In the event of a disaster, provisioning the compute stack and promoting the DB replica can easily be completed within the 2-hour RTO.

Step-by-Step Solution

Analyze RPO requirements.

The target RPO is 15 minutes. To prevent losing more than 15 minutes of transactional data, replication to the target region must be continuous. An RDS cross-region Read Replica uses asynchronous replication and satisfies this requirement.

Choosing a backup-and-restore option with manual snapshot copies is operationally heavy and risks violating RPO if replication/copies are delayed.

Analyze RTO and cost requirements.

The target RTO is 2 hours. Deploying compute resources using AWS CloudFormation templates and scaling up an Auto Scaling group takes minutes, easily fitting within the 2-hour window. This allows us to keep the Auto Scaling group capacity at zero in the DR region.

This is a Pilot Light strategy. Keeping the application load balancer and compute instances offline when not in use minimizes running costs.

Evaluate and eliminate sub-optimal strategies.

Warm Standby is rejected because keeping active compute resources running continuously in the secondary region is more expensive. S3 Glacier is rejected because retrieval delays violate the RTO. Multi-AZ database configurations are rejected because they do not span multiple AWS regions.

Ensuring the selected solution is both technically viable and the most cost-efficient choice among the options.

Key Concept

Disaster Recovery (DR) Strategies: Pilot Light vs. Warm Standby

Estimated Time:2m 0s

Question 144Question →

A healthcare technology company hosts its core prescription processing application in the us-east-1 Region. The application uses an Amazon Aurora PostgreSQL database cluster. The company needs to design a disaster recovery (DR) strategy in the us-west-2 Region. The design must achieve a Recovery Point Objective (RPO) of less than 5 minutes and a Recovery Time Objective (RTO) of less than 30 minutes. To comply with budget constraints, the strategy must also minimize ongoing infrastructure costs. Which disaster recovery configuration meets these requirements?

Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Deploy an Application Load Balancer and an Auto Scaling group in us-west-2 with the desired and minimum capacity set to 0. During a disaster recovery event, promote the secondary database cluster and scale up the Auto Scaling group.

Deploy a Warm Standby architecture in us-west-2 with an active database cluster of the same size as the primary database, and a fully scaled Application Load Balancer and Auto Scaling group running at identical capacity to the primary region.

Deploy an Amazon RDS for PostgreSQL database instance in us-east-1 with a cross-region Read Replica in us-west-2. Configure an Amazon Route 53 latency routing policy to automatically redirect application traffic to the secondary region's Read Replica in the event of a primary database failure.

Configure daily automated database exports to an Amazon S3 bucket, and use S3 Cross-Region Replication to copy the backups to an S3 Glacier Flexible Retrieval vault in us-west-2. In the event of a disaster, retrieve the backup from S3 Glacier and restore it to a new database instance.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Deploy an Application Load Balancer and an Auto Scaling group in us-west-2 with the desired and minimum capacity set to 0. During a disaster recovery event, promote the secondary database cluster and scale up the Auto Scaling group.

Answer

The correct strategy uses Amazon Aurora Global Database to achieve near-zero RPO (sub-second replication) and deploys compute resources scaled to zero in the secondary region to minimize ongoing costs. In the event of a failover, the secondary database is promoted and the compute resources are scaled up, which can easily be completed within the 30-minute RTO. This represents a highly cost-optimized Pilot Light DR pattern.

Step-by-Step Solution

Analyze RPO and RTO requirements against database replication technologies.

Amazon Aurora Global Database provides sub-second replication latency, which easily satisfies the 5-minute RPO constraint.

Choosing a continuous replication mechanism is necessary because daily snapshots or exports cannot meet a 5-minute RPO.

Evaluate the cost minimization constraint against compute deployment options.

Using a Pilot Light strategy by configuring an Auto Scaling group with a desired/minimum capacity of 0 ensures that compute charges are only incurred during testing or an actual disaster recovery event.

Running a fully scaled Warm Standby configuration continuously is expensive and violates the requirement to minimize ongoing costs.

Verify RTO compliance for promoting the secondary database and scaling compute.

Promoting an Aurora secondary cluster takes less than a minute, and scaling up the Auto Scaling group instances takes a few minutes, fitting well within the 30-minute RTO target.

Ensuring both the database promotion and compute provisioning steps can complete within the RTO budget is critical for the success of the DR plan.

Key Concept

Disaster Recovery (DR) strategies on AWS involve balancing Recovery Time Objective (RTO), Recovery Point Objective (RPO), and cost. A Pilot Light strategy keeps data replicated and infrastructure definitions ready, but compute resources are turned off or scaled to zero until a failover occurs, making it highly cost-effective.

Question 145Question →

A digital publishing company is building an automated newsletter system. When articles are published or updated, metadata events must be processed in sequence to update the search index and subscriber email caches. The publishing rate can spike dramatically during breaking news events, and downstream update workers sometimes experience transient database connection timeouts. The company needs a resilient, decoupled architecture that processes updates in the order they occur per article, buffers traffic spikes, and ensures that failing messages do not block the processing of other articles. Which TWO actions should the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Send the article update events to an Amazon SQS FIFO queue, setting the article ID as the message group ID.

Configure a dead-letter queue (DLQ) on the main Amazon SQS FIFO queue to capture messages that fail to process after the maximum receive count is exceeded.

Send the article update events to an Amazon SQS Standard queue and enable message deduplication using the MessageDeduplicationId parameter.

Send the article update events to an Amazon SQS Standard queue and configure a dead-letter queue (DLQ) to handle failed messages while ensuring ordered delivery by setting the visibility timeout to zero.

Show answer & explanation

Answer: Send the article update events to an Amazon SQS FIFO queue, setting the article ID as the message group ID.; Configure a dead-letter queue (DLQ) on the main Amazon SQS FIFO queue to capture messages that fail to process after the maximum receive count is exceeded.

Answer

To achieve decoupling, order preservation, and fault tolerance, the solution must use an Amazon SQS FIFO queue with the article ID as the MessageGroupId, combined with a Dead-Letter Queue (DLQ) to handle processing failures without blocking other articles.

To decouple the systems while maintaining strict order processing per article, a Solutions Architect should use an Amazon SQS FIFO (First-In-First-Out) queue. By setting the article ID as the MessageGroupId, SQS ensures that messages belonging to the same article are processed sequentially in the order they were received. Setting up a dead-letter queue (DLQ) ensures that poison-pill messages (those that fail repeatedly) are isolated after a specified number of attempts, allowing other messages in the queue to continue processing without blocking the pipeline.

Step-by-Step Solution

Select the appropriate messaging service that supports ordering.

Amazon SQS FIFO queues are chosen over SQS Standard queues because they guarantee first-in, first-out ordering, which is required to process article updates in sequence.

Standard SQS queues only guarantee best-effort ordering, which does not satisfy the strict sequential requirement.

Configure the message grouping strategy.

Set the MessageGroupId to the article ID on every sent message.

Using the article ID as the MessageGroupId ensures that messages belonging to the same article are processed in order, while messages for different articles can be processed concurrently to improve throughput.

Address transient failures and blockages.

Configure a dead-letter queue (DLQ) to capture messages that exceed the maximum receive count.

If a message fails repeatedly (e.g., due to database timeouts), transferring it to a DLQ unblocks the message group, allowing subsequent updates for that article to proceed.

Key Concept

Decoupling message processing using SQS FIFO queues and MessageGroupIds to maintain ordering, combined with DLQs to handle poison-pill messages.

Question 146Question →

A company hosts a microservice on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The EC2 instances are located in private subnets, and the ALB is in public subnets. The application on the EC2 instances listens on TCP port 8080. A custom Network ACL (NACL) is applied to the private subnets. The solutions architect notices that the ALB target group marks all EC2 instances as unhealthy, and clients receive HTTP 502 Bad Gateway errors. The security groups for both the ALB and the EC2 instances are configured to allow traffic on port 8080. Which configuration change is required to resolve this issue and restore healthy status to the target group?

Add an outbound rule to the EC2 instances' security group allowing TCP traffic on ephemeral ports to the ALB, because security group rules are stateless.

Reconfigure the target group health check port to TCP port 80, as the ALB listener is configured to receive HTTP traffic on port 80.

Add an outbound rule to the private subnet Network ACL that allows TCP traffic on ephemeral ports (1024-65535) to the public subnets.

Modify the Amazon Route 53 routing policy to use Latency Routing with health checks enabled to automatically route the ALB health check probes to healthy instances.

Show answer & explanation

Answer: Add an outbound rule to the private subnet Network ACL that allows TCP traffic on ephemeral ports (1024-65535) to the public subnets.

Answer

Add an outbound rule to the private subnet Network ACL that allows TCP traffic on ephemeral ports (1024-65535) to the public subnets.

The correct option is to add an outbound rule to the private subnet Network ACL that allows TCP traffic on ephemeral ports (1024-65535) to the public subnets. Because Network ACLs are stateless, return traffic from the EC2 instances back to the ALB must be explicitly allowed. When the ALB sends a health check request to port 8080 on the instances, the return traffic from port 8080 goes back to the ALB's ephemeral ports.

Step-by-Step Solution

Analyze the components and the flow of the health check requests.

The Application Load Balancer (ALB) in the public subnet sends health check requests to the EC2 instances in the private subnet on port 8080.

Health check probes are initiated by the ALB and targeted at the configured port of the backend instances.

Examine the statefulness of the security groups and Network ACLs.

Security groups are stateful and allow return traffic automatically. Network ACLs (NACLs) are stateless, meaning both inbound and outbound traffic must be explicitly allowed.

Since a custom NACL is applied to the private subnets, any return traffic generated by the EC2 instances in response to the health check probes must be allowed explicitly by an outbound NACL rule.

Identify the ports required for the return traffic.

The return traffic from the EC2 instances (destined for the ALB's client request port) must be sent to the ephemeral ports (1024-65535) of the ALB subnets.

When a client or load balancer initiates a connection, it uses an ephemeral port. The server responds back to this ephemeral port, requiring the private subnet's NACL to permit outbound ephemeral traffic.

Key Concept

Understanding the stateless nature of Network ACLs compared to stateful Security Groups when configuring health checks between an ALB and backend targets.

Question 147Question →

A company hosts a customer-facing web application on Amazon EC2 instances managed by an Auto Scaling group (ASG). The instances are registered with a target group of an Application Load Balancer (ALB). The web application serves user requests on HTTP port 80. However, the application's health status service runs on a dedicated management agent listening on TCP port 8080. The target group health check is configured to query port 8080. Currently, the security group for the EC2 instances allows inbound HTTP traffic on port 80 from the ALB security group. The ALB console reports all EC2 instances as unhealthy, and users are receiving 502 Bad Gateway errors.

Which action should the Solutions Architect take to resolve the issue?

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

Modify the subnet Network ACL to allow inbound traffic on port 8080, as security groups are stateless and cannot track the return traffic for the health checks.

Change the target group health check port setting to 'traffic-port' so that the health check automatically queries port 80.

Configure an Amazon Route 53 latency routing policy to route client traffic directly to the elastic network interfaces (ENIs) of the EC2 instances.

Show answer & explanation

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

Answer

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

The correct action is to modify the security group of the EC2 instances to allow inbound traffic on TCP port 8080 from the security group of the ALB. Since the target group health check is configured to query port 8080 but the EC2 instances' security group only allows inbound traffic on port 80, the ALB's health check requests are blocked. Enabling port 8080 inbound allows the ALB to reach the health status service, marking the instances as healthy and resolving the service outage.

Step-by-Step Solution

Analyze the ports used for application traffic and health checks.

User traffic uses port 80, but health checks use port 8080.

This establishes that two separate ports must be accessible by the Application Load Balancer.

Check the security group rules on the target EC2 instances.

Only port 80 is allowed from the ALB's security group; port 8080 is blocked.

This explains why the ALB is reporting the instances as unhealthy despite the application running correctly.

Authorize inbound traffic on port 8080 from the ALB security group to the EC2 instances.

The ALB can now successfully perform health checks, marking the instances as healthy and resuming normal traffic routing.

This resolves the network path blockage specifically for the health check endpoint.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) Health Check and Security Group Integration

Question 148Question →

A software company wants to design a disaster recovery (DR) strategy for a non-critical internal application. The company has specified a Recovery Time Objective (RTO) of 24 hours and a Recovery Point Objective (RPO) of 24 hours. The database backups must be stored in a secondary AWS Region, and the primary goal is to minimize ongoing infrastructure costs. Which disaster recovery strategy should a solutions architect recommend to meet these requirements at the lowest cost?

Backup and Restore, by copying database backups to the secondary Region daily and deploying application resources using AWS CloudFormation only during a disaster recovery event.

Pilot Light, by running a scaled-down version of the application servers and database instances in the secondary Region to achieve near-zero failover time.

Backup and Restore, by replicating databases to RDS Read Replicas in the secondary Region to serve as the automatic, immediate failover target.

Backup and Restore, by archiving the database snapshots to Amazon S3 Glacier Flexible Retrieval and using standard retrieval to recover the data within 10 minutes.

Show answer & explanation

Answer: Backup and Restore, by copying database backups to the secondary Region daily and deploying application resources using AWS CloudFormation only during a disaster recovery event.

Answer

Backup and Restore, by copying database backups to the secondary Region daily and deploying application resources using AWS CloudFormation only during a disaster recovery event.

The correct option is the Backup and Restore strategy using AWS CloudFormation. Because the RTO and RPO are both 24 hours, the company does not need active servers or continuous replication running in the disaster recovery region. Storing daily backups in Amazon S3 in the secondary region satisfies the 24-hour RPO. Deploying resources on-demand via CloudFormation templates during an actual disaster easily fits within the 24-hour RTO while minimizing ongoing costs to only S3 storage.

Step-by-Step Solution

Analyze the RTO and RPO requirements.

The target RTO is 24 hours and RPO is 24 hours.

Identifying these targets helps narrow down the acceptable disaster recovery strategies.

Evaluate the cost constraint.

The primary goal is to minimize ongoing infrastructure costs.

Since the RTO and RPO are lenient (24 hours), we should select the strategy that runs the fewest active resources in the secondary Region.

Select the most cost-effective strategy.

Backup and Restore meets the 24-hour RTO/RPO limits and incurs the lowest ongoing cost because no active compute or database instances run in the DR region until a failover occurs.

Other strategies like Pilot Light or Warm Standby keep active resources running, increasing costs unnecessarily.

Key Concept

Disaster recovery strategies differ in their RTO, RPO, and cost trade-offs, with Backup and Restore being the most cost-effective but slowest option.

Estimated Time:45s

Question 149Question →

An enterprise core banking application requires a relational database backend. The database configuration must achieve a Recovery Point Objective (RPO) of $0$ (no data loss) and a Recovery Time Objective (RTO) of less than $30$ seconds during an Availability Zone outage. The architecture must also support scaling read operations for reporting tools without impacting the primary database's write performance. Which database configuration meets these requirements with the lowest RTO and minimal operational effort?

Deploy an Amazon Aurora PostgreSQL DB cluster with a primary DB instance and at least one Aurora Replica in a different Availability Zone. Configure the reporting tools to use the cluster reader endpoint.

Deploy an Amazon RDS for PostgreSQL DB instance in a single Availability Zone. Create a Read Replica in a different Availability Zone, and use an Amazon Route 53 latency routing policy with health checks to automatically route write traffic to the replica during an outage.

Deploy an Amazon RDS for PostgreSQL database in a Multi-AZ DB instance deployment. Configure the reporting tools to connect directly to the standby replica to scale read operations.

Deploy two independent single-AZ Amazon RDS for PostgreSQL DB instances in different Availability Zones. Set up AWS Database Migration Service (AWS DMS) to perform bidirectional replication, and use an Application Load Balancer to distribute read and write traffic.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL DB cluster with a primary DB instance and at least one Aurora Replica in a different Availability Zone. Configure the reporting tools to use the cluster reader endpoint.

Answer

Deploy an Amazon Aurora PostgreSQL DB cluster with a primary DB instance and at least one Aurora Replica in a different Availability Zone, and configure the reporting tools to use the cluster reader endpoint.

The correct configuration uses Amazon Aurora PostgreSQL with a primary instance and an Aurora Replica in a different Availability Zone. Aurora's storage layer replicates data synchronously across three Availability Zones, ensuring an RPO of

0

(no data loss). If the primary instance fails, failover to the replica is automatic and typically completes in under

30

seconds. Additionally, the reporting tools can use the cluster reader endpoint to query the replica, offloading read operations from the primary writer instance.

Step-by-Step Solution

Analyze the high availability (HA) and disaster recovery (DR) requirements for RPO and RTO.

The requirements demand an RPO of

0

(no data loss, indicating synchronous replication at the storage or database layer) and an RTO of less than

30

seconds (requiring fast, automated failover).

Establishing these target limits helps filter out database engines or replication methods that rely on asynchronous replication or manual promotion steps.

Evaluate the read-scaling requirement.

The configuration must support offloading reporting queries from the primary write database instance to separate read-only resources.

This rules out configurations like standard RDS Multi-AZ DB instance deployments, which use a passive standby instance that cannot be read from.

Compare Amazon Aurora and Amazon RDS Multi-AZ capability profiles against the constraints.

Amazon Aurora replicates data synchronously across three Availability Zones at the storage layer (RPO of

0

) and can automatically failover to an Aurora Replica in another Availability Zone in less than

30

seconds (RTO <

30

seconds). The Aurora reader endpoint provides built-in load balancing for read scaling.

Aurora matches all RTO, RPO, and read scaling requirements with minimal operational complexity.

Key Concept

High Availability and Read Scaling in Amazon Aurora and Amazon RDS

Question 150Question →

A company hosts a high-traffic e-commerce platform on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). During flash sales, the ASG scales out rapidly. However, newly launched EC2 instances are immediately bombarded with a large volume of requests before they can complete their initialization tasks, such as pre-populating local caches. This causes the instances to become overloaded, fail health checks, and be prematurely terminated by the ASG. Additionally, when the flash sale ends and the ASG scales in, clients with active checkout connections receive HTTP 504 Gateway Timeout errors because their sessions are abruptly severed.

Which combination of actions should a Solutions Architect take to resolve these issues? (Select two.)

Select all that apply

Configure a slow start duration in the Application Load Balancer target group settings.

Increase the deregistration delay timeout in the Application Load Balancer target group settings.

Configure an Amazon Route 53 latency routing policy with health checks to route client traffic directly to individual EC2 instance IP addresses.

Configure stateful Network ACL rules on the application subnets to temporarily block incoming connections to new instances until their cache is populated.

Modify the target group's health check configuration to query a default port such as port 80 instead of the custom application port to prevent early health check failures.

Show answer & explanation

Answer: Configure a slow start duration in the Application Load Balancer target group settings.; Increase the deregistration delay timeout in the Application Load Balancer target group settings.

Answer

Configure a slow start duration in the Application Load Balancer target group settings, and increase the deregistration delay timeout in the Application Load Balancer target group settings.

Configuring a slow start duration in the Application Load Balancer target group settings allows newly launched EC2 instances to receive a linearly increasing share of requests, preventing them from being overwhelmed before completing cache pre-population. Increasing the deregistration delay timeout ensures that during Auto Scaling group scale-in, active checkout connections have sufficient time to complete their transactions before the target is fully deregistered and terminated, avoiding HTTP 504 Gateway Timeout errors.

Step-by-Step Solution

Address the initialization overload issue by enabling slow start.

The Application Load Balancer will linearly ramp up the volume of requests sent to newly registered EC2 instances, giving them time to populate their local database cache before handling full production load.

Newly launched instances require a warm-up period to initialize caches without being overwhelmed by immediate full request volumes.

Address the connection termination issue during scale-in by adjusting the deregistration delay.

The Application Load Balancer will keep existing connections open for the specified duration, allowing active checkout requests to complete before the instances are terminated.

Without a sufficient deregistration delay, active client requests are terminated abruptly when the Auto Scaling group terminates instances during scale-in, causing client-side HTTP 504 errors.

Key Concept

Application Load Balancer Target Group configuration (Slow Start and Deregistration Delay) to manage EC2 instance lifecycle under Auto Scaling events.

Estimated Time:2m 0s

Question 151Question →

A global financial analytics firm hosts a critical risk modeling application on-premises that generates massive datasets. The firm needs to migrate its storage backend to AWS. The architecture must store the generated datasets in a highly durable storage tier that is replicated to a secondary AWS region for disaster recovery (DR). The system must meet a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 10 minutes for accessing the DR datasets. The datasets must be immediately retrievable in the secondary region in the event of a primary region outage. Additionally, the on-premises application servers require low-latency, local cached access to the active datasets. Which storage architecture meets these requirements with the lowest recovery time and operational complexity?

Deploy an Amazon S3 File Gateway on-premises to cache active datasets locally and store the primary data in an Amazon S3 bucket. Enable S3 Versioning and configure S3 Cross-Region Replication (CRR) with S3 Replication Time Control (S3 RTC) to a secondary region. In the destination bucket, use a lifecycle policy to transition objects immediately to the S3 Glacier Instant Retrieval storage class.

Deploy an AWS Storage Gateway Volume Gateway in cached volume mode on-premises. Configure volume snapshots to back up data to Amazon S3 in the primary region, and use S3 Cross-Region Replication to copy snapshots to the secondary region. Use an S3 Lifecycle policy to transition the replicated snapshots to the S3 Glacier Flexible Retrieval storage class, using Standard retrieval during a disaster.

Deploy an Amazon EFS File Gateway on-premises. Configure Amazon EFS Replication to copy data to a secondary region. Set up an Amazon RDS Multi-AZ DB instance in the primary region and create an RDS Read Replica in the secondary region, configuring the replica as the primary automatic failover target for database transaction records.

Deploy an Amazon S3 File Gateway on-premises. Configure S3 Same-Region Replication (SRR) in the primary region, and write a custom AWS Lambda function to copy objects to the secondary region's bucket. Set up the secondary region as a Pilot Light environment, relying on manual service activation to access the data during a failover event.

Show answer & explanation

Answer: Deploy an Amazon S3 File Gateway on-premises to cache active datasets locally and store the primary data in an Amazon S3 bucket. Enable S3 Versioning and configure S3 Cross-Region Replication (CRR) with S3 Replication Time Control (S3 RTC) to a secondary region. In the destination bucket, use a lifecycle policy to transition objects immediately to the S3 Glacier Instant Retrieval storage class.

Answer

The correct architecture uses Amazon S3 File Gateway to maintain an on-premises local cache for low-latency active file access while storing the primary copy in Amazon S3. To meet the 15-minute RPO, S3 Replication Time Control (S3 RTC) is enabled for Cross-Region Replication, which guarantees that 99.9% of objects are copied to the secondary region within 15 minutes. To meet the 10-minute RTO for the DR datasets, the destination bucket uses the S3 Glacier Instant Retrieval storage class, which provides millisecond retrieval speeds at lower storage costs.

Step-by-Step Solution

Address the local low-latency requirement.

Amazon S3 File Gateway provides a local cache for frequently accessed files using standard file protocols (NFS/SMB) while using Amazon S3 as the backend.

This satisfies the requirement for on-premises servers to have low-latency cached access.

Select a replication mechanism that guarantees the 15-minute RPO.

S3 Cross-Region Replication (CRR) with S3 Replication Time Control (S3 RTC) is configured.

S3 RTC guarantees replication of 99.9% of objects within 15 minutes, meeting the 15-minute RPO with a backed SLA.

Ensure the disaster recovery storage class meets the 10-minute RTO cost-effectively.

Objects are transitioned to the S3 Glacier Instant Retrieval storage class in the secondary region.

S3 Glacier Instant Retrieval provides millisecond retrieval times (meeting the 10-minute RTO) for archived data, offering lower storage costs compared to S3 Standard.

Key Concept

Disaster recovery architectures using AWS Storage Gateway, S3 Replication Time Control (RTC), and high-availability storage classes.

Estimated Time:3m 0s

Question 152Question →

A financial services company has deployed a secure three-tier web application. The application tier runs on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application listens on custom TCP port $8443$ . The security team has configured Network ACLs (NACLs) to allow only HTTPS traffic on TCP port $443$ between the ALB subnets and the application subnets. The ALB target group has health checks configured to query TCP port $8443$ . After deployment, the operations team notices that all EC2 instances are repeatedly marked as unhealthy by the target group and subsequently terminated and replaced by the ASG, even though local tests confirm the application process is running and responding on port $8443$ . Which of the following configuration modifications will resolve the health check failures and stabilize the Auto Scaling group?

Update the Network ACLs to allow outbound traffic on TCP port

8443

from the ALB subnets and inbound traffic on TCP port

8443

to the application subnets, while also allowing traffic on ephemeral TCP ports

1024

65535

in both directions to accommodate stateless return communication.

Change the target group health check port configuration to standard TCP port

80

443

, allowing the ALB to perform health checks on standard web ports while client traffic continues to flow to the application on port

8443

Configure the application instances' security groups to be stateless to allow inbound traffic on port

8443

, and modify the Network ACLs to be stateful so they automatically permit the returning ephemeral port traffic from the instances to the ALB.

Configure Amazon Route 53 Latency routing with active-passive failover to redirect client requests directly to a secondary static page, bypass the ALB's health check threshold settings, and configure the ASG to use EC2 health checks instead of ELB health checks.

Show answer & explanation

Answer: Update the Network ACLs to allow outbound traffic on TCP port $8443$ from the ALB subnets and inbound traffic on TCP port $8443$ to the application subnets, while also allowing traffic on ephemeral TCP ports $1024$ - $65535$ in both directions to accommodate stateless return communication.

Answer

Update the Network ACLs to allow outbound traffic on TCP port

8443

from the ALB subnets and inbound traffic on TCP port

8443

to the application subnets, while also allowing traffic on ephemeral TCP ports

1024

65535

in both directions to accommodate stateless return communication.

The correct solution involves modifying the stateless Network ACLs to allow the traffic on port

8443

between the ALB subnets and the application subnets, along with allowing return traffic on the ephemeral port range (

1024

65535

). Because NACLs are stateless, they evaluate traffic in each direction independently, meaning rules must cover both the outbound/inbound request path and the inbound/outbound response path.

Step-by-Step Solution

Analyze the application port and protocol configuration.

The application listens on custom TCP port

8443

, and the ALB target group is configured to run health checks on this same port (

8443

This establishes that traffic from the ALB to the instances for both health checks and standard routing must use port

8443

Examine the Network ACL (NACL) rules currently in place.

The NACLs are currently configured to only allow HTTPS traffic on port

443

between the subnets.

Because NACLs are stateless, they must explicitly allow both the request and response paths for any network connection. Since the traffic between the ALB and the targets is on port

8443

, the current rules block this traffic.

Formulate the required NACL updates.

Inbound rules for application subnets must allow port

8443

from the ALB subnet. Outbound rules for ALB subnets must allow port

8443

to the application subnets. Return traffic must be allowed on ephemeral ports (

1024

65535

) in both directions.

This ensures the ALB can successfully send health check requests and application traffic to the targets on port

8443

and receive the responses back, resolving the health check failure.

Key Concept

Understanding Elastic Load Balancing target group health checks on custom ports and the stateless nature of Network ACLs in an AWS VPC.

Question 153Question →

A financial auditing firm is migrating its document management system to AWS. The application runs on Amazon EC2 instances deployed across multiple Availability Zones in the us-west-2 Region and requires concurrent read and write access to a shared file system. The storage solution must sustain the loss of an Availability Zone without data loss or downtime. Additionally, compliance regulations mandate a cross-region disaster recovery strategy with a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 30 minutes.

Which storage architecture meets these requirements with the least operational overhead?

Create an Amazon Elastic File System (EFS) file system using the One Zone storage class to reduce cost, and configure an AWS Backup plan to perform cross-region copies to an S3 Glacier Flexible Retrieval vault in the secondary region.

Configure an Amazon Elastic Block Store (EBS) gp3 volume with Multi-Attach enabled, mount it to all EC2 instances across the Availability Zones, and configure AWS Backup to copy snapshots to the secondary region every 15 minutes.

Create an Amazon Elastic File System (EFS) using the Standard storage class in the primary region, and configure Amazon EFS Replication to copy data to a destination EFS file system in the secondary region.

Provision an Amazon RDS PostgreSQL database in a Multi-AZ deployment to store the files, set up a cross-region Read Replica in the secondary region, and configure the application to write directly to the replica during a disaster recovery event.

Show answer & explanation

Answer: Create an Amazon Elastic File System (EFS) using the Standard storage class in the primary region, and configure Amazon EFS Replication to copy data to a destination EFS file system in the secondary region.

Answer

The correct solution uses the Amazon EFS Standard storage class, which natively replicates data across multiple Availability Zones to ensure high availability and prevent downtime during an AZ failure. It pairs this with Amazon EFS Replication to automate cross-region synchronization. EFS Replication operates continuously and asynchronously, aligning with the 15-minute RPO compliance requirement, while keeping the destination file system mounted and ready in the secondary region to satisfy the 30-minute RTO.

Step-by-Step Solution

Evaluate the requirement for concurrent access and high availability.

Amazon EFS Standard provides simultaneous read/write access for multiple EC2 instances across different Availability Zones and replicates data across those AZs to survive failures.

Amazon EBS is restricted to a single Availability Zone (even with Multi-Attach), and EFS One Zone does not span multiple AZs.

Address the disaster recovery metrics (RPO and RTO).

Amazon EFS Replication copies data asynchronously to another AWS Region, meeting an RPO of minutes (well under the 15-minute limit) and a low RTO as the secondary file system is already warm.

Using Glacier vaults for backup recovery introduces significant retrieval delays that would violate the 30-minute RTO.

Select the solution that minimizes operational overhead.

EFS Replication is a native, fully-managed feature that automatically replicates data without custom backup scripting or database configurations.

Relational databases like Amazon RDS are structurally inappropriate for direct shared file storage.

Key Concept

Amazon EFS Replication and Multi-AZ Resiliency

Estimated Time:1m 30s

Question 154Question →

A company runs a production application on an Amazon RDS for PostgreSQL database instance. The database currently operates in a single Availability Zone. The Solutions Architect needs to modify the database configuration to ensure high availability with automatic failover in the event of an infrastructure failure or Availability Zone outage. Which configuration change will meet these requirements with the least operational effort?

Deploy an RDS Read Replica in a different Availability Zone

Configure a multi-region Pilot Light database environment using AWS Database Migration Service (DMS)

Modify the database instance to enable a Multi-AZ deployment

Deploy an RDS Read Replica and configure Route 53 Latency routing to manage failover

Show answer & explanation

Answer: Modify the database instance to enable a Multi-AZ deployment

Answer

Modify the database instance to enable a Multi-AZ deployment

Modifying the RDS instance to a Multi-AZ deployment is the correct answer. AWS automatically provisions a standby replica in a different Availability Zone, synchronously replicates data to it, and performs automatic failover in the event of an outage by updating the DNS record of the database endpoint.

Step-by-Step Solution

Identify the primary requirement: high availability with automatic failover for an Amazon RDS database.

Limits the viable options to AWS services that support automatic DNS redirection and failover.

The scenario requires zero manual intervention during an outage.

Evaluate the difference between Multi-AZ deployments and Read Replicas.

Multi-AZ uses synchronous replication with automated failover, while Read Replicas use asynchronous replication for scaling reads.

Promoting a Read Replica requires manual promotion or complex scripting, which does not provide native automatic failover.

Select Multi-AZ deployment as the solution.

Enabling Multi-AZ achieves synchronous replication and automatic failover with the least operational effort.

AWS manages the replication and failover process natively without additional user configuration.

Key Concept

Amazon RDS Multi-AZ deployments for high availability and automatic failover

Question 155Question →

A financial services company runs a critical transactional application backed by an Amazon RDS PostgreSQL DB instance. Currently, the database is deployed in a single Availability Zone (AZ). Due to compliance regulations, the database layer must be redesigned to ensure high availability. The solution must achieve a Recovery Point Objective (RPO) of zero (no data loss) and a Recovery Time Objective (RTO) of under two minutes in the event of an AZ failure. Which database configuration should a solutions architect recommend to meet these requirements?

Modify the existing Amazon RDS DB instance to be a Multi-AZ deployment.

Create an Amazon RDS Read Replica in a different Availability Zone, and configure a custom monitoring script to promote the read replica to primary if the primary instance fails.

Deploy a warm standby Amazon RDS PostgreSQL DB instance in a different AWS Region, and use AWS Database Migration Service (AWS DMS) to continuously replicate data.

Deploy an Amazon RDS Read Replica in a second Availability Zone, and configure Amazon Route 53 latency-based routing to automatically fail over database connection endpoints.

Show answer & explanation

Answer: Modify the existing Amazon RDS DB instance to be a Multi-AZ deployment.

Answer

Modify the existing Amazon RDS DB instance to be a Multi-AZ deployment.

Modifying the existing DB instance to a Multi-AZ deployment matches all criteria. It synchronously replicates database changes to a standby instance in a different Availability Zone, ensuring zero data loss (RPO = 0). If the primary instance fails, Amazon RDS automatically performs a failover by updating the database DNS CNAME record to point to the standby instance, which typically takes between one and two minutes (RTO < 2 minutes).

Step-by-Step Solution

Analyze the requirements for high availability, specifically the RPO (Recovery Point Objective) of zero and RTO (Recovery Time Objective) of under two minutes.

Identified that the replication must be synchronous to ensure no data loss (RPO = 0), and the failover mechanism must be automatic and fast (RTO < 2 minutes).

This sets the baseline criteria to evaluate the available database configurations.

Evaluate the replication type of Amazon RDS options.

Multi-AZ deployments use synchronous replication to a standby instance in a different AZ, whereas Read Replicas use asynchronous replication.

Only synchronous replication can guarantee an RPO of zero (no data loss) during an unexpected primary node failure.

Evaluate the failover mechanisms of the proposed solutions.

Multi-AZ deployments perform automatic DNS failover to the standby replica, typically completing within 60-120 seconds. Promoting a read replica or cross-region warm standby is a manual process or requires complex custom scripting, which increases RTO.

Ensures that the configuration meets the RTO requirement of under two minutes.

Key Concept

Amazon RDS Multi-AZ deployments provide high availability, data redundancy, and automatic failover by utilizing synchronous replication to a standby instance in a different Availability Zone.

Question 156Question →

An enterprise healthcare platform hosts its critical medical imaging application in the `us-east-1` Region. The application runs on Amazon EC2 instances distributed across three Availability Zones (AZs) and requires concurrent, POSIX-compliant read/write access to shared storage for active patient scans. Active scans must be immediately resilient to AZ-level failures. Scans older than $90$ days must be transitioned to a lower-cost tier to optimize costs, but must remain accessible within an emergency retrieval window of under $5$ minutes. Additionally, a disaster recovery (DR) site in the `us-west-2` Region must be maintained using a pilot light strategy. The DR site has a target Recovery Point Objective (RPO) of $15$ minutes and a Recovery Time Objective (RTO) of $10$ minutes. Which storage architecture meets all of these requirements with the lowest operational complexity?

Deploy a Multi-AZ Amazon EFS file system in us-east-1 and configure an EFS Lifecycle policy to transition files to EFS Archive after

90

days. Enable EFS Replication to copy data to a destination EFS file system in us-west-2. Deploy pilot light EC2 instances in us-west-2 that remain stopped until a failover event, at which point they are started and mount the replicated EFS file system.

Deploy a Multi-AZ Amazon EFS file system in us-east-1. Implement a custom script to move files older than

90

days to Amazon S3 Glacier Flexible Retrieval using Standard retrieval. Configure EFS Replication to a destination EFS file system in us-west-2, and maintain stopped EC2 instances in us-west-2 to mount the replica during failover.

Deploy a Multi-AZ Amazon EFS file system in us-east-1 and configure an EFS Lifecycle policy to transition files to EFS Archive after

90

days. Set up AWS Backup to copy EFS snapshots to us-west-2 once daily. Deploy pilot light EC2 instances in us-west-2 that remain stopped, and restore the EFS file system from the daily backup during a failover event.

Deploy a Multi-AZ Amazon EFS file system in us-east-1 and configure an EFS Lifecycle policy to transition files to EFS Archive after

90

days. To implement disaster recovery, configure an Amazon RDS PostgreSQL DB instance with a Read Replica in us-west-2, and use the database replication stream to synchronize EFS mount points and file changes, promoting the replica during failover.

Show answer & explanation

Answer: Deploy a Multi-AZ Amazon EFS file system in us-east-1 and configure an EFS Lifecycle policy to transition files to EFS Archive after $90$ days. Enable EFS Replication to copy data to a destination EFS file system in us-west-2. Deploy pilot light EC2 instances in us-west-2 that remain stopped until a failover event, at which point they are started and mount the replicated EFS file system.

Answer

Deploy a Multi-AZ Amazon EFS file system in us-east-1, configure an EFS Lifecycle policy to transition files to EFS Archive after 90 days, enable EFS Replication to us-west-2, and use stopped EC2 instances in us-west-2 as pilot light recovery targets.

The correct architecture utilizes Multi-AZ Amazon EFS to support concurrent, POSIX-compliant writes across three Availability Zones. Transitioning to EFS Archive via EFS Lifecycle Management ensures cost optimization while preserving sub-second file retrieval speeds (well below the

5

-minute RTO). EFS Replication continuously synchronizes data to a target EFS file system in the destination region, achieving an RPO of minutes (meeting the

15

-minute target). Finally, starting stopped EC2 instances (pilot light strategy) to mount the destination EFS file system can easily be completed in under

10

minutes, meeting the RTO.

Step-by-Step Solution

Select Multi-AZ EFS for us-east-1 storage.

Provides concurrent POSIX-compliant file system access across all three Availability Zones, ensuring immediate resilience to AZ failures.

Meets the requirement for active patient scans to have regional high availability and shared access.

Configure EFS Lifecycle Management to transition files to EFS Archive after 90 days.

Files are automatically moved to a lower-cost tier while maintaining sub-second retrieval times.

Satisfies the regulatory requirement for cost-efficient long-term storage while keeping access times under the 5-minute RTO.

Enable native EFS Replication to a destination EFS file system in us-west-2.

Replicates file modifications asynchronously with an RPO of minutes (typically under 15 minutes).

Satisfies the 15-minute RPO disaster recovery requirement.

Configure stopped EC2 instances in us-west-2 to mount the replicated EFS file system upon startup.

A pilot light disaster recovery target that can be fully active in under 10 minutes.

Satisfies the 10-minute RTO disaster recovery requirement with minimal cost.

Key Concept

Designing a multi-region, resilient storage architecture with EFS Multi-AZ, EFS Archive lifecycle tiering, EFS Replication, and pilot light EC2 compute failover.

Estimated Time:3m 0s

Question 157Question →

An enterprise runs a critical transactional application backed by an Amazon RDS for PostgreSQL database instance in the us-east-1 Region. The database must sustain an Availability Zone outage with zero data loss (RPO = 0) and automatic failover in less than 60 seconds (RTO < 60s). The enterprise also requires a disaster recovery (DR) solution in the us-west-2 Region with an RPO of less than 5 minutes and an RTO of less than 15 minutes. Which two database configuration actions should the solutions architect take to meet these requirements with the least operational overhead?

Select all that apply

Modify the primary database instance to a Multi-AZ DB cluster deployment to support synchronous replication across three Availability Zones and automated failover.

Configure an in-region read replica in another Availability Zone, and create a custom script to automate promotion of the replica if the primary instance becomes unresponsive.

Set up AWS Backup to perform daily database snapshots, copy them to the secondary region, and deploy an AWS CloudFormation template to restore the database in the secondary region during a disaster.

Create an Amazon RDS cross-region read replica in the secondary region to asynchronously replicate data and serve as the promotion target for regional disaster recovery.

Configure Amazon Route 53 latency-based routing to automatically distribute write traffic between the primary instance and the secondary region to achieve active-active database capabilities.

Show answer & explanation

Answer: Modify the primary database instance to a Multi-AZ DB cluster deployment to support synchronous replication across three Availability Zones and automated failover.; Create an Amazon RDS cross-region read replica in the secondary region to asynchronously replicate data and serve as the promotion target for regional disaster recovery.

Answer

Modify the primary database instance to a Multi-AZ DB cluster deployment, and create a cross-region read replica in the secondary region.

To achieve high availability with an RPO of 0 and an RTO of less than 60 seconds, the database must be configured with synchronous replication and automated failover. An Amazon RDS Multi-AZ DB cluster deployment provides synchronous replication across three Availability Zones and failover in under 35 seconds, satisfying the primary region HA goals. For cross-region disaster recovery, an Amazon RDS cross-region read replica replicates data asynchronously with very low replication lag (RPO < 5 minutes) and can be promoted to a primary database in the secondary region in under 15 minutes (RTO < 15 minutes) with minimal administrative overhead.

Step-by-Step Solution

Evaluate the high availability and failover requirements within the primary region.

The requirements demand an RPO of 0 (no data loss) and an RTO of less than 60 seconds.

An Amazon RDS Multi-AZ DB cluster deployment replicates data synchronously across three Availability Zones, ensuring zero data loss (RPO = 0) and provides automated failover within 35 seconds, which satisfies the local high availability goal.

Evaluate the disaster recovery requirements in the secondary region.

The requirements demand an RPO of less than 5 minutes and an RTO of less than 15 minutes.

Creating a cross-region read replica replicates data asynchronously, keeping replication lag under a few seconds (RPO < 5 minutes). The replica can be promoted to a standalone primary database in under 15 minutes (RTO < 15 minutes), meeting the disaster recovery criteria.

Analyze and eliminate alternate database replication and recovery configurations.

Using custom promotion scripts for in-region replicas fails synchronous replication and failover RTO requirements. Re-provisioning from snapshots violates the 15-minute RTO. Route 53 latency routing is not supported for active-active writes on RDS PostgreSQL.

This leaves Multi-AZ DB cluster deployment and a cross-region read replica as the only options that satisfy both primary and secondary region constraints with minimal operational overhead.

Key Concept

Amazon RDS Multi-AZ DB clusters provide synchronous replication across three Availability Zones for zero data loss and automated sub-minute failovers, while cross-region read replicas provide asynchronous replication for multi-region disaster recovery with low replication lag and fast promotion capabilities.

Question 158Question →

A financial auditing firm hosts a document management system on AWS where millions of PDF records are stored in an Amazon S3 bucket. The compliance team mandates a highly resilient storage architecture that protects against a total AWS Region outage. The disaster recovery plan dictates a Recovery Time Objective (RTO) of less than 15 minutes and a Recovery Point Objective (RPO) of under 15 minutes. Which storage strategy should a solutions architect implement to satisfy these requirements?

Configure Amazon S3 Cross-Region Replication (CRR) to replicate objects to a destination S3 bucket in a secondary AWS Region, allowing the application to immediately access the replica bucket during a failover.

Replicate the documents to an Amazon S3 Glacier Flexible Retrieval vault in a secondary AWS Region, and use standard retrieval to restore the files to a standard S3 bucket when a primary Region outage is declared.

Set up an Amazon RDS Multi-AZ DB instance and configure Amazon S3 lifecycle policies to continuously migrate and sync the PDF objects directly into Amazon RDS Read Replicas in a secondary Region for real-time failover.

Establish a Pilot Light disaster recovery architecture by keeping a duplicate S3 bucket and replication agents in a secondary Region turned off, manually activating replication and syncing data only after a failure occurs.

Show answer & explanation

Answer: Configure Amazon S3 Cross-Region Replication (CRR) to replicate objects to a destination S3 bucket in a secondary AWS Region, allowing the application to immediately access the replica bucket during a failover.

Answer

Amazon S3 Cross-Region Replication (CRR) replicates objects automatically and asynchronously to another AWS Region. This provides a low RPO (usually within seconds/minutes) and keeps the data in a standard S3 bucket, which allows immediate read access during a regional disaster (meeting the 15-minute RTO).

Step-by-Step Solution

Analyze the disaster recovery constraints, specifically the 15-minute Recovery Time Objective (RTO) and 15-minute Recovery Point Objective (RPO) for object storage protection against a region outage.

Identified that the storage must be replicated across regions automatically (asynchronous replication) and the recovery destination must allow immediate read access without significant retrieval delays.

This narrows down the potential storage classes and replication modes to those that support automatic replication and immediate access.

Evaluate the replication mechanism of Amazon S3 Cross-Region Replication (CRR) against the constraints.

CRR continuously replicates new S3 objects to another region automatically (meeting low RPO) and stores them in a readable S3 bucket (allowing immediate access during a regional failover, meeting the 15-minute RTO).

This matches the objective of resilient and highly available cross-region storage.

Key Concept

Cross-Region Replication (CRR) provides automatic, asynchronous copying of S3 objects across AWS Regions to meet low RTO and RPO requirements for disaster recovery.

Question 159Question →

A healthcare provider is deploying a medical imaging application on Amazon EC2 instances across multiple Availability Zones in a primary AWS region. The application requires a shared file system that supports POSIX-compliant file operations and allows concurrent read and write access from all EC2 instances. Additionally, the provider requires a disaster recovery strategy to replicate this shared storage to a secondary AWS region with a Recovery Point Objective (RPO) of less than 15 minutes. Which combination of storage configurations will meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon Elastic File System (Amazon EFS) file system in the primary region and mount it on the EC2 instances using EFS mount targets in each Availability Zone.

Enable Amazon EFS Replication to replicate the file system to a destination EFS file system in the secondary AWS region.

Provision Amazon EBS gp3 volumes with Multi-Attach enabled in the primary region, and use Amazon Data Lifecycle Manager (DLM) to replicate snapshots to the secondary region every 15 minutes.

Store the images in an Amazon S3 Glacier Flexible Retrieval vault and mount the vault directly to the EC2 instances across multiple Availability Zones.

Deploy an Amazon RDS Multi-AZ DB instance and configure cross-region read replicas to serve as the shared file storage.

Show answer & explanation

Answer: Create an Amazon Elastic File System (Amazon EFS) file system in the primary region and mount it on the EC2 instances using EFS mount targets in each Availability Zone.; Enable Amazon EFS Replication to replicate the file system to a destination EFS file system in the secondary AWS region.

Answer

The correct configuration is to create an Amazon EFS file system with mount targets in each Availability Zone in the primary region, and then configure Amazon EFS Replication to replicate file system data to a destination EFS file system in the secondary AWS region.

Creating an Amazon EFS file system in the primary region provides a scalable, highly available shared storage layer that can be concurrently mounted by EC2 instances across different Availability Zones. Configuring EFS Replication to a destination file system in the secondary region ensures automated cross-region replication that aligns with an RPO of less than 15 minutes.

Step-by-Step Solution

Identify the file sharing and access requirements for the EC2 instances.

The application requires concurrent read and write access to a shared POSIX-compliant file system across multiple Availability Zones.

This points to Amazon EFS as the appropriate storage service, since standard block storage (Amazon EBS) does not support multi-AZ sharing, and object storage (Amazon S3) is not POSIX-compliant.

Select the cross-region disaster recovery mechanism that meets the RPO requirement.

The solution must replicate storage to a secondary region with an RPO of less than 15 minutes.

Amazon EFS Replication satisfies this by continuously replicating file system modifications to a destination EFS file system in the secondary region with a typical RPO of minutes.

Key Concept

Cross-region disaster recovery and high availability for shared file systems using Amazon EFS and EFS Replication.

Estimated Time:2m 0s

Question 160Question →

A company is designing a highly resilient storage solution on AWS for its critical media assets. The assets must be protected against accidental deletion, and the architecture must ensure the assets are replicated to a secondary AWS Region to support a disaster recovery plan with a Recovery Time Objective (RTO) of less than 15 minutes. Which two configurations should a solutions architect implement to meet these requirements?

Select all that apply

Configure Amazon S3 Cross-Region Replication (CRR) to replicate objects to a bucket in the secondary AWS Region.

Store the assets in Amazon S3 Glacier Flexible Retrieval using standard retrieval options to achieve cross-region disaster recovery.

Enable Amazon S3 Versioning on the source and destination buckets.

Configure Amazon RDS Read Replicas in the secondary AWS Region to handle automatic write failover for the media storage.

Implement a Pilot Light recovery model with active, running EC2 instances in the secondary region to guarantee instant storage failover.

Show answer & explanation

Answer: Configure Amazon S3 Cross-Region Replication (CRR) to replicate objects to a bucket in the secondary AWS Region.; Enable Amazon S3 Versioning on the source and destination buckets.

Answer

Configure Amazon S3 Cross-Region Replication (CRR) to replicate objects to a bucket in the secondary AWS Region, and enable Amazon S3 Versioning on the source and destination buckets.

To satisfy both requirements, the solutions architect must configure Amazon S3 Cross-Region Replication (CRR) and enable Amazon S3 Versioning. Versioning ensures that any deleted or overwritten files can be restored, while CRR automatically replicates the files to another AWS Region. Because the files are already copied, they are immediately accessible, keeping the Recovery Time Objective (RTO) well below 15 minutes.

Step-by-Step Solution

Enable versioning on the S3 buckets.

S3 Versioning is active, protecting objects from being permanently deleted or overwritten accidentally by keeping historical versions of each object.

This directly satisfies the requirement to protect assets against accidental deletion.

Configure Cross-Region Replication (CRR) on the source bucket.

Automatic and asynchronous replication of newly uploaded media assets to the destination bucket in the secondary AWS Region is established.

This satisfies the cross-region disaster recovery requirement while maintaining low RTO because the files are pre-replicated and immediately accessible in the target region.

Key Concept

Designing highly available, durable, and cross-region resilient object storage with Amazon S3 Versioning and Cross-Region Replication (CRR).

PreviousPage 8 / 20Next

Design Resilient Architectures

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