Examkin

Design Resilient Architectures

382 questions

All types382Multiple choice195Multiple select187
Question 121Question →

A company is deploying a secure internal microservice on a fleet of Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The microservice is configured to listen on port 84438443. The target group is configured to route HTTPS traffic to port 84438443 with the health check port set to 'traffic-port'. The EC2 instances are launched in private subnets, while the ALB resides in public subnets. The private subnets are associated with a custom Network ACL (NACL) that permits inbound traffic on port 84438443 from the public subnets and outbound traffic on port 84438443 to the public subnets. The EC2 security group allows inbound traffic on port 84438443 from the ALB security group, and has the default outbound rule allowing all traffic. However, the ALB marks all EC2 instances as unhealthy, and clients receive HTTP 502502 Bad Gateway errors. Which of the following actions should the solutions architect take to resolve the health check issue and restore normal operation?

Show answer & explanation

Answer: Update the custom Network ACL rules on the private subnets to allow outbound traffic on ephemeral ports (10241024-6553565535) to the public subnets.

Answer

Update the custom Network ACL rules on the private subnets to allow outbound traffic on ephemeral ports (10241024-6553565535) to the public subnets.
The correct option is the one suggesting to update the custom Network ACL rules on the private subnets. Network ACLs are stateless, meaning that outbound return traffic must be explicitly allowed. When the Application Load Balancer sends health check requests to the EC2 instances on port 84438443, the instances respond using ephemeral source ports (10241024-6553565535). Because the outbound NACL rule only allowed traffic on port 84438443, the return traffic was blocked, causing the load balancer to mark the instances as unhealthy. Allowing outbound traffic to ephemeral ports resolves this issue.

Step-by-Step Solution

1
Analyze the statefulness of the security group and Network ACL configuration.
Identify that the security group is stateful and does not block the return path, whereas the Network ACL (NACL) is stateless and requires explicit rules for return traffic.
To pinpoint which security filter is blocking the health check responses from the EC2 instances.
2
Determine the source and destination ports for the load balancer health checks.
The ALB sends health checks to the instances on port 84438443 (destination). The instances reply back to the ALB's ephemeral ports in the range 10241024-6553565535 (destination).
To verify if the return traffic matches the allowed outbound rule of the private subnets' custom NACL.
3
Apply the correction to the stateless Network ACL.
Add an outbound rule allowing TCP traffic in the range 10241024-6553565535 to the public subnets where the ALB is located.
This allows the return traffic from the instances to reach the ALB, allowing the health check to succeed.

Key Concept

Stateless nature of Network ACLs compared to stateful Security Groups in Elastic Load Balancing architectures.
Estimated Time:2m 30s
Question 122Question →

A financial services firm is designing a real-time transaction ledger. The ledger must process deposit and withdrawal events in the exact order they are initiated for each individual bank account to prevent overdrafts. The event volume routinely spikes to 2,5002,500 transactions per second. Two independent downstream applications—a ledger database writer and a real-time fraud detection engine—must process every transaction. The architecture must guarantee that duplicate messages sent within a 5-minute window are discarded, and it must minimize operational overhead.

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

Select all that apply

Show answer & explanation

Answer: Create an Amazon Simple Notification Service (Amazon SNS) FIFO topic and subscribe two Amazon Simple Queue Service (Amazon SQS) FIFO queues to the topic, one for each downstream application.; Enable high-throughput mode on the SQS FIFO queues, and configure the transaction events to use the bank account ID as the message group ID.

Answer

Create an Amazon SNS FIFO topic with two SQS FIFO queues subscribed to it, enable high-throughput mode on the SQS FIFO queues, and use the bank account ID as the message group ID.
To achieve both event fan-out and strict sequencing under a high-throughput scenario, the architecture must utilize Amazon SNS FIFO and Amazon SQS FIFO. An SNS FIFO topic preserves ordering and deduplication when forwarding events to subscribed SQS FIFO queues. Setting the bank account ID as the message group ID allows the SQS FIFO queue to group related messages together for ordered processing while enabling horizontal scaling across multiple partitions. High-throughput mode allows the FIFO queues to scale dynamically and accommodate the 2,5002,500 TPS volume, while SQS FIFO's native deduplication satisfies the 5-minute window without custom application logic.

Step-by-Step Solution

1
Analyze ordering and throughput constraints.
The system requires strict ordering per bank account. The throughput can reach 2,5002,500 TPS, which exceeds the standard SQS FIFO queue limit of 300300 TPS.
This establishes that SQS FIFO queues with high-throughput mode enabled are necessary to handle the traffic while guaranteeing order.
2
Design the fan-out mechanism.
Use an Amazon SNS FIFO topic to publish the events, and subscribe two separate Amazon SQS FIFO queues to this topic.
This allows both independent downstream applications to receive a copy of every transaction event without competing for messages, while preserving ordering and deduplication properties.
3
Configure message grouping and deduplication.
Set the bank account ID as the message group ID and leverage SQS FIFO's native 5-minute deduplication window.
Using the bank account ID as the message group ID ensures that events for the same account are sequenced correctly while allowing different accounts to be processed concurrently. SQS FIFO's native deduplication discards duplicates within 5 minutes without additional coding.

Key Concept

Combining Amazon SNS FIFO and SQS FIFO queues to achieve high-throughput event fan-out with strict ordering and native deduplication.
Estimated Time:3m 0s
Question 123Question →

