Examkin

Design Resilient Architectures

382 questions

All types382Multiple choice195Multiple select187
Question 261Question →

A company runs a global mobile application with backend APIs hosted on Amazon EC2 instances behind Application Load Balancers (ALBs) in both the us-west-2 and eu-central-1 regions. Under normal conditions, users should be directed to the closest region to minimize latency. If the application in one region becomes unavailable, traffic must be automatically routed to the other region. The database backend consists of an Amazon Aurora Global Database with the primary cluster in us-west-2 and a read-only secondary cluster in eu-central-1. Which configuration should the solutions architect choose to meet these requirements?

Show answer & explanation

Answer: Create Route 53 Latency-based alias records pointing to the ALBs in both regions, and enable Evaluate Target Health on both records.

Answer

Create Route 53 Latency-based alias records pointing to the ALBs in both regions, and enable Evaluate Target Health on both records.
The correct configuration uses Route 53 Latency-based alias records pointing to the Application Load Balancers in both regions with Evaluate Target Health enabled. This ensures that users are directed to the region with the lowest latency under normal conditions. If one of the regions becomes unavailable, Route 53 detects the unhealthy status of the ALB and automatically routes subsequent DNS requests to the healthy region.

Step-by-Step Solution

1
Analyze the business requirements for latency and availability.
Under normal operations, traffic must route to the region with lowest latency (us-west-2 or eu-central-1), which requires an active-active configuration using Latency-based routing.
Latency-based routing ensures users are automatically directed to the AWS region that provides the lowest network latency.
2
Configure health checks for failover capability.
Evaluate Target Health must be enabled on the Route 53 Alias records pointing to the Application Load Balancers.
This allows Route 53 to inherit the health status of the ALBs from the load balancer target groups, preventing traffic from being sent to an unhealthy region.
3
Select the correct Route 53 record type.
Use Alias records instead of standard CNAME records.
Alias records are required to use the Evaluate Target Health feature and allow routing at the zone apex.

Key Concept

Combining Route 53 Latency Routing with Evaluate Target Health on Alias records allows active-active routing with automatic failover.
Question 262Question →

A company has a web application running on Amazon EC2 instances inside an Auto Scaling group (ASG). The instances are registered with an Amazon Application Load Balancer (ALB). The application process on several instances crashes, causing the ALB target group health checks to mark those instances as unhealthy. However, the ASG does not terminate and replace the unhealthy instances. Which configuration change will ensure that the Auto Scaling group automatically replaces instances that fail the Application Load Balancer health check?

Show answer & explanation

Answer: Update the Auto Scaling group health check type configuration from EC2 to ELB.

Answer

Update the Auto Scaling group health check type configuration from EC2 to ELB.
The correct answer is to update the Auto Scaling group's health check configuration to use ELB. By default, Auto Scaling groups only monitor EC2 status checks. If an application process crashes but the underlying EC2 instance remains running, the EC2 status checks will pass, and the Auto Scaling group will not replace the instance. Changing the health check type to ELB ensures the Auto Scaling group replaces any instance that fails the target group health checks.

Step-by-Step Solution

1
Analyze the current state of the Auto Scaling group's health check configuration.
The Auto Scaling group is currently configured to use only the default EC2 health check type.
By default, an Auto Scaling group only monitors EC2 status checks (such as hardware failures or operating system status) and does not automatically monitor the application-level health status reported by the Application Load Balancer.
2
Identify the configuration that integrates load balancer status with Auto Scaling lifecycle management.
The health check type needs to be updated to ELB.
When the ELB health check type is enabled, the Auto Scaling group will consider an instance unhealthy if either the EC2 status checks fail or the Elastic Load Balancing target group health check fails.
3
Implement the configuration change on the Auto Scaling group.
The Auto Scaling group automatically terminates and replaces instances when they fail the load balancer health check.
This configuration bridges the gap between the application-level checks performed by the load balancer and the lifecycle management of the Auto Scaling group.

Key Concept

Auto Scaling Group Health Check Types
Estimated Time:1m 0s
Question 263Question →

A multinational financial services firm hosts a critical transactional API across two AWS Regions: us-east-1 (primary) and us-west-2 (disaster recovery). In both regions, the API runs on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB) and is configured to listen on custom TCP port 8443. The firm uses Amazon Route 53 with failover routing policies pointing to the ALBs via Alias records. During a simulated failover drill, the API service on the EC2 instances in us-east-1 is stopped, causing the instances to become unhealthy. However, Route 53 does not route traffic to the us-west-2 ALB, and external clients continue to receive timeout errors from us-east-1. Which configuration changes must the solutions architect implement to resolve this issue and enable automated failover?

Show answer & explanation

Answer: Enable Evaluate Target Health on the Route 53 primary Alias record, and configure the ALB target group health check to query the custom application port 8443.

Answer

Enable Evaluate Target Health on the Route 53 primary Alias record, and configure the ALB target group health check to query the custom application port 8443.
The correct option is to enable Evaluate Target Health on the primary Route 53 Alias record and ensure the target group health check monitors port 8443. For an ALB Alias record, Route 53 determines health by evaluating the target group's health metrics. If 'Evaluate Target Health' is set to Yes and the target group correctly monitors the custom API port, the failure of the API service will cause all targets to become unhealthy, which in turn causes Route 53 to failover to the disaster recovery region.

Step-by-Step Solution

