All practice questions

1462 questions

All types1,462 Multiple choice739 Multiple select723

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

Add a rule to the subnet Network Access Control List (NACL) allowing inbound traffic on port 80 and ephemeral ports from the client subnet.

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

Configure the EC2 security group to permit inbound TCP traffic on port 80 from the Application Load Balancer security group.

Change the Amazon Route 53 routing policy to latency-based routing with target health checks pointing directly to the EC2 instances.

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

Identify the port on which the service is listening on the EC2 instances.

The application listens and runs healthy on port 8080.

This establishes the target port that health checks and routing should target.

Check the default target group health check port settings.

By default, health check configurations often default to port 80 rather than the traffic port if not explicitly overridden.

This identifies the source of the health check failure (requesting port 80 instead of 8080).

Modify the health check port to 8080.

The load balancer begins successfully checking the application on port 8080 and marks instances as healthy.

Aligning the health check port with the active application port resolves the unhealthy status and the 502 Bad Gateway errors.

Key Concept

ELB Target Group Health Check Port Alignment

Question 482Question →

A collaborative document editing platform stores document metadata and change logs in Amazon DynamoDB. The platform experiences write bottlenecks during active collaboration sessions, causing throttling, while users also experience latency greater than $50$ milliseconds when retrieving the latest document updates. The database currently uses a low-cardinality attribute, the project creation date, as the partition key. Which two actions should the solutions architect take to resolve these performance issues? (Select two.)

Select all that apply

Change the partition key to a high-cardinality attribute, such as a unique document UUID, to distribute write traffic evenly across partitions.

Use the project creation date as the partition key and a sequential timestamp as the sort key to order the write operations.

Migrate the workload to Amazon RDS and configure a Read Replica to automatically accept write requests during peak write times.

Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read responses and reduce retrieval latency to microseconds.

Configure the DynamoDB table to use provisioned capacity mode with a fixed high value of Write Capacity Units (WCUs) to handle the spikes, while disabling auto-scaling.

Show answer & explanation

Answer: Change the partition key to a high-cardinality attribute, such as a unique document UUID, to distribute write traffic evenly across partitions.; Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read responses and reduce retrieval latency to microseconds.

Answer

Changing the partition key to a high-cardinality attribute like a unique document UUID, and deploying an Amazon DynamoDB Accelerator (DAX) cluster to cache read responses.

The correct options recommend changing the partition key to a high-cardinality attribute like a unique document UUID and deploying Amazon DynamoDB Accelerator (DAX). Changing the partition key distributes the write workload evenly across physical partitions, eliminating the partition-level bottlenecks that cause throttling. Deploying DAX introduces an in-memory caching layer that handles frequent read requests, reducing retrieval latency from milliseconds to microseconds and offloading read traffic from the database.

Step-by-Step Solution

Analyze the database configuration and partition key design to identify the cause of the write bottlenecks.

The use of a low-cardinality partition key (project creation date) results in all write operations for documents created on the same day hitting the same physical partition, causing a hot partition.

DynamoDB distributes data across partitions based on the partition key value. Low-cardinality keys lead to uneven traffic distribution and throttling.

Identify the correct design to resolve the write throughput limitations.

Choosing a high-cardinality attribute, such as a unique document UUID, distributes the write operations evenly across all available physical partitions.

High-cardinality partition keys ensure even distribution of reads and writes, maximizing the utilization of provisioned throughput.

Determine the appropriate caching solution to reduce read latency below the millisecond threshold.

Deploying Amazon DynamoDB Accelerator (DAX) provides an in-memory cache that intercepts read requests.

DAX reduces read latency from milliseconds to microseconds, offloads the read load from the main DynamoDB table, and does not require modifying application query logic.

Key Concept

High-performing DynamoDB database design relies on choosing high-cardinality partition keys to prevent hot partitions, and using in-memory caching layers like DAX to achieve microsecond read latency.

Estimated Time:2m 0s

Question 483Question →

A company runs a read-heavy content management application on AWS. The application database is deployed on an Amazon RDS for MySQL DB instance. The workload consists of a steady, low-volume write rate of $10$ transactions per second, but read requests regularly spike up to $5,000$ queries per second during peak hours. The database currently uses a db.r6g.4xlarge Multi-AZ instance to handle the peak read traffic, but the company wants to optimize the high database costs while maintaining high availability. Which database architecture is the most cost-effective while meeting the application's availability and performance needs?

Modify the primary database instance to a Single-AZ deployment, and configure a Read Replica in a different Availability Zone to serve as the automatic failover target in the event of a primary database outage.

Modify the primary database instance to a smaller Multi-AZ instance class, such as db.r6g.large, to handle the steady write workload, and deploy RDS Read Replicas to offload the peak read traffic.

Migrate the database to Amazon DynamoDB and configure the table in Provisioned Capacity mode with a fixed

5,000

Read Capacity Units (RCUs) and

10

Write Capacity Units (WCUs) to guarantee performance during peak hours.

Keep the db.r6g.4xlarge Multi-AZ deployment to handle peak workloads, and purchase a Compute Savings Plan to reduce the hourly compute cost of the database instance.

Show answer & explanation

Answer: Modify the primary database instance to a smaller Multi-AZ instance class, such as db.r6g.large, to handle the steady write workload, and deploy RDS Read Replicas to offload the peak read traffic.

Answer

Modify the primary database instance to a smaller Multi-AZ instance class, such as db.r6g.large, to handle the steady write workload, and deploy RDS Read Replicas to offload the peak read traffic.

The correct architecture scales down the primary database instance to a smaller Multi-AZ instance class to handle the steady write workload, and uses cheaper RDS Read Replicas to offload the peak read traffic. This aligns the compute capacity with the actual query demands, leading to significant cost savings compared to maintaining a large db.r6g.4xlarge primary instance that cannot offload reads to its Multi-AZ standby.

Step-by-Step Solution

Analyze the database workload characteristics and the current configuration constraints.

The application has a low write volume (

10

transactions per second) and a spiky read volume (

5,000

queries per second). The current db.r6g.4xlarge Multi-AZ instance is oversized and expensive because Multi-AZ standbys cannot serve read traffic.