A healthcare telemedicine platform processes patient consultation records in its primary AWS Region, us-east-1. The architecture consists of a containerized application running on Amazon EKS and a transactional database on Amazon RDS for PostgreSQL. To comply with national health regulations, the platform must implement a disaster recovery (DR) strategy in a secondary Region, us-west-2, with a Recovery Time Objective (RTO) of 10 minutes and a Recovery Point Objective (RPO) of 5 minutes. The strategy must also allow the company to perform quarterly DR drills in an isolated environment without affecting the production workload. Which of the following strategies meets these requirements while minimizing costs during normal operations?

Show answer & explanation

Answer: Migrate the database to Amazon Aurora PostgreSQL-Compatible Edition and configure an Aurora Global Database with the primary cluster in us-east-1 and a single-node secondary cluster in us-west-2. Deploy a scaled-down Amazon EKS cluster in us-west-2 with the minimum node capacity required to run core services. Configure Amazon Route 53 with failover routing. For quarterly drills, clone the secondary Aurora database cluster using the database cloning feature, and run testing workloads against the clone and the secondary EKS cluster.

Answer

Migrate the database to Amazon Aurora PostgreSQL-Compatible Edition, configure an Aurora Global Database with a single-node secondary cluster, deploy a scaled-down Amazon EKS cluster in the secondary Region, and use Aurora's database cloning feature for isolated testing.
Migrating the database to Amazon Aurora PostgreSQL and setting up an Aurora Global Database ensures sub-second replication lag, meeting the 5-minute RPO. Deploying a scaled-down EKS cluster (Warm Standby) keeps the control plane active and instances warmed up, allowing fast scaling within 10 minutes (meeting the RTO). Aurora's fast database cloning feature allows creating an isolated copy of the secondary database cluster in the DR region, which can be modified during drills without affecting production data replication.

Step-by-Step Solution

1
Analyze the RPO requirement of 5 minutes.
Determine that asynchronous cross-region database replication is required (data lag must be minimal). Daily backups copied to S3 Glacier are eliminated due to potential 24-hour data loss.
Ensures that data loss is within acceptable regulatory limits.
2
Analyze the RTO requirement of 10 minutes.
Rule out pilot light compute strategies with zero active nodes and cold recoveries from templates, since EC2 node instantiation, cluster registration, and container deployment exceed 10 minutes. A warm standby with active, scaled-down node groups is necessary.
Ensures the application can be scaled up and serve traffic within the RTO window.
3
Identify the mechanism for non-disruptive, isolated DR drills.
Recognize that Aurora Fast Database Cloning provides an instant, isolated, writeable database clone at no initial cost and without breaking cross-region replication. Promoting an RDS Read Replica is ruled out as it breaks replication and disrupts production.
Allows compliance validation without impacting production workload or failover readiness.

Key Concept

Disaster Recovery strategies (Warm Standby vs. Pilot Light) and Cross-Region replication configurations using Amazon Aurora Global Databases and database cloning.
Question 124Question →

A media company is planning a disaster recovery (DR) strategy on AWS. The solutions architect recommends implementing a Pilot Light strategy in a secondary AWS Region to achieve a low Recovery Time Objective (RTO) while keeping idle resource costs to a minimum.

Which of the following actions should the solutions architect take to implement this strategy? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Replicate the primary database to a continuously running database instance in the secondary AWS Region to keep the data up to date.; Maintain application server configurations as Amazon Machine Images (AMIs) and launch the instances only during a failover event.

Answer

Replicate the primary database to a continuously running database instance in the secondary AWS Region, and maintain application server configurations as Amazon Machine Images (AMIs) to launch only during failover.
In a Pilot Light disaster recovery (DR) strategy, the data tier (such as the database) is kept running and continuously updated in the recovery region to minimize recovery time. Compute and application infrastructure are kept dormant or stored as configuration templates (like AMIs) to minimize idle running costs. These templates are only used to provision active instances when a failover is triggered.

Step-by-Step Solution

1
Identify the key constraints of a Pilot Light disaster recovery strategy.
Pilot Light requires databases (the 'pilot light') to be running and replicating data, while application servers and other compute infrastructure are kept turned off or defined as templates to minimize costs.
This establishes the baseline architectural pattern for Pilot Light, separating the data layer (always running/replicating) from the compute layer (decommissioned/dormant).
2
Evaluate the database tier configuration.
The database must be replicated to the recovery region in real-time or near real-time, requiring a running database instance to host and apply the replicated data.
This guarantees that the data is current and ready for use without lengthy restore operations from backups, keeping RTO low.
3
Evaluate the compute tier configuration.
Application servers should not be running. Instead, they should be prepared as AMIs or CloudFormation templates, ready to be provisioned only when a disaster is declared.
This satisfies the requirement to minimize idle compute cost, distinguishing Pilot Light from Warm Standby (where scaled-down servers are running).

Key Concept

Pilot Light Disaster Recovery Strategy
Question 125Question →

A company is deploying a new web application on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The solutions architect needs to ensure that the ALB only routes traffic to instances that are running the web service successfully, and that the ASG automatically terminates and replaces any instance where the web service has failed. Which two configurations should the solutions architect implement to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the Auto Scaling group health check type to ELB.; Configure the Application Load Balancer target group health check to monitor the specific port and path where the web application is running.

Answer

To meet the requirements, the solutions architect must set the Auto Scaling group health check type to ELB and configure the Application Load Balancer target group health check to monitor the specific port and path where the web application is running.
Configuring the Auto Scaling group to use ELB health checks ensures that the group will replace instances if they fail the application-level load balancer health checks. Configuring the Application Load Balancer target group health check to monitor the specific port and path where the web application is running ensures that the load balancer correctly identifies whether the application itself is healthy, rather than just the underlying EC2 instance.

