All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

An enterprise financial analytics application processes large datasets using a fleet of Amazon EC2 instances. The application reads data from an Amazon RDS for PostgreSQL DB instance in a Multi-AZ deployment, and writes temporary raw output files to attached Amazon EBS gp3 volumes. During daily batch processing runs, performance degrades. Database metrics show high CPU utilization and elevated read latencies on the primary database due to analytical queries. Concurrently, the EC2 instances show high I/O wait times, indicating that the EBS volumes are bottlenecked. Which two modifications should the Solutions Architect implement to optimize the performance of the database and compute tiers? (Select TWO.)

Select all that apply

Deploy one or more Amazon RDS read replicas, and configure the batch application to route read-intensive analytical queries to the replica endpoints.

Modify the EBS gp3 volumes on the EC2 instances to increase the provisioned throughput and IOPS, or utilize EC2 instance store volumes for temporary scratch space.

Enable query caching and read auto-scaling directly on the standby replica of the Multi-AZ RDS DB instance to distribute the analytical query load.

Request that AWS Support pre-warm the Application Load Balancer (ALB) that sits in front of the EC2 batch processing fleet to ensure sufficient throughput for incoming data.

Show answer & explanation

Answer: Deploy one or more Amazon RDS read replicas, and configure the batch application to route read-intensive analytical queries to the replica endpoints.; Modify the EBS gp3 volumes on the EC2 instances to increase the provisioned throughput and IOPS, or utilize EC2 instance store volumes for temporary scratch space.

Answer

Deploy Amazon RDS read replicas and route read queries to them, and modify the EBS gp3 volumes to increase provisioned throughput/IOPS or use instance store volumes.

Creating RDS read replicas offloads analytical query workloads from the primary database instance, resolving primary DB CPU and read latency issues. Upgrading the gp3 EBS volumes' provisioned performance or switching to instance store volumes for temporary scratch files provides the high throughput and IOPS necessary to eliminate EC2 I/O bottlenecks.

Step-by-Step Solution

Analyze the database bottleneck.

Identify that CPU and read latencies on the primary database are caused by read-heavy analytical queries on a Multi-AZ deployment.

Multi-AZ deployments do not provide horizontal scaling; standby instances are passive and cannot handle read traffic.

Address the database bottleneck.

Create Amazon RDS read replicas and configure the application to send read queries to the new replica endpoints.

This offloads read operations from the primary DB instance, freeing up resources and reducing latency.

Analyze the compute storage bottleneck.

Identify that high I/O wait times on EC2 instances are due to the performance limits of the gp3 EBS volumes during batch file writes.

Standard gp3 baseline performance may be insufficient for high-throughput sequential or random I/O operations.

Address the compute storage bottleneck.

Increase provisioned throughput and IOPS on gp3 volumes or utilize local instance store volumes for transient scratch space.

This provides the required storage performance to eliminate I/O wait times during processing.

Key Concept

Horizontal scaling of read workloads using RDS read replicas and optimization of EC2 storage using provisioned EBS performance or instance store volumes.

Estimated Time:2m 0s

Question 1062Question →

An enterprise operates a multi-region application across two AWS accounts to support disaster recovery. Account A hosts the primary application infrastructure in the us-east-1 Region, including a public Application Load Balancer (ALB) and an Auto Scaling group of Amazon EC2 instances inside a VPC. Account B hosts the standby infrastructure in the us-west-2 Region with a similar configuration. A Route 53 public hosted zone, managed in a separate shared services account, routes external traffic to the ALBs using failover routing. Internal microservices in the primary VPC query a shared service using an internal domain name registered in a Route 53 Private Hosted Zone (PHZ) internal.corp hosted in Account A. During a disaster recovery simulation, the primary region was degraded due to backend database replication lag and EC2 instance failures, but the public ALB in us-east-1 remained operational. The simulation revealed two issues: 1. The public Route 53 failover record did not route traffic to the standby ALB in us-west-2 because the health check was configured to monitor the ALB's endpoint, which returned a 200 OK status from a static welcome page on the ALB itself. 2. The EC2 instances launched in Account B's VPC in us-west-2 were unable to resolve the internal domain names hosted in Account A's PHZ. Which combination of steps will resolve these issues and ensure a reliable, automated failover process?

Share the Route 53 Private Hosted Zone internal.corp from Account A to Account B using AWS Resource Access Manager (RAM). Configure the Route 53 public hosted zone to use latency-based routing, and disable 'Evaluate Target Health' on the alias records to prevent intermittent failovers caused by temporary database replication lag.

Establish a VPC Peering connection between Account A's VPC and Account B's VPC to automatically extend private DNS resolution of internal.corp across the accounts. Configure Route 53 Application Recovery Controller (ARC) routing controls for the public ALBs, but set up the routing controls without Route 53 health checks to prevent automated failover from occurring without manual operator confirmation.

Create a VPC association authorization in Account A for the Private Hosted Zone internal.corp targeting the VPC in Account B, and then associate the VPC in Account B with the hosted zone. Configure a custom health check endpoint (such as /health) on the ALB target group that validates backend application and database connectivity, and enable 'Evaluate Target Health' on the Route 53 public alias failover records.

Attach a cross-account IAM role to Account B's EC2 instances that grants Route 53 read-only permissions to query the Private Hosted Zone in Account A. Configure the public Route 53 hosted zone to route traffic using a weighted routing policy, and deploy an AWS Lambda function triggered by Amazon CloudWatch alarms to manually swap DNS weights from Account A to Account B when an outage is detected.

Show answer & explanation

Answer: Create a VPC association authorization in Account A for the Private Hosted Zone internal.corp targeting the VPC in Account B, and then associate the VPC in Account B with the hosted zone. Configure a custom health check endpoint (such as /health) on the ALB target group that validates backend application and database connectivity, and enable 'Evaluate Target Health' on the Route 53 public alias failover records.

Answer