1
Analyze Route 53 Alias health evaluation behavior.
By default, Route 53 Alias records do not evaluate the health of the underlying resources (the ALB's targets) unless the 'Evaluate Target Health' parameter is explicitly set to Yes.
This is necessary because Route 53 needs permission and instructions to inspect the health of the ALB target group.
2
Examine the target group health check configuration.
The target group must query the port where the actual application is listening (port 8443) rather than a default port (like port 80).
If the health check port is misconfigured, the ALB may continue to report the instances as healthy even when the core API application has crashed or stopped.
3
Synthesize the requirements for automatic DNS failover.
Combining 'Evaluate Target Health' on the Alias record with a correct health check port configuration allows Route 53 to detect that zero healthy targets exist in the primary region's ALB target group, triggering an automatic failover to the secondary region.
Route 53 marks an ALB as unhealthy only when all targets in all associated target groups are unhealthy.

Key Concept

Route 53 DNS failover relies on the combination of Alias record health evaluation and accurate Application Load Balancer target group health checks.
Estimated Time:3m 0s
Question 264Question →

An organization is launching an internal analytics dashboard on Amazon EC2 instances managed by an Auto Scaling group. The dashboard application is configured to run on TCP port 8080. The instances are deployed in private subnets behind an Application Load Balancer (ALB). The solutions architect has associated a custom Network ACL (NACL) with the private subnets. Although security groups are configured to allow port 8080 traffic between the ALB and the EC2 instances, the ALB target group reports all instances as unhealthy. Local testing confirms the dashboard service is responding normally on port 8080.

Which combination of steps must the solutions architect take to resolve this issue and allow the health checks to pass? (Select two.)

Select all that apply

Show answer & explanation

Answer: Modify the target group's health check configuration to query port 8080 instead of the default port 80.; Add an outbound rule to the private subnet's custom Network ACL to allow TCP traffic to the load balancer subnet on ephemeral ports (1024-65535).

Answer

To resolve the unhealthy target status, the solutions architect must configure the target group health check port to 8080 and ensure the stateless Network ACL allows outbound ephemeral return traffic from the EC2 subnet to the Application Load Balancer.
The Application Load Balancer target group needs to be configured with the correct health check port (port 8080) to match the port where the dashboard application is running. By default, the health check may query port 80, which fails because the application is bound to port 8080. Additionally, since a custom Network ACL (NACL) is applied to the private subnets, outbound rules must be configured to allow return traffic. Because NACLs are stateless, they do not automatically track connections, and return traffic from the EC2 instances to the ALB must be explicitly allowed on ephemeral ports (1024-65535).

Step-by-Step Solution

1
Identify the port mismatch between the application and the load balancer health check configuration.
The health check port must be updated from the default (port 80) to port 8080.
The dashboard application is bound to port 8080; querying port 80 will fail as nothing is listening on it.
2
Analyze the custom Network ACL (NACL) configuration for the private subnets.
Add an outbound rule allowing TCP traffic on ephemeral ports (1024-65535) to the load balancer subnet.
Network ACLs are stateless, meaning return traffic from the EC2 instances to the load balancer must be explicitly permitted.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) configuration with stateless Network ACLs and custom ports
Question 265Question →

An enterprise application uses a proprietary TCP-based protocol to process transactions. The application runs on Amazon EC2 instances within private subnets, managed by an Auto Scaling group (ASG) behind a Network Load Balancer (NLB). The application daemon listens on TCP port 7001 for transaction traffic, while a separate monitoring service on the same instances listens on TCP port 7005 to report health status. Currently, the NLB target group is configured to use the TCP protocol, with the health check port set to 'traffic-port'. The target group health checks are failing, causing the NLB to mark all instances as unhealthy and prevent transaction routing. The Security Group assigned to the EC2 instances permits inbound TCP traffic on ports 7001 and 7005 from the VPC CIDR. The subnets use a custom Network Access Control List (NACL) that permits inbound TCP traffic on ports 7001 and 7005 from the VPC CIDR, but contains no outbound rules other than the default deny rule. Which combination of actions should a Solutions Architect take to resolve the health check failure and allow transactions to flow? (Select two.)

Select all that apply

Show answer & explanation

Answer: Update the target group configuration to specify port 7005 as the health check port instead of using the traffic port.; Add an outbound rule to the subnet's Network ACL allowing TCP traffic to the ephemeral port range (1024–65535) to handle return traffic.

Answer

Update the target group configuration to specify port 7005 as the health check port instead of using the traffic port, and add an outbound rule to the subnet's Network ACL allowing TCP traffic to the ephemeral port range (1024–65535) to handle return traffic.
The target group must be configured to probe port 7005, which is where the health status service is running, rather than the default traffic port (port 7001). Additionally, because Network ACLs are stateless, any inbound request (such as a health check or transaction request) requires an explicit outbound rule to allow the response traffic to return to the client's or load balancer's ephemeral ports (1024–65535). Configuring these two changes resolves the communication block and allows the load balancer to accurately verify instance health and route client traffic.

Step-by-Step Solution

1
Analyze the health check port mismatch.
Identify that the daemon listens for transactions on port 7001 but health checks are on port 7005. Since the target group is configured to use 'traffic-port' (port 7001), the NLB is probing the wrong port, causing health check failures.
Health check probes must be sent to the port where the monitoring service is actively listening.
2
Analyze the Network ACL configurations.
Identify that the custom NACL has no outbound rules other than the default deny rule. Because NACLs are stateless, they do not automatically allow return traffic for established inbound connections.
To allow the EC2 instances to respond to health checks and clients, an outbound NACL rule is required to permit traffic to the ephemeral ports (1024-65535) used by the source initiators.
3
Evaluate the stateful nature of Security Groups.
Determine that the Security Group assigned to the EC2 instances does not need outbound rule modifications for return traffic because Security Groups are stateful and automatically allow return traffic.
Modifying security group outbound rules for ephemeral port return traffic is unnecessary and does not resolve stateless NACL blocks.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB)
Estimated Time:2m 30s
Question 266Question →