Step-by-Step Solution

1
Determine how the Auto Scaling group monitors instance health.
By default, the Auto Scaling group only performs EC2 status checks (system and instance status checks), which do not detect if the web server process has crashed.
To ensure the Auto Scaling group replaces instances when the web application fails, the health check type must be updated to ELB.
2
Determine how the Application Load Balancer monitors application health.
The target group health check must be configured to query the specific port and path where the web application is active.
This ensures the load balancer accurately tracks application health and redirects traffic away from failed instances.

Key Concept

ELB and Auto Scaling Group Health Check Integration
Estimated Time:1m 0s
Question 126Question →

A company is deploying a containerized microservice for processing real-time IoT telemetry data. The service runs on Amazon EC2 instances managed by an Auto Scaling group (ASG). An Application Load Balancer (ALB) routes traffic to the instances. The telemetry service is configured to listen on port 8080. The target group is configured to route traffic to port 8080. The security group associated with the EC2 instances allows inbound traffic on port 8080 from the ALB security group. After deployment, the ALB registers all EC2 instances as unhealthy, and users receive a 502 Bad Gateway error. The solutions architect verifies that the service is running and healthy on the instances when tested locally on port 8080. Which action should the solutions architect take to resolve this issue?

Show answer & explanation

Answer: Update the target group health check settings to query port 8080 instead of the default port 80.

Answer

Update the target group health check settings to query port 8080 instead of the default port 80.
The correct answer is to update the target group health check settings to query port 8080. By default, unless specified, the health check port may default to port 80. Since the microservice is listening on port 8080, the load balancer's health check requests to port 80 fail, causing the instances to be marked as unhealthy. Explicitly setting the health check port to 8080 resolves the issue.

Step-by-Step Solution

1
Identify the port on which the service is listening on the EC2 instances.
The application listens and runs healthy on port 8080.
This establishes the target port that health checks and routing should target.
2
Check the default target group health check port settings.
By default, health check configurations often default to port 80 rather than the traffic port if not explicitly overridden.
This identifies the source of the health check failure (requesting port 80 instead of 8080).
3
Modify the health check port to 8080.
The load balancer begins successfully checking the application on port 8080 and marks instances as healthy.
Aligning the health check port with the active application port resolves the unhealthy status and the 502 Bad Gateway errors.

Key Concept

ELB Target Group Health Check Port Alignment
Question 127Question →

An enterprise runs a critical API workload on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ALB is configured with an HTTPS listener forwarding traffic to a target group on port 84438443. The application on the EC2 instances processes user traffic on port 84438443. However, the application's internal health status is exposed only via a lightweight management server running on port 80808080 on the same instances. Currently, the EC2 security group allows inbound TCP traffic on port 84438443 from the ALB security group. The target group health check is set to its default configuration, and the instances are consistently marked as unhealthy by the ALB, causing the ASG to terminate and relaunch them. Which configuration change should a solutions architect implement to resolve the health check failures while maintaining the principle of least privilege?

Show answer & explanation

Answer: Modify the target group health check configuration to override the port to 8080, and add a rule to the EC2 security group allowing inbound TCP traffic on port 8080 from the ALB security group.

Answer

Modify the target group health check configuration to override the port to 8080, and add a rule to the EC2 security group allowing inbound TCP traffic on port 8080 from the ALB security group.
The correct option addresses both the network connectivity and the application configuration. By overriding the target group health check port to 8080, the Application Load Balancer (ALB) is directed to send health probes to the correct port where the application health endpoint resides. Furthermore, adding an inbound rule to the EC2 security group for port 8080 allows the ALB's stateful health probes to successfully reach the instances, resolving the health check failures under the principle of least privilege.

Step-by-Step Solution

1
Analyze the target group port mapping.
The target group uses port 8443 by default for traffic and health checks ('traffic-port').
Identify why the ALB is sending health check requests to port 8443 instead of the management port 8080.
2
Configure the health check port override.
Modify the target group settings to explicitly perform health checks on port 8080.
Ensure that the load balancer queries the correct port where the application's health status is exposed.
3
Update security group rules.
Add an inbound rule to the EC2 instance security group allowing TCP port 8080 traffic from the ALB security group.
Since security groups are stateful and evaluate traffic at the instance level, the ALB's health check queries on port 8080 will be blocked unless explicitly permitted by the security group.

Key Concept

ELB Target Group Health Check Port Configuration and Security Group Integration
Estimated Time:2m 30s
Question 128Question →

A financial services firm hosts a web application on Amazon EC2 instances in an Auto Scaling group (ASG). The instances are registered as targets in a target group for an Application Load Balancer (ALB). The application listens on TCP port 8080. The EC2 instance security group allows inbound traffic on TCP port 8080 from the ALB security group. However, the ALB health checks are failing, and the ALB is marking all instances as unhealthy. The systems administrator verifies that the application is running normally on the instances and accepting traffic. Which configuration change will resolve this issue?

Show answer & explanation

Answer: Update the target group health check settings to use port 8080 or the 'traffic-port' option.

Answer

Update the target group health check settings to use port 8080 or the 'traffic-port' option.
The correct option is to update the target group health check settings to use port 8080 or the 'traffic-port' option. Since the application runs on port 8080, any health probe sent to a different port (such as the default port 80) will fail because no process is listening on that port. Aligning the health check port to the traffic port ensures the Application Load Balancer successfully probes the running application.

