All practice questions

1462 questions

All types1,462 Multiple choice739 Multiple select723

A corporate training provider is developing a new online portal. The portal requires two databases:

1. A database to cache active user session states during training modules. The traffic is highly unpredictable and experiences sudden, intense spikes when new courses are published, but is otherwise near zero.
2. A database to store employee profiles and certification histories. This workload is highly predictable and stable, with minor, gradual increases during business hours.

Which TWO database configurations should a solutions architect recommend to achieve the most cost-effective solution? (Select TWO.)

Select all that apply

Use Amazon DynamoDB in on-demand capacity mode for the session cache workload.

Use Amazon RDS for PostgreSQL with provisioned capacity for the relational database, and purchase database Reserved Instances for the baseline usage.

Use Amazon DynamoDB in provisioned capacity mode for the session cache to ensure maximum throughput during sudden spikes.

Use Amazon RDS for PostgreSQL and configure the application to promote a read replica to the primary instance during peak write periods to handle the workload.

Purchase AWS Compute Savings Plans to automatically apply hourly discounts to the DynamoDB tables and Amazon RDS DB instances.

Show answer & explanation

Answer: Use Amazon DynamoDB in on-demand capacity mode for the session cache workload.; Use Amazon RDS for PostgreSQL with provisioned capacity for the relational database, and purchase database Reserved Instances for the baseline usage.

Answer

Use Amazon DynamoDB in on-demand capacity mode for the session cache, and use Amazon RDS for PostgreSQL with provisioned capacity combined with Reserved Instances for the relational database.

For the session cache, the unpredictable and spiky traffic pattern is best served by Amazon DynamoDB in on-demand mode. This ensures the system scales instantly to meet the spikes without incurring charges during idle hours. For the stable and predictable relational database, using Amazon RDS for PostgreSQL with database Reserved Instances provides the highest cost savings for a continuous baseline workload.

Step-by-Step Solution

Analyze the capacity requirements for the session cache workload.

The session cache workload has highly unpredictable spikes and long periods of near-zero traffic. On-demand capacity mode in DynamoDB is the most cost-effective since it avoids over-provisioning costs.

On-demand capacity mode charges only for actual read/write requests, making it cheaper than maintaining a high provisioned throughput that is rarely utilized.

Analyze the capacity requirements for the employee profile and certification database.

The profile database workload is relational (PostgreSQL), predictable, and continuous. Standard RDS with Reserved Instances (RIs) is the most cost-effective.

Reserved Instances provide substantial discounts for database workloads that run continuously with a predictable baseline.

Evaluate and rule out non-applicable discount options and architectural patterns.

Rule out Compute Savings Plans (which do not apply to RDS or DynamoDB) and manual replica promotion (which is functionally incorrect for handling write capacity and increases complexity/costs).

Ensures that the final selections align with AWS billing rules and architectural best practices.

Key Concept

Selecting optimal capacity and pricing models (On-Demand vs. Provisioned/Reserved) based on workload predictability and engine requirements.

Estimated Time:2m 0s

Question 1302Question →

A fleet management company is designing a serverless alert processing pipeline. IoT devices in fleet vehicles send diagnostic alert events via HTTPS to an API endpoint. The traffic is highly unpredictable, with long periods of inactivity followed by sudden, high-volume bursts during peak driving hours. The alerts from each unique vehicle must be processed in the exact chronological order they were generated to ensure accurate event tracking. Each alert requires a brief, 3-second validation and database write operation. The company wants to minimize costs and eliminate idle compute expenses.

Which combination of two actions will meet these requirements most cost-effectively? (Select TWO.)

Select all that apply

Route incoming HTTPS requests from Amazon API Gateway directly to an Amazon SQS FIFO queue.

Configure an AWS Lambda function to poll the Amazon SQS FIFO queue and process the alerts.

Route incoming HTTPS requests from Amazon API Gateway to a standard Amazon SQS queue.

Configure an AWS Lambda function to run continuously in a loop using a recursive invocation pattern to poll a standard Amazon SQS queue.

Deploy the processing logic on Amazon ECS using AWS Fargate tasks configured to run continuously to poll the queue.

Show answer & explanation

Answer: Route incoming HTTPS requests from Amazon API Gateway directly to an Amazon SQS FIFO queue.; Configure an AWS Lambda function to poll the Amazon SQS FIFO queue and process the alerts.

Answer

Routing incoming HTTPS requests from Amazon API Gateway directly to an Amazon SQS FIFO queue and configuring an AWS Lambda function to poll the Amazon SQS FIFO queue and process the alerts.