A company is designing a disaster recovery (DR) architecture for a web application using an active-passive strategy. The primary environment runs on Amazon EC2 instances behind an Application Load Balancer (ALB) in the us-east-1 Region. The secondary environment consists of a static maintenance page hosted on an Amazon S3 bucket configured for website hosting in the us-west-2 Region. The company wants to use Amazon Route 53 to automatically redirect user traffic to the maintenance page if the primary environment becomes unavailable. Which two configurations must the solutions architect implement to achieve this goal? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure a primary Failover alias record pointing to the Application Load Balancer in us-east-1, and set Evaluate Target Health to Yes.; Configure a secondary Failover alias record pointing to the Amazon S3 bucket website endpoint in us-west-2.

Answer

Configure a primary Failover alias record pointing to the Application Load Balancer in us-east-1 with Evaluate Target Health set to Yes, and configure a secondary Failover alias record pointing to the Amazon S3 bucket website endpoint in us-west-2.
To implement active-passive failover using Amazon Route 53, the Solutions Architect must create a primary Failover alias record pointing to the Application Load Balancer (ALB) and enable 'Evaluate Target Health'. When Evaluate Target Health is set to Yes, Route 53 inherits the health status of the ALB and its backend targets. The architect must also configure a secondary Failover alias record pointing to the Amazon S3 static website endpoint. Under normal conditions, Route 53 routes all queries to the primary ALB. If the ALB becomes unhealthy, Route 53 automatically switches routing to the secondary S3 website endpoint.

Step-by-Step Solution

1
Configure the primary routing endpoint.
A primary Failover alias record is created pointing to the primary ALB.
Alias records allow Route 53 to natively route traffic to AWS resources like an ALB without extra query charges. Setting 'Evaluate Target Health' to Yes tells Route 53 to monitor the health of the ALB and its targets.
2
Configure the secondary routing endpoint.
A secondary Failover alias record is created pointing to the Amazon S3 static website endpoint.
This establishes the active-passive DR pair, ensuring traffic shifts to the static page when the primary record is determined to be unhealthy.

Key Concept

Active-passive DNS failover using Route 53 Failover routing policies and Alias records with target health evaluation.
Question 267Question →

A company hosts a secure financial transaction processing service on 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 listens on port 8443. However, due to security compliance, the application health check endpoint runs on a separate administrative service on port 8080 on the same instances. The target group is configured with the port set to 8443, and the health check port is set to the default 'traffic-port'. The EC2 instances are in private subnets, while the ALB is in public subnets. Custom Network ACLs (NACLs) are applied to both subnets. The security groups are configured to allow port 8443 and port 8080 inbound from the ALB security group, and outbound security groups are configured to allow all traffic. After deployment, the ALB marks all targets as unhealthy, and the ASG begins continuously terminating and replacing the instances. Which combination of actions will resolve this issue? (Select two.)

Select all that apply

Show answer & explanation

Answer: Modify the target group's health check configuration to explicitly set the health check port to 8080.; Add an outbound rule to the private subnet's Network ACL allowing traffic to the public subnets on ephemeral ports (1024-65535).

Answer

To resolve the health check failure, you must override the target group health check port configuration to explicitly probe port 8080, and add an outbound rule to the private subnet's Network ACL to permit return traffic to the public subnets on ephemeral ports (1024-65535).
The correct options are the actions to modify the target group's health check configuration to explicitly set the health check port to port 8080, and to add an outbound rule to the private subnet's Network ACL allowing traffic to the public subnets on ephemeral ports (1024-65535). Overriding the health check port is necessary because the target group traffic port (8443) does not host the health check service. Furthermore, because Network ACLs are stateless, an outbound rule is required on the private subnet to permit the return traffic initiated by the load balancer, which falls within the ephemeral port range.

Step-by-Step Solution

1
Analyze the target group configuration and locate the port mismatch.
The target group is configured to forward client traffic to port 8443, but the health check port is set to 'traffic-port'. This causes the ALB to probe port 8443 for health checks, whereas the administrative service only listens on port 8080.
By default, the target group uses the traffic port for health checks unless overridden.
2
Identify the remedy for the health check port mismatch.
Modify the target group settings to override the health check port, changing it from 'traffic-port' to 8080.
This directs the ALB health probes to the correct service running on the instances.
3
Evaluate the network filtering layer for potential blocks.
Since the ALB is in the public subnets and the EC2 instances are in the private subnets with custom Network ACLs, we must assess NACL rules. Security groups are stateful and allow return traffic automatically, but Network ACLs are stateless.
Stateless filters require explicit rules for both inbound request traffic and outbound return traffic.
4
Formulate the correct Network ACL configuration.
Ensure the private subnet's Network ACL has an outbound rule allowing traffic back to the public subnets (where the ALB resides) on ephemeral ports (1024-65535).
When the ALB establishes a connection to the backend target, the response traffic from the target is sent back using the ephemeral port range of the client (the ALB).

Key Concept

Configuring load balancer health checks on custom ports requires overriding the target group health check settings, and ensuring stateless network filters (Network ACLs) are configured to permit return traffic on ephemeral ports.
Estimated Time:3m 0s
Question 268Question →