Identifying that the primary database is oversized for writes and that Multi-AZ does not scale reads is key to optimizing the architecture.

Evaluate scale-out options for read traffic and scale-down options for write traffic.

By deploying a smaller db.r6g.large Multi-AZ primary instance, high availability is maintained for the write path at a much lower cost. Adding Read Replicas (which are single-AZ and cheaper) allows scaling the read performance to

5,000

queries per second only when needed.

Separating read scaling from write high-availability requirements is the standard AWS best practice for cost-optimized database design.

Identify and eliminate options that violate AWS pricing or architectural rules.

Compute Savings Plans do not cover RDS. Read Replicas do not support automatic failover. Provisioning static high capacity in DynamoDB leads to expensive idle resources.

Eliminating options with architectural misconceptions ensures the chosen solution is correct and feasible.

Key Concept

Read replicas should be used to offload read traffic from the primary instance, allowing the primary instance to be downsized and reducing overall database costs while maintaining high availability via Multi-AZ.

Estimated Time:2m 0s

Question 484Question →

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

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

Update the target group health check path to point to http://localhost:8080/health while keeping the health check port set to the default traffic-port setting.

Update the target group health check port to 8080, and modify the subnet Network ACL (NACL) to allow inbound TCP traffic on port 8080 from the ALB subnets.

Change the Route 53 DNS record to use a Latency routing policy targeting the individual public IP addresses of the EC2 instances, bypassing the ALB.

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

Analyze the target group port mapping.

The target group uses port 8443 by default for traffic and health checks ('traffic-port').

Identify why the ALB is sending health check requests to port 8443 instead of the management port 8080.

Configure the health check port override.

Modify the target group settings to explicitly perform health checks on port 8080.

Ensure that the load balancer queries the correct port where the application's health status is exposed.

Update security group rules.

Add an inbound rule to the EC2 instance security group allowing TCP port 8080 traffic from the ALB security group.

Since security groups are stateful and evaluate traffic at the instance level, the ALB's health check queries on port 8080 will be blocked unless explicitly permitted by the security group.

Key Concept

ELB Target Group Health Check Port Configuration and Security Group Integration

Estimated Time:2m 30s

Question 485Question →

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

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

Configure the Application Load Balancer listener to perform health checks on port 80, and modify the instance security group to allow inbound traffic on port 80.

Modify the subnet Network ACL associated with the EC2 instances to permit outbound traffic on port 8080, because security groups are stateless and require explicit outbound rules.

Set up an Amazon Route 53 latency routing policy with health checks directed at the individual EC2 instance elastic IP addresses.

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

Identify the application's listening port.

The application listens on TCP port 8080.

Health check probes must reach a port where the application is actively listening.

Analyze the load balancer target group configuration.

The target group is default-configured or misconfigured to probe a port other than 8080 (such as port 80).

If the ALB health check port does not match the application port, the health check fails.

Update the health check settings in the target group.

Setting the health check port to 8080 or 'traffic-port' restores successful health checks.

This aligns the load balancer's probes with the active application port, resolving the unhealthy status.

Key Concept

ELB Target Group Health Check Port Alignment

Estimated Time:1m 30s

Question 486Question →

A digital media agency uses a fleet of Amazon EC2 instances to run a distributed 3D rendering engine. The rendering nodes require sub-millisecond, low-latency network communication to synchronize frame buffers during active renders. Additionally, a central scheduler distributes tasks to the rendering nodes on port $8080$ behind an Application Load Balancer. The rendering service is configured to start and bind to port $8080$ only after the instance finishes loading its local textures. Which two configuration steps must a solutions architect implement to ensure optimal performance and prevent the load balancer from marking active nodes as unhealthy? (Select TWO.)

Select all that apply

Provision the EC2 instances within a cluster placement group.

Modify the health check port in the target group to match the application port of

8080

Provision the EC2 instances within a spread placement group.

Provision the EC2 instances within a partition placement group.

Leave the target group health check port configuration at its default value.

Show answer & explanation

Answer: Provision the EC2 instances within a cluster placement group.; Modify the health check port in the target group to match the application port of $8080$ .

Answer

To achieve the required low-latency performance and prevent the load balancer from marking healthy instances as unhealthy, the EC2 instances should be provisioned within a cluster placement group, and the target group health check port must be modified to match the application port of

8080

The correct configurations involve provisioning the instances within a cluster placement group and specifying the health check port as

8080

in the ALB target group. A cluster placement group ensures that instances are physically close together in a single Availability Zone, which delivers the low-latency network connection needed for the rendering engine. Modifying the target group health check port to

8080

ensures the load balancer queries the correct port where the application is listening, preventing healthy nodes from being marked as unhealthy.

Step-by-Step Solution

Analyze network latency requirements for the distributed rendering workload.

Identify that the rendering nodes require tightly coupled, low-latency network communication to synchronize frame buffers.

This dictates the choice of EC2 placement group to optimize node-to-node network performance.

Select the appropriate EC2 placement group type.

Select a cluster placement group, which places instances close together inside a single Availability Zone.

Cluster placement groups allow instances to achieve low-latency, high-performance networking, whereas spread and partition placement groups focus on high availability and fault isolation.

Align the ALB target group health check port with the application service port.

Configure the target group health check port explicitly to port

8080

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

80

. Since the rendering application runs on custom port

8080

and is not listening on port

80

, using the default port would cause the ALB to mark healthy instances as unhealthy.

Key Concept

Optimizing EC2 instance placement for low-latency networking while correctly configuring load balancer health checks for custom application ports.

Question 487Question →

A retail company is launching a promotional website for a new product line. The website serves static content and retrieves product catalog information via an API. The website traffic is highly unpredictable, with extreme spikes during marketing campaigns and long periods of inactivity. Additionally, a nightly inventory synchronization process runs continuously for $3$ hours to update the catalog database. The company wants to design a serverless architecture that minimizes costs, especially during idle periods, while scaling automatically.

Which architecture should a solutions architect recommend to meet these requirements?

Host static content on Amazon S3 with an Amazon CloudFront distribution, use Amazon API Gateway with AWS Lambda for the API, run the nightly inventory sync as an Amazon ECS task on AWS Fargate, and store product catalog data in Amazon DynamoDB configured in on-demand capacity mode.