Routing incoming HTTPS requests from Amazon API Gateway directly to an Amazon SQS FIFO queue and configuring AWS Lambda to poll the queue is the most cost-effective solution. API Gateway provides a serverless frontend that scales automatically and charges only per request. Direct integration with SQS FIFO buffers the messages and guarantees order processing per vehicle ID using the MessageGroupId. AWS Lambda scales to zero during idle periods, ensuring that compute costs are only incurred during the 3-second execution time when processing alerts.

Step-by-Step Solution

Select a serverless ingestion and queueing mechanism that supports strict ordering.

Amazon API Gateway integrates directly with Amazon SQS FIFO queues.

This setup allows HTTPS requests from vehicles to be securely received and queued in chronological order without needing continuously running servers or incurring compute costs during idle periods.

Select a scale-to-zero compute service to process the buffered messages.

AWS Lambda is configured to poll the SQS FIFO queue via event source mapping.

AWS Lambda automatically polls SQS, processes the alerts, and scales down to zero when there is no traffic, ensuring no costs are paid for idle compute time.

Key Concept

Serverless and Automated Scaling Architectures for Cost Efficiency

Estimated Time:2m 0s

Question 1303Question →

A software-as-a-service (SaaS) company wants to detect potential threats within its AWS account, including compromised IAM credentials and EC2 instances communicating with command-and-control servers. When a threat is detected, the security team must be notified via a webhook to their external security operations center (SOC). The webhook URL requires an API key for authentication, which must be stored securely. Which architecture meets these requirements with the least operational overhead?

Configure stateless Network ACLs on all VPC subnets to identify and block traffic to known command-and-control servers. Configure the Network ACLs to trigger an AWS Lambda function that retrieves the webhook API key from AWS Secrets Manager and sends the alert.

Enable Amazon GuardDuty to monitor for threats and compromised credentials. Create an Amazon EventBridge rule that triggers an AWS Lambda function when GuardDuty generates a finding. Store the webhook API key in AWS Secrets Manager, and configure the Lambda function to retrieve the secret and call the webhook.

Enable Amazon GuardDuty to monitor for threats. Create an Amazon EventBridge rule that triggers an AWS Lambda function when GuardDuty generates a finding. Store the webhook API key as a plaintext String parameter in AWS Systems Manager Parameter Store, and configure the Lambda function to retrieve the parameter and call the webhook.

Enable AWS Shield Advanced to monitor API activity and network traffic for command-and-control communications. Configure a custom AWS WAF rule to trigger an AWS Lambda function that retrieves the webhook API key from AWS Secrets Manager and sends the alert.

Show answer & explanation

Answer: Enable Amazon GuardDuty to monitor for threats and compromised credentials. Create an Amazon EventBridge rule that triggers an AWS Lambda function when GuardDuty generates a finding. Store the webhook API key in AWS Secrets Manager, and configure the Lambda function to retrieve the secret and call the webhook.

Answer

Amazon GuardDuty is the AWS native threat detection service that continuously monitors VPC Flow Logs, CloudTrail logs, and DNS queries for potential security issues, including compromised IAM credentials and external command-and-control servers. Setting up an EventBridge rule to trigger an AWS Lambda function allows for real-time alerting to the external security operations center (SOC). Webhook API keys are sensitive credentials and must be stored securely using AWS Secrets Manager to prevent exposure.

Step-by-Step Solution

Enable GuardDuty threat detection

Amazon GuardDuty automatically analyzes VPC Flow Logs, DNS logs, and CloudTrail events to detect malicious activities and unauthorized access patterns (e.g., C2 server communication, compromised IAM keys).

This establishes threat detection capabilities with no agent setup or network overhead.

Configure event-driven alerting

An Amazon EventBridge rule matches GuardDuty finding events and routes them to an AWS Lambda function.

This automates the alert pipeline in real-time.

Securely retrieve credentials and notify the SOC

The Lambda function retrieves the API key from AWS Secrets Manager and sends the authenticated alert payload to the SOC webhook.

Storing the key in AWS Secrets Manager ensures sensitive credentials are encrypted and stored according to security best practices.

Key Concept

Amazon GuardDuty is the managed threat detection service that monitors account activity and network behavior in AWS, which can trigger EventBridge rules to automate remediation or notification tasks. Sensitive credentials like API keys must be securely stored in AWS Secrets Manager or Parameter Store (SecureString) rather than in plaintext.

Estimated Time:1m 30s

Question 1304Question →

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

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

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

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

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

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

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

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

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

Review the security group rules applied to the EC2 instances.

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

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

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

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

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

Key Concept

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

Question 1305Question →