A company hosts a web application on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application listens on custom port 84438443 for HTTPS traffic. The target group is configured to forward traffic to port 84438443. Although the application is running normally and accepting connections locally, the ALB is marking all EC2 instances as unhealthy. The EC2 instance security group allows inbound traffic on port 84438443 from the ALB security group. Which of the following is the most likely cause of this issue?

Show answer & explanation

Answer: The target group's health check configuration is using the default protocol port of 8080 instead of 84438443 or the 'traffic-port' setting.

Answer

The target group's health check configuration is using the default protocol port of 8080 instead of 84438443 or the 'traffic-port' setting.
The correct answer states that the target group's health check is misconfigured to use the default protocol port of 8080. In AWS Elastic Load Balancing, target groups default to performing health checks on the protocol's standard port (such as port 8080 for HTTP) unless they are explicitly configured to use a custom port or the 'traffic-port' setting. Since the web application is only listening on port 84438443, health check probes sent to port 8080 fail, leading the ALB to identify the targets as unhealthy.

Step-by-Step Solution

1
Analyze the application port settings and target group settings.
The application listens on port 84438443, the target group forwards traffic to port 84438443, and the EC2 security group allows inbound traffic on port 84438443 from the ALB.
This confirms that the application is reachable on its listening port from the ALB, meaning the issue must be related to health check configurations or misconfigured network filters.
2
Examine target group default behaviors for health checks.
By default, the target group health check uses the default protocol port (8080 for HTTP) unless explicitly configured otherwise.
Since the application only runs on port 84438443, health checks sent to port 8080 will not be answered, causing the ALB to mark the instances as unhealthy.
3
Evaluate network configuration distractors regarding statefulness.
Security groups are stateful, so no outbound rule is needed on the EC2 instances. Network ACLs are stateless, but return traffic from the EC2 targets back to the ALB uses ephemeral ports (10241024-6553565535), not port 84438443.
This rules out security group and Network ACL configuration misconceptions as the root cause of the unhealthy status.

Key Concept

ELB Target Group Health Check Port configuration and its default protocol port behavior.
Estimated Time:1m 30s
Question 269Question →

A solutions architect is deploying a web application on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application runs on a custom port 8080. The security group of the EC2 instances allows inbound traffic only from the ALB's security group on port 8080. The solutions architect needs to configure the environment so that unhealthy instances are automatically detected and replaced by the ASG. Which TWO configurations should the solutions architect perform to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the target group health check port to use the traffic port or port 8080.; Configure the Auto Scaling group to use Elastic Load Balancing (ELB) health checks.

Answer

Configure the target group health check port to use the traffic port or port 8080, and configure the Auto Scaling group to use Elastic Load Balancing (ELB) health checks.
To ensure correct application health detection and automatic recovery, the Solutions Architect must perform two actions. First, the Application Load Balancer target group must perform health checks on the actual port where the application is listening (port 8080) because the security group blocks other ports such as the default port 80. Second, the Auto Scaling group must have its health check type set to 'ELB' so it can receive health check failures from the load balancer and automatically replace unhealthy instances.

Step-by-Step Solution

1
Align the Target Group health check port with the application's listening port.
The target group health checks are sent to port 8080, which is allowed by the security group and listened to by the web server.
By default, target groups run health checks on the traffic port or port 80. Since the custom application port is 8080 and security groups block port 80, the default checks would fail.
2
Enable ELB health checks in the Auto Scaling group configuration.
The Auto Scaling group receives health status updates from the Application Load Balancer target group.
By default, the ASG only uses EC2 status checks (hardware/system level). It must be explicitly configured to use ELB health checks so that application-level failures detected by the ALB prompt the replacement of unhealthy instances.

Key Concept

ELB health checks integrated with Auto Scaling groups for custom application ports.
Question 270Question →

A company is hosting a simple web application on Amazon EC2 instances. The instances are managed by an Auto Scaling group (ASG) and receive traffic through an Application Load Balancer (ALB). The web application is configured to run on custom port 80808080. The solutions architect needs to configure the load balancer and security groups to ensure traffic is correctly routed and instances are properly monitored.

Which of the following actions should the solutions architect perform to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the target group of the Application Load Balancer to perform health checks on the custom port 80808080.; Configure the security group of the EC2 instances to allow inbound traffic from the security group of the Application Load Balancer on port 80808080.

Answer

Configure the target group of the Application Load Balancer to perform health checks on the custom port 80808080, and configure the security group of the EC2 instances to allow inbound traffic from the security group of the Application Load Balancer on port 80808080.
To ensure that the Application Load Balancer (ALB) can successfully route traffic and monitor the health of the EC2 instances, the target group health checks must query the port where the application is listening (port 80808080). Additionally, the security group attached to the EC2 instances must allow inbound traffic on port 80808080 from the security group of the ALB.

Step-by-Step Solution

1
Identify the application port configuration.
The application listens on custom port 80808080.
All traffic from the load balancer and health checks must be routed to this specific port.
2
Set the health check port for the ELB Target Group.
The Target Group is configured to run active health checks on port 80808080.
If default port 8080 is used, health check probes will fail because no service is listening on port 8080, causing the ALB to flag all instances as unhealthy.
3
Configure instance-level security groups to accept traffic.
The EC2 instances' security group is updated to allow inbound TCP traffic on port 80808080 from the ALB's security group source.
This allows the ALB to forward client requests and perform health check probes successfully.