The correct answer resolves both issues using native AWS features. To enable cross-account VPC resolution for a Route 53 Private Hosted Zone (PHZ), you must first create a VPC association authorization in the hosting account (Account A) and then associate the target VPC (Account B's VPC) from the target account. For the failover issue, configuring the ALB target group health checks to use a custom endpoint (like /health) that verifies backend application and database connectivity ensures that if the backend degrades, the targets will be marked unhealthy. Enabling 'Evaluate Target Health' on the Route 53 alias failover record then allows Route 53 to automatically detect the unhealthy ALB and fail over to the standby region.

Step-by-Step Solution

Authorize the Private Hosted Zone association from Account A to the VPC in Account B.

An association authorization is created for the target VPC in Account B.

Route 53 Private Hosted Zones cannot be directly associated across accounts without authorization from the owner account.

Associate the VPC in Account B with the Private Hosted Zone in Account A using the AWS CLI or API.

The standby instances in Account B's VPC can resolve the internal domain names under the private hosted zone.

Once authorized, the target account must accept the association so its VPC Route 53 resolver queries the hosted zone.

Configure the ALB target group health check path to a custom path (such as /health) that validates backend application logic and database replication status.

The ALB will report unhealthy status if the backend application or database connection fails, rather than only testing the load balancer listener.

A default HTTP listener response does not reflect actual application availability, which prevents DNS failover if the application fails but the ALB remains online.

Enable 'Evaluate Target Health' on the Route 53 public alias records pointing to the ALBs.

Route 53 automatically stops routing traffic to the primary ALB when its target group health check fails.

Setting 'Evaluate Target Health' to yes instructs Route 53 to check the health of the ALB's backend targets and perform automated DNS failover.

Key Concept

Cross-account Route 53 Private Hosted Zone association and deep application health checks for automated multi-region failover

Question 1063Question →

A financial services company operates a microservices-based application running on Amazon ECS with AWS Fargate across ten member accounts within an AWS Organization. The operations team needs to build a centralized dashboard in a designated monitoring account to analyze application performance, query log groups, and view distributed service traces across all member accounts. The solution must minimize operational overhead and avoid manual infrastructure provisioning or custom log-routing agents. Which strategy should a Solutions Architect implement to meet these requirements?

Modify the ECS task definitions in each member account to include a sidecar container running the CloudWatch Agent. Configure the agent using a static JSON configuration file to stream local container logs and custom metrics directly to log groups in the central monitoring account using cross-account IAM roles assumed by the task execution role.

Configure CloudWatch cross-account observability by creating a sink in the central monitoring account and defining links in the member accounts using AWS CloudWatch Observability Access Manager (OAM). Enable sharing for logs, metrics, and traces, and access the consolidated data from the monitoring account's CloudWatch console.

Deploy an Amazon Kinesis Data Firehose delivery stream in each member account to collect container logs and send them to a centralized Amazon S3 bucket in the monitoring account. Use Amazon Athena to query the logs and Amazon QuickSight to visualize metrics, ensuring the S3 bucket policy is configured to allow cross-account writes from the member accounts' Firehose IAM roles.

Attach a Service Control Policy (SCP) at the root level of the AWS Organization that grants permission for ECS tasks to write CloudWatch logs and X-Ray traces directly to the monitoring account. Configure the ECS tasks to write to the central monitoring account's regional CloudWatch and X-Ray endpoints.

Show answer & explanation

Answer: Configure CloudWatch cross-account observability by creating a sink in the central monitoring account and defining links in the member accounts using AWS CloudWatch Observability Access Manager (OAM). Enable sharing for logs, metrics, and traces, and access the consolidated data from the monitoring account's CloudWatch console.

Answer

The correct solution leverages Amazon CloudWatch cross-account observability using AWS CloudWatch Observability Access Manager (OAM). By creating a central sink in the monitoring account and linking the member accounts to it, the operations team can search logs, view consolidated metrics, and inspect traces across all accounts from the central console. This approach requires no agent maintenance or sidecar management, minimizing operational overhead.

Step-by-Step Solution

Create a centralized sink in the monitoring account using AWS CloudWatch Observability Access Manager (OAM).

A sink is provisioned with a resource policy allowing access from the Organization or member accounts.

This establishes a central endpoint to receive observability data.

Create links in each source member account pointing to the central sink's ARN, choosing to share metrics, logs, and traces.

The member accounts are securely connected to the central monitoring account.

This enables native AWS sharing of CloudWatch and X-Ray data without custom pipelines.

Open the CloudWatch console in the monitoring account to view consolidated metrics, run cross-account log searches, and inspect service traces.

Operational visibility is unified across all ten member accounts with minimal administrative overhead.

This provides a single pane of glass for monitoring and troubleshooting without custom scripts or agents.

Key Concept

CloudWatch Cross-Account Observability using AWS OAM

Question 1064Question →

An application runs on Amazon EC2 instances managed by an Auto Scaling group deployed across three Availability Zones ( $AZ-A$ , $AZ-B$ , and $AZ-C$ ). The EC2 instances are in private subnets and need to make outbound connections to the internet to fetch system updates. Which actions should a Solutions Architect take to design a network topology that provides high availability and fault tolerance for outbound internet traffic if any single Availability Zone experiences an outage? (Select TWO.)

Select all that apply

Deploy a NAT gateway in a public subnet within each of the three Availability Zones.

Configure the route table for the private subnets in each Availability Zone to route outbound internet traffic through the NAT gateway in the corresponding Availability Zone.

Deploy a single NAT gateway in the public subnet of

AZ-A

and configure the route tables for private subnets in

AZ-B

and

AZ-C

to route traffic through it.

Deploy a NAT gateway in a private subnet in each of the three Availability Zones to protect the gateway from direct public internet exposure.

Set the Auto Scaling group default cooldown period to

60

seconds to accelerate the launching of new instances when outbound traffic fails.

Show answer & explanation

Answer: Deploy a NAT gateway in a public subnet within each of the three Availability Zones.; Configure the route table for the private subnets in each Availability Zone to route outbound internet traffic through the NAT gateway in the corresponding Availability Zone.

Answer

Deploy a NAT gateway in a public subnet within each of the three Availability Zones, and configure the route table for the private subnets in each Availability Zone to route outbound internet traffic through the NAT gateway in the corresponding Availability Zone.

To achieve high availability and fault tolerance for outbound internet traffic in a multi-AZ VPC, a NAT Gateway must be deployed in a public subnet in each Availability Zone. The private subnets in each Availability Zone should then be configured to route their outbound traffic (

0.0.0.0/0

) to the NAT Gateway in the same Availability Zone. This ensures that the failure of a single Availability Zone does not impact outbound traffic from the other healthy Availability Zones.

Step-by-Step Solution

Analyze the single point of failure in the network architecture.

Identified that routing traffic from multiple Availability Zones through a single NAT Gateway makes the entire outbound path dependent on the health of that gateway's Availability Zone.

AWS NAT Gateways operate within a single Availability Zone. If that zone fails, the gateway becomes unavailable, causing connectivity loss for all dependent subnets.

Design a highly available NAT Gateway topology.

Determine that deploying a NAT Gateway in a public subnet in each Availability Zone (

AZ-A

AZ-B

, and

AZ-C

) is required for zone redundancy.

Zonal NAT Gateways ensure that if one Availability Zone goes down, the instances in the other zones can still access the internet through their local, functioning NAT Gateways.

Configure routing to support zonal isolation.

Point the route table of the private subnets in each Availability Zone to the NAT Gateway in the same zone.

This configuration avoids cross-zone dependencies and charges, ensuring that outbound traffic stays within the same zone until it leaves the VPC.

Key Concept

High Availability and Fault Tolerance with Zonal NAT Gateways

Estimated Time:1m 30s

Question 1065Question →

A SaaS platform operates a real-time media processing pipeline in the `us-east-1` Region. The architecture consists of an ingestion fleet of Amazon EC2 instances behind an Application Load Balancer (ALB) in the `IngestionVPC`, and a processing cluster of EC2 instances in the `ProcessingVPC`. Currently, the two VPCs are connected via an AWS Transit Gateway. The ingestion instances resolve the processing cluster's domain names using a Route 53 Private Hosted Zone (PHZ) that is associated only with the `ProcessingVPC`, leading to intermittent name resolution failures. The platform is preparing for a scheduled live-streaming event that will generate an immediate, massive traffic spike (flash traffic). The solutions architect must optimize the network to minimize latency and maximize throughput between the ingestion and processing tiers, resolve the DNS failures, and ensure the infrastructure can handle the traffic surge without dropping packets.

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

Select all that apply

Establish a VPC Peering connection between the IngestionVPC and the ProcessingVPC, update the subnet route tables to direct inter-VPC traffic through the peering connection, and configure the EC2 instances to use jumbo frames with an MTU of

9001

Associate the existing Route 53 Private Hosted Zone with the IngestionVPC to enable internal name resolution for the processing cluster.

Submit a support ticket to AWS to pre-warm the Application Load Balancer prior to the event to handle the sudden traffic surge.

Route all inter-VPC traffic through an AWS Direct Connect gateway connected directly to both VPCs to bypass the Transit Gateway and achieve low-latency transitive routing.

Create a new, separate Route 53 Private Hosted Zone with the same domain name in the IngestionVPC to resolve local queries, instead of associating the existing zone.

Configure the ALB with a target tracking scaling policy based on the RequestCountPerTarget metric to scale the load balancer during the event, rather than requesting pre-warming.

Show answer & explanation

Answer: Establish a VPC Peering connection between the IngestionVPC and the ProcessingVPC, update the subnet route tables to direct inter-VPC traffic through the peering connection, and configure the EC2 instances to use jumbo frames with an MTU of $9001$ .; Associate the existing Route 53 Private Hosted Zone with the IngestionVPC to enable internal name resolution for the processing cluster.; Submit a support ticket to AWS to pre-warm the Application Load Balancer prior to the event to handle the sudden traffic surge.

Answer

To optimize network performance, establish a VPC Peering connection and configure jumbo frames (MTU

9001

) on the EC2 instances. To resolve the DNS issues, associate the existing Route 53 Private Hosted Zone with the IngestionVPC. To handle the flash traffic, submit a support ticket to AWS to pre-warm the ALB.

The correct architecture involves establishing a VPC Peering connection between the IngestionVPC and ProcessingVPC, which provides the lowest latency and highest throughput for same-region traffic while supporting jumbo frames (MTU

9001

). To resolve the domain name resolution failures, the existing Route 53 Private Hosted Zone must be associated with the IngestionVPC. To handle the anticipated flash traffic without packet loss, the Application Load Balancer must be pre-warmed by submitting a support ticket to AWS.

Step-by-Step Solution

Establish VPC Peering between the IngestionVPC and ProcessingVPC, update subnet route tables to point to the peering connection, and set the MTU to

9001

on the EC2 instances.

Inter-VPC traffic bypasses the Transit Gateway, eliminating extra hops and bandwidth caps, and jumbo frames reduce packet overhead for large transfers.

VPC Peering provides direct routing with higher throughput and lower latency than Transit Gateway in the same region, and supports jumbo frames.

Associate the existing Route 53 Private Hosted Zone of the ProcessingVPC with the IngestionVPC.

The ingestion fleet can resolve the private DNS names of the processing cluster directly.

A Route 53 Private Hosted Zone must be associated with a VPC for instances in that VPC to resolve its DNS records.

Submit a request to AWS Support to pre-warm the Application Load Balancer.

The ALB is pre-provisioned with the capacity required to handle the anticipated flash traffic surge immediately.

ALB auto-scaling is reactive; sudden, massive traffic spikes will exceed the current capacity and lead to dropped connections before scaling completes.

Key Concept

Optimizing inter-VPC network throughput and latency using VPC Peering and Jumbo Frames, cross-VPC Route 53 Private Hosted Zone association, and pre-warming Application Load Balancers for flash traffic.

Question 1066Question →

An investment bank runs a daily risk analysis simulation on AWS. The application tier runs on a fleet of memory-optimized Amazon EC2 instances in an Auto Scaling group (ASG). Every day at 09:00 UTC, a massive batch of simulation queries is initiated, causing immediate CPU utilization spikes on both the application fleet and the database, which is hosted on Amazon RDS PostgreSQL. Additionally, during the simulation, the EC2 instances perform heavy write operations to write transient checkpoint files to attached EBS gp3 volumes, resulting in high write latency and disk queue length spikes. Which combination of architectural modifications will optimize the compute and storage performance of this platform?

Configure a scheduled scaling action for the EC2 Auto Scaling group to scale out before 09:00 UTC. Deploy Amazon RDS PostgreSQL Read Replicas and route read queries to the read replica endpoints. Increase the provisioned IOPS and throughput of the attached gp3 volumes to accommodate checkpoint write requirements.

Configure a scheduled scaling action for the EC2 Auto Scaling group to scale out before 09:00 UTC. Route the read queries to the standby instance of the RDS PostgreSQL Multi-AZ deployment to offload the primary instance. Increase the provisioned IOPS and throughput of the attached gp3 volumes to accommodate checkpoint write requirements.

Rely on dynamic target tracking scaling policies based on CPU utilization to scale out the EC2 Auto Scaling group at 09:00 UTC. Deploy an Application Load Balancer to route traffic to the EC2 instances, relying on the load balancer's automatic scaling to handle the instant load spike. Deploy Amazon RDS PostgreSQL Read Replicas and route read queries to the read replica endpoints.

Migrate the simulation runs to AWS Fargate to scale compute dynamically, and purchase EC2 Instance Savings Plans to optimize the compute cost of these Fargate tasks. Deploy Amazon RDS PostgreSQL Read Replicas and route read queries to the read replica endpoints.

Show answer & explanation

Answer: Configure a scheduled scaling action for the EC2 Auto Scaling group to scale out before 09:00 UTC. Deploy Amazon RDS PostgreSQL Read Replicas and route read queries to the read replica endpoints. Increase the provisioned IOPS and throughput of the attached gp3 volumes to accommodate checkpoint write requirements.

Answer

The correct option addresses all three performance bottlenecks optimally. Scheduled scaling resolves the slow response of dynamic scaling before the daily 09:00 UTC simulation run. Deploying RDS Read Replicas offloads database CPU usage by distributing the read spike. Increasing provisioned IOPS and throughput on EBS gp3 volumes directly resolves storage latency bottlenecks without paying for unnecessary storage space.

Step-by-Step Solution

Address predictable compute scale-out latency.

Implement a scheduled scaling action for the Auto Scaling group set to trigger prior to 09:00 UTC.

Target tracking policies react only after metrics cross thresholds, leading to performance degradation during sudden spikes. Scheduled scaling ensures compute capacity is warm and ready before the workload begins.

Address database read bottlenecks.

Deploy one or more RDS PostgreSQL Read Replicas and modify the application to route read queries to their endpoints.

RDS PostgreSQL Multi-AZ standbys cannot handle read connections. Offloading query traffic to dedicated Read Replicas preserves primary instance CPU for write transactions.

Optimize transient storage performance.

Provision higher IOPS and throughput parameters directly on the gp3 volumes without expanding disk size.

EBS gp3 volumes allow independent adjustment of IOPS and throughput to meet temporary performance spikes, avoiding the need to over-provision storage capacity.

Key Concept

Optimizing compute and storage involves matching workloads to the correct provisioning mechanisms: scheduled scaling for predictable compute spikes, read replicas for database read distribution, and independent EBS throughput provisioning.

Question 1067Question →

A financial services company operates a latency-critical application in the us-east-1 Region. The application's core components are split across two AWS accounts: Account A hosts the real-time processing fleet on Amazon EC2 instances in private subnets across three Availability Zones in VPC-Processing, and Account B hosts a caching layer in VPC-Cache. Currently, the two VPCs are connected via an AWS Transit Gateway.

During high-volume events, the platform experiences increased latency and packet drops. A network audit reveals the following:
* Outbound internet traffic from all private subnets in VPC-Processing is routed through a single NAT Gateway located in Availability Zone us-east-1a.
* Large database synchronization streams between the processing fleet and the caching layer are capped at $1.25\text{ Gbps}$ per connection, even though the EC2 instances support up to $25\text{ Gbps}$ network bandwidth.
* EC2 instances in VPC-Processing resolve the private IP addresses of the caching layer by querying a Route 53 Private Hosted Zone (PHZ) created in Account B, but queries are currently traversing public resolvers, causing elevated DNS resolution times.

Which combination of actions will resolve the latency and throughput bottlenecks while ensuring high availability?

Replace the Transit Gateway connection between VPC-Processing and VPC-Cache with a VPC Peering connection. Deploy a NAT Gateway in each of the three Availability Zones in VPC-Processing, and update the private route tables to route outbound traffic to the local NAT Gateway in the same zone. Authorize and associate the Route 53 Private Hosted Zone in Account B with VPC-Processing.

Request AWS Support to pre-warm the Application Load Balancer in VPC-Processing to handle traffic surges. Retain the Transit Gateway connection and request a bandwidth limit increase. Keep the single NAT Gateway in Availability Zone us-east-1a to control costs, and authorize and associate the Route 53 Private Hosted Zone in Account B with VPC-Processing.

Replace the Transit Gateway connection between VPC-Processing and VPC-Cache with a VPC Peering connection. Retain the single NAT Gateway in Availability Zone us-east-1a to minimize Elastic IP usage, but update route tables to use inter-AZ routes for resiliency. Configure Route 53 Resolver outbound endpoints in VPC-Processing and inbound endpoints in VPC-Cache to handle DNS queries across the peering connection.

Establish connections from both VPC-Processing and VPC-Cache to a central AWS Direct Connect Gateway to enable low-latency transitive routing between the VPCs. Deploy a NAT Gateway in each of the three Availability Zones in VPC-Processing. Authorize and associate the Route 53 Private Hosted Zone in Account B with VPC-Processing.

Show answer & explanation

Answer: Replace the Transit Gateway connection between VPC-Processing and VPC-Cache with a VPC Peering connection. Deploy a NAT Gateway in each of the three Availability Zones in VPC-Processing, and update the private route tables to route outbound traffic to the local NAT Gateway in the same zone. Authorize and associate the Route 53 Private Hosted Zone in Account B with VPC-Processing.

Answer

Replace the Transit Gateway connection with a VPC Peering connection, deploy a NAT Gateway in each of the three Availability Zones, and authorize and associate the Route 53 Private Hosted Zone in Account B with VPC-Processing.

The correct solution resolves the three latency and throughput bottlenecks. Replacing the Transit Gateway with a VPC Peering connection removes the

1.25\text{ Gbps}

single-flow TCP limit that Transit Gateway VPC attachments enforce, enabling single-flow replication to scale up to the EC2 instances' maximum bandwidth. Deploying a NAT Gateway in each Availability Zone removes the single point of failure, prevents cross-AZ data transfer latency, and distributes egress load. Authorizing and associating the Route 53 Private Hosted Zone in Account B directly with VPC-Processing in Account A allows local DNS queries to be resolved directly by the Route 53 resolver (

169.254.169.253

), minimizing lookup latency.