Step-by-Step Solution

1
Identify the application's listening port.
The application listens on TCP port 8080.
Health check probes must reach a port where the application is actively listening.
2
Analyze the load balancer target group configuration.
The target group is default-configured or misconfigured to probe a port other than 8080 (such as port 80).
If the ALB health check port does not match the application port, the health check fails.
3
Update the health check settings in the target group.
Setting the health check port to 8080 or 'traffic-port' restores successful health checks.
This aligns the load balancer's probes with the active application port, resolving the unhealthy status.

Key Concept

ELB Target Group Health Check Port Alignment
Estimated Time:1m 30s
Question 129Question →

A company hosts a web application on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The EC2 instances reside in a private subnet, and the ALB is in a public subnet. The application is configured to listen on port 8080. A security engineer updates the private subnet's Network Access Control List (NACL) to allow inbound traffic from the public subnet on TCP port 8080, and outbound traffic to the public subnet on TCP port 8080. Shortly after, the ALB target group health checks begin failing, and the EC2 instances are marked unhealthy. What is the reason for this health check failure?

Show answer & explanation

Answer: Network ACLs are stateless, and the outbound Network ACL is blocking the return traffic because it does not allow traffic to the ephemeral ports used by the ALB.

Answer

Network ACLs are stateless, and the outbound Network ACL is blocking the return traffic because it does not allow traffic to the ephemeral ports used by the ALB.
The correct answer identifies that Network ACLs (NACLs) are stateless. When the Application Load Balancer sends a health check request from an ephemeral port to the instances on port 8080, the request is allowed inbound. However, because NACLs are stateless, the return traffic from the instances back to the ALB's ephemeral port range (1024-65535) is blocked by the outbound NACL, which is restricted to port 8080. Opening the outbound NACL to ephemeral ports resolves the issue.

Step-by-Step Solution

1
Identify the key network security component mentioned in the failure.
The scenario focuses on the update to the Network Access Control List (NACL) of the private subnet.
Since the health check failures began immediately after the NACL change, the root cause must be related to the stateless nature of NACLs.
2
Analyze how stateless network devices process traffic flow.
Inbound rules allow the request in, but outbound rules must explicitly permit the response to go back to the source port (ephemeral ports 1024-65535).
Because the outbound NACL was only configured to allow port 8080, it blocked the return traffic to the ALB.
3
Differentiate security groups from NACLs.
Security groups are stateful and automatically permit return traffic, while NACLs require explicit two-way configuration.
This confirms the issue lies solely with the stateless Network ACL configuration.

Key Concept

Understanding the stateless nature of Network Access Control Lists (NACLs) and how they affect Elastic Load Balancing (ELB) health check traffic.
Question 130Question →

A financial technology company is migrating its core transaction ledger application to AWS. The application runs on Amazon EC2 instances behind an Application Load Balancer and uses an Amazon RDS for PostgreSQL database. To comply with regulatory standards, the company requires a multi-Region disaster recovery (DR) strategy with a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 2 minutes. The design must minimize the ongoing infrastructure cost in the recovery Region. Which combination of actions should a solutions architect recommend to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Migrate the database to Amazon Aurora PostgreSQL Global Database, placing the primary cluster in the active Region and a secondary cluster in the recovery Region.; Deploy the application tier in the recovery Region using an Auto Scaling group with the desired capacity set to zero, and configure Amazon Route 53 active-passive failover routing with health checks.

Answer

The solutions architect should migrate the database to Amazon Aurora PostgreSQL Global Database and deploy the application tier using an Auto Scaling group with desired capacity set to zero combined with Amazon Route 53 active-passive failover routing.
The correct combination requires migrating the database to Amazon Aurora PostgreSQL Global Database and deploying the application tier using an Auto Scaling group with zero running EC2 instances combined with Route 53 failover routing. Aurora Global Database has a replication lag of less than a second, meeting the 2-minute RPO, and can be promoted in under a minute, meeting the 15-minute RTO. Scaling the EC2 instances to zero minimizes compute costs in the recovery Region during normal operations, representing a Pilot Light strategy. Route 53 active-passive failover routing ensures that traffic is redirected to the recovery Region once the health checks report that the primary Region is unavailable.

Step-by-Step Solution

1
Select a database replication technology that meets the 2-minute RPO.
Amazon Aurora PostgreSQL Global Database replicates data across Regions asynchronously with sub-second latency.
Standard multi-Region backups or replication strategies with higher lag cannot guarantee the 2-minute RPO.
2
Select a cost-effective application deployment strategy for the recovery Region that meets the 15-minute RTO.
An Auto Scaling group with desired capacity set to zero ensures no running EC2 instance costs during normal operations.
This Pilot Light strategy minimizes costs compared to Warm Standby while allowing instances to scale up quickly within the 15-minute RTO window.
3
Establish the DNS routing mechanism to handle automatic failover.
Configure Amazon Route 53 active-passive failover routing linked with application health checks.
Active-passive failover with health checks ensures user traffic is redirected automatically only when a failure is detected, avoiding misrouting issues associated with latency-only routing.

Key Concept

Designing Multi-Region Architectures for Disaster Recovery under strict RTO/RPO and cost constraints.
Estimated Time:3m 0s
Question 131Question →

A retail company is designing an application that receives transaction logs from physical stores. The transaction logs must be processed in the exact order they are received to ensure accurate inventory updates. The processing application must run continuously as a background process to handle the constant stream of messages. The solutions architect needs to decouple the ingestion layer from the processing layer.