Key Concept

ELB Target Group health check configurations and security group port alignment for custom application ports.
Estimated Time:1m 0s
Question 271Question →

A logistics company operates a fleet of IoT tracking devices that transmit real-time location telemetry using a custom UDP-based protocol to Amazon EC2 instances behind a Network Load Balancer (NLB) in a single AWS Region. The company also hosts a web portal where global clients download large, historical tracking reports in PDF format stored in an Amazon S3 bucket. Clients are experiencing high latency when downloading reports, and the IoT devices suffer from packet loss over the public internet during peak hours. A solutions architect must design a highly resilient architecture to reduce latency and packet loss. Which solution should the solutions architect recommend?

Show answer & explanation

Answer: Deploy AWS Global Accelerator to route the UDP telemetry traffic to the Network Load Balancer, and create an Amazon CloudFront distribution to cache and serve the PDF reports from the Amazon S3 bucket.

Answer

Deploy AWS Global Accelerator to route the UDP telemetry traffic to the Network Load Balancer, and create an Amazon CloudFront distribution to cache and serve the PDF reports from the Amazon S3 bucket.
The correct solution uses AWS Global Accelerator to route the UDP telemetry traffic over the AWS global network to the Network Load Balancer, minimizing latency and packet loss. Concurrently, it uses Amazon CloudFront to cache and serve the static PDF reports from the S3 bucket close to the users, offloading the S3 origin and optimizing performance.

Step-by-Step Solution

1
Analyze the protocols and traffic types: the telemetry stream uses a custom UDP protocol, and the historical reports are static PDF files delivered over HTTPS.
Identify that CloudFront cannot be used for the UDP stream as it only supports HTTP/HTTPS, and that S3 downloads are static and would benefit from edge caching.
Choosing the correct acceleration and delivery mechanism depends on protocol support and content type (cachable vs non-cachable).
2
Select the appropriate network acceleration tool for the UDP traffic to solve packet loss and latency over the public internet.
Select AWS Global Accelerator, which provides static IP addresses and Anycast routing to direct UDP traffic over the AWS global network to the NLB, bypassing public internet congestion.
Route 53 latency routing only resolves DNS and does not optimize path transit or prevent packet loss over the public internet.
3
Select the caching solution for the static PDF files stored in S3.
Select Amazon CloudFront to cache the PDF files at Edge Locations globally.
Caching static files close to users reduces latency and offloads read operations from the origin S3 bucket, maintaining high availability.

Key Concept

Selecting and combining Amazon CloudFront and AWS Global Accelerator based on protocol support and caching requirements.
Question 272Question →

An enterprise application hosted on Amazon EC2 instances inside an Auto Scaling group (ASG) is positioned behind an Application Load Balancer (ALB). The ALB target group has stickiness enabled using ALB-generated duration-based cookies. The ASG is configured with a target tracking scaling policy based on the average CPU utilization metric. During a promotional event, a small number of heavy API clients initiate a massive volume of concurrent requests. System administrators observe that a few EC2 instances become severely overloaded and fail health checks, while the remaining instances in the ASG remain underutilized. The ASG does not scale out to add more capacity. Which action should the solutions architect take to resolve the performance imbalance and ensure the application scales effectively?

Show answer & explanation

Answer: Disable target group stickiness on the Application Load Balancer and modify the application to store session state externally in an Amazon ElastiCache cluster.

Answer

Disable target group stickiness on the Application Load Balancer and modify the application to store session state externally in an Amazon ElastiCache cluster.
Disabling target group stickiness on the Application Load Balancer allows traffic to be distributed evenly across all healthy EC2 instances in the Auto Scaling group using the configured load balancing algorithm (such as round-robin or least outstanding requests). Storing session state externally in Amazon ElastiCache ensures the application remains stateless, preventing localized overloads from heavy API consumers and enabling the target tracking policy based on average CPU utilization to scale the Auto Scaling group out or in accurately.

Step-by-Step Solution

1
Analyze the current architecture's bottleneck caused by stickiness and target tracking.
Identify that ALB-generated cookie stickiness binds specific heavy clients to specific EC2 instances, causing localized CPU spikes on those instances.
Average CPU utilization of the ASG remains below the scaling threshold because underutilized instances balance out the average, preventing scale-out.
2
Evaluate the options for scaling stateless versus stateful application components.
Determine that making the application tier stateless by offloading session storage to a caching tier is necessary to distribute traffic evenly.
Decoupling session state allows any instance to handle any request, enabling effective load balancing.
3
Configure the Application Load Balancer and session storage backend.
Disable target group stickiness on the ALB and provision an Amazon ElastiCache cluster for external session storage.
This permits the ALB to distribute requests evenly via round-robin or least outstanding requests, ensuring that CPU utilization rises uniformly across the ASG and triggers auto-scaling correctly under heavy load.

Key Concept

Decoupling session state from compute instances to enable effective load balancing and auto-scaling.
Estimated Time:3m 0s
Question 273Question →

An enterprise is migrating a stateful legacy web application to AWS. The application runs on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application listens on custom port 8080. During testing under load, users experience session loss and are forced to log in repeatedly when the application scales. Additionally, during scale-in events, users whose requests are currently being processed experience immediate connection drops and HTTP 502/504 errors. The network and security teams require strict control over VPC boundaries using both security groups and Network ACLs (NACLs).

Which two actions should a solutions architect take to resolve the session issues and prevent request failures during scale-in? (Select two.)

Select all that apply

Show answer & explanation

Answer: Enable sticky sessions (session affinity) on the Application Load Balancer target group using duration-based cookies.; Configure a deregistration delay (connection draining) on the Application Load Balancer target group.

Answer

Enable sticky sessions (session affinity) on the target group, and configure a deregistration delay (connection draining) on the target group.
To resolve the session loss issues in a stateful application, sticky sessions (session affinity) must be enabled on the Application Load Balancer target group so that a client is repeatedly routed to the same backend instance. To prevent active connections and requests from being cut off during scale-in operations, a deregistration delay (connection draining) must be configured on the target group to keep the connections alive until the in-flight requests complete.

Step-by-Step Solution

1
Address session loss by binding users to their session-holding instances.
Enabling sticky sessions (session affinity) on the target group ensures that subsequent requests from the same user are sent to the same EC2 instance, avoiding session loss.
Because the application is stateful and stores session data locally, routing requests to different instances causes session drops.
2
Address connection drops during scaling down events by delaying instance termination.
Configuring a deregistration delay (connection draining) ensures that the load balancer keeps active connections open until in-flight requests finish, up to the configured limit, before the ASG terminates the instance.
This prevents HTTP 502/504 errors and immediate session termination when the ASG attempts to scale in.

Key Concept

ELB Sticky Sessions and Deregistration Delay
Question 274Question →

A startup is deploying a new API service on Amazon EC2 instances managed by an Auto Scaling group (ASG). The API service is configured to run on port 5000. An Application Load Balancer (ALB) is configured to route traffic to these instances. However, the ALB shows all targets in the target group as unhealthy. A solutions architect verifies that the API service is running on the instances. Which two configurations are required to resolve this issue and allow the ALB to perform successful health checks? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the target group health check settings to use port 5000 or the traffic port.; Update the security group associated with the EC2 instances to allow inbound traffic on port 5000 from the security group of the Application Load Balancer.

Answer

Configure the target group health check settings to use port 5000 or the traffic port, and update the security group associated with the EC2 instances to allow inbound traffic on port 5000 from the security group of the Application Load Balancer.
The Application Load Balancer must be configured to send health check requests to the port where the API service is listening, which is port 5000. Additionally, the security group for the EC2 instances must allow inbound traffic on port 5000 from the ALB's security group so the health check probes can successfully reach the instances.

Step-by-Step Solution

1
Identify the application port and verify health check settings.
The application runs on port 5000, but standard health checks default to port 80 or traffic port if not customized.
To verify health, the load balancer must query the specific port where the application is listening.
2
Ensure network path and security group permissions are open.
The target EC2 instances must allow inbound traffic from the ALB on port 5000.
Security groups are stateful; allowing inbound traffic on port 5000 from the ALB security group allows both health check probes and client request traffic.

Key Concept

Application Load Balancer health checks require alignment between the target group health check port configuration, the application listening port, and security groups that permit traffic from the load balancer.
Question 275Question →

A company hosts a critical customer registration service at the apex domain example.com. The backend API is deployed using Regional Amazon API Gateway endpoints in us-east-1 (primary) and us-west-2 (secondary standby). The company needs to design an active-passive disaster recovery strategy that automatically routes all API traffic to us-west-2 if the us-east-1 regional endpoint becomes unavailable. The DNS records are managed in Amazon Route 53.

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

Select all that apply

Show answer & explanation

Answer: Create an HTTPS-based Route 53 health check that monitors the health of the primary regional API Gateway endpoint, and associate this health check with the primary DNS record.; Configure a primary Failover Alias record for the apex domain pointing to the primary regional API Gateway custom domain name, and configure a secondary Failover Alias record pointing to the secondary regional API Gateway custom domain name, setting 'Evaluate Target Health' to 'No' on both.

Answer

Configure an HTTPS-based Route 53 health check for the primary regional API Gateway endpoint and associate it with the primary DNS record, and create primary and secondary Failover Alias records pointing to the regional custom domain names with 'Evaluate Target Health' set to 'No'.
To configure active-passive failover for regional API Gateway endpoints at the apex domain, you must use Route 53 Failover Alias records. Because API Gateway regional custom domains do not support Route 53's automatic 'Evaluate Target Health' functionality, you must set 'Evaluate Target Health' to 'No' on both alias records. Additionally, you must create a custom HTTPS Route 53 health check that probes the primary regional API Gateway endpoint and associate this health check with the primary Failover Alias record.

Step-by-Step Solution

1
Create an HTTPS-based Route 53 health check to monitor the health of the primary API Gateway regional endpoint.
A DNS health check is created that regularly probes the status of the primary API Gateway endpoint.
API Gateway regional custom domain names do not support the automated 'Evaluate Target Health' feature, so an external health check is required to detect endpoint failure.
2
Configure primary and secondary Failover Alias records for the apex domain pointing to the regional API Gateway custom domains.
DNS queries to the apex domain will resolve to the primary endpoint under normal operation and fail over to the secondary standby endpoint if the health check fails.
Failover routing policies are required for active-passive DNS configurations, and setting 'Evaluate Target Health' to 'No' allows the custom health check to govern the failover state.

Key Concept

Configuring active-passive Route 53 DNS failover for regional API Gateway endpoints using custom health checks and Failover Alias records.
Question 276Question →

A company hosts a latency-sensitive API on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The API processes user transactions on TCP port 8443. A separate monitoring agent on each instance listens on TCP port 9999 to report service health metrics. The ALB's target group is configured to perform health checks on port 9999. The subnet's stateless Network Access Control List (NACL) allows inbound TCP traffic on port 8443 from all sources and allows all outbound traffic.