A financial services company is deploying a distributed graph database for fraud detection on a fleet of Amazon EC2 instances. The graph database nodes require low-latency and high-throughput node-to-node network communication to synchronize transaction states. Additionally, client traffic is routed to the database nodes on port 8443 via a Network Load Balancer (NLB), while a custom health monitoring daemon runs on each instance on port 8080. Which combination of configuration steps should a solutions architect take to meet these requirements?

Deploy the EC2 instances within a spread placement group. Configure the Network Load Balancer target group to perform health checks using port 8080.

Deploy the EC2 instances within a cluster placement group. Configure the Network Load Balancer target group to perform health checks using port 8443.

Deploy the EC2 instances within a cluster placement group. Configure the Network Load Balancer target group to perform health checks using port 8080.

Deploy the EC2 instances within a partition placement group. Configure the Network Load Balancer target group to perform health checks using port 8443.

Show answer & explanation

Answer: Deploy the EC2 instances within a cluster placement group. Configure the Network Load Balancer target group to perform health checks using port 8080.

Answer

Deploy the EC2 instances within a cluster placement group and configure the Network Load Balancer target group to perform health checks using port 8080.

Deploying the EC2 instances in a cluster placement group packs them close together within a single Availability Zone, enabling low-latency, high-throughput node-to-node communications. Configuring the health check on port 8080 ensures that the Network Load Balancer correctly queries the dedicated health monitoring daemon rather than the database service port, preventing healthy instances from being falsely marked as unhealthy.

Step-by-Step Solution

Analyze node-to-node networking requirements.

Determine that the distributed graph database requires low-latency and high-throughput network communication.

This establishes the need for a cluster placement group, which packs instances close together inside a single Availability Zone.

Evaluate the placement group types.

Select a cluster placement group over spread or partition placement groups.

Cluster placement groups are optimized for low-latency node-to-node communication, which is required for graph synchronization.

Identify the health monitoring service port.

Identify that the health daemon runs on port 8080, distinct from the client traffic port 8443.

The health checks must target the port where the monitoring daemon is listening to avoid false negatives.

Key Concept

Selecting cluster placement groups for low-latency node-to-node communication and aligning NLB health check ports with custom monitoring daemons.

Question 1306Question →

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

Select all that apply

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

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

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

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

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

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

Analyze target group health check port settings.

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

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

Analyze security group rules for the instances.

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

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

Key Concept

ELB Target Group Health Checks and Security Group Rules

Question 1307Question →

A financial services company is migrating an on-premises relational transaction database to Amazon RDS for PostgreSQL. The database is $1\text{ TB}$ in size and requires high availability with automatic failover to support regulatory compliance. The database storage must support a constant baseline performance of $6,000\text{ IOPS}$ . The company wants to minimize costs while meeting all performance and compliance requirements.

Which database storage and availability configuration is the most cost-effective solution?

Deploy the database on Amazon RDS for PostgreSQL in a Multi-AZ configuration using gp3 storage with

6,000\text{ IOPS}

of provisioned performance.

Deploy the database on Amazon RDS for PostgreSQL in a Single-AZ configuration using gp3 storage with

6,000\text{ IOPS}

, and create a Read Replica in a different Availability Zone to serve as the automatic failover target.

Migrate the database to Amazon DynamoDB in provisioned capacity mode with

6,000\text{ Write Capacity Units (WCUs)}

and

6,000\text{ Read Capacity Units (RCUs)}

to handle the required I/O throughput.

Deploy the database on Amazon RDS for PostgreSQL in a Multi-AZ configuration using gp3 storage, export daily transaction logs to Amazon S3 Standard-Infrequent Access (S3 Standard-IA), and delete the S3 objects after

7\text{ days}

to minimize storage costs.

Show answer & explanation

Answer: Deploy the database on Amazon RDS for PostgreSQL in a Multi-AZ configuration using gp3 storage with $6,000\text{ IOPS}$ of provisioned performance.

Answer

Deploy the database on Amazon RDS for PostgreSQL in a Multi-AZ configuration using gp3 storage with 6,000 IOPS of provisioned performance.

The correct option is the one proposing Multi-AZ with gp3 storage. Amazon RDS gp3 storage allows users to provision IOPS and throughput independently of storage capacity. For a database requiring

6,000\text{ IOPS}

and

1\text{ TB}

of storage, gp3 is the most cost-effective storage type because the baseline is

3,000\text{ IOPS}

and the additional

3,000\text{ IOPS}

can be provisioned at a low cost without increasing the storage volume size. A Multi-AZ deployment satisfies the high availability and automatic failover requirements.

Step-by-Step Solution

Analyze storage cost-optimization for

6,000\text{ IOPS}

and

1\text{ TB}