Which TWO actions should the solutions architect take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Create an Amazon SQS FIFO queue to buffer the incoming transaction logs.; Deploy the processing worker on Amazon ECS using AWS Fargate to run the containerized application continuously.

Answer

The solutions architect should create an Amazon SQS FIFO queue to buffer the transaction logs and deploy the processing worker on Amazon ECS using AWS Fargate.
To satisfy the requirements of decoupling and strict message ordering, the solutions architect must use an Amazon SQS FIFO queue. Additionally, because the processing service needs to run continuously as a background process, hosting it on Amazon ECS with AWS Fargate provides a scalable, managed, and continuous execution environment.

Step-by-Step Solution

1
Determine the message ordering requirement.
The transaction logs must be processed in the exact order they are received to ensure correct inventory updates.
This dictates the choice of queue type, requiring a First-In-First-Out mechanism.
2
Select the correct queue service.
Amazon SQS FIFO queue is selected to guarantee order and decouple the ingestion and processing layers.
Standard queues do not guarantee message order, while FIFO queues ensure strict ordering.
3
Analyze the consumer application workload characteristics.
The worker application must run continuously to process a steady stream of incoming messages.
This dictates the choice of compute service, favoring persistent container orchestration over short-lived serverless functions.
4
Select the correct compute service.
Amazon ECS with AWS Fargate is chosen to host the containerized worker continuously.
AWS Lambda is not suitable due to its 15-minute maximum execution timeout.

Key Concept

Decoupling message processing using SQS FIFO queues and deploying continuous consumers using Amazon ECS.
Question 132Question →

A company hosts a specialized data processing service on Amazon EC2 instances. The instances are managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The backend application runs on custom port 80808080. The target group is configured to route traffic to the instances on port 80808080, but the default health checks are failing, and the ALB marks all newly launched instances as unhealthy. Additionally, during scale-in events, active client connections—which can take up to 1010 minutes (600600 seconds) to complete—are being terminated abruptly before finishing their tasks.

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

Select all that apply

Show answer & explanation

Answer: Set the deregistration delay timeout attribute of the ALB target group to 600600 seconds.; Modify the target group's health check configuration to explicitly use port 80808080.

Answer

Setting the target group deregistration delay to 600600 seconds and modifying the health check configuration to target port 80808080 explicitly.
The correct options are to increase the target group's deregistration delay to 600600 seconds and explicitly set the health check port to 80808080. Increasing the deregistration delay allows active transactions to complete gracefully during scale-in. Explicitly targeting port 80808080 in the health check ensures the load balancer accurately monitors the backend application.

Step-by-Step Solution

1
Analyze the connection termination issue.
Identified that the default deregistration delay (connection draining) is forcing active connections to drop before the 1010-minute (600600-second) window needed by the processing tasks.
By increasing the deregistration delay to 600600 seconds, the ALB allows in-flight requests to complete before terminating the EC2 instance.
2
Analyze the health check failure issue.
Identified that target group health checks are targeting the wrong port (e.g., port 8080) instead of the application's active listening port (80808080).
Setting the health check port explicitly to 80808080 ensures the ALB queries the port where the backend service is actually running.

Key Concept

ELB connection draining (deregistration delay) configuration and target group port mapping for health checks.
Question 133Question →

A financial technology company hosts a transactional banking application on AWS. The architecture consists of Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer, and a Multi-AZ Amazon RDS for PostgreSQL database. To meet regulatory compliance, the company must establish a cross-region disaster recovery (DR) plan with a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 2 hours. The solutions architect must design a solution that minimizes ongoing infrastructure costs in the secondary region. Which disaster recovery strategy should the solutions architect recommend to meet these requirements?

Show answer & explanation

Answer: Replicate the database to the secondary region using an Amazon RDS cross-region read replica. Store the application AMIs in the secondary region and maintain AWS CloudFormation templates to provision the Application Load Balancer and Auto Scaling group only during a failover event.

Answer

Replicate the database to the secondary region using an Amazon RDS cross-region read replica. Store the application AMIs in the secondary region and maintain AWS CloudFormation templates to provision the Application Load Balancer and Auto Scaling group only during a failover event.
The correct option proposes a Pilot Light disaster recovery strategy. By replicating the database using an Amazon RDS cross-region read replica, the solution ensures that transactional data is continuously copied, satisfying the 15-minute RPO. Since the RTO is relatively generous (2 hours), compute resources such as Application Load Balancers and Auto Scaling groups do not need to run continuously. Deploying these resources dynamically using stored AMIs and pre-configured CloudFormation templates minimizes ongoing infrastructure costs in the secondary region while comfortably meeting the 2-hour RTO.

Step-by-Step Solution

1
Evaluate the RPO requirement (15 minutes) against data replication options.
Cross-region RDS read replicas provide continuous asynchronous replication, keeping data lag to a few seconds or minutes, which easily satisfies the 15-minute RPO.
Ensures that the secondary database is up-to-date and ready for promotion with minimal data loss.
2
Evaluate the RTO requirement (2 hours) and cost-minimization constraint.
A Pilot Light strategy allows the database to run as a read replica in the secondary region while keeping compute resources shut down or unprovisioned. Deploying compute resources via CloudFormation templates and AMIs takes less than 30 minutes, which is well within the 2-hour RTO limit and minimizes compute costs.
Allows the company to avoid paying for running EC2 instances and load balancer idle time in the secondary region during normal operations.
3
Compare against the Warm Standby and Backup and Restore alternatives.
Warm Standby is rejected due to unnecessary ongoing compute cost. Backup and Restore with Glacier is rejected because Glacier retrieval times exceed the 2-hour RTO, and hourly snapshots violate the 15-minute RPO.
Selects the optimal strategy that meets all recovery goals while staying cost-optimized.