Host static content on Amazon S3 with an Amazon CloudFront distribution, use Amazon API Gateway with a scheduled AWS Lambda function running a continuous loop for

3

hours to process the nightly inventory sync, and store product catalog data in Amazon DynamoDB configured in on-demand capacity mode.

Host static content on Amazon S3 with an Amazon CloudFront distribution configured with a Time to Live (TTL) of

0

for all cache behaviors, use Amazon API Gateway with AWS Lambda for the API, run the nightly inventory sync as an Amazon ECS task on AWS Fargate, and store product catalog data in Amazon DynamoDB configured in on-demand capacity mode.

Show answer & explanation

Answer: Host static content on Amazon S3 with an Amazon CloudFront distribution, use Amazon API Gateway with AWS Lambda for the API, run the nightly inventory sync as an Amazon ECS task on AWS Fargate, and store product catalog data in Amazon DynamoDB configured in on-demand capacity mode.

Answer

The correct solution recommends Amazon S3 and Amazon CloudFront for static hosting, AWS Lambda and Amazon API Gateway for lightweight API requests, Amazon ECS on AWS Fargate for the

3

-hour inventory sync, and Amazon DynamoDB in on-demand capacity mode. This aligns the billing model of each service with the workload profile: compute costs scale to zero during idle periods, the long-running inventory task runs safely without timeout limits, and database costs reflect actual request volume rather than provisioned capacity.

Step-by-Step Solution

Analyze the web hosting and API requirements.

Amazon S3 combined with Amazon CloudFront provides highly scalable, low-latency static hosting. Amazon API Gateway with AWS Lambda provides a serverless API that scales instantly and costs nothing during periods of inactivity.

To ensure maximum cost-efficiency during idle periods and automatic scaling during marketing spikes.

Evaluate the database scaling and capacity requirements.

Select Amazon DynamoDB on-demand capacity mode.

Since traffic is highly unpredictable with long idle periods, on-demand capacity mode prevents paying for unused provisioned capacity, ensuring cost-efficiency.

Evaluate the backend processing requirements for the nightly inventory synchronization.

Select Amazon ECS on AWS Fargate.

The task runs continuously for

3

hours, which exceeds the AWS Lambda maximum execution limit of

15

minutes. Amazon ECS on Fargate runs containers serverlessly and only incurs charges for the exact duration of the container execution, making it the most cost-effective choice for long-running batch processes.

Key Concept

Selecting cost-optimized compute, integration, and database services by aligning performance profiles with automated scaling and serverless architectures.

Estimated Time:1m 30s

Question 488Question →

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

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

The EC2 instance security group is blocking the return traffic to the ALB because security groups are stateless and require an explicit outbound rule for ephemeral ports.

The ALB target group health check is configured to use the default 'traffic-port', which causes a port mismatch since the application is listening on port 8080.

Amazon Route 53 is using a latency routing policy to direct health check requests, which bypasses the target group and attempts to query the instances directly on port 80.

Show answer & explanation

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

Answer

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

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

Step-by-Step Solution

Identify the key network security component mentioned in the failure.

The scenario focuses on the update to the Network Access Control List (NACL) of the private subnet.

Since the health check failures began immediately after the NACL change, the root cause must be related to the stateless nature of NACLs.

Analyze how stateless network devices process traffic flow.

Inbound rules allow the request in, but outbound rules must explicitly permit the response to go back to the source port (ephemeral ports 1024-65535).

Because the outbound NACL was only configured to allow port 8080, it blocked the return traffic to the ALB.

Differentiate security groups from NACLs.

Security groups are stateful and automatically permit return traffic, while NACLs require explicit two-way configuration.

This confirms the issue lies solely with the stateless Network ACL configuration.

Key Concept

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

Question 489Question →

A financial services provider hosts a transactional processing application on Amazon EC2 instances within an Auto Scaling group behind an Application Load Balancer (ALB). The application requires a complex bootstrap process—including downloading security certificates and loading a large dataset into local memory—which takes approximately 6 minutes before the instance can pass health checks. During sudden market volatility, rapid traffic spikes overload the existing instances, causing request timeouts before new instances can finish bootstrapping. Which solution will most effectively minimize the latency of scaling out the compute capacity?

Implement an Amazon EC2 Auto Scaling warm pool to maintain a pool of pre-initialized instances in a Stopped state, and use lifecycle hooks to run the bootstrap steps before the instances are stopped.

Modify the Auto Scaling group launch template to deploy the EC2 instances inside a cluster placement group to maximize throughput and accelerate the data transfer during bootstrapping.

Configure the ALB target group health check to query a lightweight secondary port that responds immediately upon instance startup, allowing the instance to receive traffic while bootstrapping in the background.

Migrate the application to AWS Lambda and configure Provisioned Concurrency to handle the spikes, keeping the execution environments active continuously to process the transactional workloads.

Show answer & explanation

Answer: Implement an Amazon EC2 Auto Scaling warm pool to maintain a pool of pre-initialized instances in a Stopped state, and use lifecycle hooks to run the bootstrap steps before the instances are stopped.

Answer

Implement an Amazon EC2 Auto Scaling warm pool to maintain a pool of pre-initialized instances in a Stopped state, and use lifecycle hooks to run the bootstrap steps before the instances are stopped.

Implementing a warm pool with pre-initialized instances in a Stopped state allows the Auto Scaling group to rapidly scale out. When a scaling event is triggered, the instances only need to be started, skipping the 6-minute bootstrap process. Using lifecycle hooks ensures that the bootstrapping is completed before the instance is stopped and placed in the pool.

Step-by-Step Solution

Analyze the bottleneck during scale-out events.

The bottleneck is the 6-minute bootstrap process required for new instances to become healthy.

Before solving the scaling latency, we must identify that the delay is caused by application initialization rather than network or load balancer provisioning.

Evaluate solutions that bypass or pre-run the initialization phase.

Amazon EC2 Auto Scaling warm pools allow instances to be launched, initialized, and then stopped or kept in a warm state.

By pre-initializing instances, they can be brought into service almost immediately when a scale-out event occurs, eliminating the 6-minute bootstrap time.

Verify that lifecycle hooks are used correctly with the warm pool.

Lifecycle hooks ensure the bootstrap script completes fully before the instance is put into the warm pool.

This guarantees that instances are fully ready to process transactions the moment they are started.

Key Concept

Amazon EC2 Auto Scaling Warm Pools allow applications with long initialization times to scale out rapidly by maintaining a pool of pre-initialized instances.

Estimated Time:2m 0s

Question 490Question →

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

Select all that apply

Migrate the database to Amazon Aurora PostgreSQL Global Database, placing the primary cluster in the active Region and a secondary cluster in the recovery Region.

Deploy the application tier in the recovery Region using an Auto Scaling group with the desired capacity set to zero, and configure Amazon Route 53 active-passive failover routing with health checks.

Configure the database with an Amazon RDS for PostgreSQL cross-Region Read Replica in the recovery Region, and configure the replica to serve as the automatic failover target for the primary database.

Configure an Amazon Route 53 latency-based routing policy to automatically redirect user traffic to the recovery Region if the active Region becomes unavailable.

Implement a Warm Standby strategy by running duplicate EC2 instances at full capacity in the recovery Region, while using daily database snapshots copied to Amazon S3 Glacier Flexible Retrieval to restore data.

Show answer & explanation

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

Answer

The solutions architect should migrate the database to Amazon Aurora PostgreSQL Global Database and deploy the application tier using an Auto Scaling group with desired capacity set to zero combined with Amazon Route 53 active-passive failover routing.

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

Step-by-Step Solution

Select a database replication technology that meets the 2-minute RPO.

Amazon Aurora PostgreSQL Global Database replicates data across Regions asynchronously with sub-second latency.

Standard multi-Region backups or replication strategies with higher lag cannot guarantee the 2-minute RPO.

Select a cost-effective application deployment strategy for the recovery Region that meets the 15-minute RTO.

An Auto Scaling group with desired capacity set to zero ensures no running EC2 instance costs during normal operations.

This Pilot Light strategy minimizes costs compared to Warm Standby while allowing instances to scale up quickly within the 15-minute RTO window.

Establish the DNS routing mechanism to handle automatic failover.

Configure Amazon Route 53 active-passive failover routing linked with application health checks.

Active-passive failover with health checks ensures user traffic is redirected automatically only when a failure is detected, avoiding misrouting issues associated with latency-only routing.

Key Concept

Designing Multi-Region Architectures for Disaster Recovery under strict RTO/RPO and cost constraints.

Estimated Time:3m 0s

Question 491Question →

A gaming company needs to process game session logs uploaded to an Amazon S3 bucket. The processing application runs as a containerized workload, with each log file taking 20 to 30 minutes to process. The logs must be processed in the exact order they are uploaded to maintain chronological player states in Amazon DynamoDB. The volume of uploads is highly unpredictable, with significant spikes during weekends and virtually no activity during weekdays. Which architecture is the most cost-effective and meets these requirements?

Configure Amazon S3 to send event notifications to an Amazon SQS FIFO queue. Run the containerized application on Amazon Elastic Container Service (Amazon ECS) using AWS Fargate, scaling tasks based on the queue size, and store the state in Amazon DynamoDB configured with on-demand capacity mode.

Configure Amazon S3 to send event notifications to a standard Amazon SQS queue. Run the containerized application on Amazon Elastic Container Service (Amazon ECS) using AWS Fargate, scaling tasks based on the queue size, and store the state in Amazon DynamoDB configured with on-demand capacity mode.

Configure Amazon S3 to trigger an AWS Lambda function directly to download and process the log files, and store the state in Amazon DynamoDB configured with on-demand capacity mode.

Show answer & explanation

Answer: Configure Amazon S3 to send event notifications to an Amazon SQS FIFO queue. Run the containerized application on Amazon Elastic Container Service (Amazon ECS) using AWS Fargate, scaling tasks based on the queue size, and store the state in Amazon DynamoDB configured with on-demand capacity mode.

Answer

The correct architecture uses Amazon SQS FIFO to guarantee that log files are processed in chronological order. Since the processing jobs take 20 to 30 minutes, they exceed the 15-minute execution limit of AWS Lambda, requiring containerized execution on AWS Fargate. AWS Fargate scales tasks dynamically based on queue activity to ensure cost efficiency. Finally, using Amazon DynamoDB in on-demand capacity mode is the most cost-effective option for highly unpredictable workloads with extended idle periods, as it charges only for read and write requests actually performed rather than provisioning unused capacity.

Step-by-Step Solution

Evaluate the execution duration requirement against compute options.

Since each log processing job takes 20 to 30 minutes, AWS Lambda (which has a 15-minute execution limit) is ruled out. Containerized execution on AWS Fargate is chosen as the compute platform.

AWS Fargate allows containerized tasks to run without time limits while scaling dynamically and avoiding the management of underlying EC2 instances.

Determine the decoupling and ordering mechanism.

Amazon SQS FIFO queue is selected to receive S3 event notifications.

The scenario requires logs to be processed in the exact order they are uploaded to maintain chronological state. Only SQS FIFO guarantees first-in, first-out delivery, whereas standard SQS does not.

Select the database capacity mode for the highly variable workload.

Configure Amazon DynamoDB with on-demand capacity mode.

Since the workload is highly unpredictable with zero activity on weekdays and high spikes on weekends, on-demand capacity mode is the most cost-effective as it charges only for actual read and write requests and has zero idle compute/capacity cost.

Key Concept

Combining serverless and automated scaling compute (Fargate), ordered messaging (SQS FIFO), and on-demand database capacity (DynamoDB) to optimize costs for unpredictable, long-running batch workloads.

Estimated Time:2m 0s

Question 492Question →

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

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

Select all that apply

Create an Amazon SQS FIFO queue to buffer the incoming transaction logs.

Deploy the processing worker on Amazon ECS using AWS Fargate to run the containerized application continuously.

Create an Amazon SQS Standard queue to buffer the incoming transaction logs.

Deploy the processing worker as an AWS Lambda function configured with a 15-minute timeout to execute the code continuously.

Show answer & explanation

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

Answer

The solutions architect should create an Amazon SQS FIFO queue to buffer the transaction logs and deploy the processing worker on Amazon ECS using AWS Fargate.

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

Step-by-Step Solution

Determine the message ordering requirement.

The transaction logs must be processed in the exact order they are received to ensure correct inventory updates.

This dictates the choice of queue type, requiring a First-In-First-Out mechanism.

Select the correct queue service.

Amazon SQS FIFO queue is selected to guarantee order and decouple the ingestion and processing layers.

Standard queues do not guarantee message order, while FIFO queues ensure strict ordering.

Analyze the consumer application workload characteristics.

The worker application must run continuously to process a steady stream of incoming messages.

This dictates the choice of compute service, favoring persistent container orchestration over short-lived serverless functions.

Select the correct compute service.

Amazon ECS with AWS Fargate is chosen to host the containerized worker continuously.

AWS Lambda is not suitable due to its 15-minute maximum execution timeout.

Key Concept

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

Question 493Question →

A company is designing a secure architecture to allow a third-party vendor's application, running in AWS Account B ( $222222222222$ ), to write diagnostic logs to an Amazon S3 bucket in the company's AWS Account A ( $111111111111$ ). The S3 bucket in Account A is encrypted using an AWS KMS customer managed key. The solution must ensure that the vendor cannot access other resources in Account A, does not use long-term AWS credentials, is protected against the confused deputy problem, and follows the principle of least privilege. Which TWO configurations must a solutions architect implement to meet these requirements?

Select all that apply

Create an IAM role in Account A with a trust policy that allows the principal `arn:aws:iam::222222222222:root` to perform `sts:AssumeRole`, and include a condition for `sts:ExternalId` matching a unique vendor-provided identifier.

Attach a permissions policy to the IAM role in Account A that grants `s3:PutObject` permissions on the S3 bucket and `kms:GenerateDataKey` permissions on the KMS key, and configure the KMS key policy to allow the IAM role to use the key.

Create a dedicated IAM user in Account A, attach the required S3 and KMS permissions, and save the access keys as a String parameter type in Systems Manager Parameter Store for the vendor to retrieve.

Use the AWS account root user of Account A to generate a pre-signed S3 URL with an extended expiration, and configure the vendor application to upload diagnostic logs directly using this URL.

Modify the S3 bucket policy in Account A to allow write access directly to the vendor's IAM role, and rely on automatic KMS key rotation to automatically update key access permissions.

Show answer & explanation

Answer: Create an IAM role in Account A with a trust policy that allows the principal `arn:aws:iam::222222222222:root` to perform `sts:AssumeRole`, and include a condition for `sts:ExternalId` matching a unique vendor-provided identifier.; Attach a permissions policy to the IAM role in Account A that grants `s3:PutObject` permissions on the S3 bucket and `kms:GenerateDataKey` permissions on the KMS key, and configure the KMS key policy to allow the IAM role to use the key.

Answer

The solutions architect must create an IAM role in Account A that trusts Account B with an external ID condition, and attach a policy allowing write access to the S3 bucket and permission to generate data keys from the KMS key.

To secure cross-account access without long-term credentials, a solutions architect should configure the third party to assume an IAM role in the resource-owning account. Trusting the root principal of Account B allows IAM administrators in Account B to delegate this role to their local resources, while the external ID prevents the confused deputy vulnerability. The assumed role must also possess write permissions for S3 and permissions to generate data keys for the KMS customer managed key to perform SSE-KMS encryption.

Step-by-Step Solution

Establish the cross-account trust relationship.

An IAM role in Account A is created, allowing Account B to assume it under the condition that a specific external ID is supplied.

This eliminates the need for long-term credentials and addresses the confused deputy problem.

Configure permissions for writing encrypted S3 data.

The IAM role permissions policy is configured with S3 write access and KMS data key generation permissions.

Writing to a bucket encrypted with a customer managed KMS key requires both S3 and KMS permissions.

Update resource-based key policies.

The KMS key policy is updated to explicitly trust the IAM role in Account A.

KMS customer managed keys require explicit key policy permissions to allow IAM identities to execute cryptographic operations.

Key Concept

Implementing secure cross-account delegation using IAM roles, trust policies with external IDs, and resource permissions for KMS-encrypted S3 buckets.

Estimated Time:3m 0s

Question 494Question →

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

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

Select all that apply

Set the deregistration delay timeout attribute of the ALB target group to

600

seconds.

Modify the target group's health check configuration to explicitly use port

8080

Add an outbound rule to the subnet's Network ACL (NACL) to statefully track and allow active connections on port

8080

during instance termination.

Configure an Amazon Route 53 latency-based routing policy to direct client traffic away from instances that are terminating during scale-in.

Configure the target group's default port to

80

and enable sticky sessions (session affinity) with a cookie duration of

600

seconds.

Show answer & explanation

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

Answer

Setting the target group deregistration delay to

600

seconds and modifying the health check configuration to target port

8080

explicitly.

The correct options are to increase the target group's deregistration delay to

600

seconds and explicitly set the health check port to

8080

. Increasing the deregistration delay allows active transactions to complete gracefully during scale-in. Explicitly targeting port

8080

in the health check ensures the load balancer accurately monitors the backend application.

Step-by-Step Solution

Analyze the connection termination issue.

Identified that the default deregistration delay (connection draining) is forcing active connections to drop before the

10

-minute (

600

-second) window needed by the processing tasks.

By increasing the deregistration delay to

600

seconds, the ALB allows in-flight requests to complete before terminating the EC2 instance.

Analyze the health check failure issue.

Identified that target group health checks are targeting the wrong port (e.g., port

80

) instead of the application's active listening port (

8080

Setting the health check port explicitly to

8080

ensures the ALB queries the port where the backend service is actually running.

Key Concept

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

Question 495Question →

A financial technology company is designing a cost-optimization strategy for its application environment on AWS. The application consists of three main components:

1. A core transactional processing service running continuously 24/7 on Amazon ECS with AWS Fargate.
2. A metadata repository on Amazon DynamoDB that handles highly unpredictable, spiky request volumes throughout the day.
3. An image-processing task that runs for less than 10 seconds per invocation, triggered whenever users upload new documents to Amazon S3.