size.

Amazon RDS gp3 storage allows independent provisioning of IOPS up to

6,000\text{ IOPS}

at a low cost. Amazon RDS gp2 requires

2\text{ TB}

of storage to get

6,000\text{ IOPS}

since gp2 gives

3\text{ IOPS/GB}

. Thus, gp3 is the most cost-effective storage type.

Choosing the correct storage type ensures that the database receives the required I/O performance without paying for unnecessary storage capacity.

Evaluate high availability requirements.

Regulatory compliance requires automatic failover, which is provided by Amazon RDS Multi-AZ deployments using synchronous replication.

Single-AZ deployments with Read Replicas utilize asynchronous replication and do not support automatic failover out of the box.

Identify the most cost-effective option that satisfies both requirements.

The combination of Multi-AZ with gp3 storage and

6,000\text{ IOPS}

meets all requirements at the lowest cost.

This configuration avoids overprovisioning storage or incurring S3 lifecycle penalties.

Key Concept

Cost-optimized storage and high availability configuration in Amazon RDS.

Estimated Time:2m 0s

Question 1308Question →

A global logistics company tracks package delivery statuses using an Amazon Aurora MySQL database cluster. The database handles a steady write volume of $120$ transactions per second (TPS) from regional scanning devices. Customer queries for tracking updates create read spikes of up to $7,500$ queries per second (QPS), causing read query latency to exceed the target threshold of $15\text{ ms}$ . The database writes remain stable. A solutions architect must design a high-performing and highly available database architecture that ensures read queries have low latency.

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

Select all that apply

Add Aurora Replicas to the database cluster and configure the application to use the reader endpoint for tracking query traffic.

Deploy an Amazon ElastiCache cluster to cache frequently accessed package shipment queries.

Migrate the database to Amazon DynamoDB and use the package scan timestamp as the partition key.

Configure a PostgreSQL Read Replica in a different AWS Region and configure it as the automatic failover target for the primary Aurora MySQL instance.

Enable Amazon DynamoDB Accelerator (DAX) to cache the queries coming from the Aurora database cluster.

Show answer & explanation

Answer: Add Aurora Replicas to the database cluster and configure the application to use the reader endpoint for tracking query traffic.; Deploy an Amazon ElastiCache cluster to cache frequently accessed package shipment queries.

Answer

To resolve the read latency issues and ensure high performance and availability, the solutions architect should add Aurora Replicas to the database cluster and use the reader endpoint, and deploy an Amazon ElastiCache cluster to cache frequently accessed queries.

The correct options involve adding Aurora Replicas to scale read operations horizontally and using the cluster's reader endpoint to load-balance queries. Additionally, introducing Amazon ElastiCache caches frequently requested package history, reducing latency to the sub-millisecond range and offloading the primary database cluster.

Step-by-Step Solution

Analyze read/write patterns and identify bottlenecks.

Write volume (

120

TPS) is low and stable, but read volume is extremely high (

7,500

QPS), resulting in degraded read latency that exceeds

15\text{ ms}

This confirms the database is read-heavy and requires optimization at the read and caching layers.

Implement database-level read scaling.

Add Aurora Replicas to the database cluster and direct read queries to the reader endpoint.

Aurora Replicas offload the query load from the primary instance, and the reader endpoint automatically balances connections among the reader instances.

Implement database caching.

Deploy an Amazon ElastiCache cluster to cache frequently accessed query results.

ElastiCache provides sub-millisecond latencies for cached data, further shielding the database from repetitive read queries.

Key Concept

Scaling database reads using read replicas (reader endpoints) and implementing in-memory caching (ElastiCache) are standard patterns for optimizing database read performance and achieving low latency.

Estimated Time:2m 0s

Question 1309Question →

A Solutions Architect is designing the database architecture for a global corporate travel booking application. The application needs to support high-throughput booking transactions in the primary AWS Region and provide employees worldwide with access to travel history queries with latency under 100 milliseconds. Which of the following database configurations should the Solutions Architect select to meet these performance requirements? (Select TWO.)

Select all that apply

Migrate the database to Amazon Aurora MySQL and configure an Aurora Global Database with read replicas in the secondary Regions to serve local reads.

Deploy an Amazon ElastiCache for Redis cluster in each Region to cache frequently read order history data and minimize read latency.

Configure Amazon RDS for MySQL with cross-Region read replicas, and set up the application to promote the replicas to primary instances during peak write periods to distribute write operations.

Migrate the database to an Amazon DynamoDB table using the transaction timestamp as the partition key to ensure sequential sorting and high write performance.