To meet security compliance, a security engineer modifies the subnet NACL's outbound rule to only allow outbound TCP traffic to port 8443. Immediately after this change, the ALB marks all instances in the target group as unhealthy. Furthermore, Route 53, which is configured with latency-based routing policies to distribute traffic between this Region and another active Region, continues to send client requests to the unhealthy ALB.

Which combination of actions will restore the target health status and ensure Route 53 diverts traffic away from this Region during a failure? (Select two.)

Select all that apply

Show answer & explanation

Answer: Modify the subnet Network ACLs to allow inbound TCP traffic on port 9999 and outbound TCP traffic to ephemeral ports (1024-65535).; Configure 'Evaluate Target Health' to Yes on the Route 53 alias records that point to the Application Load Balancer.

Answer

Modify the subnet Network ACLs to allow inbound TCP traffic on port 9999 and outbound TCP traffic to ephemeral ports (1024-65535), and configure 'Evaluate Target Health' to Yes on the Route 53 alias records that point to the Application Load Balancer.
The correct solution requires configuring the stateless subnet Network ACLs to allow the inbound health check traffic on port 9999 and the outbound return traffic to the load balancer's ephemeral ports (1024-65535). Additionally, enabling 'Evaluate Target Health' on the Route 53 alias records ensures that Route 53 monitors the health of the targets behind the Application Load Balancer and diverts traffic to the healthy Region if all targets are unhealthy.

Step-by-Step Solution

1
Analyze the health check failure caused by the outbound Network ACL rule modification.
The ALB health check queries port 9999. Since the subnet Network ACL is stateless, restricting outbound traffic to port 8443 prevents the EC2 instances from sending TCP responses back to the ALB's health check requests.
Stateless Network ACLs require explicit rules for both inbound request traffic and outbound return traffic.
2
Determine the necessary Network ACL rules to allow the health check traffic.
An inbound rule must allow TCP port 9999 traffic from the ALB, and an outbound rule must allow TCP traffic to ephemeral ports (1024-65535) back to the ALB.
The ALB initiates connections to port 9999 from its ephemeral ports, which requires the return traffic to be allowed outbound.
3
Determine why Route 53 continues routing traffic to the unhealthy Region.
Route 53 latency-based routing distributes traffic based on latency but does not automatically monitor endpoint health unless explicitly configured.
Route 53 alias records pointing to Application Load Balancers must have 'Evaluate Target Health' set to Yes to dynamically fail over when the backend targets are unhealthy.

Key Concept

Configuring health checks and routing for resilience with stateless Network ACLs and Route 53 latency-based routing.
Question 277Question →

A company runs a high-availability customer portal on Amazon EC2 instances managed by an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB). The ALB target group is configured with ELB health checks targeting a deep health check endpoint (`/healthcheck`) that queries the backend Amazon RDS database. During a scheduled database maintenance window, the database becomes temporarily unresponsive. Consequently, all EC2 instances fail the target group health check. Since the ASG health check type is set to ELB, it begins terminating and recreating all instances in a continuous loop, causing prolonged downtime and high operational costs. Which architectural modification should a Solutions Architect implement to prevent this loop of instance terminations during database outages?

Show answer & explanation

Answer: Configure the ALB health check to query a shallow endpoint that only verifies the web server status, and handle database connectivity issues gracefully within the application code.

Answer

Configure the ALB health check to query a shallow endpoint that only verifies the web server status, and handle database connectivity issues gracefully within the application code.
The correct answer is to configure a shallow health check. A shallow health check only verifies that the web server or application process is running (e.g., via a simple static file or status page), rather than verifying deep dependencies like database connectivity. When the database becomes unavailable, the web server instances will still pass the shallow health check, preventing the Auto Scaling Group from terminating them. The application can then handle the database outage gracefully by displaying a maintenance page or returning a structured error code, while keeping the infrastructure stable.

Step-by-Step Solution

1
Identify the root cause of the instance termination loop.
The deep health check queries the database, causing the ALB to mark instances as unhealthy when the database is down, which prompts the ASG to terminate healthy web server instances.
Understanding the dependency between target group health checks and ASG instance lifecycle is critical to troubleshooting termination loops.
2
Modify the target group health check configuration to use a shallow endpoint.
The health check path is changed to target a static page or a lightweight endpoint (e.g., `/ping` or `/index.html`) that only verifies the web server process itself is running.
A shallow health check ensures the load balancer only monitors the health of the EC2 instance and the web server process, preventing database outages from triggering instance termination.
3
Implement application-level error handling for database connection failures.
The application handles database connection errors gracefully (e.g., by displaying a friendly error message or a read-only view) without failing the ALB health check.
Graceful degradation ensures the application remains online to serve static content or error messages rather than experiencing a complete infrastructure tear-down.

Key Concept

Shallow vs. Deep Health Checks in Elastic Load Balancing and Auto Scaling Groups
Question 278Question →

A financial company hosts a reporting application on a fleet of Amazon EC2 instances managed by an Auto Scaling group (ASG). The instances run in private subnets and are registered with an Application Load Balancer (ALB). The application receives traffic on port 8000, but its health check endpoint is exposed on administrative port 8081. Currently, the ALB is marking all instances as unhealthy, and the ASG is continuously terminating and replacing them. Which two configurations are required to resolve this issue and allow the ALB to perform health checks successfully? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the health check port in the ALB target group settings to port 8081.; Add a rule to the EC2 instances' security group allowing inbound TCP traffic on port 8081 from the ALB's security group.