Step-by-Step Solution

Address the single-flow replication throughput bottleneck by replacing the Transit Gateway attachment.

Create a VPC Peering connection between VPC-Processing and VPC-Cache, enabling single-flow TCP traffic to utilize the full network bandwidth capacity of the EC2 instances, bypassing the Transit Gateway

1.25\text{ Gbps}

single-flow limit.

Transit Gateway imposes a hard limit of

1.25\text{ Gbps}

per single 5-tuple stream, whereas VPC Peering has no such limitation.

Resolve the single point of failure and cross-AZ egress latency.

Deploy one NAT Gateway in the public subnet of each of the three Availability Zones in VPC-Processing. Update the route tables of the private subnets to send outbound internet traffic (

0.00.0/0

) to the local NAT Gateway in their respective zone.

This removes cross-AZ data transfer latency/charges and ensures high availability if one Availability Zone experiences an outage.

Optimize cross-account DNS resolution for the caching layer.

Create a Private Hosted Zone association authorization in Account B for VPC-Processing, and accept the association from Account A.

Associating the Route 53 PHZ directly with VPC-Processing ensures DNS queries are answered locally by the Route 53 resolver (

169.254.169.253

) without traversing public networks or requiring extra resolver endpoints.

Key Concept

Removing single-stream bandwidth limits using VPC Peering, ensuring high availability with multi-AZ NAT Gateways, and optimizing cross-account DNS with Route 53 Private Hosted Zone associations.

Estimated Time:3m 0s

Question 1068Question →

A company runs a critical business application on Amazon ECS on AWS Fargate in the us-west-2 Region, distributed across three Availability Zones. The application's backend database is an Amazon Aurora PostgreSQL Serverless v2 cluster. The company wants to implement a disaster recovery (DR) solution in the us-east-1 Region. The business requires a Recovery Point Objective (RPO) of 5 minutes and a Recovery Time Objective (RTO) of 15 minutes, while minimizing idle compute costs in the disaster recovery region.

Which TWO actions should the Solutions Architect take to design a disaster recovery solution that meets these requirements? (Select TWO.)

Select all that apply

Configure an Amazon Aurora Global Database with the primary cluster in the primary region and a secondary cluster in the secondary region.

Deploy the ECS Fargate services in the secondary region using AWS CloudFormation with the desired task count set to 0, scaling up the tasks during a failover event.

Configure AWS Backup to take database snapshots every 2 hours, copy them to the secondary region, and restore the database to a new cluster during failover.

Configure a Route 53 failover routing policy for the public application endpoint pointing to both regions, but omit Route 53 health checks to prevent premature failover from transient network issues.

Deploy a Route 53 Private Hosted Zone in the secondary region with the same domain name as the primary region, relying on the active VPC peering connection to automatically resolve internal DNS queries across both regions without VPC association.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in the primary region and a secondary cluster in the secondary region.; Deploy the ECS Fargate services in the secondary region using AWS CloudFormation with the desired task count set to 0, scaling up the tasks during a failover event.

Answer

Configuring Amazon Aurora Global Database with a secondary cluster in the secondary region, and deploying the ECS Fargate services in the secondary region with the desired task count set to 0.

To meet the 5-minute RPO, Amazon Aurora Global Database is required as its physical replication lag is typically less than a second. To meet the 15-minute RTO while keeping costs at a minimum, ECS Fargate services can be configured with a desired task count of 0 in the secondary region and scaled up only when a failover is initiated.

Step-by-Step Solution

Evaluate the database replication options against the RPO of 5 minutes. Aurora Global Database provides sub-second replication, satisfying this constraint.

Select Amazon Aurora Global Database replication.

Standard backup and restore operations cannot meet the sub-5-minute RPO and sub-15-minute RTO.

Evaluate the compute strategy to minimize idle costs while meeting the 15-minute RTO. ECS Fargate tasks can be pre-configured with a desired count of 0.

Select Fargate task scale-up on demand.

ECS Fargate tasks provision and start in under a few minutes, which easily fits within the 15-minute RTO window.

Key Concept

Selecting replication and compute architectures to balance multi-region RTO/RPO limits and operational cost constraints.