Move the order history data to an Amazon DynamoDB table configured in Provisioned Capacity Mode with static read and write capacity units to handle highly unpredictable, spiky traffic.

Show answer & explanation

Answer: Migrate the database to Amazon Aurora MySQL and configure an Aurora Global Database with read replicas in the secondary Regions to serve local reads.; Deploy an Amazon ElastiCache for Redis cluster in each Region to cache frequently read order history data and minimize read latency.

Answer

Migrate the database to Amazon Aurora MySQL with an Aurora Global Database configuration and deploy an Amazon ElastiCache for Redis cluster in each Region to cache queries.

Migrating the application database to Amazon Aurora MySQL and using Aurora Global Database enables local read replicas in secondary Regions, which reduces read latency significantly for global users. In addition, deploying Amazon ElastiCache for Redis in each Region caches queries close to the application servers, satisfying the sub-100 millisecond response time requirement.

Step-by-Step Solution

Analyze read and write requirements.

Write transactions occur in a primary Region, while read queries must be served globally under 100 milliseconds.

This establishes that the solution requires a high-performance write capability in the primary Region and low-latency read replica or caching mechanisms in remote Regions.

Evaluate global database technologies.

Amazon Aurora Global Database provides replication to secondary Regions with typical latencies of less than 1 second, enabling fast local reads.

Serving reads locally from secondary Regions is essential to achieve sub-100 millisecond read performance globally.

Evaluate in-memory caching solutions.

Amazon ElastiCache for Redis can store travel history queries locally in each Region for sub-millisecond retrieval.

Caching frequently accessed static data reduces database load and guarantees consistent ultra-low latency.

Key Concept

Scaling global reads with minimal latency requires a combination of local in-memory caching (Amazon ElastiCache) and fast replication to remote database endpoints (Amazon Aurora Global Database). Schema designs must avoid monotonically increasing keys (like timestamps) to prevent partition hotspots.

Question 1310Question →

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

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

Select all that apply

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

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

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

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

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

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

Analyze the application port configuration and identify the mismatch.

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

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

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

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

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

Key Concept

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

Question 1311Question →

A company's security team needs to monitor network traffic for a multi-tier web application. They suspect that a compromised Amazon EC2 instance in a private subnet is attempting to perform unauthorized network scans on other resources within the same Virtual Private Cloud (VPC). The team needs to capture the source IP, destination IP, source port, destination port, and protocol for all network traffic at the subnet level without installing any host-based software. Which solution will meet these requirements?

Deploy AWS WAF on the subnet to monitor and log all Layer 3 and Layer 4 IP traffic flowing between the EC2 instances.

Configure Network ACLs on the private subnet to log all connection metadata directly to AWS CloudTrail.

Enable VPC Flow Logs on the private subnet and publish the logs to an Amazon S3 bucket.

Enable AWS Shield Advanced on the VPC to log internal host-to-host traffic metadata.

Show answer & explanation

Answer: Enable VPC Flow Logs on the private subnet and publish the logs to an Amazon S3 bucket.

Answer

Enable VPC Flow Logs on the private subnet and publish the logs to an Amazon S3 bucket.

The correct solution is to enable VPC Flow Logs on the private subnet and publish the logs to an Amazon S3 bucket. VPC Flow Logs captures IP traffic metadata (source/destination IPs, ports, and protocol) at the Elastic Network Interface (ENI) level without needing any agents. It can deliver these logs to Amazon S3 or CloudWatch Logs.

Step-by-Step Solution

Identify the requirement to capture network flow data (source/destination IPs, ports, and protocols) at the subnet level.

Determined that network traffic metadata monitoring is required.

This establishes the scope of traffic metadata that needs to be collected.

Evaluate native AWS logging capabilities that operate agentlessly at the network boundary.

Identified VPC Flow Logs as the native feature designed to capture flow information for subnets, network interfaces, or VPCs without requiring host-based software.

The business scenario forbids host-based software, ruling out agent-based monitoring utilities.

Select a valid destination for the captured log data.

Configured the flow logs to publish to Amazon S3, which supports durable, secure, and cost-effective log storage.

VPC Flow Logs natively supports publishing to Amazon S3 or Amazon CloudWatch Logs.

Key Concept

Agentless network traffic metadata logging via VPC Flow Logs

Question 1312Question →

A retail company is migrating its product inventory database to AWS. The database experiences a steady, predictable baseline of $1,200\text{ read operations per second}$ and $200\text{ write operations per second}$ during regular hours. However, during flash sales that occur for $1\text{ hour}$ every Friday evening, read traffic spikes to $15,000\text{ operations per second}$ and write traffic spikes to $3,000\text{ operations per second}$ . The database schema is non-relational, and the company wants to optimize cost while ensuring the database does not throttle during flash sales. Which TWO configurations should the solutions architect recommend to meet these requirements cost-effectively? (Select TWO.)