Which of the following compute selection and purchasing strategies is the most cost-effective for this environment?

Run the ECS tasks on AWS Fargate covered by a Compute Savings Plan; configure Amazon DynamoDB in On-Demand capacity mode; and use AWS Lambda for the short-lived document processing tasks.

Run the ECS tasks on AWS Fargate, configure Amazon DynamoDB in Provisioned capacity mode, and cover all compute and database costs (Fargate, DynamoDB, and Lambda) under a single Compute Savings Plan.

Migrate the continuous 24/7 ECS core transactional processing service to run on AWS Lambda; configure Amazon DynamoDB in On-Demand capacity mode; and purchase a Compute Savings Plan to cover all Lambda functions.

Run the ECS tasks on AWS Fargate covered by a Compute Savings Plan; configure Amazon DynamoDB in Provisioned capacity mode with high fixed read/write capacity units to handle the peaks; and use AWS Lambda for the short-lived tasks.

Show answer & explanation

Answer: Run the ECS tasks on AWS Fargate covered by a Compute Savings Plan; configure Amazon DynamoDB in On-Demand capacity mode; and use AWS Lambda for the short-lived document processing tasks.

Answer

Run the ECS tasks on AWS Fargate covered by a Compute Savings Plan; configure Amazon DynamoDB in On-Demand capacity mode; and use AWS Lambda for the short-lived document processing tasks.

The correct strategy combines Compute Savings Plans for the steady-state ECS Fargate tasks, DynamoDB On-Demand capacity mode for the spiky, unpredictable database traffic, and AWS Lambda for the short-lived, event-driven tasks. Compute Savings Plans apply to Fargate and Lambda, offering up to a 66% discount on Fargate workloads. DynamoDB On-Demand avoids over-provisioning costs by charging only for active read/write requests. AWS Lambda is cost-effective for sub-second and low-duration tasks as you only pay when the function is active.

Step-by-Step Solution

Analyze the compute requirements for the core transactional processing service running continuously 24/7 on Amazon ECS with AWS Fargate.

Identify that a Compute Savings Plan is the most cost-effective purchasing model for Fargate as it offers up to 66% savings over On-Demand rates for a 1- or 3-year commitment, fitting the steady-state nature of the workload.

Steady-state containerized workloads running continuously benefit significantly from the commitment-based discounts of Compute Savings Plans.

Analyze the database requirements for Amazon DynamoDB with highly unpredictable, spiky traffic.

Select On-Demand capacity mode rather than Provisioned capacity mode.

On-Demand capacity mode charging per request is more cost-effective for unpredictable and spiky workloads because it avoids the high cost of provisioning for peak capacity that remains largely idle.

Analyze the requirements for the short-lived image-processing tasks running for less than 10 seconds.

Select AWS Lambda as the compute service.

AWS Lambda is designed for short-lived, event-driven functions and automatically scales. Since charges are based on execution duration (rounded to the millisecond) and execution count, it is highly cost-effective compared to maintaining idle EC2 or Fargate instances.

Key Concept

Selecting cost-optimal compute services (ECS Fargate vs Lambda) and aligning them with appropriate purchasing strategies (Compute Savings Plans) and database scaling modes (DynamoDB On-Demand).

Estimated Time:1m 30s

Question 496Question →

A company has a global logistics application deployed on Amazon Elastic Kubernetes Service (EKS) across two AWS regions: us-east-1 and eu-west-1. The application requires access to a proprietary third-party API key to query shipping rates. The API key must be encrypted at rest using a customer managed key (CMK) and must be rotated automatically every 90 days. The application in both regions must retrieve the key with minimal latency. Which combination of actions should a solutions architect recommend to meet these requirements with the least operational overhead? (Select TWO.)

Select all that apply

Store the API key as a secret in AWS Secrets Manager in us-east-1, and configure replication of the secret to eu-west-1.

Create an AWS Lambda function that performs the API key rotation, and configure AWS Secrets Manager to trigger the function every 90 days.

Store the API key as a plaintext String parameter in AWS Systems Manager Parameter Store to allow direct access from both regions without decryption overhead.

Enable automatic key rotation on the KMS customer managed key (CMK) that encrypts the API key secret to automatically rotate the API key value every 90 days.

Store the API key as a SecureString parameter in AWS Systems Manager Parameter Store, and configure KMS key rotation to automatically update the API key value every 90 days.

Show answer & explanation

Answer: Store the API key as a secret in AWS Secrets Manager in us-east-1, and configure replication of the secret to eu-west-1.; Create an AWS Lambda function that performs the API key rotation, and configure AWS Secrets Manager to trigger the function every 90 days.

Answer

Store the API key as a secret in AWS Secrets Manager in us-east-1 with replication to eu-west-1, and create an AWS Lambda function triggered by Secrets Manager to rotate the secret every 90 days.

Storing the API key in AWS Secrets Manager with native replication to another region ensures local low-latency access in both regions. Creating a custom Lambda function to rotate the secret and scheduling it via Secrets Manager satisfies the 90-day automatic rotation requirement.

Step-by-Step Solution

Select a secure storage service that supports cross-region replication and automatic rotation.

AWS Secrets Manager is chosen because it supports native replication to multiple regions (for low-latency access in us-east-1 and eu-west-1) and built-in integration with AWS Lambda for automatic rotation.

Systems Manager Parameter Store does not support native cross-region replication or built-in rotation schedules for custom secrets, which would increase operational overhead.

Configure the replication of the secret from the primary region to the secondary region.

The secret is stored in us-east-1 and replicated to eu-west-1, allowing EKS pods in both regions to query local replica secrets with minimal latency.

This satisfies the requirement to access the secret with low latency across regions.

Implement automatic rotation of the third-party API key.

A custom AWS Lambda function is developed to interact with the third-party provider and update the secret value in Secrets Manager. Secrets Manager is configured to run this Lambda function every 90 days.

Since the API key belongs to a third-party service, automatic rotation requires custom logic implemented via a Lambda function. KMS key rotation only rotates the backing KMS key, not the secret content itself.

Key Concept

