Design Resilient Architectures

382 questions

Question 281Question

A company runs a web application on Amazon EC2 instances within an Auto Scaling group behind an Application Load Balancer (ALB). The application listens on TCP port 8080. After a new deployment, the ALB marks all instances as unhealthy, causing the Auto Scaling group to repeatedly terminate and launch new instances. Which two actions should a solutions architect take to resolve this issue? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the health check port in the Application Load Balancer (ALB) target group to use port 8080 or the traffic port.; Update the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB.

Answer

Configure the health check port in the Application Load Balancer target group to use port 8080 or the traffic port, and update the security group of the EC2 instances to allow inbound traffic on port 8080 from the security group of the ALB.
The correct options are configuring the ALB target group health check port to 8080 and updating the EC2 security group to allow inbound traffic on port 8080 from the ALB. This aligns the load balancer's health check queries with the actual port the application listens on and allows the security group to permit that traffic.

Step-by-Step Solution

1
Identify the application port configuration.
The web application is configured to run on TCP port 8080.
Health checks must target the port where the application is listening.
2
Align target group health check settings.
Configure the ALB target group health check to query port 8080.
Using the default port 80 results in health check failures because nothing is listening on port 80.
3
Configure Security Groups for health check and user traffic.
Allow inbound TCP traffic on port 8080 in the EC2 instance security group, sourcing from the ALB security group.
The ALB must have network access to query the application port (8080) on the target instances.

Key Concept

Auto Scaling and Application Load Balancer Target Group health checks require aligning the target group health check port and security group permissions with the application port.
Question 282Question

A company is designing a high-throughput financial transaction processing application on AWS. The application must process incoming transactions in the exact order they are received. Transactions are ingested via Amazon API Gateway and must be decoupled before being processed by a fleet of microservices running on Amazon Elastic Container Service (Amazon ECS). Additionally, an independent compliance microservice must receive a copy of every transaction for near real-time auditing and archiving, although the compliance service itself does not require strict ordering. Which combination of steps should a solutions architect take to meet these requirements with the least operational overhead? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Publish incoming transactions from Amazon API Gateway to an Amazon SNS FIFO topic.; Create two Amazon SQS FIFO queues: one for the transaction processing backend and one for the compliance microservice. Subscribe both queues to the SNS FIFO topic.

Answer

Publish incoming transactions from Amazon API Gateway to an Amazon SNS FIFO topic, and create two Amazon SQS FIFO queues (one for the transaction processing backend and one for the compliance microservice) subscribed to the SNS FIFO topic.
To process transactions in strict order with a decoupled, fan-out architecture, the ingestion must use an Amazon SNS FIFO topic. Because Amazon SNS FIFO topics strictly limit subscriber endpoints to Amazon SQS FIFO queues, the compliance microservice must also use an SQS FIFO queue despite not requiring strict ordering itself. This design ensures end-to-end message ordering, deduplication, and successful fan-out delivery.

Step-by-Step Solution

1
Analyze the ordering requirements for the transaction processing backend.
Transactions must be processed in the exact order they are received, requiring end-to-end FIFO (First-In-First-Out) ordering.
This establishes that both the ingestion/fan-out layer (SNS) and the queueing layer (SQS) for the transaction backend must support FIFO semantics.
2
Determine the decoupling and fan-out mechanism.
An Amazon SNS FIFO topic is required to publish and fan out the messages while preserving strict ordering.
Standard SNS topics do not guarantee message ordering, which would break the transactional ordering requirement before messages reach the queues.
3
Evaluate the subscription constraints for Amazon SNS FIFO topics.
SNS FIFO topics only support Amazon SQS FIFO queues as subscriber endpoints.
Because of this native AWS restriction, any microservice subscribing to the SNS FIFO topic—including the compliance service—must use an SQS FIFO queue, regardless of whether that specific service needs ordering.

Key Concept

End-to-end FIFO ordering in event-driven systems using Amazon SNS FIFO and Amazon SQS FIFO integration rules.
Estimated Time:3m 0s
Question 283Question

A solutions architect is troubleshooting a microservices application deployed on AWS. The application consists of a fleet of Amazon EC2 instances in an Auto Scaling group (ASG) residing in private subnets. The ASG is registered with a target group of an Application Load Balancer (ALB) located in public subnets. The application is configured to listen on TCP port 8443, and the target group is configured with a target port of 8443. The health check is set to use the `traffic-port` (TCP port 8443) with the path `/healthz`.

To secure the network traffic, the following configurations are applied:
1. The security group associated with the EC2 instances allows inbound TCP traffic on port 8443 from the security group of the ALB.
2. The custom Network ACL (NACL) for the private subnets allows inbound TCP traffic on port 8443 from the public subnet CIDR block.
3. The custom NACL for the private subnets allows outbound TCP traffic on port 8443 to the public subnet CIDR block.

The application is running correctly on the EC2 instances, and querying the `/healthz` endpoint locally on the instances returns a `200 OK` status. However, the ALB marks all instances in the target group as unhealthy, and the ASG is continuously terminating and replacing the instances.

Which of the following modifications is required to resolve this issue and allow the ALB to successfully perform health checks?

Show answer & explanation

Answer: Modify the private subnet outbound Network ACL (NACL) rule to allow outbound TCP traffic on ephemeral ports (1024-65535) to the public subnet CIDR block.

Answer

Modify the private subnet outbound Network ACL (NACL) rule to allow outbound TCP traffic on ephemeral ports (1024-65535) to the public subnet CIDR block.
The Application Load Balancer (ALB) initiates connection requests using ephemeral ports (1024-65535) to the target port (8443) on the EC2 instances. Because Network ACLs (NACLs) are stateless, return traffic must be explicitly allowed. Allowing outbound TCP traffic on ephemeral ports (1024-65535) to the public subnet CIDR block allows the EC2 instances to respond to the ALB's requests. Since the return traffic's destination port is the ALB's ephemeral port, this outbound rule enables the ALB to receive the health check response and mark the instances as healthy.

Step-by-Step Solution

1
Analyze the load balancing and routing path between the Application Load Balancer (ALB) in the public subnet and the EC2 instances in the private subnet.
The path involves stateless Network ACLs (NACLs) at the subnet boundaries and stateful Security Groups at the instance boundary.
Understanding the stateful versus stateless nature of these filters is key to identifying why traffic might be blocked in one direction.
2
Determine how connections are established by the ALB to the targets.
The ALB initiates a TCP connection from an ephemeral source port (1024-65535) to the destination target port (8443) on the EC2 instances.
This establishes the source and destination ports for both the request and the response packets.
3
Examine the stateless custom Network ACL (NACL) rules applied to the private subnets.
The inbound rule allows TCP traffic on destination port 8443, which lets the ALB's health check request reach the instances. However, the outbound rule only allows traffic with a destination port of 8443.
Because NACLs are stateless, return traffic is not tracked. The response packet from the EC2 instance is sent from source port 8443 back to the ALB's ephemeral destination port. Because the outbound NACL does not allow outbound traffic to ephemeral ports (1024-65535), the response is dropped.
4
Identify the required rule modification to permit the return traffic.
Add an outbound NACL rule for the private subnets allowing TCP traffic on destination ports 1024-65535 to the public subnet CIDR block.
This permits the return TCP packets to reach the ALB, completing the health check handshake.

Key Concept

Stateless Network ACLs require explicit outbound rules for return traffic using ephemeral client ports, unlike stateful security groups which track connection states automatically.
Estimated Time:3m 0s
Question 284Question

A company hosts a critical web application on Amazon EC2 instances behind an Application Load Balancer (ALB) in the us-east-1 Region. The company wants to implement an active-passive disaster recovery (DR) strategy using a warm standby environment in the us-west-2 Region. The solution must automatically route user traffic to the secondary region with minimal downtime if the primary region's application becomes unavailable. Which two configuration steps must a solutions architect take to meet these requirements? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Configure a Route 53 failover alias record for the apex domain pointing to the primary Application Load Balancer, set the record type as Primary, and enable Evaluate Target Health.; Configure a Route 53 failover alias record for the apex domain pointing to the secondary Application Load Balancer, set the record type as Secondary, and enable Evaluate Target Health.

Answer

Configure primary and secondary Route 53 failover alias records pointing to the respective Application Load Balancers, ensuring Evaluate Target Health is enabled for both.
The correct options state that we must configure a Route 53 failover alias record pointing to the primary Application Load Balancer as 'Primary', and another failover alias record pointing to the secondary Application Load Balancer as 'Secondary', both with 'Evaluate Target Health' enabled. This setup creates a fully automated active-passive DNS failover configuration.

Step-by-Step Solution

1
Analyze the disaster recovery strategy requirements.
Identify that an active-passive failover configuration is needed for the apex domain pointing to Application Load Balancers in two different regions.
This determines that Route 53 failover routing policies are the correct mechanism to automatically redirect traffic.
2
Configure the primary Route 53 record.
Create a failover alias record pointing to the primary ALB in us-east-1, mark it as Primary, and enable Evaluate Target Health.
This allows Route 53 to monitor the health of the primary ALB using its target health metrics and determine when to fail over.
3
Configure the secondary Route 53 record.
Create a failover alias record pointing to the secondary ALB in us-west-2, mark it as Secondary, and enable Evaluate Target Health.
This provides a backup endpoint for Route 53 to route traffic to once the primary endpoint is determined to be unhealthy.

Key Concept

Route 53 Failover Routing Policy allows you to configure active-passive failover configurations. Using alias records with Evaluate Target Health enables automatic redirection without the need for manual DNS updates.
Question 285Question

A company hosts a containerized web application on Amazon EC2 instances within a private subnet. The instances are managed by an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB). The application listens on custom TCP port 80808080. The ALB's target group is configured to route traffic to port 80808080, but its health check is configured to use the default HTTP port 8080. As a result, all newly launched EC2 instances fail the ALB health check and are terminated by the ASG.

The security group assigned to the EC2 instances allows inbound TCP traffic on port 80808080 from the ALB security group, and allows all outbound traffic. The private subnet's Network ACL allows inbound traffic on port 80808080 and port 8080, but its outbound rule only allows traffic to destination ports 8080 and 443443 to allow for package updates.

Which two actions should a solutions architect take to resolve the health check failures and allow the instances to receive application traffic? (Select two.)

Select all that apply

Show answer & explanation

Answer: Modify the target group health check settings to perform health checks on port 80808080 instead of the default port.; Update the outbound Network ACL rules of the private subnet to allow traffic to ephemeral ports 1024655351024-65535.

Answer

The correct actions are to modify the target group health check settings to perform health checks on port 80808080 instead of the default port, and to update the outbound Network ACL rules of the private subnet to allow traffic to ephemeral ports 1024655351024-65535.
The correct actions resolve the two root issues preventing successful health checks. First, correcting the health check port ensures that the load balancer queries the active application service running on port 80808080 instead of the default port 8080. Second, opening the outbound Network ACL to ephemeral ports allows the stateless firewall to permit the return packets of the TCP connections initiated by the load balancer nodes.

Step-by-Step Solution

1
Analyze why the health check fails on port 8080.
The application only listens on port 80808080, so requests sent to port 8080 receive no response, marking the targets as unhealthy.
To identify the mismatch between where the application is listening and where the load balancer is sending health checks.
2
Analyze the stateless Network ACL behavior on return traffic.
Although inbound traffic on port 80808080 is allowed, return traffic from the EC2 instances back to the Application Load Balancer's ephemeral client ports is blocked by the restricted outbound Network ACL.
To understand why TCP handshakes fail even if the health check port is corrected.
3
Determine the necessary corrections to allow traffic flow.
Modify the health check settings to target port 80808080 and update the outbound Network ACL rules to allow TCP traffic to ephemeral ports 1024655351024-65535.
To align the health check destination with the active application port and permit stateless return packets to reach the load balancer.

Key Concept

Ensuring health check port alignment and configuring stateless Network ACLs for ephemeral port return traffic in a load-balanced Auto Scaling architecture.
Question 286Question

A solutions architect is configuring an Application Load Balancer (ALB) and an Auto Scaling group to host a stateful web application. The application requires user session state to be maintained on the specific Amazon EC2 instance where the session was established. Which of the following configurations should the solutions architect implement to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Enable sticky sessions (session affinity) on the Application Load Balancer target group.; Configure the target group to use duration-based cookies or application-based cookies.

Answer

To maintain user session state on specific instances, enable sticky sessions (session affinity) on the Application Load Balancer target group and configure the target group to use duration-based or application-based cookies.
To maintain user session state on specific EC2 instances, the solutions architect must enable sticky sessions (session affinity) on the target group associated with the Application Load Balancer. Sticky sessions use cookies to bind a client session to a specific instance. Consequently, configuring the target group to use duration-based or application-based cookies is also required to manage the cookie lifecycle and affinity behavior.

Step-by-Step Solution

1
Analyze the application requirements.
The application is stateful and stores session data in instance memory, requiring client requests to be sent to the same EC2 instance.
Identify the need for session stickiness (affinity) at the load balancer level.
2
Select the appropriate load balancer configuration option.
Enabling sticky sessions on the target group forces the Application Load Balancer to route requests from the same user to the same target instance.
Provide the core routing capability to maintain session affinity.
3
Define the cookie mechanism for tracking session affinity.
Choose either duration-based cookies or application-based cookies under target group attributes.
Provide the client-side mechanism (cookies) that the load balancer uses to route the client back to the correct instance.

Key Concept

Session stickiness (session affinity) allows an Application Load Balancer to bind a user's session to a specific target instance by using cookies.
Estimated Time:1m 0s
Question 287Question

A company is hosting a specialized transaction processing application on a fleet of Amazon EC2 instances managed by an Auto Scaling group (ASG). The instances are registered with a target group for an Application Load Balancer (ALB). The application receives transaction requests on TCP port 9443, and the target group is configured to route traffic to port 9443 with the health check port set to 'traffic-port'. To verify application health, the load balancer needs to query an administrative status API endpoint that runs on port 8081 of the instances. Currently, the ALB is marking all instances as unhealthy, causing the ASG to continuously terminate and launch new instances. Which action should the solutions architect take to resolve this issue?

Show answer & explanation

Answer: Modify the target group configuration to explicitly set the health check port to 8081.

Answer

Modify the target group configuration to explicitly set the health check port to 8081.
The target group is configured to route user traffic to the application's transaction port (9443). However, because the application's health status API runs on a separate administration port (8081), the solutions architect must override the default health check port settings from 'traffic-port' to port 8081. This ensures that the Application Load Balancer (ALB) sends health probes to the correct port while maintaining transaction routing to port 9443.

Step-by-Step Solution

1
Analyze the ports used by the application and the health check configuration.
The application listens on port 9443 for transactions, while the health check status endpoint runs on port 8081.
Understanding the separation of transaction traffic and administrative health check endpoints is necessary to determine the correct port mapping.
2
Evaluate the behavior of the default 'traffic-port' setting in the ALB target group.
By default, 'traffic-port' tells the ALB to perform health checks on the same port it routes traffic to, which is port 9443. Since the status API is on port 8081, the health check fails.
This explains why the ALB is currently marking the instances as unhealthy.
3
Identify the correct configuration update required to separate routing port from health check port.
Specify port 8081 under the health check settings of the target group.
This allows the ALB to route production traffic to port 9443 while sending health checks to port 8081.

Key Concept

ELB target group health checks can be configured to use a custom port different from the traffic port.
Estimated Time:2m 0s
Question 288Question

A company runs a high-traffic web application on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application handles long-lived WebSocket connections and standard HTTP requests. During scale-in events, users complain that their active WebSocket sessions are abruptly terminated. Additionally, during sudden traffic surges, the ASG fails to scale out quickly enough because the default scaling metric (average CPU utilization) does not immediately reflect the sudden increase in connection volume. Which two actions should the solutions architect take to resolve these issues? (Select two.)

Select all that apply

Show answer & explanation

Answer: Increase the deregistration delay (connection draining) timeout value for the Application Load Balancer target group to allow active connections to persist during scale-in.; Configure a target tracking scaling policy for the Auto Scaling group using the Application Load Balancer request count per target metric.

Answer

The correct actions are to increase the deregistration delay timeout for the target group and to configure a target tracking scaling policy for the Auto Scaling group using the Application Load Balancer request count per target metric.
To prevent active WebSocket connections from being terminated abruptly when an EC2 instance is being decommissioned during scale-in, the deregistration delay (connection draining) timeout on the target group should be increased. This allows the load balancer to keep existing connections open until they complete or the timeout expires. To address the slow scaling issue, using the Application Load Balancer request count per target metric in a target tracking policy provides a direct, immediate indicator of request volume changes, allowing the Auto Scaling group to scale out faster than it would when relying solely on CPU utilization metrics, which have a delayed response to sudden network spikes.

Step-by-Step Solution

1
Analyze the connection termination issue during scale-in events.
Identify that the default deregistration delay (connection draining) timeout is too short for long-lived WebSocket connections, causing them to be terminated when instances are decommissioned.
Increasing this timeout allows the load balancer to drain active connections gracefully.
2
Analyze the slow scale-out issue during sudden traffic spikes.
Determine that CPU utilization is a lagging indicator for connection-heavy or network-bound sudden spikes, whereas Application Load Balancer request count per target responds immediately to traffic increases.
Configuring a target tracking policy based on target request count allows the ASG to scale out rapidly as request volume spikes.

Key Concept

Graceful connection management via ELB connection draining and rapid scaling using load balancer metrics.
Question 289Question

A logistics company is designing an event-driven telemetry ingestion system to track delivery vehicles globally. The system must process location updates in the exact chronological order they are generated for each individual vehicle to ensure accurate routing history. Three downstream consumer applications—a live customer map, a fleet analytics engine, and an archival database—must independently process the same location stream in real time. The ingestion layer must scale automatically to handle sudden spikes in traffic during peak delivery hours. Which architecture meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Deploy an Amazon Kinesis Data Stream in On-Demand capacity mode, using the vehicle identifier as the partition key. Configure each downstream application as a Kinesis consumer utilizing enhanced fan-out.

Answer

The architecture that uses Amazon Kinesis Data Streams in On-Demand capacity mode with vehicle identifier partition keys and enhanced fan-out consumers.
The correct solution uses an Amazon Kinesis Data Stream in On-Demand capacity mode with the vehicle identifier as the partition key. This partition key routing ensures all coordinates for a specific vehicle are sent to the same shard, preserving chronological ordering. Configuring each downstream application as an independent Kinesis consumer with enhanced fan-out allows parallel, non-blocking real-time processing of the same stream. On-Demand mode eliminates the operational overhead of manually monitoring and scaling shards during traffic spikes.

Step-by-Step Solution

1
Analyze the ordering requirement.
Identify that location updates must be ordered chronologically per vehicle.
To ensure that routing history remains accurate, sequential consistency must be preserved using partition keys in Kinesis or message groups in FIFO systems.
2
Analyze the multi-consumer and real-time fan-out requirements.
Identify that multiple downstream consumers need to read the same event stream independently in real time.
Kinesis streams support multiple independent consumers natively, and enhanced fan-out provides dedicated read throughput to prevent lag. In contrast, standard queue systems are designed for competing consumers where each message is processed once.
3
Evaluate the scaling and operational overhead requirements.
Select On-Demand capacity mode for Kinesis Data Streams.
On-Demand mode automatically scales throughput up and down to handle unpredictable spikes in traffic without manual intervention or custom monitoring logic.

Key Concept

Real-time event streaming with ordered delivery and independent fan-out consumer scaling using Amazon Kinesis Data Streams.
Question 290Question

An e-commerce company hosts its critical shopping cart and order processing application on AWS. The application runs on Amazon ECS tasks using the AWS Fargate launch type in the us-east-1 Region, backed by an Amazon Aurora PostgreSQL Multi-AZ DB cluster. The company needs to design a disaster recovery (DR) solution in the us-west-2 Region. The DR solution must support a Recovery Point Objective (RPO) of 5 minutes and a Recovery Time Objective (RTO) of 15 minutes. The company wants to minimize costs during normal operations while ensuring the compute capacity can scale up rapidly during a failover. Which combination of actions should the Solutions Architect take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Set up an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2.; Deploy a Warm Standby compute environment by maintaining a scaled-down ECS service in us-west-2. Configure an Application Load Balancer in us-west-2, and set up Amazon Route 53 failover routing with health checks pointing to both regions.

Answer

To meet the RPO of 5 minutes and RTO of 15 minutes while minimizing cost, the Solutions Architect should set up an Amazon Aurora Global Database with a secondary cluster in us-west-2, and deploy a Warm Standby compute environment by maintaining a scaled-down ECS service with Route 53 failover routing and health checks in us-west-2.
The correct architecture combines Amazon Aurora Global Database for the data layer and a Warm Standby compute environment for the application layer. Aurora Global Database provides sub-second replication to the secondary region, satisfying the 5-minute RPO, and supports promotion of the secondary cluster to primary in less than a minute, supporting the 15-minute RTO. For the compute layer, keeping a scaled-down ECS service running in the secondary region ensures that network paths, load balancers, and tasks are warm and ready to scale up rapidly using ECS Auto Scaling. Configuring Route 53 failover routing with health checks ensures that user traffic is automatically and dynamically redirected to the secondary region if the primary region's Application Load Balancer becomes unhealthy.

Step-by-Step Solution

1
Evaluate the database replication strategy to satisfy the 5-minute Recovery Point Objective (RPO).
Identify that Amazon Aurora Global Database uses storage-level, physical replication to copy data asynchronously to a secondary region with latency of less than one second, far exceeding the RPO requirement.
Choosing the correct database replication method ensures minimal data loss and compliant RPO.
2
Evaluate the database failover strategy to satisfy the 15-minute Recovery Time Objective (RTO).
Confirm that an Aurora Global Database secondary cluster can be promoted to a standalone read-write cluster in under a minute, meeting the RTO requirement.
Rapid database promotion is critical for minimizing overall application downtime during a regional outage.
3
Determine the optimal compute deployment model to balance the 15-minute RTO and cost-minimization goals.
Select a Warm Standby compute model where a scaled-down ECS service is continuously running in the secondary region. This avoids the long startup latencies of a Pilot Light setup (which starts with 0 tasks) while costing less than an Active-Active deployment.
Maintaining active but scaled-down compute capacity allows tasks to scale up rapidly using ECS Auto Scaling and accept traffic quickly.
4
Establish the DNS routing and health check policy to automate regional failover.
Configure Amazon Route 53 failover routing with health checks targeting both Application Load Balancers. If the us-east-1 load balancer fails, Route 53 automatically redirects client traffic to the us-west-2 load balancer.
Automating traffic redirection based on endpoint health ensures seamless switchover and minimal manual intervention.

Key Concept

Disaster recovery planning using a combination of Aurora Global Database and Warm Standby compute strategies to achieve low RTO and RPO targets cost-effectively.
Question 291Question

An analytics company hosts a distributed data ingestion service on Amazon EC2 instances inside an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ingestion service processes incoming data on port 5001, while a separate health status daemon runs on port 9001. The ASG is currently configured with the default EC2 health check type. During a recent event, the ingestion service crashed on several instances, but the ASG did not terminate them, resulting in lost data. To resolve this, a solutions architect updated the configuration, but the ASG began aggressively terminating newly launched instances before they could complete their 10-minute cache warming process.

Which two actions should the solutions architect take to resolve these issues? (Select two.)

Select all that apply

Show answer & explanation

Answer: Change the Auto Scaling group health check type from EC2 to ELB.; Increase the Auto Scaling group health check grace period to at least 600 seconds.

Answer

Change the Auto Scaling group health check type from EC2 to ELB, and increase the Auto Scaling group health check grace period to at least 600 seconds.
Changing the Auto Scaling group health check type from EC2 to ELB ensures that the ASG monitors application-level availability via the Application Load Balancer target group. In addition, increasing the health check grace period to at least 600 seconds prevents the ASG from prematurely terminating new instances while they are performing their 10-minute cache warming process.

Step-by-Step Solution

1
Analyze why crashed instances are not being replaced.
The Auto Scaling group is configured with the EC2 health check type, which only monitors hypervisor-level instance status. If the application service crashes but the OS remains healthy, the instance is marked healthy.
To ensure instances with crashed application services are replaced, we must link the ASG to the Application Load Balancer's target group health checks by changing the health check type to ELB.
2
Analyze why new instances are being terminated immediately after launching.
When the health check type is changed to ELB, the ASG begins monitoring the ALB's health checks immediately or after the grace period. Because the cache warming process takes 10 minutes (600 seconds) to complete, the instance fails health checks initially and is terminated prematurely by the ASG.
Increasing the health check grace period to at least 600 seconds prevents the ASG from evaluating the health status of new instances until they have completed initialization.
3
Ensure the target group health check port is correctly configured.
The target group health checks must query the health status daemon on port 9001 rather than the traffic port (5001) to accurately assess the node status.
Using the traffic port would result in health check failures, causing all instances to be marked unhealthy.

Key Concept

Auto Scaling Group integration with Elastic Load Balancing health checks and health check grace periods
Question 292Question

A solutions architect has configured an Application Load Balancer (ALB) to distribute traffic to a fleet of Amazon EC2 instances. The web application runs on port 80 on the EC2 instances. The security group associated with the EC2 instances is configured to allow inbound traffic on port 80 from the ALB security group. However, the ALB is marking all EC2 instances as unhealthy. Which of the following is the most likely cause of this issue?

Show answer & explanation

Answer: The Network ACL associated with the EC2 instance subnets is blocking the traffic.

Answer

The Network ACL associated with the EC2 instance subnets is blocking the traffic.
The Network ACL associated with the EC2 instance subnets is blocking the traffic. Because Network ACLs are stateless, they evaluate inbound and outbound traffic independently. Even if a stateful security group allows the inbound health check, a stateless Network ACL that does not allow inbound traffic on port 80 or outbound return traffic on ephemeral ports (typically 1024-65535) will block the health check requests, causing the Application Load Balancer to mark the instances as unhealthy.

Step-by-Step Solution

1
Analyze the stateful vs. stateless nature of the network components.
Security groups are stateful, meaning return traffic is allowed automatically. Network ACLs are stateless, meaning return traffic must be explicitly allowed.
This helps identify why traffic might be blocked outbound even if inbound security groups are correctly configured.
2
Evaluate the health check port configuration.
The application listens on port 80, and the health check queries port 80. This is a correct match, ruling out port mismatch issues.
Verifying that the target group configuration aligns with the application port rules out target group health check port mismatches.
3
Determine if DNS routing affects internal load balancer health checks.
Route 53 latency routing controls client-to-ALB routing, not ALB-to-EC2 target communication.
This rules out DNS routing policies as a cause of internal target health check failures.

Key Concept

Stateless Network ACLs vs. Stateful Security Groups in ELB Health Checks
Estimated Time:50s
Question 293Question

A retail company hosts its core ordering application on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application runs on a custom port 8085. The ALB listener is configured to accept HTTPS traffic on port 443 and forward it to a target group containing the EC2 instances on port 8085. To meet strict security requirements, the EC2 security group is restricted to allow inbound TCP traffic on port 8085 only from the ALB security group. However, after a new deployment, the target group health checks fail, and the ASG repeatedly terminates and replaces the instances.

Which action should the Solutions Architect take to resolve the issue and ensure the instances pass health checks while maintaining the current security posture?

Show answer & explanation

Answer: Update the target group health check configuration to use the traffic-port (port 8085) for health checks.

Answer

Update the target group health check configuration to use the traffic-port (port 8085) for health checks.
The application runs on port 8085, and the EC2 instances' security group only allows inbound traffic on port 8085 from the Application Load Balancer (ALB). By default, target group health checks are sent to the default port (typically port 80) unless customized. Updating the target group health check configuration to use the traffic-port (port 8085) ensures that health check requests are sent to the port where the application is listening and where traffic is permitted by the security group.

Step-by-Step Solution

1
Analyze the port mappings and security group rules.
The application listens on port 8085. The security group on the EC2 instances restricts inbound traffic to port 8085 from the Application Load Balancer (ALB) security group.
This establishes that port 8085 is the only valid port for application traffic and health checks under the current security posture.
2
Identify why the target group health checks are failing.
By default, target groups perform health checks on the default port (typically port 80) unless overridden. Since port 80 is blocked by the security group and has no service listening, health checks fail.
Pinpointing the port mismatch clarifies why the load balancer marks healthy instances as unhealthy.
3
Select the resolution that resolves the port mismatch without introducing security vulnerabilities.
Configure the target group to perform health checks on the traffic-port (port 8085).
This ensures the load balancer queries the correct active application port, aligned with existing security group rules.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) Target Group Health Check Port configuration
Question 294Question

A gaming company hosts a mobile leaderboard application on Amazon EC2 instances in an Auto Scaling group (ASG). The instances are registered with a target group for an Application Load Balancer (ALB). The leaderboard application listens on custom TCP port 80808080, but the ALB shows all EC2 instances as unhealthy. A solutions architect verifies that the application is running correctly on the instances. Which two actions should the solutions architect take to resolve the health check issues? (Select two.)

Select all that apply

Show answer & explanation

Answer: Update the ALB target group health check configuration to use port 80808080 or select the traffic port option.; Configure the security group of the EC2 instances to allow inbound TCP traffic on port 80808080 from the security group of the ALB.

Answer

To resolve the health check issues, the target group health check port must match the application port (port 80808080), and the EC2 instances' security group must permit inbound traffic on port 80808080 from the load balancer.
The correct actions are to update the target group health check to query the custom port 80808080 (or select the traffic port option) and configure the EC2 instances' security group to allow inbound traffic on port 80808080 from the ALB's security group. This ensures the load balancer can reach the application to evaluate its health and forward client traffic.

Step-by-Step Solution

1
Verify and align the health check port configuration.
Changing the target group health check port to port 80808080 or traffic-port ensures the ALB targets the active application port.
By default, if the target group is configured on a custom port but the health check is set to a default port (like port 8080), the instances will be marked unhealthy.
2
Ensure network connectivity between the ALB and the EC2 instances.
Updating the EC2 instance security group to allow port 80808080 inbound from the ALB's security group allows the health check requests and application traffic to flow.
Security groups require an explicit inbound rule for traffic to enter the instances.

Key Concept

Auto Scaling and Elastic Load Balancing health check configuration and security group alignment
Question 295Question

A medical device manufacturer is building an IoT monitoring system on AWS to process state-change logs from thousands of diagnostic devices. The system must process status updates for each device chronologically to maintain an accurate device history. During peak usage, the system experiences brief, massive spikes in telemetry messages. The architecture must fan out these state-change events to two distinct backend systems: a real-time status-tracking service and a historical compliance auditing database. Which solution meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Publish the state-change events to an Amazon SNS FIFO topic. Subscribe two Amazon SQS FIFO queues to the topic, with one queue dedicated to the status-tracking service and the other to the compliance auditing database.

Answer

Publish the state-change events to an Amazon SNS FIFO topic. Subscribe two Amazon SQS FIFO queues to the topic, with one queue dedicated to the status-tracking service and the other to the compliance auditing database.
Publishing events to an Amazon SNS FIFO topic and subscribing two Amazon SQS FIFO queues is the optimal decoupling pattern. SNS FIFO topics preserve message ordering and deliver messages to subscribed SQS FIFO queues in a first-in, first-out manner. The device ID is mapped to the message group ID, ensuring messages for the same device are processed in order by the downstream consumers. This fully managed approach requires no custom polling logic, keeps operational overhead to a minimum, and handles traffic spikes seamlessly.

Step-by-Step Solution

1
Identify the core requirements: message ordering preservation per device, fan-out to two distinct services, spike resilience, and minimal operational overhead.
Limits the valid design choices to event-driven services that support FIFO delivery and fan-out natively.
We must filter out solutions that use standard queues (which do not guarantee ordering) or those requiring heavy custom container/compute management.
2
Evaluate the subscription constraints of Amazon SNS FIFO.
Rule out direct subscription of AWS Lambda functions or standard SQS queues to the SNS FIFO topic.
Amazon SNS FIFO topics only support SQS FIFO queues as subscribers to guarantee ordering preservation.
3
Analyze the operational overhead of the Kinesis and Lambda custom polling option.
Rule out the Kinesis solution due to the inefficient and expensive continuous polling loop implementation in AWS Lambda.
Continuous execution loops in serverless functions are a major cost and operational anti-pattern.
4
Confirm the capability of SNS FIFO to SQS FIFO integration.
Each SQS FIFO queue will receive identical ordered copies of the messages, preserving the FIFO ordering per Message Group ID (device ID) for each downstream application independently.
This satisfies all business and technical constraints with a fully managed serverless architecture.

Key Concept

Decoupling with FIFO ordering and fan-out.
Estimated Time:3m 0s
Question 296Question

A logistics company hosts a fleet tracking application on AWS. The application runs on Amazon ECS Fargate tasks behind an Application Load Balancer (ALB) in the primary Region (us-east-1). The database is an Amazon RDS for PostgreSQL Multi-AZ DB instance. The company requires a disaster recovery (DR) strategy in a secondary Region (us-west-2) with a Recovery Time Objective (RTO) of less than 1515 minutes and a Recovery Point Objective (RPO) of less than 55 minutes. The solution must minimize ongoing operational costs. Which two actions should a solutions architect take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Create an Amazon RDS cross-region read replica in the secondary Region. During a failover, promote the read replica to a standalone DB instance.; Deploy the ECS service in the secondary Region with a minimum desired task count of 11. Configure an Application Load Balancer in the secondary Region, and set up Amazon Route 53 active-passive failover routing with health checks.

Answer

The correct options are creating an Amazon RDS cross-region read replica in the secondary Region (promoting it during failover), and deploying the ECS service in the secondary Region with a minimum task count of one along with an Application Load Balancer and Route 53 active-passive failover routing with health checks.
The correct actions combine an Amazon RDS cross-region read replica in the secondary Region with a Warm Standby ECS deployment and Route 53 active-passive failover. Creating a cross-region read replica satisfies the RPO of less than 55 minutes since replication is continuous and asynchronous, and promoting the replica to a standalone database takes only a few minutes. Running a single Fargate task in the secondary Region keeps compute costs minimal while ensuring that the infrastructure is ready to receive traffic immediately upon a DNS failover, satisfying the RTO of less than 1515 minutes.

Step-by-Step Solution

1
Analyze the RPO requirement of less than 55 minutes.
Identify that data replication to the secondary Region must be near real-time. Since the primary database is Amazon RDS for PostgreSQL, an asynchronous cross-region read replica is the most appropriate option to keep replication lag within seconds/minutes while keeping costs low compared to active-active architectures.
Ensures that data loss is minimized to meet the RPO threshold.
2
Analyze the RTO requirement of less than 1515 minutes.
Determine that compute capacity must be pre-provisioned or quickly deployable, and failover routing must be automated. Running a scaled-down ECS Fargate task (desired count of 11) represents a Warm Standby strategy that allows traffic to be served immediately upon DNS failover, avoiding the startup delays of deploying infrastructure from scratch.
Allows the application to recover and start serving traffic within the RTO budget.
3
Evaluate the database replication options.
Rule out RDS Multi-AZ for cross-region replication since Multi-AZ is strictly single-region. Rule out periodic snapshots since 1212-hour snapshot copying does not meet the 55-minute RPO and restoration takes too long for the 1515-minute RTO.
Eliminates database options that violate either the synchronous cross-region technical limitation or RPO/RTO constraints.
4
Evaluate routing and failover options.
Rule out latency-based routing without active health checks, as it does not perform automated failover during a regional outage.
Eliminates incorrect DNS configurations that fail to provide high availability.

Key Concept

Disaster recovery (DR) strategies (specifically Warm Standby vs. Pilot Light) require aligning AWS database replication (like RDS cross-region replicas) and routing mechanisms (like Route 53 failover routing) to meet specific RTO and RPO objectives at the lowest cost.
Estimated Time:3m 0s
Question 297Question

A solutions architect is designing a high-performance web application. The application tier runs on Amazon EC2 instances inside an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB). The application listens on a custom port 84438443. The ALB is configured with a target group targeting the EC2 instances. The solutions architect configures the security group of the EC2 instances to accept incoming TCP traffic on port 84438443 from the ALB's security group. However, the instances are showing as unhealthy in the target group, and users receive a HTTP 502502 Bad Gateway error. The subnets containing the EC2 instances are associated with a custom Network Access Control List (Network ACL). Which TWO configurations must the solutions architect verify or modify to resolve the health check issues and restore service? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the health check port in the ALB target group settings to use port 84438443 instead of the default port.; Verify that the custom Network ACL has an inbound rule allowing traffic on port 84438443 and an outbound rule allowing traffic on ephemeral ports 1024655351024-65535 for the EC2 subnet.

Answer

The solutions architect must configure the health check port in the target group settings to use port 84438443, and verify that the custom Network ACL allows inbound traffic on port 84438443 and outbound traffic on ephemeral ports 1024655351024-65535 for the EC2 subnet.
The correct options involve configuring the target group health check to point to the actual application port (port 84438443) and ensuring that the stateless Network ACL has rules allowing inbound traffic on port 84438443 and outbound traffic on the ephemeral port range (1024655351024-65535) to allow health check probes and responses to pass successfully.

Step-by-Step Solution

1
Analyze target group health check configuration.
Identify that because the application is listening on custom port 84438443, health checks targeting the default port (like port 8080) will fail if the instances do not listen on port 8080.
Health checks must target the correct port on which the web application is running to verify its status.
2
Review Network ACL behavior and rules.
Determine that Network ACLs are stateless, which requires outbound traffic rules for response traffic on ephemeral ports (1024655351024-65535) in addition to inbound traffic rules.
Since the ALB communicates with the target group, the subnet containing the EC2 instances must allow return traffic to the ALB's ephemeral ports.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) Target Health Checks and Stateless Network Security with Network ACLs
Question 298Question

A company is designing a disaster recovery (DR) strategy for a database on AWS. The company requires a Recovery Point Objective (RPO) of 11 hour and a Recovery Time Objective (RTO) of 1515 minutes. The solutions architect wants to minimize ongoing running costs. Which of the following strategies meets these requirements at the lowest cost?

Show answer & explanation

Answer: A Pilot Light strategy that replicates the database data to the secondary AWS Region, runs a minimal database instance, and provisions the application servers from Amazon Machine Images (AMIs) during a failover.

Answer

A Pilot Light strategy that replicates the database data to the secondary AWS Region, runs a minimal database instance, and provisions the application servers from Amazon Machine Images (AMIs) during a failover.
The correct strategy is a Pilot Light architecture. In this setup, critical data such as the database is replicated to the disaster recovery region and kept active, while application servers remain unprovisioned (or exist only as AMIs) to minimize ongoing costs. The application servers can be quickly provisioned from AMIs during failover, which satisfies the 1515-minute RTO.

Step-by-Step Solution

1
Analyze the RTO and RPO requirements.
The RPO is 11 hour (permits minimal data loss) and the RTO is 1515 minutes (demands fast recovery).
This determines which DR strategies are capable of meeting the recovery window.
2
Evaluate the cost constraint.
Backup and Restore is too slow for a 1515-minute RTO. Warm Standby and Multi-site are too expensive. Pilot Light is the most cost-effective strategy that can meet the RTO.
We must find the strategy that satisfies the recovery objectives at the lowest ongoing running cost.
3
Identify the correct implementation of the Pilot Light strategy.
Replicating data to an active database and keeping application servers unprovisioned until failover meets both the cost and RTO requirements.
This matches the definition of a Pilot Light strategy.

Key Concept

Disaster recovery strategies differ in cost and recovery times. Pilot Light maintains database replication with minimal resources and provisions the rest of the application stack only during failover, offering a balance of low cost and quick recovery.
Estimated Time:1m 0s
Question 299Question

A solutions architect is configuring an Application Load Balancer (ALB) to distribute traffic to Amazon EC2 instances running a web service on custom port 80808080. The instances are managed by an Auto Scaling group. The solutions architect notices that the load balancer is marking all instances as unhealthy. The service is running on the instances, and security groups allow traffic on port 80808080. What is the most likely cause of this issue?

Show answer & explanation

Answer: The target group health check is configured to query the default port 8080 instead of port 80808080.

Answer

The target group health check is configured to query the default port 8080 instead of port 80808080.
The correct answer is correct because the web application listens on port 80808080, but the health check port is misconfigured to query the default port 8080. Since no service is listening on port 8080, the health checks fail and the instances are marked as unhealthy. Setting the health check port to 80808080 or utilizing the traffic port resolves the mismatch.

Step-by-Step Solution

1
Analyze the web service port configuration and health check behavior.
The web service runs on port 80808080, but if the health check is misconfigured to target port 8080, requests will fail since no service listens on port 8080.
Health checks must target a port where the application is listening to return a successful response.
2
Evaluate the statefulness of security groups.
Security groups are stateful, so outbound return traffic is automatically allowed.
Understanding security group statefulness helps rule out return-traffic blockages as a cause.
3
Identify Route 53 routing policy limitations.
Route 53 resolves client queries to the load balancer but does not perform target-level health check routing.
This rules out DNS routing policy misconfigurations.

Key Concept

ELB Target Group Health Check Port Configuration
Question 300Question

An enterprise retail organization is migrating its inventory management pipeline to AWS. The pipeline must process inventory state-change events generated by retail stores. The requirements are:

1. Event processing must be strictly ordered on a per-store basis to prevent race conditions in warehouse stock levels.
2. The events must be fanned out to two separate downstream microservices: a real-time inventory reconciliation service and a near-real-time business intelligence dashboard.
3. The total ingestion throughput across all stores is expected to exceed 15,000 messages per second, while individual store volume varies dynamically.

Which TWO configurations should a solutions architect combine to meet these requirements with the lowest operational overhead? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create an Amazon SNS FIFO topic and subscribe two Amazon SQS FIFO queues to the topic, setting the retail store ID as the Message Group ID for all published events.; Enable high-throughput FIFO for both the Amazon SNS FIFO topic and the subscribed Amazon SQS FIFO queues to support the required message throughput.

Answer

The correct solution involves creating an Amazon SNS FIFO topic that fans out to two Amazon SQS FIFO queues, using the store ID as the Message Group ID, and enabling high-throughput FIFO mode on both the SNS topic and the SQS queues.
The correct solution uses an Amazon SNS FIFO topic to fan out inventory events to two Amazon SQS FIFO queues (one for each downstream service). By setting the store ID as the Message Group ID, messages are processed in order for each individual store while allowing parallel processing across different stores. To handle the 15,000 messages per second throughput, high-throughput FIFO mode must be enabled on both the SNS FIFO topic and the SQS FIFO queues, which scales the throughput limits.

Step-by-Step Solution

1
Analyze the ordering and fan-out requirements.
Identify that the system requires message ordering grouped by store ID and delivery to two independent downstream services.
Ordering requires FIFO capability (using a Message Group ID or partition key), and delivery to two independent services requires a pub/sub fan-out pattern.
2
Evaluate the throughput requirements against standard AWS service limits.
Identify that the total throughput of 15,000 messages/sec exceeds the default limit of SQS/SNS FIFO queues (which is 300 messages/sec without high-throughput mode).
High-throughput FIFO mode must be enabled to scale SQS and SNS FIFO to support 15,000 messages/sec.
3
Determine the configuration with the lowest operational overhead.
Select SNS FIFO subscribed to SQS FIFO with high-throughput mode enabled, rather than provisioning and managing Kinesis shards.
SNS/SQS is fully serverless and handles scaling automatically without manual shard management, minimizing operational overhead.

Key Concept

Decoupling event-driven architectures with high-throughput SNS FIFO and SQS FIFO to maintain ordering within specific message groups.
PreviousPage 15 / 20Next