Select all that apply

Configure Amazon DynamoDB in Provisioned Capacity Mode and configure AWS Application Auto Scaling to schedule write capacity scaling before and after the flash sales.

Implement Amazon ElastiCache to cache inventory read requests, reducing the required DynamoDB provisioned read capacity during both baseline and peak hours.

Configure Amazon DynamoDB in On-Demand Capacity Mode to automatically scale up to support the read and write spikes during the flash sales.

Configure Amazon DynamoDB with provisioned capacity set statically to

15,000

Read Capacity Units (RCUs) and

3,000

Write Capacity Units (WCUs) to prevent throttling.

Migrate the database to Amazon RDS for PostgreSQL with a Multi-AZ deployment and route the write traffic spikes to the standby replica to distribute the load.

Show answer & explanation

Answer: Configure Amazon DynamoDB in Provisioned Capacity Mode and configure AWS Application Auto Scaling to schedule write capacity scaling before and after the flash sales.; Implement Amazon ElastiCache to cache inventory read requests, reducing the required DynamoDB provisioned read capacity during both baseline and peak hours.

Answer

The correct configurations are to run DynamoDB in Provisioned Capacity Mode with scheduled scaling for write capacity and to deploy Amazon ElastiCache to cache inventory read requests.

Implementing scheduled scaling for write capacity and caching reads with Amazon ElastiCache is the most cost-effective solution. Since the flash sale occurs at a predictable time, AWS Application Auto Scaling can schedule write capacity increases to

3,000\text{ WCUs}

before the sale and scale back down to the baseline of

200\text{ WCUs}

after the sale, preventing throttling at the beginning of the sale. Caching product inventory details with Amazon ElastiCache reduces the read load on DynamoDB, allowing the database to be provisioned with a low, cost-optimized read capacity baseline instead of provisioning for the

15,000\text{ RCUs}

peak.

Step-by-Step Solution

Analyze the workload characteristics and database requirements.

The database has a non-relational schema with a steady baseline of

1,200\text{ reads/sec}

and

200\text{ writes/sec}

, and a predictable spike to

15,000\text{ reads/sec}

and

3,000\text{ writes/sec}

for

1\text{ hour}

once a week.

Identifying the workload patterns helps determine the most cost-effective database engine, capacity mode, and scaling strategy.

Evaluate the cost-effectiveness of DynamoDB capacity modes.

Provisioned Capacity Mode is cheaper for the predictable baseline. Since standard auto-scaling takes time to scale up, scheduling scaling activities before the weekly flash sale ensures write capacity is ready without throttling.

Scheduled scaling aligned with predictable events optimizes write cost while ensuring performance.

Determine the best caching strategy for the read path.

Introduce Amazon ElastiCache to cache inventory details. This offloads the

15,000\text{ reads/sec}

peak from DynamoDB, allowing the database read capacity to remain low.

Caching read-heavy workloads is much cheaper than provisioning database throughput to handle extreme read peaks.

Key Concept

Cost-optimized database capacity planning using DynamoDB scheduled scaling and ElastiCache caching layers for predictable and spike workloads.

Estimated Time:2m 0s

Question 1313Question →

An autonomous vehicle research company is running large-scale LiDAR sensor simulation workloads across a fleet of Amazon EC2 instances. The simulation nodes must frequently exchange spatial data frames with microsecond-level network latency. The nodes also run a management service on port $9100$ , which is registered with an Application Load Balancer (ALB). During initial testing, the simulation experiences significant network latency, and the ALB target group marks all EC2 instances as unhealthy. Which combination of actions should a solutions architect take to resolve these issues?

Deploy the EC2 instances in a spread placement group, and update the ALB target group health check settings to monitor port

9100

Deploy the EC2 instances in a cluster placement group, and configure the ALB target group health check to query the default traffic port.

Deploy the EC2 instances in a cluster placement group, and update the ALB target group health check settings to monitor port

9100

Deploy the EC2 instances in a partition placement group, and configure the ALB target group health check to query the default traffic port.

Show answer & explanation

Answer: Deploy the EC2 instances in a cluster placement group, and update the ALB target group health check settings to monitor port $9100$ .

Answer

Deploying the EC2 instances in a cluster placement group and updating the ALB target group health check settings to monitor port

9100

resolves both the latency and health check issues.

A cluster placement group is the correct choice because it places instances physically close to each other within a single Availability Zone, providing the low-latency, high-throughput network performance required for tightly coupled applications. Furthermore, modifying the target group health check port to match the custom port where the management service is listening resolves the health check mismatch, allowing the load balancer to correctly identify the instances as healthy.