AWS Secrets Manager supports native cross-region replication and automated custom secret rotation via AWS Lambda functions, whereas KMS key rotation only rotates the cryptographic keys and not the secrets themselves.

Estimated Time:2m 0s

Question 497Question →

An enterprise has two VPCs (VPC A and VPC B) in the same AWS Region. VPC A hosts a transaction processing application, and VPC B hosts a centralized logging cluster. The application streams approximately $60\text{ TB}$ of data monthly to the logging cluster. Currently, the two VPCs are connected via an AWS Transit Gateway. The enterprise wants to reduce the network data transfer costs for this log transmission while ensuring that all traffic remains private. Which two of the following configuration changes should a Solutions Architect recommend? (Choose two.)

Select all that apply

Establish a VPC Peering connection between VPC A and VPC B.

Update the route tables in both VPC A and VPC B to route the traffic destined for the logging cluster through the VPC Peering connection.

Provision a NAT Gateway in the public subnet of each VPC and route the log traffic over the public internet.

Establish an AWS Site-to-Site VPN connection between the two VPCs to encrypt and route the log traffic.

Create an AWS Transit Gateway Connect attachment and route the traffic through a Generic Routing Encapsulation (GRE) tunnel.

Show answer & explanation

Answer: Establish a VPC Peering connection between VPC A and VPC B.; Update the route tables in both VPC A and VPC B to route the traffic destined for the logging cluster through the VPC Peering connection.

Answer

Establish a VPC Peering connection between the two VPCs and update the route tables to route the log traffic through the VPC Peering connection instead of the Transit Gateway.

For transferring high volumes of data (such as

60\text{ TB}

monthly) between two VPCs in the same AWS Region, establishing a VPC Peering connection is the most cost-effective option. Unlike AWS Transit Gateway, which charges a per-GB processing fee (

0.02\text{ USD}

per

\text{GB}

), VPC Peering has no data processing fees and no hourly connection charges. Traffic routed via VPC Peering only incurs standard inter-AZ data transfer fees if the traffic traverses Availability Zones (

0.01\text{ USD}

per

\text{GB}

in each direction). Updating the VPC route tables ensures that the database traffic is directed through the VPC Peering connection rather than the Transit Gateway.

Step-by-Step Solution

Analyze the current architecture and costs.

The current setup uses AWS Transit Gateway to route

60\text{ TB}

of data monthly between two VPCs in the same Region. Transit Gateway charges a data processing fee (

0.02\text{ USD}

per

\text{GB}

in most regions), resulting in a processing cost of

60 \times 1000 \times 0.02 = 1200\text{ USD}

per month.

This establishes the baseline cost and identifies where the optimization can occur.

Evaluate alternative private routing mechanisms.