Key Concept

Disaster Recovery strategies (Pilot Light vs. Warm Standby) and cross-region database replication in AWS.
Estimated Time:2m 0s
Question 134Question →

A company hosts a high-traffic web application on Amazon EC2 instances inside a private subnet. The instances are managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). After the security team updated the network access control list (Network ACL) of the private subnet to restrict inbound traffic to only port 80, the ALB target group health checks began failing, marking all EC2 instances as unhealthy and resulting in HTTP 502 Bad Gateway errors. The security groups associated with the EC2 instances allow all inbound traffic from the ALB. Which configuration change will resolve this issue and restore application availability?

Show answer & explanation

Answer: Add an outbound rule to the private subnet Network ACL allowing TCP traffic to the ALB subnet on ephemeral ports 1024−655351024 - 65535.

Answer

Add an outbound rule to the private subnet Network ACL allowing TCP traffic to the ALB subnet on ephemeral ports 1024−655351024 - 65535.
The correct option is correct because Network ACLs are stateless, meaning that outbound return traffic must be explicitly allowed. When the ALB sends a health check request to the EC2 instances on port 80, the return traffic from the instances back to the ALB is sent on an ephemeral port (1024−655351024 - 65535). Because the Network ACL only has an inbound rule for port 80 and no outbound rule for ephemeral ports, the return traffic is blocked, causing the health checks to fail. Adding an outbound rule for the ephemeral ports resolves the issue.

Step-by-Step Solution

1
Identify the impact of the Network ACL change on the network path between the Application Load Balancer (ALB) and the Amazon EC2 instances.
The Network ACL blocks all outbound return traffic from the EC2 instances to the ALB because Network ACLs are stateless, and only inbound traffic on port 80 was allowed.
Understanding the stateless nature of Network ACLs helps diagnose why healthy instances are marked unhealthy when inbound rules are tightened without considering outbound return paths.
2
Analyze the port requirements for the return traffic from the EC2 instances to the ALB.
Return traffic initiated by an inbound request on port 80 is sent back to the client (ALB) on ephemeral ports, which typically range from 10241024 to 6553565535.
The stateless Network ACL must explicitly permit outbound traffic on the ephemeral port range to allow the HTTP response to reach the ALB.
3
Formulate the correction to the Network ACL configuration.
Add an outbound rule to the private subnet's Network ACL allowing TCP traffic to the ALB's subnet on ports 1024−655351024 - 65535.
This allows the response of the health checks to successfully return to the ALB, allowing the targets to be marked as healthy and restoring service.

Key Concept

Stateless Network ACLs require explicit configuration of outbound return traffic paths, which utilize ephemeral ports.
Estimated Time:2m 0s
Question 135Question →

A digital ticketing platform handles concert ticket purchases and cancellations. The transaction details must be processed in the exact sequence they are generated to ensure seat availability is calculated accurately. During ticket sales for major events, the portal experiences massive surges in traffic that overwhelm the backend database. A solutions architect needs to decouple the portal from the transaction processing backend to buffer traffic spikes while maintaining strict transaction order. Which solution meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Send the transaction updates to an Amazon SQS FIFO queue. Configure an AWS Lambda function to process the messages, using the concert ID as the Message Group ID to ensure sequential processing of transactions for each concert.

Answer

Send the transaction updates to an Amazon SQS FIFO queue, and configure an AWS Lambda function to process the messages, using the concert ID as the Message Group ID to ensure sequential processing of transactions for each concert.
The correct solution uses an Amazon SQS FIFO queue to decouple the ticketing portal from the database. SQS FIFO queues ensure first-in, first-out delivery. By setting the concert ID as the Message Group ID, all transactions relating to the same concert are processed in the order they occurred. Using an AWS Lambda function integrated as the event source represents the lowest operational overhead option, as AWS manages the polling infrastructure.

Step-by-Step Solution

1
Analyze the requirement for message ordering and traffic buffering.
The platform needs a buffer to absorb spikes in transactional traffic and must process updates chronologically per concert.
This indicates that a FIFO queueing mechanism is required to decouple the application layers.
2
Select the appropriate queuing service and configuration.
Amazon SQS FIFO is selected because it guarantees strict ordering and deduplication.
SQS standard queues cannot be used because they do not guarantee message order.
3
Determine the message grouping strategy.
Use the concert ID as the Message Group ID.
This guarantees that transactions for the same concert are processed sequentially, while transactions for different concerts can be scaled and processed in parallel.
4
Identify the low-overhead consumer mechanism.
Configure AWS Lambda to poll the queue natively as an event source.
Lambda automatically handles integration, polling, and scaling with minimal operational management.

Key Concept

Decoupling message flows with order preservation using Amazon SQS FIFO queues and AWS Lambda.
Question 136Question →

A smart home security company is designing an event-driven system to process status logs from connected smart hubs (e.g., alarm armed, sensor triggered, door unlocked). To ensure the correct application logic, the status logs for each individual home must be processed in the precise order they are generated. The logs must be fanned out to both a real-time alerting service and a secondary database ingestion worker. The architecture must be decoupled, scalable, and minimize operational overhead.