Question 1069Question →

A healthcare startup stores sensitive patient genomic data in an Amazon S3 bucket. The startup must grant read-only access to specific genomic data files to a third-party research group operating in a separate AWS account that is outside the startup's AWS organization. Currently, all data in the S3 bucket is unencrypted. The compliance team mandates that all files must be encrypted at rest using customer-managed keys (CMKs) to ensure complete auditability of key access, and that the external researchers must be able to securely decrypt and retrieve the files. Which combination of actions must the Solutions Architect perform to implement this configuration? (Select TWO.)

Select all that apply

Create a customer-managed KMS key in the startup's account, configure its key policy to delegate permissions to the startup's root account, and explicitly add a statement to the key policy that grants the external research role permission to perform the kms:Decrypt action.

Apply a bucket policy to the startup's S3 bucket that grants the external research role permission to perform s3:GetObject, and configure the IAM policy of the external research role to allow both s3:GetObject on the startup's bucket and kms:Decrypt on the customer-managed KMS key.

Configure the S3 bucket to use the default AWS-managed KMS key (aws/s3) for encryption, and update the bucket policy to grant the external research role read access to the bucket.

Attach a Service Control Policy (SCP) to the Organizational Unit (OU) level of the startup's organization that explicitly permits cross-account kms:Decrypt and s3:GetObject access to the external research role's ARN.

Update the S3 bucket policy to grant both s3:GetObject and kms:Decrypt permissions to the external research role, bypassing the need to modify the KMS key policy.

Show answer & explanation

Answer: Create a customer-managed KMS key in the startup's account, configure its key policy to delegate permissions to the startup's root account, and explicitly add a statement to the key policy that grants the external research role permission to perform the kms:Decrypt action.; Apply a bucket policy to the startup's S3 bucket that grants the external research role permission to perform s3:GetObject, and configure the IAM policy of the external research role to allow both s3:GetObject on the startup's bucket and kms:Decrypt on the customer-managed KMS key.

Answer

Create a customer-managed KMS key and allow the external role decryption permissions in the key policy, then configure the S3 bucket policy to grant object retrieval access and have the external IAM policy permit both actions.

To share S3 objects encrypted with KMS cross-account, a customer-managed KMS key must be used. The key policy must be updated to allow the external account or role to perform the decryption operation. In addition, the S3 bucket policy must allow the external role retrieval permissions, and the IAM policy of the external role must explicitly allow both retrieval and decryption actions on the respective resources.

Step-by-Step Solution

Create and configure a customer-managed KMS key.

A key is generated whose policy can be customized to allow cross-account access.

AWS-managed KMS keys do not support policy modification and cannot be shared across accounts.

Add the external IAM role to the customer-managed KMS key policy.

The external role receives decryption permissions for objects encrypted with this key.

KMS permissions must be declared in the key policy to enable cross-account access.

Configure the S3 bucket policy and the external IAM role policy.

The external role has both S3 and KMS permissions to retrieve and decrypt objects.

Cross-account access to S3 requires permissions on both the S3 bucket policy and the IAM user/role policy.

Key Concept

Cross-account access to encrypted S3 resources requires a customer-managed KMS key, a key policy that permits the external entity to perform decryption, an S3 bucket policy permitting read access, and local IAM policies in the external account enabling both actions.

Estimated Time:2m 0s

Question 1070Question →

An enterprise is designing a highly resilient multi-account network architecture in the ap-southeast-1 Region. The design includes two application VPCs: vpc-app-hr in AWS Account A and vpc-app-finance in AWS Account B. A third VPC, vpc-shared-services in AWS Account C, hosts a centralized repository and a Route 53 Private Hosted Zone (PHZ) named services.internal.

An AWS Transit Gateway named tgw-hub in Account C connects all three VPCs. The application VPCs must have private DNS resolution for services.internal and require highly available, cost-effective outbound internet access for downloading patches. To centralize egress control, the security team mandates using NAT Gateways deployed in vpc-shared-services.

Which combination of configurations will meet these requirements while ensuring resilience to Availability Zone (AZ) failures? (Select TWO.)

Select all that apply

Deploy one NAT Gateway in each of two Availability Zones within the public subnets of vpc-shared-services. Configure the subnet route tables in the private subnets of vpc-shared-services to route outbound traffic through their respective zone's NAT Gateway. Set a route for 0.0.0.0/0 in the application VPC subnet route tables pointing to tgw-hub.

From AWS Account C, authorize the association of services.internal with vpc-app-hr and vpc-app-finance using the Route 53 API. Then, from Accounts A and B, accept the association requests using the AWS CLI or SDK to link the application VPCs to the Private Hosted Zone.

Deploy a single NAT Gateway in the ap-southeast-1a subnet of vpc-shared-services to minimize cost. In the private subnet route tables of vpc-shared-services across all Availability Zones, configure a route pointing all 0.0.0.0/0 traffic to this single NAT Gateway.

Associate the services.internal Private Hosted Zone with vpc-shared-services only, and enable DNS support on the Transit Gateway attachments to transitively resolve queries from vpc-app-hr and vpc-app-finance.

In the Transit Gateway route table associated with the application VPCs, configure a static route for 0.0.0.0/0 targeting the NAT Gateway resource identifiers located in the public subnets of vpc-shared-services.

Show answer & explanation

Answer: Deploy one NAT Gateway in each of two Availability Zones within the public subnets of vpc-shared-services. Configure the subnet route tables in the private subnets of vpc-shared-services to route outbound traffic through their respective zone's NAT Gateway. Set a route for 0.0.0.0/0 in the application VPC subnet route tables pointing to tgw-hub.; From AWS Account C, authorize the association of services.internal with vpc-app-hr and vpc-app-finance using the Route 53 API. Then, from Accounts A and B, accept the association requests using the AWS CLI or SDK to link the application VPCs to the Private Hosted Zone.

Answer

The correct configurations are to deploy one NAT Gateway in each of the two Availability Zones within the public subnets of the shared services VPC, routing traffic to them via the Transit Gateway, and to perform cross-account Private Hosted Zone association by authorizing the association from the owner account and accepting it from the application accounts.

The solution requires high availability and cross-account DNS resolution. Deploying a NAT Gateway per Availability Zone in the shared services VPC ensures zone redundancy, preventing single-AZ failures from causing outage cascades. Cross-account Private Hosted Zone association requires creating an authorization from the hosting account (Account C) and then creating the association from the consumer accounts (Accounts A and B). This resolves DNS queries natively and cost-effectively.

Step-by-Step Solution

Configure the cross-account Private Hosted Zone association.

Generate association authorizations from Account C for vpc-app-hr and vpc-app-finance, then associate the VPCs in Accounts A and B.

Allows resource DNS resolution of services.internal in the application VPCs without incurring endpoint charges.

Deploy zone-redundant NAT Gateways.

Two NAT Gateways are created in separate Availability Zones in the public subnets of the shared services VPC.

Ensures that internet egress remains functional even during a single Availability Zone outage.

Configure Transit Gateway and subnet routing tables.

Application VPC subnet route tables direct 0.0.0.0/0 to the Transit Gateway, which routes the traffic to the shared services VPC attachment, where local private subnet route tables forward the traffic to their respective zone's NAT Gateway.

Enforces centralized egress controls through the shared security boundaries.

Key Concept

Multi-account private DNS resolution and highly available centralized internet egress architecture using AWS Transit Gateway and zone-redundant NAT Gateways.

Question 1071Question →

An enterprise runs a multi-tier financial transaction system across two AWS accounts in an AWS Organization: Account A (Application) and Account B (Data).

In Account A, the application tier is deployed on Amazon EC2 instances in an Auto Scaling group behind an internal Application Load Balancer (ALB) across three Availability Zones in a primary VPC (VPC-App) in us-east-1. Outbound internet traffic to external payment processing endpoints is routed through a single NAT Gateway located in us-east-1a.
In Account B, database transactions are managed by an Amazon Aurora PostgreSQL Global Database. The primary cluster is in us-east-1 (VPC-Data), and a secondary read-only cluster is in us-east-2 (VPC-DR).
The application in VPC-App (Account A) queries the database in VPC-Data (Account B) using a private domain db.internal.corp. The Private Hosted Zone (PHZ) for db.internal.corp is created and hosted in Account B.

A recent Availability Zone outage in us-east-1a degraded the NAT Gateway, causing payment processing to fail. During the subsequent recovery attempt, operator confusion between managed and unplanned global database failovers delayed database promotion to us-east-2 by over 30 minutes. Additionally, recovery EC2 instances provisioned in us-east-2 failed to resolve the database's private domain db.internal.corp.

To prevent future outages, a Solutions Architect must design a disaster recovery (DR) and resiliency strategy that achieves a Recovery Time Objective (RTO) of 10 minutes and a Recovery Point Objective (RPO) of 1 minute. The secondary application tier in us-east-2 must remain dormant or at minimal capacity until a failover is declared.

Which set of actions should the Solutions Architect implement to satisfy these requirements?

Deploy a single NAT Gateway in VPC-App to minimize runtime costs, routing traffic from all private subnets to it. In Account B, share the db.internal.corp Private Hosted Zone with Account A using AWS Resource Access Manager (RAM). During a us-east-1 outage, execute a managed failover of the Aurora Global Database to us-east-2 to ensure zero data loss. Maintain a pilot light DR pattern in us-east-2, restoring the database from Daily Amazon S3 backups when a failover is required.

Deploy a NAT Gateway in each Availability Zone of VPC-App and update subnet routing tables accordingly. In Account B, authorize the association of the db.internal.corp Private Hosted Zone with VPC-App and the recovery VPC in us-east-2 using the AWS CLI or SDK; accept the associations in Account A. During a us-east-1 outage, perform an unplanned failover of the Aurora Global Database to promote the us-east-2 secondary cluster. Implement a warm standby DR pattern in us-east-2 with Auto Scaling groups running at minimal capacity, shifting traffic using Route 53 Application Recovery Controller routing controls.

Maintain the single NAT Gateway in us-east-1a. Associate the db.internal.corp Private Hosted Zone in Account B with the shared AWS Transit Gateway to enable automatic DNS resolution in Account A. During an outage, initiate an unplanned failover of the Aurora Global Database to us-east-2. Implement a warm standby in us-east-2, using Route 53 active-active failover with public Route 53 health checks configured to query the private IP addresses of the application EC2 instances directly.

Deploy a NAT Gateway in each Availability Zone of VPC-App. In Account B, share the db.internal.corp Private Hosted Zone with Account A using AWS Resource Access Manager (RAM). During a us-east-1 outage, perform a managed failover of the Aurora Global Database to us-east-2. Configure a pilot light DR pattern in us-east-2, keeping all EC2 instances stopped, and use Route 53 failover records linked to CloudWatch alarms in us-east-1 that monitor the primary Aurora database cluster's status.

Show answer & explanation

Answer: Deploy a NAT Gateway in each Availability Zone of VPC-App and update subnet routing tables accordingly. In Account B, authorize the association of the db.internal.corp Private Hosted Zone with VPC-App and the recovery VPC in us-east-2 using the AWS CLI or SDK; accept the associations in Account A. During a us-east-1 outage, perform an unplanned failover of the Aurora Global Database to promote the us-east-2 secondary cluster. Implement a warm standby DR pattern in us-east-2 with Auto Scaling groups running at minimal capacity, shifting traffic using Route 53 Application Recovery Controller routing controls.

Answer

Deploy a NAT Gateway in each Availability Zone of VPC-App, establish cross-account Private Hosted Zone associations using Route 53 VPC association authorizations, promote the secondary Aurora cluster via unplanned failover during an outage, and use a warm standby pattern in the recovery region managed by Route 53 Application Recovery Controller routing controls.

The correct option addresses all design flaws of the existing architecture: it establishes NAT Gateway redundancy by deploying a gateway in each Availability Zone of VPC-App; it correctly authorizes and accepts cross-account Private Hosted Zone associations so that the recovery environment in us-east-2 can resolve the database domain; it implements an unplanned failover of the Aurora Global Database to bypass the unreachable primary region; and it uses a warm standby pattern with Route 53 Application Recovery Controller routing controls to quickly and deterministically redirect traffic within the 10-minute RTO constraint.

Step-by-Step Solution

Ensure NAT Gateway redundancy by deploying a NAT Gateway in each Availability Zone of VPC-App and pointing each private subnet's route table to its local NAT Gateway.

Outbound egress traffic to external payment processors remains highly available and resilient to any single Availability Zone outage.

The original design had a single NAT Gateway in us-east-1a, representing a single point of failure that caused payment processing to fail when us-east-1a went offline.

Configure cross-account Private Hosted Zone (PHZ) association for db.internal.corp by calling create-vpc-association-authorization in Account B for VPC-App and VPC-DR (Account A), and then calling associate-vpc-with-hosted-zone in Account A.

Application EC2 instances in VPC-App (us-east-1) and VPC-DR (us-east-2) in Account A can successfully resolve the db.internal.corp domain name to the private database endpoints.

Route 53 Private Hosted Zones cannot be shared across accounts using AWS Resource Access Manager (RAM) or Transit Gateways. A direct cross-account VPC association is required.

Perform an unplanned failover of the Amazon Aurora PostgreSQL Global Database to promote the secondary read-only cluster in us-east-2 to primary.

The secondary cluster in us-east-2 is promoted to writeable primary status, enabling application writes in the recovery region.

A managed failover requires the primary cluster in us-east-1 to be healthy and reachable to synchronize state. During an active outage where the primary region is degraded, only an unplanned failover (failover-global-cluster) is possible to recover within the RTO.

Implement a warm standby recovery strategy in us-east-2 with Auto Scaling groups pre-configured at minimal scale, and use Route 53 Application Recovery Controller (ARC) routing controls to fail over traffic.

Traffic is shifted to us-east-2, and application capacity scales up quickly to handle the production load within the 10-minute RTO limit.

A pilot light pattern relying on database restores or stopped instances takes too long to launch and bootstrap, failing the 10-minute RTO. ARC routing controls provide deterministic, rapid failover during regional outages without relying on regional Route 53 health check resolvers in the degraded region.

Key Concept

Disaster Recovery pattern selection, cross-account Private Hosted Zone association, NAT Gateway multi-AZ redundancy, and Aurora Global Database unplanned failover mechanics.

Estimated Time:4m 0s

Question 1072Question →

An enterprise uses AWS CodePipeline in a centralized DevOps account ( $111111111111$ ) to build and deploy a microservices application to an Amazon ECS cluster running in a target production account ( $222222222222$ ). The pipeline stores its build artifacts in an Amazon S3 bucket in the DevOps account. The S3 bucket is encrypted.

During a deployment run, the pipeline fails at the Deploy stage with the following error:
`KMS.NotFoundException: The KMS key with ID arn:aws:kms:us-east-1:111111111111:key/... does not exist or is not authorized.`

A Solutions Architect needs to resolve the deployment failure while adhering to the principle of least privilege.

Which combination of configuration steps will resolve the deployment failure? (Select TWO.)

Select all that apply

Grant the IAM role used by CodeDeploy in the target account permissions for `kms:Decrypt` and `kms:GenerateDataKey` on the DevOps account's customer managed key (CMK). Update the KMS CMK policy in the DevOps account to allow the target account's deployment IAM role to perform `kms:Decrypt` and `kms:GenerateDataKey` actions.

Configure the Amazon S3 artifact bucket in the DevOps account to use a customer managed key (CMK) instead of the default AWS managed key (`aws/s3`). Update the S3 bucket policy in the DevOps account to allow the IAM role used by CodeDeploy in the target account to perform `s3:GetObject` and `s3:PutObject` actions.

Configure the Amazon S3 artifact bucket in the DevOps account to use the default AWS managed KMS key (`aws/s3`). Update the IAM policy of the target account's deployment role to allow cross-account usage of the `aws/s3` key in the DevOps account.

Create a Service Control Policy (SCP) at the Organization root that explicitly allows cross-account actions on the DevOps account's KMS key and S3 bucket, and attach the SCP to the Organizational Unit (OU) containing both accounts.

Manually update the ECS Task Definition in the target production account with the new container image URI and configure AWS Systems Manager State Manager to detect this drift and automatically synchronize the deployment metadata back to the DevOps account's S3 bucket.

Show answer & explanation

Answer: Grant the IAM role used by CodeDeploy in the target account permissions for `kms:Decrypt` and `kms:GenerateDataKey` on the DevOps account's customer managed key (CMK). Update the KMS CMK policy in the DevOps account to allow the target account's deployment IAM role to perform `kms:Decrypt` and `kms:GenerateDataKey` actions.; Configure the Amazon S3 artifact bucket in the DevOps account to use a customer managed key (CMK) instead of the default AWS managed key (`aws/s3`). Update the S3 bucket policy in the DevOps account to allow the IAM role used by CodeDeploy in the target account to perform `s3:GetObject` and `s3:PutObject` actions.

Answer

Configure the S3 artifact bucket to use a customer managed key (CMK) instead of the default AWS managed key, update the S3 bucket policy to allow access to the target deployment role, and update both the KMS CMK policy and the target IAM role to allow key decryption and data key generation.

To fix cross-account deployment errors in CodePipeline, the target deployment role must have permissions to decrypt artifacts stored in the DevOps account's S3 bucket. Because AWS-managed keys cannot be shared across accounts, the S3 bucket must be encrypted using a Customer Managed Key (CMK). Permissions must be enabled on both sides: the source account's KMS key policy and S3 bucket policy must trust the target account's deployment role, and the target account's deployment role policy must allow KMS decryption and S3 retrieval.

Step-by-Step Solution

Change the encryption of the S3 artifact bucket in the DevOps account to use a Customer Managed Key (CMK).

The bucket is encrypted with a key whose policy can be modified to allow cross-account access.

AWS-managed keys (like `aws/s3`) do not support policy modification and cannot be shared across accounts.

Modify the KMS CMK key policy in the DevOps account to grant the target deployment role permissions for `kms:Decrypt` and `kms:GenerateDataKey`.

Resource-based permissions are established on the key.

Cross-account access to KMS requires explicit delegation in the key policy.

Modify the S3 bucket policy in the DevOps account to grant the target deployment role permissions for `s3:GetObject`.

Resource-based permissions are established on the S3 bucket.

The target deployment role must be able to read deployment artifacts from the DevOps S3 bucket.

Attach an IAM policy to the target deployment role in the target account that allows `kms:Decrypt`, `kms:GenerateDataKey`, and `s3:GetObject` on the DevOps account resources.

Identity-based permissions are established.

Both identity-based and resource-based policies must allow cross-account access for the operations to succeed.

Key Concept

Cross-Account KMS and S3 permissions for CodePipeline deployments

Question 1073Question →

An autonomous vehicle telemetry company collects high-frequency sensor data from test vehicles. The data is uploaded to a central on-premises operations center and then replicated to AWS. The AWS environment consists of a primary VPC and $3$ spoke VPCs in the `us-west-2` Region, all connected via an AWS Transit Gateway. The on-premises operations center connects to AWS via a $10\text{ Gbps}$ AWS Direct Connect connection using a Private Virtual Interface (Private VIF) terminated at a Virtual Private Gateway (VGW) in the primary VPC. Telemetry files average $120\text{ MB}$ in size and are uploaded via HTTPS. During peak test hours, uploads experience high latency and packet retransmissions, and DNS queries for the internal ingestion API endpoints fail intermittently or take too long to resolve from the spoke VPCs. The solution must maximize throughput, minimize latency, ensure high availability, and avoid unnecessary inter-VPC network hops for DNS resolution. Which two actions should the solutions architect take to meet these requirements?

Select all that apply

Configure a Transit Virtual Interface (Transit VIF) on the Direct Connect connection, associate it with a Direct Connect Gateway connected to the Transit Gateway, and enable Jumbo Frames (MTU

9001

) end-to-end on the Direct Connect connection and Transit Gateway attachments.

Associate the Route 53 Private Hosted Zone hosting the telemetry endpoints directly with all spoke VPCs to enable local DNS resolution inside each VPC.

Configure a Direct Connect Gateway to route transitive traffic directly between the spoke VPCs, bypassing the Transit Gateway to reduce inter-VPC routing overhead.

Associate the Route 53 Private Hosted Zone only with the primary VPC, and route all spoke VPC DNS queries to the primary VPC's inbound resolver endpoint over Transit Gateway attachments.

Centralize all outbound public traffic by routing it through a single NAT Gateway deployed in

1

Availability Zone of the primary VPC to simplify route table management.

Deploy an Application Load Balancer in the primary VPC to forward ingestion traffic, relying on its default auto-scaling behavior to absorb sudden, massive spikes in telemetry uploads.

Show answer & explanation

Answer: Configure a Transit Virtual Interface (Transit VIF) on the Direct Connect connection, associate it with a Direct Connect Gateway connected to the Transit Gateway, and enable Jumbo Frames (MTU $9001$ ) end-to-end on the Direct Connect connection and Transit Gateway attachments.; Associate the Route 53 Private Hosted Zone hosting the telemetry endpoints directly with all spoke VPCs to enable local DNS resolution inside each VPC.

Answer

Configure a Transit Virtual Interface (Transit VIF) on the Direct Connect connection with Jumbo Frames (MTU

9001

) enabled end-to-end, and associate the Route 53 Private Hosted Zone directly with all spoke VPCs.

Configuring a Transit VIF and enabling Jumbo Frames (MTU

9001

) end-to-end reduces packet overhead and TCP fragmentation, maximizing throughput for large files over Direct Connect. Associating the Route 53 Private Hosted Zone directly with all spoke VPCs enables local DNS resolution via the local Route 53 Resolver, eliminating the latency and overhead of forwarding queries transitively across VPCs.

Step-by-Step Solution

Migrate the Direct Connect connection from a Private VIF to a Transit VIF connected to a Direct Connect Gateway.

Enables connectivity to a Transit Gateway, which supports multi-VPC routing and Jumbo Frames.

Transit VIFs and Transit Gateways support MTU up to

9001

(Jumbo Frames), which reduces packet overhead and TCP retransmissions for large file transfers.

Enable Jumbo Frames (MTU

9001

) end-to-end across the Direct Connect VIF, Transit Gateway, and VPC route tables.

Increases the maximum transmission unit size to

9001

bytes.

Replicating

120\text{ MB}

files over HTTPS is highly throughput-dependent. Increasing the MTU minimizes packet fragmentation and header overhead.

Associate the Route 53 Private Hosted Zone directly with all spoke VPCs.

Enables local DNS resolution inside each spoke VPC via the Route 53 Resolver.

Local DNS resolution avoids transitive DNS query latency and network hops through Transit Gateway to inbound endpoints.

Key Concept

Optimizing network performance for large file transfers involves maximizing MTU sizes (Jumbo Frames) along the network path and localizing DNS resolution to avoid unnecessary transit latency.

Question 1074Question →

A company operates a web-based geographic information system (GIS) on AWS. The application runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The instances query an Amazon RDS for PostgreSQL database configured with Multi-AZ for high availability.

During predictable daily peak hours, the application experiences significant performance degradation. CloudWatch metrics indicate that the RDS primary instance CPU utilization consistently exceeds 90%. Additionally, the ALB drops multiple connections due to a sudden, massive surge in user traffic at the exact start of peak hours, and the EC2 instances experience high write latency on their attached Amazon EBS gp3 volumes.

Which combination of actions should a solutions architect take to optimize the compute and storage performance of the system?

Create an Amazon RDS Read Replica and configure the application to route read-only queries to the read replica endpoint. Request AWS Support to pre-warm the Application Load Balancer before the peak hours start. Increase the provisioned IOPS and throughput of the existing EBS gp3 volumes.

Configure the application to route read-only queries to the standby instance of the RDS Multi-AZ deployment. Request AWS Support to pre-warm the Application Load Balancer before the peak hours start. Replace the EBS gp3 volumes with gp2 volumes and increase the volume size to obtain higher baseline performance.

Create an Amazon RDS Read Replica and configure the application to route read-only queries to the read replica endpoint. Rely on the Application Load Balancer's automatic scaling and decrease the scaling cooldown period in the EC2 Auto Scaling group to handle the traffic surge. Migrate the EBS gp3 volumes to Provisioned IOPS SSD (io2) volumes to reduce cost while increasing throughput.

Configure the application to route read-only queries to the standby instance of the RDS Multi-AZ deployment. Deploy Amazon ElastiCache for Memcached to cache database queries and enable multi-AZ replication to ensure high availability of the cache. Migrate the EBS gp3 volumes to Cold HDD (sc1) volumes to improve write latency.

Show answer & explanation

Answer: Create an Amazon RDS Read Replica and configure the application to route read-only queries to the read replica endpoint. Request AWS Support to pre-warm the Application Load Balancer before the peak hours start. Increase the provisioned IOPS and throughput of the existing EBS gp3 volumes.

Answer

Create an Amazon RDS Read Replica and route read-only queries to it, request AWS Support to pre-warm the Application Load Balancer, and increase the provisioned IOPS and throughput of the existing EBS gp3 volumes.

The correct option addresses all three performance bottlenecks accurately: an RDS Read Replica offloads read traffic to resolve the DB CPU utilization issue; ALB pre-warming prevents connection drops from sudden traffic surges; and increasing the provisioned IOPS and throughput of the gp3 volumes resolves the storage latency directly.

Step-by-Step Solution

Address the database CPU utilization bottleneck by offloading read operations.

Create an Amazon RDS Read Replica and update the application connection pooling or configuration to direct read-only queries to the read replica endpoint instead of the primary instance.

This reduces the CPU load on the primary DB instance, allowing it to handle write traffic and critical operations.

Address the connection drops at the start of peak hours caused by rapid traffic spikes.

Request AWS Support to pre-warm the Application Load Balancer.

ALBs automatically scale, but a sudden, massive surge can exceed the rate at which the ALB scales out. Pre-warming prepares the load balancer with the required capacity beforehand.

Address the write latency on the EC2 storage layer.

Modify the existing EBS gp3 volumes to increase their provisioned IOPS and throughput parameters.

EBS gp3 volumes support independent scaling of performance (IOPS and throughput) up to limits without needing to scale the volume size or migrate to expensive io2 storage.

Key Concept

Identifying and resolving performance bottlenecks at the database read tier, load balancing tier, and block storage tier by using RDS Read Replicas, ALB pre-warming, and independent EBS performance scaling.

Question 1075Question →

A financial company hosts an application that stores sensitive transaction reports in an Amazon S3 bucket. To comply with data protection regulations, the objects are encrypted using the default AWS-managed KMS key (aws/s3). The company now needs to grant read-only access to these S3 objects to an external auditing team operating in a separate AWS account. The external team is currently blocked when attempting to read the objects, despite having the correct S3 permissions. Which of the following is the most appropriate action to resolve this issue and securely allow cross-account access?

Create a customer managed KMS key, re-encrypt the S3 objects using this new key, and update its key policy to grant the external AWS account's role permission to use the key.

Modify the key policy of the default AWS-managed KMS key (aws/s3) to grant decrypt permissions to the IAM role used by the external auditing team.

Create a Service Control Policy (SCP) at the root level of the AWS Organization that allows the external account's role to access the default AWS-managed KMS key (aws/s3).

Add a statement to the S3 bucket policy in the source account that delegates kms:Decrypt permissions to the external account principal for the default AWS-managed KMS key (aws/s3).

Show answer & explanation

Answer: Create a customer managed KMS key, re-encrypt the S3 objects using this new key, and update its key policy to grant the external AWS account's role permission to use the key.

Answer

Create a customer managed KMS key, re-encrypt the S3 objects using this new key, and update its key policy to grant the external AWS account's role permission to use the key.

For cross-account access to encrypted S3 objects, the external role must have permissions on the S3 bucket and decrypt permissions on the KMS key. Because default AWS-managed KMS keys (aws/s3) cannot be shared across accounts and their key policies cannot be modified, a customer managed key must be used. Re-encrypting the objects with a customer managed KMS key and allowing the external account's IAM role in its key policy successfully solves the issue.

Step-by-Step Solution

Identify the KMS key encryption constraint.

Identify that the S3 objects are encrypted with a default AWS-managed KMS key (aws/s3), which cannot be modified or shared cross-account.

Determines why the external auditing team is blocked despite having correct S3 bucket permissions.

Create a customer managed KMS key.

A new customer managed key is created in the source account, which supports custom key policies.

Enables configuration of cross-account access via the key policy.

Modify the key policy and S3 permissions.

Grant decrypt permissions on the customer managed key to the external account's role and re-encrypt S3 objects.

Allows the external role to perform both s3:GetObject and kms:Decrypt operations required to access the files.

Key Concept

Cross-account AWS KMS access rules and limitations of default AWS-managed KMS keys.

Estimated Time:1m 0s

Question 1076Question →

A logistics company is designing a new cloud infrastructure on AWS across three VPCs: a Shared Services VPC (vpc-shared), a Production application VPC (vpc-prod), and a Development application VPC (vpc-dev). The company has an on-premises datacenter that must connect securely to these VPCs using an existing 10 Gbps AWS Direct Connect (DX) connection. Additionally, resources in the private subnets of vpc-prod and vpc-dev require outbound internet access to download software patches, but they must not be directly exposed to the internet. The design must minimize operational overhead, be resilient to Availability Zone (AZ) failures, and allow private DNS resolution for internal domain names across all environments, including the on-premises datacenter. Which TWO of the following networking configurations should the Solutions Architect implement to meet these requirements?

Select all that apply

Deploy a NAT Gateway in each utilized Availability Zone within the Shared Services VPC, and update the spoke VPC route tables to direct default traffic (0.0.0.0/0) to the Transit Gateway, which forwards it to the Shared Services VPC NAT Gateways.

Associate the Route 53 Private Hosted Zones with all three VPCs (vpc-shared, vpc-prod, and vpc-dev), and create Route 53 Resolver Inbound Endpoints in the Shared Services VPC to forward DNS requests originating from the on-premises datacenter.

Deploy a single NAT Gateway in one Availability Zone of the Shared Services VPC to centralize and process all outbound traffic from both spoke VPCs to minimize running costs.

Configure the AWS Direct Connect Gateway to perform transitive routing between the spoke VPCs and the Shared Services VPC, bypassing the need for an AWS Transit Gateway.

Associate the Route 53 Private Hosted Zones exclusively with the Shared Services VPC, and rely on Transit Gateway attachment routing to resolve DNS queries originating from the development and production VPCs.

Show answer & explanation

Answer: Deploy a NAT Gateway in each utilized Availability Zone within the Shared Services VPC, and update the spoke VPC route tables to direct default traffic (0.0.0.0/0) to the Transit Gateway, which forwards it to the Shared Services VPC NAT Gateways.; Associate the Route 53 Private Hosted Zones with all three VPCs (vpc-shared, vpc-prod, and vpc-dev), and create Route 53 Resolver Inbound Endpoints in the Shared Services VPC to forward DNS requests originating from the on-premises datacenter.

Answer

Deploy a NAT Gateway in each utilized Availability Zone within the Shared Services VPC, and update the spoke VPC route tables to direct default traffic to the Transit Gateway, which forwards it to the Shared Services VPC NAT Gateways. Additionally, associate the Route 53 Private Hosted Zones with all three VPCs (vpc-shared, vpc-prod, and vpc-dev), and create Route 53 Resolver Inbound Endpoints in the Shared Services VPC to forward DNS requests originating from the on-premises datacenter.

To achieve high availability and prevent single points of failure for outbound internet traffic, NAT Gateways must be deployed in each Availability Zone where resources reside. Centralizing egress through a Transit Gateway to these redundant NAT Gateways satisfies the security and HA requirements. For private DNS resolution, Route 53 Private Hosted Zones must be associated with every VPC requiring resolution, and Route 53 Resolver Inbound Endpoints are required to receive and resolve DNS queries coming from on-premises clients over the Direct Connect link.

Step-by-Step Solution

Address the high availability and resiliency requirements for egress internet traffic.

Deploy redundant NAT Gateways across multiple Availability Zones in the Shared Services VPC rather than a single NAT Gateway.

A single NAT Gateway represents a single point of failure in the event of an AZ outage.

Configure internal DNS resolution across the multi-account/multi-VPC architecture and on-premises.

Associate the Route 53 Private Hosted Zone (PHZ) with the Shared Services VPC, the Production VPC, and the Development VPC, and set up Route 53 Resolver Inbound Endpoints in the Shared Services VPC.

VPCs cannot resolve names in a PHZ unless the PHZ is explicitly associated with them. The Inbound Endpoints provide IP addresses in the VPC that on-premises DNS servers can target to resolve AWS-internal names.

Establish proper routing paths for hybrid connectivity.

Use Transit Gateway to manage routing between the spoke VPCs, Shared Services VPC, and the Direct Connect Gateway.

Direct Connect Gateway alone does not support transitive VPC-to-VPC or VPC-to-on-premises routing without a Transit Gateway.

Key Concept

Designing a resilient hybrid network architecture with centralized internet egress and cross-VPC/on-premises DNS resolution.

Question 1077Question →

An enterprise operates a transaction processing application in `us-east-1` within AWS Account A. The database tier uses an Amazon Aurora PostgreSQL cluster. To improve disaster recovery and satisfy regulatory compliance, the enterprise plans to deploy a warm standby recovery environment in `us-west-2` within AWS Account B. The target Recovery Point Objective (RPO) is $1$ minute, and the Recovery Time Objective (RTO) is $15$ minutes.

The application uses an internal Route 53 Private Hosted Zone named `internal.corp` in Account A for database endpoint resolution. Additionally, during a failover event, application servers in Account B must be able to securely connect to a public third-party credit verification service via the internet.

Which of the following combinations of actions should the Solutions Architect take to enhance reliability and meet the DR requirements? (Select TWO.)

Select all that apply

Configure an Amazon Aurora Global Database with the primary cluster in `us-east-1` (Account A) and a secondary cluster in `us-west-2` (Account B). In Account A, authorize the association of the Route 53 Private Hosted Zone `internal.corp` with the VPC in Account B. In Account B, associate the VPC with the hosted zone.

In Account B's VPC, deploy a NAT Gateway in each public subnet across multiple Availability Zones. Configure the route table of each private subnet to route outbound traffic (

0.0.0.0/0

) to the NAT Gateway in the corresponding Availability Zone.

Share the Aurora cluster in Account A with Account B using AWS Resource Access Manager (RAM) to create a cross-region Read Replica. In Account B, configure a Route 53 Resolver forwarding rule pointing to Account A's inbound resolver endpoint to resolve the `internal.corp` domain.

Deploy a single NAT Gateway in a public subnet in Account B's VPC, and update the route tables of all private subnets to point outbound traffic to it. Create Route 53 failover records pointing to the primary and secondary databases, omitting Route 53 health checks to speed up failover times.

Attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing Account B to grant access to Route 53 resources in Account A. Deploy a single NAT instance in Account B with source/destination checks enabled to route outbound internet traffic.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in `us-east-1` (Account A) and a secondary cluster in `us-west-2` (Account B). In Account A, authorize the association of the Route 53 Private Hosted Zone `internal.corp` with the VPC in Account B. In Account B, associate the VPC with the hosted zone.; In Account B's VPC, deploy a NAT Gateway in each public subnet across multiple Availability Zones. Configure the route table of each private subnet to route outbound traffic ( $0.0.0.0/0$ ) to the NAT Gateway in the corresponding Availability Zone.

Answer

Configure an Amazon Aurora Global Database with cross-account Route 53 Private Hosted Zone association, and deploy redundant NAT Gateways across multiple Availability Zones in the destination VPC.

The correct architecture uses Amazon Aurora Global Database to achieve the required sub-second replication latency, meeting the 1-minute RPO constraint. To ensure that database hostnames resolve correctly in Account B, the Route 53 Private Hosted Zone from Account A must be associated with the VPC in Account B using cross-account VPC association authorization. To prevent outbound communication failures to the payment gateway in the event of an Availability Zone outage, the NAT Gateways must be redundantly deployed in each public subnet, mapping to the respective Availability Zones.

Step-by-Step Solution

Address database replication requirements for the RPO threshold.

Implement Aurora Global Database to achieve sub-second cross-region replication lag, meeting the target RPO of under 1 minute.

Aurora Global Database is the standard managed solution for cross-region disaster recovery with near-zero replication lag.

Configure DNS resolution for database endpoints across accounts.

Authorize the VPC association from the owner account (Account A) and associate it inside the destination VPC account (Account B).

This allows resources in Account B to resolve DNS queries against the Private Hosted Zone hosted in Account A without using complex resolver forwarding rules.

Ensure outbound connectivity in the secondary region is highly available.

Deploy a NAT Gateway in each Availability Zone in Account B's VPC.

Using a single NAT Gateway introduces a single point of failure, meaning an outage in the hosting Availability Zone would break outbound API validation queries.

Key Concept

Disaster recovery preparation requires highly resilient database replication, cross-account DNS host mapping, and redundant network egress points.

Question 1078Question →

A smart grid utility metering company operates an IoT platform that ingests high-frequency energy consumption data from millions of smart meters. The ingestion microservices write data directly to a PostgreSQL database hosted on Amazon RDS. During peak intervals, the database experiences severe write contention and CPU utilization spikes to $95\%$ , causing delayed telemetry processing and dropped ingestion requests. A Solutions Architect must optimize the database tier to reduce ingestion latency, lower RDS connection overhead, and ensure that real-time analytics dashboards can read the aggregated telemetry with sub-millisecond response times. The architecture requires high availability, automatic failover, and the ability to reconstruct historical metrics from the cache if the database is temporarily offline. Which combination of architectural optimizations should the Solutions Architect implement to resolve the performance bottlenecks while meeting the requirements? (Select TWO.)

Select all that apply

Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ replication and append-only file (AOF) persistence enabled, caching the frequently accessed real-time telemetry metrics to offload read traffic.

Deploy Amazon RDS Proxy between the ingestion microservices and the RDS PostgreSQL instance to manage database connection pooling.

Deploy an Amazon ElastiCache for Memcached cluster with auto-discovery enabled to cache the real-time telemetry metrics, configuring replica nodes across multiple Availability Zones to ensure data persistence.

Configure an Amazon DynamoDB Accelerator (DAX) cluster in front of the RDS PostgreSQL database to transparently cache query results.