VPC Peering provides direct, private network connectivity between VPCs in the same Region. Unlike Transit Gateway, VPC Peering has no hourly connection fees or data processing charges. Traffic within the same Availability Zone is free, and cross-AZ traffic only incurs standard data transfer fees (

0.01\text{ USD}

per

\text{GB}

VPC Peering is identified as the most cost-effective routing solution for high-volume intra-region traffic.

Plan the implementation steps.

A VPC Peering connection must be created and accepted between VPC A and VPC B. Then, the route tables in the private subnets of both VPCs must be updated to direct traffic destined for the other VPC's CIDR block through the VPC Peering connection instead of the Transit Gateway.

This updates the routing path to bypass the Transit Gateway and leverage the cost-effective VPC Peering connection.

Key Concept

Choosing VPC Peering over Transit Gateway to minimize data processing fees for high-volume data transfer between VPCs in the same Region.

Question 498Question →

A financial technology company operates a transaction processing application deployed across two AWS Regions: us-east-1 and us-west-2. The application requires access to a third-party payment gateway API key that must be rotated every 30 days. To comply with security mandates, the key must be encrypted at rest using a Customer Managed Key (CMK) in AWS KMS, and the KMS CMK itself must be rotated annually. The solution must ensure that client applications in both Regions can retrieve the active API key with latency under $50\text{ ms}$ and experience no service interruptions during both API key rotation and KMS key rotation. Which architecture should a solutions architect recommend to meet these requirements with the least operational overhead?

Create a secret in AWS Secrets Manager in us-east-1 with replication to us-west-2. Use a Customer Managed Key (CMK) to encrypt the secret. Configure automated rotation every 30 days using a custom AWS Lambda function. Enable annual rotation on the KMS CMK, and configure the Lambda function to re-encrypt all historical secret versions using the new KMS key version immediately after KMS key rotation occurs.

Create a Systems Manager Parameter Store parameter of type String in both us-east-1 and us-west-2. Configure an AWS Lambda function triggered by an Amazon EventBridge scheduled event to update the parameter value in both Regions every 30 days. Configure the Customer Managed Key (CMK) used to encrypt the parameters to rotate automatically every year.

Create a secret in AWS Secrets Manager in us-east-1 and enable multi-Region replication to us-west-2. Configure the secret to use a Customer Managed Key (CMK) in each Region. Enable Secrets Manager automatic rotation every 30 days using a custom AWS Lambda function, and enable automatic key rotation on both KMS CMKs. Configure the application in each Region to read the secret from the local Secrets Manager endpoint.

Create a Systems Manager Parameter Store parameter of type SecureString in us-east-1. Configure a custom AWS Lambda function triggered by an Amazon EventBridge scheduled event to replicate the parameter value to us-west-2 and manually rotate the KMS Customer Managed Key (CMK) material every 30 days to keep the parameter and KMS key versions synchronized.

Show answer & explanation

Answer: Create a secret in AWS Secrets Manager in us-east-1 and enable multi-Region replication to us-west-2. Configure the secret to use a Customer Managed Key (CMK) in each Region. Enable Secrets Manager automatic rotation every 30 days using a custom AWS Lambda function, and enable automatic key rotation on both KMS CMKs. Configure the application in each Region to read the secret from the local Secrets Manager endpoint.

Answer

The correct architecture uses AWS Secrets Manager's native multi-Region replication to copy the secret to the secondary Region, allowing local applications to retrieve the secret with minimal latency. Encryption is handled using a Customer Managed Key (CMK) in each Region. Configuring automatic rotation via a custom Lambda function ensures the third-party credential is rotated every 30 days, and enabling automatic KMS CMK rotation ensures that key rotation occurs seamlessly without needing manual re-encryption or causing application downtime.

Step-by-Step Solution

Select AWS Secrets Manager for storing the sensitive API key rather than AWS Systems Manager Parameter Store.

Secrets Manager is chosen because it supports native multi-Region replication and automated rotation out-of-the-box, which aligns with the requirements of minimal latency (< 50 ms via local endpoints) and low operational overhead.

Systems Manager Parameter Store lacks native cross-Region replication and automated rotation features for third-party keys.

Configure multi-Region replication for the secret from us-east-1 to us-west-2 using local KMS CMKs in each Region.

The secret is automatically replicated and re-encrypted in us-west-2 using the destination Region's KMS CMK.

This guarantees that application instances in both Regions can query their local Secrets Manager endpoint to retrieve the secret with low latency.

Implement a custom AWS Lambda function to rotate the third-party API credential every 30 days, and configure Secrets Manager to trigger it.

Secrets Manager manages the execution of the Lambda function to update the secret value and propagates the updated secret to the replica Region.

Since the API key belongs to a third-party gateway, a custom Lambda function is necessary to call the gateway's API to obtain a new key and update the secret value.

Enable automatic annual key rotation on the KMS Customer Managed Keys in both Regions.

AWS KMS generates a new backing key annually while retaining the old backing key to decrypt any historical ciphertext.

This ensures that older secret versions can still be decrypted seamlessly without requiring manual re-encryption or causing application downtime.

Key Concept

AWS Secrets Manager multi-Region replication combined with custom rotation Lambda functions and AWS KMS automatic key rotation mechanics.

Estimated Time:3m 0s

Question 499Question →

A genomics research institute is deploying a DNA sequencing pipeline on Amazon EC2 instances. The workload requires a tightly-coupled cluster of compute nodes to perform distributed sequence alignment using Message Passing Interface (MPI). In addition, a web dashboard queries a status daemon running on port $9443$ of these instances to monitor alignment progress. The dashboard traffic is distributed to the instances via an Application Load Balancer (ALB) listening on port $443$ .

Which TWO configurations should a solutions architect implement to achieve optimal network performance for the MPI workload and ensure the ALB correctly monitors the status daemon?

Select all that apply

Deploy the EC2 instances in a cluster placement group within a single Availability Zone.

Deploy the EC2 instances in a spread placement group across multiple Availability Zones.

Configure the ALB target group's health checks to use port

9443

instead of the default traffic port.

Configure the ALB target group to perform health checks on the default traffic port of

443

Deploy the EC2 instances in a partition placement group to isolate processing workloads on distinct hardware partitions.

Show answer & explanation

Answer: Deploy the EC2 instances in a cluster placement group within a single Availability Zone.; Configure the ALB target group's health checks to use port $9443$ instead of the default traffic port.

Answer

Deploy the EC2 instances in a cluster placement group within a single Availability Zone, and configure the Application Load Balancer target group's health checks to use the custom daemon port instead of the default traffic port.

The correct configurations are to deploy the EC2 instances in a cluster placement group and to configure the ALB target group's health checks to use the specific port where the status daemon runs. A cluster placement group places instances physically close to each other in a single Availability Zone, providing the low-latency network performance required by tightly-coupled MPI workloads. Additionally, specifying the custom daemon port for the ALB health checks ensures the load balancer accurately monitors the status daemon's health rather than the main web server port.

Step-by-Step Solution

Determine the placement group requirement for a tightly-coupled MPI computing workload.

A cluster placement group is selected because it enables low-latency, high-throughput node-to-node networking within a single Availability Zone.

Tightly-coupled cluster nodes must communicate with minimal latency, which is the primary benefit of cluster placement groups.

Identify the correct health check port configuration for the status daemon.

The health check port in the target group configuration must be explicitly set to the daemon's port.

If the daemon runs on a custom port that is different from the main traffic port, the default traffic port health check will fail to monitor the actual daemon.

Key Concept

Tightly-coupled high-performance computing (HPC) environments require cluster placement groups for low-latency networking, and load balancers must have health checks aligned with the specific service ports of monitored daemons.

Question 500Question →

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

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

Deploy a scaled-down application tier with a minimum capacity of EC2 instances running behind an Application Load Balancer in the secondary region. Replicate the RDS database using a cross-region read replica, and scale up the EC2 instances during a failover.

Export RDS automated snapshots hourly and copy them to an Amazon S3 Glacier Flexible Retrieval vault in the secondary region. In the event of a disaster, initiate standard retrieval of the database snapshots, restore the database, and deploy the application resources.

Configure Amazon RDS Multi-AZ in the primary region. Use Amazon Route 53 latency-based routing to automatically redirect user traffic to the secondary region and promote the standby database instance in the secondary region during an outage.

Show answer & explanation

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

Answer

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

Step-by-Step Solution

Evaluate the RPO requirement (15 minutes) against data replication options.

Cross-region RDS read replicas provide continuous asynchronous replication, keeping data lag to a few seconds or minutes, which easily satisfies the 15-minute RPO.

Ensures that the secondary database is up-to-date and ready for promotion with minimal data loss.

Evaluate the RTO requirement (2 hours) and cost-minimization constraint.

A Pilot Light strategy allows the database to run as a read replica in the secondary region while keeping compute resources shut down or unprovisioned. Deploying compute resources via CloudFormation templates and AMIs takes less than 30 minutes, which is well within the 2-hour RTO limit and minimizes compute costs.

Allows the company to avoid paying for running EC2 instances and load balancer idle time in the secondary region during normal operations.

Compare against the Warm Standby and Backup and Restore alternatives.

Warm Standby is rejected due to unnecessary ongoing compute cost. Backup and Restore with Glacier is rejected because Glacier retrieval times exceed the 2-hour RTO, and hourly snapshots violate the 15-minute RPO.

Selects the optimal strategy that meets all recovery goals while staying cost-optimized.

Key Concept

Disaster Recovery strategies (Pilot Light vs. Warm Standby) and cross-region database replication in AWS.

Estimated Time:2m 0s

PreviousPage 25 / 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

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