Which combination of services and configurations should a solutions architect use to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create an Amazon SNS FIFO topic to ingest the smart hub status logs and publish them to downstream subscribers.; Create Amazon SQS FIFO queues for the alerting service and the database ingestion worker, subscribing both queues to the SNS topic.

Answer

Create an Amazon SNS FIFO topic to ingest the smart hub status logs, and create Amazon SQS FIFO queues for the alerting service and database worker subscribed to the SNS FIFO topic.
To preserve ordering during event ingestion and distribution, Amazon SNS FIFO must be paired with Amazon SQS FIFO queues. An SNS FIFO topic ensures that message ordering is maintained when fanning out. SQS FIFO queues then receive these ordered messages and guarantee first-in, first-out processing for each downstream consumer independently.

Step-by-Step Solution

1
Select a message ordering mechanism that supports publishing and pub/sub routing.
Amazon SNS FIFO is chosen to ingest logs while preserving message sequencing.
We must fan out status updates to multiple downstream destinations while preserving the exact order per smart home.
2
Select a message buffering mechanism for the downstream processing services that maintains order.
Amazon SQS FIFO queues are selected for each downstream consumer.
Downstream workers require buffer queues to prevent data loss, and FIFO queues ensure that the message sequence is preserved through processing.
3
Subscribe the SQS FIFO queues to the SNS FIFO topic.
A fully decoupled pub/sub message delivery system that guarantees strict ordering and message deduplication.
By connecting SQS FIFO queues to the SNS FIFO topic, both consumers get a complete, ordered copy of each status log message independently.

Key Concept

Using Amazon SNS FIFO and Amazon SQS FIFO queues together enables decoupled, fan-out messaging architectures that guarantee strict first-in, first-out (FIFO) ordering and deduplication.
Question 137Question →

A financial company is building a transaction ledger application where users deposit and withdraw funds. The application must process these transaction events in the exact order they occur to prevent incorrect balances. Additionally, a compliance service and an auditing service must both receive a copy of every transaction event in near-real-time. If a transaction fails to process after five attempts, it must be moved to a separate queue for analysis without blocking subsequent transactions.

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: Create an Amazon SNS FIFO topic to receive the transaction events, and subscribe two Amazon SQS FIFO queues to the topic to fan out the events to both the compliance and auditing services.; Configure a redrive policy on each Amazon SQS FIFO queue to send failed transaction events to an Amazon SQS FIFO dead-letter queue (DLQ).

Answer

Create an Amazon SNS FIFO topic to receive the transaction events, subscribe two Amazon SQS FIFO queues to the topic, and configure a redrive policy on each SQS FIFO queue to send failed events to an SQS FIFO dead-letter queue (DLQ).
To process transaction events in strict chronological order and distribute them to multiple independent services, you must use Amazon SNS FIFO combined with Amazon SQS FIFO. SNS FIFO distributes messages in a first-in, first-out order to multiple subscribed SQS FIFO queues. Additionally, to handle processing failures without stalling the entire queue (head-of-line blocking), a redrive policy must be configured on the SQS FIFO queues to send failed messages to an SQS FIFO dead-letter queue (DLQ). This combination ensures both strict ordering and resilient decoupling.

Step-by-Step Solution

1
Select the messaging components that support strict ordering and publish-subscribe fan-out.
Amazon SNS FIFO and Amazon SQS FIFO are selected.
Standard SQS and SNS do not guarantee first-in, first-out (FIFO) ordering. SNS FIFO allows publishing to a single topic and fanning out to multiple SQS FIFO queues while preserving message order.
2
Design the fan-out architecture by subscribing SQS FIFO queues to the SNS FIFO topic.
Two SQS FIFO queues (one for compliance and one for auditing) are subscribed to the SNS FIFO topic.
This decoupled setup ensures both downstream services receive their own copy of all events in the correct sequence without interfering with each other.
3
Implement error handling for failed messages that preserves ordering requirements.
A redrive policy pointing to an SQS FIFO Dead-Letter Queue (DLQ) is configured.
An SQS FIFO queue requires its DLQ to also be a FIFO queue. This allows failed events to be isolated after five attempts without blocking the remaining transaction events in the main queue.

Key Concept

Decoupling event-driven architectures with ordering guarantees using SNS FIFO, SQS FIFO, and FIFO Dead-Letter Queues.
Question 138Question →

A telehealth platform hosts its patient portal application in the us-east-1 Region using Amazon EC2 instances and an Amazon RDS for MySQL DB instance. The company needs to design a pilot light disaster recovery (DR) strategy in the us-west-2 Region. The DR solution must achieve a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 4 hours, while minimizing ongoing infrastructure costs. Which solution meets these requirements?

Show answer & explanation

Answer: Configure an Amazon RDS cross-region read replica in the us-west-2 Region. Store the application tier as Amazon Machine Images (AMIs) in us-west-2, and launch the EC2 instances from the AMIs only during a failover event.

Answer

Configure an Amazon RDS cross-region read replica in the us-west-2 Region. Store the application tier as Amazon Machine Images (AMIs) in us-west-2, and launch the EC2 instances from the AMIs only during a failover event.
The correct solution involves configuring an Amazon RDS cross-region read replica in us-west-2 to achieve low-latency asynchronous database replication. This satisfies the 15-minute RPO. By storing the application tier as AMIs in the secondary region and launching the EC2 instances only during a failover event, the solution minimizes ongoing compute costs while allowing the system to be fully provisioned well within the 4-hour RTO. This represents a classic pilot light disaster recovery strategy.

Step-by-Step Solution