Configure PostgreSQL synchronous replication to a new Read Replica in another Availability Zone, and update the analytics dashboards to query the replica using the primary database endpoint.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ replication and append-only file (AOF) persistence enabled, caching the frequently accessed real-time telemetry metrics to offload read traffic.; Deploy Amazon RDS Proxy between the ingestion microservices and the RDS PostgreSQL instance to manage database connection pooling.

Answer

Deploying Amazon RDS Proxy to establish connection pooling and deploying an Amazon ElastiCache for Redis cluster with Multi-AZ replication and persistence enabled to cache the real-time telemetry metrics.

Deploying Amazon RDS Proxy resolves the database's CPU and write-path bottleneck by establishing a persistent connection pool, mitigating connection churn from the ingestion microservices. Concurrently, deploying Amazon ElastiCache for Redis with Multi-AZ replication and persistence (AOF) enabled allows the application to offload real-time analytical read queries to a high-performance in-memory cache, while ensuring data durability and automatic failover capability.

Step-by-Step Solution

Analyze the ingestion bottleneck

High connection churn from microservices to RDS PostgreSQL causes CPU exhaustion and write contention.

Creating and destroying database connections frequently is resource-intensive for PostgreSQL.

Address the connection overhead

Introduce Amazon RDS Proxy to pool and reuse database connections.

Connection pooling mitigates CPU spikes by maintaining a warm pool of established connections to the RDS instance.

Address the read latency and caching durability requirements

Select Amazon ElastiCache for Redis with Multi-AZ and AOF persistence enabled.

Redis is selected over Memcached because it supports data replication, high availability, and persistence features required to reconstruct metrics during DB downtime.

Key Concept

Mitigating RDS CPU and write bottlenecks using RDS Proxy for connection pooling, combined with ElastiCache Redis for durable, replicated caching.

Estimated Time:3m 0s

Question 1079Question →

An enterprise is designing a highly resilient network architecture in the eu-central-1 Region for a credit-scoring platform. The design includes two spoke VPCs, vpc-scoring-prod and vpc-analytics-prod, each containing workloads distributed across Availability Zones eu-central-1a and eu-central-1b. Additionally, a centralized egress VPC, vpc-egress-central, is deployed in the same region to inspect and NAT all outbound internet traffic. The platform has the following constraints: 1. All outbound internet traffic from the spoke VPCs must flow through the central egress VPC. 2. Outbound connectivity must be resilient to the outage of a single Availability Zone. 3. Workloads in both spoke VPCs must resolve internal DNS queries for scoring.internal, a Route 53 Private Hosted Zone (PHZ) hosted in a separate Shared Services AWS account. 4. The solution must minimize cost and operational complexity. Which of the following architectures satisfies these requirements?

Establish VPC Peering connections between the spoke VPCs and the central egress VPC. Deploy a NAT Gateway in both Availability Zones eu-central-1a and eu-central-1b within vpc-egress-central. Configure the route tables of the spoke VPCs to point

0.0.0.0/0

to the VPC Peering connection. In the Shared Services account, submit a Route 53 VPC association authorization for the spoke VPCs, and complete the association from the spoke accounts.

Interconnect the spoke VPCs and the central egress VPC using an AWS Transit Gateway. Deploy a single NAT Gateway in Availability Zone eu-central-1a within vpc-egress-central. Configure the spoke VPC route tables to route

0.0.0.0/0

traffic to the Transit Gateway, and configure the Transit Gateway route table to route

0.0.0.0/0

to the central egress VPC. In the Shared Services account, submit a Route 53 VPC association authorization for the spoke VPCs, and complete the association from the spoke accounts.

Interconnect the spoke VPCs and the central egress VPC using an AWS Transit Gateway. Deploy a NAT Gateway in both Availability Zones eu-central-1a and eu-central-1b within vpc-egress-central. Configure the spoke VPC route tables to route

0.0.0.0/0

traffic to the Transit Gateway, and configure the Transit Gateway route table to route

0.0.0.0/0

to the central egress VPC. In the Shared Services account, submit a Route 53 VPC association authorization for the spoke VPCs, and complete the association from the spoke accounts.

0.0.0.0/0

traffic to the Transit Gateway, and configure the Transit Gateway route table to route

0.0.0.0/0

to the central egress VPC. In the Shared Services account, deploy Route 53 Resolver inbound endpoints. In the spoke VPC accounts, deploy Route 53 Resolver outbound endpoints and configure forwarding rules for scoring.internal targeting the inbound endpoints.

Show answer & explanation

Answer: Interconnect the spoke VPCs and the central egress VPC using an AWS Transit Gateway. Deploy a NAT Gateway in both Availability Zones eu-central-1a and eu-central-1b within vpc-egress-central. Configure the spoke VPC route tables to route $0.0.0.0/0$ traffic to the Transit Gateway, and configure the Transit Gateway route table to route $0.0.0.0/0$ to the central egress VPC. In the Shared Services account, submit a Route 53 VPC association authorization for the spoke VPCs, and complete the association from the spoke accounts.

Answer

0.0.0.0/0

traffic to the Transit Gateway, and configure the Transit Gateway route table to route

0.0.0.0/0

to the central egress VPC. In the Shared Services account, submit a Route 53 VPC association authorization for the spoke VPCs, and complete the association from the spoke accounts.

The correct architecture uses AWS Transit Gateway to enable transitive routing from the spoke VPCs through the central egress VPC, meeting the routing requirement. It deploys a NAT Gateway in both Availability Zones to ensure high availability and prevent single-AZ failures from causing outages. Finally, it uses Route 53 VPC association authorization to share the private hosted zone across accounts, which introduces zero additional cost and maintains the lowest operational complexity.

Step-by-Step Solution

Use AWS Transit Gateway to interconnect the spoke VPCs and the central egress VPC.

Establishes a hub-and-spoke network topology that supports transitive routing for outbound internet traffic.

VPC Peering does not support transitive routing, so a transit hub like Transit Gateway is required to forward traffic from spoke VPCs to a central egress VPC.

Deploy a NAT Gateway in both Availability Zones eu-central-1a and eu-central-1b inside the egress VPC.

Provides high availability and redundancy for outbound internet traffic.

If an entire Availability Zone experiences an outage, workloads in the remaining zone can still access the internet through the local NAT Gateway in that zone.

Perform a cross-account Route 53 Private Hosted Zone association between the Shared Services account and the spoke VPCs.

Enables resolution of the scoring.internal domain in the spoke VPCs without adding resolver endpoints.

Using cross-account association is the native and cost-free method to share a PHZ between VPCs in different accounts, minimizing both cost and operational overhead.

Key Concept

Centralized egress routing using AWS Transit Gateway combined with cross-account Route 53 Private Hosted Zone association.

Estimated Time:3m 0s

Question 1080Question →

An enterprise operates a public-facing web application deployed across two AWS Regions: us-east-1 (primary) and us-west-2 (standby) for disaster recovery. The architecture consists of an Application Load Balancer (ALB) and an Auto Scaling group of EC2 instances in each region. The company uses Amazon Route 53 with failover routing policies. The primary alias record has 'Evaluate Target Health' set to 'No' and is associated with a Route 53 HTTP health check that directly queries the ALB DNS name. During a recent database outage in the primary region, the web servers behind the primary ALB began returning HTTP 500 errors to users, but DNS failover to the standby region did not occur. Which action should the solutions architect take to ensure reliable failover to the standby region during future application or database outages?

Create a Route 53 Private Hosted Zone for the application domain, associate it with the VPCs in both regions, and use simple routing policies to map the domain to interface VPC endpoints for the Application Load Balancers.

Modify the disaster recovery strategy to a Pilot Light pattern, terminate the standby EC2 instances, and replace the Route 53 failover records with latency-based routing records that lack health checks.

Change the Route 53 primary alias record configuration to set 'Evaluate Target Health' to 'Yes' and configure the ALB target group health check to query a specific path that validates database connectivity.

Deploy a single NAT Gateway in the primary region's public subnets to consolidate all outbound application server traffic and configure the ALB target group health checks to route through this NAT Gateway.

Show answer & explanation

Answer: Change the Route 53 primary alias record configuration to set 'Evaluate Target Health' to 'Yes' and configure the ALB target group health check to query a specific path that validates database connectivity.

Answer

The correct answer is the option that proposes changing the Route 53 primary alias record configuration to set 'Evaluate Target Health' to 'Yes' and configuring the ALB target group health check to query a specific path that validates database connectivity.

Setting 'Evaluate Target Health' to 'Yes' on the primary Route 53 alias record forces Route 53 to determine health based on the registered targets of the ALB rather than the availability of the ALB endpoint itself. Since the application servers were returning 500 errors during a database outage, updating the target group's health checks to test a path verifying database connectivity ensures the instances are marked unhealthy, triggering Route 53 to fail over to the standby region.

Step-by-Step Solution

Identify why Route 53 did not fail over during the database outage.

The primary alias record has 'Evaluate Target Health' set to 'No', and the health check only monitors the ALB endpoint itself, which remains responsive even if the backend instances or databases are failing.

Understanding the root cause is necessary to configure correct health check inheritance.

Configure Route 53 to inherit the health status of the ALB's backend targets.

Enable 'Evaluate Target Health' on the Route 53 primary alias record.

This instructs Route 53 to evaluate the health of the targets registered with the ALB's target groups, rather than just the load balancer itself.

Align the ALB target group health check with application dependency health.

Configure the target group health check to query a path that verifies active database connectivity.

This ensures that if the database fails, the target group marks the instances as unhealthy, which bubble up to Route 53 to trigger failover.

Key Concept

Disaster recovery failover routing with health check propagation and target evaluation

PreviousPage 54 / 99Next

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