Step-by-Step Solution

Address inter-node network latency by choosing the correct placement group.

Identify that a cluster placement group packs instances close together inside an Availability Zone, enabling low-latency, high-throughput network performance.

Tightly coupled applications like simulations require minimal network latency, which cluster placement groups provide.

Resolve the Application Load Balancer health check failures.

Update the target group's health check configuration to target port

9100

instead of the default traffic port.

By default, target groups perform health checks on the traffic port or port

80

. If the management service runs on port

9100

, the default health check will fail because there is no listener on the default port.

Key Concept

Selecting cluster placement groups for low-latency node-to-node communication and configuring ALB custom health check ports.

Estimated Time:2m 0s

Question 1314Question →

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

Select all that apply

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

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

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

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

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

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

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

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

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

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

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

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

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

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

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

Key Concept

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

Alternative Method

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

Estimated Time:2m 0s

Question 1315Question →

A company runs a critical transactional application on an Amazon RDS for PostgreSQL Multi-AZ DB instance. The database is currently sized as a $db.m6g.4xlarge$ instance to handle a combination of transactional writes and a heavy volume of read-only business intelligence (BI) queries. The transactional write workload is steady and low, but the BI queries cause CPU utilization to spike to $90\%$ during business hours. The company wants to optimize costs while maintaining high availability.

Which database design is the most cost-effective solution?

Create an Amazon RDS Read Replica to handle the BI queries, and downsize the primary Multi-AZ DB instance to a

db.m6g.large

instance.

Configure the application to route the BI queries to the Multi-AZ standby DB instance to utilize its idle capacity, and downsize the primary instance to a

db.m6g.large

instance.

Convert the Multi-AZ deployment to a Single-AZ deployment, create a Read Replica to handle the BI queries, and configure the Read Replica as the primary disaster recovery failover target.

Migrate the database to Amazon DynamoDB using Provisioned Capacity mode to handle both transactional writes and BI queries at a lower cost.

Show answer & explanation

Answer: Create an Amazon RDS Read Replica to handle the BI queries, and downsize the primary Multi-AZ DB instance to a $db.m6g.large$ instance.

Answer

Create an Amazon RDS Read Replica to handle the BI queries, and downsize the primary Multi-AZ DB instance to a

db.m6g.large

instance.

The correct option offloads the read-heavy business intelligence queries to an Amazon RDS Read Replica. Since the primary database only needs to handle the steady, low-volume write transactions, the primary Multi-AZ instance (and its standby) can be safely downsized from

db.m6g.4xlarge

db.m6g.large

, resulting in significant cost savings while maintaining high availability.

Step-by-Step Solution

Analyze the workload characteristics and database requirements.

The workload has high-volume reads (BI queries) and low-volume writes, requiring high availability (Multi-AZ).

Understanding the separation of read and write traffic is critical to sizing database instances.

Select a mechanism to offload read queries.

An Amazon RDS Read Replica is created to handle the BI read queries.

This removes the

90\%

CPU utilization bottleneck from the primary database instance.

Resize the primary Multi-AZ database instance.

Downsize the primary Multi-AZ instance from

db.m6g.4xlarge

db.m6g.large

Since the primary database now only processes the steady, low-volume write transactions, it no longer needs to be oversized. This reduces the cost of the Multi-AZ deployment.

Key Concept

Separation of read and write workloads using RDS Read Replicas to optimize Multi-AZ compute costs.

Question 1316Question →

An online collaborative workspace platform needs to store session state data for active users. The requirements specify that both read and write operations must consistently achieve sub-millisecond latency, even during sudden, unpredictable usage spikes. The database schema is a simple key-value structure containing user IDs and session tokens. Which database architecture should a solutions architect recommend to meet these requirements?

Store the session data in Amazon DynamoDB, using the current date formatted as YYYY-MM-DD as the partition key to group sessions by day.

Deploy an Amazon RDS for MySQL DB instance with multiple read replicas, and configure the application to write to the replicas during write spikes.

Implement an Amazon ElastiCache for Redis cluster with replication enabled across multiple Availability Zones.

Store the session data in Amazon DynamoDB configured with Provisioned Capacity Mode set to the lowest baseline to minimize database costs.

Show answer & explanation

Answer: Implement an Amazon ElastiCache for Redis cluster with replication enabled across multiple Availability Zones.

Answer

The correct architecture is to implement an Amazon ElastiCache for Redis cluster with replication enabled across multiple Availability Zones.