1
Analyze RPO requirements.
To meet an RPO of 15 minutes, the database must replicate changes to the secondary region asynchronously with minimal lag. An RDS cross-region read replica provides this continuous, low-latency replication.
Traditional backup methods (like daily snapshots) would result in a recovery point of 12-24 hours, violating the 15-minute RPO constraint.
2
Analyze RTO and cost requirements.
To implement a cost-optimized 'pilot light' environment under a 4-hour RTO, application servers should not run continuously. Instead, keeping AMIs ready in the target region allows rapid deployment during a failover event.
Keeping EC2 instances powered down or unprovisioned minimizes compute costs, while launching them from AMIs takes under 30 minutes, easily fitting within the 4-hour RTO window.
3
Select the optimal disaster recovery configuration.
Combine the RDS cross-region read replica (for database RPO) with stored AMIs (for cost-efficient compute RTO).
This combination exactly satisfies the pilot light pattern: database replication is live (lighted), but compute resources are inactive until failover.

Key Concept

Disaster recovery (DR) strategies involve balancing RTO, RPO, and cost. A pilot light strategy maintains a running database replica to protect data (meeting strict RPOs) while keeping application compute resources idle or stored as AMIs to minimize costs.
Question 139Question →

A medical device company is building an IoT platform that monitors patient health metrics. The platform receives events representing critical patient state changes (e.g., 'normal', 'warning', 'critical', 'resolved') sent from wearable sensors. For each patient, these state changes must be processed in the exact order they occurred to ensure the medical dashboard displays the current clinical state. Events from different patients must be processed concurrently to handle high throughput during peak hours. Which solution meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Publish the health events to an Amazon SQS FIFO queue, using the patient ID as the Message Group ID. Configure an AWS Lambda function to consume and process the messages.

Answer

Publish the health events to an Amazon SQS FIFO queue, using the patient ID as the Message Group ID. Configure an AWS Lambda function to consume and process the messages.
The correct option correctly uses an Amazon SQS FIFO queue to guarantee ordered delivery. By setting the Message Group ID to the patient ID, messages associated with the same patient are always processed in the exact order they are received, while messages for different patients are processed in parallel by the AWS Lambda function. This approach has the lowest operational overhead as it relies entirely on serverless, managed integrations.

Step-by-Step Solution

1
Identify the ordering constraint
Events must be processed in the exact sequence they occur for each patient (per-patient ordering), but events across different patients can be processed concurrently.
This requirement determines that a message grouping mechanism is needed rather than global ordering.
2
Evaluate SQS FIFO queue capability
SQS FIFO queues guarantee order at the message group level. Using patient ID as the Message Group ID fulfills the ordering requirement for each patient while allowing parallel processing across different patients.
SQS FIFO automatically manages ordered delivery within a group and allows concurrent consumption across groups without manual partition management.
3
Compare operational overhead of alternatives
SQS Standard queues cannot guarantee ordering, necessitating complex consumer-side sorting. Kinesis Data Streams requires active shard provisioning and management. SQS FIFO with Lambda provides a fully managed serverless scaling model with the least operational overhead.
Minimizing operational overhead is a key requirement of the solution.

Key Concept

Using Amazon SQS FIFO queues with Message Group IDs allows per-identifier ordered processing while scaling consumer processing in parallel.
Question 140Question →

A company hosts a web application on Amazon EC2 instances within an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ASG is configured with default settings. During a minor software failure, the web server process on one of the EC2 instances crashes. The ALB target group health checks correctly identify the instance as unhealthy and stop routing user traffic to it. However, the ASG does not terminate or replace the unhealthy instance, leading to reduced capacity. Which action should a solutions architect take to ensure the unhealthy instance is automatically replaced?

Show answer & explanation

Answer: Configure the Auto Scaling group to use Elastic Load Balancing (ELB) health checks instead of the default EC2 health checks.

Answer

Configure the Auto Scaling group to use Elastic Load Balancing (ELB) health checks instead of the default EC2 health checks.
By default, an Amazon EC2 Auto Scaling group only monitors EC2 status checks (which evaluate hypervisor and hardware health). If a web server process crashes but the OS is still running, the EC2 status checks will succeed. Configuring the Auto Scaling group to use Elastic Load Balancing (ELB) health checks forces the ASG to terminate and replace instances that fail the Application Load Balancer's target group health checks, maintaining application availability.

Step-by-Step Solution

1
Analyze the default behavior of the Auto Scaling group (ASG) health check mechanism.
By default, the ASG only uses EC2 status checks. Since the instance OS remains active and running during a web server application crash, the EC2 status check passes, and the ASG considers the instance healthy.
Understanding why the ASG does not automatically replace the instance is key to identifying the correct corrective configuration.
2
Determine how the Application Load Balancer (ALB) health checks behave.
The ALB performs application-level health checks (e.g., HTTP/HTTPS requests to a health path). It correctly identifies the instance as unhealthy and stops routing user traffic to it.
Since the load balancer already has the correct application health state, this state must be communicated to the ASG.
3
Modify the ASG health check type to integrate with the ALB.
Changing the ASG health check configuration from 'EC2' to 'ELB' allows the ASG to receive health status updates from the load balancer's target groups, terminating and replacing any instances marked unhealthy by the load balancer.
This configuration bridges the gap between application-level health status and instance lifecycle management.

Key Concept

Auto Scaling Group Health Check Integration with Elastic Load Balancing
Estimated Time:1m 30s
PreviousPage 7 / 20Next
Design Resilient Architectures Practice Questions — AWS Certified Solutions Architect - Associate — Page 7 | Examkin