Answer

The target group health check settings must be updated to use port 8081, and the security group of the EC2 instances must be modified to allow inbound TCP traffic on port 8081 from the security group of the Application Load Balancer.
To resolve the issue, the solutions architect must configure the ALB target group's health check port to match the administrative port (8081) where the application is listening for health status checks. Additionally, the security group for the EC2 instances must allow inbound TCP traffic on port 8081 from the security group of the Application Load Balancer, ensuring the health check requests are permitted through the instance's firewall.

Step-by-Step Solution

1
Identify the ports involved in the scenario.
The application receives client traffic on port 8000, while the health check endpoint is on port 8081.
Since these are different, the default behavior of targeting the traffic port (8000) for health checks will fail.
2
Configure the target group to query the custom health check port.
Override the target group health check port setting by specifying port 8081.
This ensures the ALB sends health check requests to the administration port where the health endpoint is running.
3
Configure the host security controls to allow health check traffic.
Allow inbound traffic on port 8081 from the ALB security group in the EC2 instance security group.
Security groups act as a stateful firewall at the instance level and must explicitly permit the health check queries from the load balancer.

Key Concept

Configuring Application Load Balancer health checks on custom ports requires overriding the health check port in the target group and allowing the traffic through instance-level security groups.
Question 279Question →

An online banking platform uses an Application Load Balancer (ALB) in the eu-west-1 Region to route portal traffic to backend EC2 instances. To meet disaster recovery compliance, the organization has deployed a warm standby replica of their application stack in the ap-southeast-2 Region, which includes a standby ALB and a cross-region Amazon RDS Read Replica. The organization wants to configure Amazon Route 53 to support automated active-passive routing for their zone apex domain (bank.com). If the primary region's ALB becomes unhealthy, traffic must fail over to the standby region, where the database replica will be promoted manually. Which Route 53 routing configuration should a solutions architect recommend to meet these requirements?

Show answer & explanation

Answer: Create a primary Failover Alias record for bank.com pointing to the eu-west-1 ALB, and a secondary Failover Alias record pointing to the ap-southeast-2 ALB. Set Evaluate Target Health to Yes on both records.

Answer

Create a primary Failover Alias record for bank.com pointing to the eu-west-1 ALB, and a secondary Failover Alias record pointing to the ap-southeast-2 ALB. Set Evaluate Target Health to Yes on both records.
The correct configuration uses Route 53 Failover routing with Alias records pointing to the Application Load Balancers. Alias records are required because the destination is the zone apex domain (bank.com), which cannot have CNAME records. Setting 'Evaluate Target Health' to Yes allows Route 53 to inherit the health status of the ALB targets directly, enabling automated DNS failover without requiring separate custom health checks.

Step-by-Step Solution

1
Select the correct record type and routing policy for active-passive failover at the zone apex.
Identify that a Failover routing policy is required for active-passive routing, and Alias records must be used instead of CNAME records because the target is the zone apex (bank.com).
DNS RFCs do not allow CNAME records at the zone apex, but Route 53 Alias records can map the zone apex directly to AWS resources like ALBs.
2
Configure health checking to monitor the primary and secondary endpoints.
Set Evaluate Target Health to Yes on both the primary and secondary Alias records.
Setting Evaluate Target Health to Yes tells Route 53 to evaluate the health of the ALB using its target group health checks, eliminating the need to configure custom Route 53 health checks.
3
Verify database promotion requirements.
Ensure that the RDS Read Replica promotion remains a separate operational step, as Route 53 is a DNS service and cannot promote databases.
Route 53 only handles DNS routing; database failover/promotion must be handled at the database or application layer.

Key Concept

Route 53 Failover Routing with Alias Records
Question 280Question →

A healthcare clinic hosts a patient scheduling application on a fleet of Amazon EC2 instances. The instances are registered with a target group for an Application Load Balancer (ALB) and managed by an Auto Scaling group. The clinic's IT team reports that the ALB target group shows all EC2 instances as unhealthy, preventing patients from accessing the portal. However, verification confirms that the web service is running normally on the instances themselves. What is the most likely cause of this behavior?

Show answer & explanation

Answer: The security group for the EC2 instances does not allow inbound traffic from the security group of the Application Load Balancer.

Answer

The security group for the EC2 instances does not allow inbound traffic from the security group of the Application Load Balancer.
For an Application Load Balancer to successfully perform health checks, the security group assigned to the registered EC2 instances must explicitly permit inbound traffic from the Application Load Balancer's security group on the application's port. Since security groups are stateful, return traffic is automatically allowed.

Step-by-Step Solution

1
Identify where the failure is occurring.
The target group health checks are failing, meaning the Application Load Balancer cannot reach the instances on the health check port.
Since the application runs fine locally, the problem lies in network connectivity or permissions between the ALB and the EC2 instances.
2
Evaluate security configurations governing internal traffic between the ALB and EC2 instances.
Confirm that the security group of the EC2 instances must allow inbound traffic from the ALB's security group on the application port.
By default, security groups block all inbound traffic unless explicitly permitted. If the EC2 instances do not allow inbound traffic from the ALB, health checks will fail.

Key Concept

Elastic Load Balancing health checks and Security Group rules
Estimated Time:1m 0s
PreviousPage 14 / 20Next
Design Resilient Architectures Practice Questions — AWS Certified Solutions Architect - Associate — Page 14 | Examkin