Implementing an Amazon ElastiCache for Redis cluster provides an in-memory data store that natively achieves sub-millisecond response times for both read and write operations. It is well-suited for key-value structures and handles unpredictable spikes through internal memory speed and scalable replication.

Step-by-Step Solution

Analyze database requirements.

Identify that the system requires sub-millisecond latency for both reads and writes, handles simple key-value structures, and experiences unpredictable traffic spikes.

This sets the architectural baseline, eliminating standard disk-based databases like RDS that typically average single-digit millisecond latency for writes.

Select the correct database technology class.

Choose an in-memory database like Amazon ElastiCache for Redis to satisfy the sub-millisecond write and read latency constraints.

In-memory caching and databases are the primary AWS services capable of delivering sub-millisecond latencies for active session stores.

Evaluate and eliminate incorrect scaling and partitioning strategies.

Discard strategies involving hot-key partition designs, writing to read-only RDS replicas, or under-provisioning DynamoDB capacity.

These strategies introduce throttling, database exceptions, and failures to meet performance SLAs under load.

Key Concept

In-memory database solutions, such as Amazon ElastiCache, are optimized for simple key-value operations that require sub-millisecond read/write latency under volatile workloads.

Question 1317Question →

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

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

Select all that apply

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

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

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

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

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

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

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

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

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

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

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

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

Key Concept

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

Question 1318Question →

An energy grid operator runs a distributed power-flow optimization simulator on a fleet of Amazon EC2 instances. The simulator nodes must communicate with each other using Message Passing Interface (MPI) with the lowest possible latency. The optimization service on each instance runs on port 7001. A Network Load Balancer (NLB) distributes management API requests to the instances, but currently reports all instances as unhealthy because the health check is set to the default port 80. Which configuration will achieve the required network performance and resolve the health check issue?

Configure a partition placement group for the EC2 instances. Update the NLB target group health check port to 7001.

Configure a cluster placement group for the EC2 instances. Keep the target group health check port at the default port 80.

Configure a cluster placement group for the EC2 instances. Update the NLB target group health check port to 7001.

Configure a spread placement group for the EC2 instances. Update the NLB target group health check port to 7001.

Show answer & explanation

Answer: Configure a cluster placement group for the EC2 instances. Update the NLB target group health check port to 7001.

Answer

Configure a cluster placement group for the EC2 instances. Update the NLB target group health check port to 7001.

For tightly-coupled MPI applications requiring low latency, a cluster placement group is the appropriate choice because it physically groups the instances together inside a single Availability Zone. Additionally, because the application is listening on port 7001, the health check port must be updated from the default port 80 to port 7001 so the load balancer can verify the actual application status instead of getting connection timeouts on an unused port.

Step-by-Step Solution

Analyze the latency and network performance requirements for the node-to-node communication.

Determine that the MPI-based application requires a cluster placement group to achieve the lowest possible node-to-node latency.

Cluster placement groups launch instances in a single Availability Zone on shared underlying hardware to support high-throughput, low-latency communication.

Identify the cause of the Network Load Balancer marking the EC2 instances as unhealthy.

Detect a port mismatch between the application (port 7001) and the target group health check configuration (default port 80).

Because the application is not listening on port 80, TCP connection attempts from the NLB fail, leading to unhealthy target status.

Combine the correct placement group strategy with the health check modification.

Deploy the instances in a cluster placement group and update the target group health check port to 7001.

This resolves the network performance requirements while ensuring the NLB can successfully monitor application availability.

Key Concept

Selecting the correct EC2 placement group for low-latency node-to-node communication and ensuring that the load balancer health check configuration aligns with the application port.

Estimated Time:2m 0s

Question 1319Question →

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

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

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

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

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

Show answer & explanation

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

Answer

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

Step-by-Step Solution

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

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

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

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

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

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

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

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

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

Key Concept

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

Question 1320Question →

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

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

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

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

80

) rather than port

8443

where the application is listening.

Amazon Route

53

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

Show answer & explanation

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

Answer

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

80

) rather than port

8443

where the application is listening.

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

80

) rather than the application's actual listening port (

8443

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

502

Bad Gateway errors.

Step-by-Step Solution

Analyze the load balancer behavior and the HTTP

502

error.

The HTTP

502

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

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

Examine the application port configuration versus the health check configuration.

The application listens on port

8443

, and the target group routes traffic to port

8443

, but the health check port is not explicitly specified.

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

80

for HTTP), which has nothing listening on it.

Verify if other network access configurations are correct.

The EC2 security group allows traffic on port

8443

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

This rules out security groups blocking application traffic on port

8443

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

Key Concept

Target Group Health Checks

PreviousPage 66 / 74Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution