All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

An enterprise is designing a highly resilient and scalable hybrid network architecture to connect its on-premises data centers in New York and London with AWS environments in the `us-east-1` and `eu-west-2` Regions. The design includes a central AWS Transit Gateway in `us-east-1` (`tgw-us-east-1`) and another in `eu-west-2` (`tgw-eu-west-2`) connected via a Transit Gateway peering attachment. A central Shared Services VPC is deployed in `us-east-1` and hosts Route 53 Private Hosted Zones (PHZs). Multiple spoke VPCs are deployed in both regions, each with private subnets distributed across $3$ Availability Zones. The on-premises locations are connected to a global Direct Connect Gateway (`dxgw-global`) via $10\text{ Gbps}$ AWS Direct Connect connections, and backup Site-to-Site VPN connections are established to each regional Transit Gateway. Spoke VPC workloads require low-latency, highly available outbound internet access, secure cross-premises DNS resolution, and resilient hybrid failover. Which two actions must the solutions architect take to satisfy these requirements? (Select two.)

Select all that apply

In each spoke VPC, deploy a single NAT Gateway in a public subnet within one Availability Zone, and configure the default route (

0.0.0.0/0

) in the route tables of all private subnets to point to this NAT Gateway to optimize idle hourly charges.

In each spoke VPC, deploy a NAT Gateway in a public subnet within each of the

3

Availability Zones, and configure the default route (

0.0.0.0/0

) in the route table of each private subnet to point to the NAT Gateway in its corresponding Availability Zone.

Associate the Route 53 Private Hosted Zones in the Shared Services VPC with all spoke VPCs in both Regions. Configure Route 53 Resolver Inbound Endpoints in the Shared Services VPC to receive DNS queries from on-premises DNS servers, and Outbound Endpoints with forwarding rules to route queries for on-premises domains.

Configure Route 53 Resolver conditional forwarding rules in each spoke VPC to forward DNS queries for the Private Hosted Zones to the Shared Services VPC's Route 53 Resolver Inbound Endpoint IP addresses, avoiding direct cross-account hosted zone associations.

Configure the global Direct Connect Gateway (`dxgw-global`) to act as the transit routing hub between `tgw-us-east-1` and `tgw-eu-west-2` by enabling transit routing on the gateway, thereby routing inter-VPC traffic across the Direct Connect backbone.

Show answer & explanation

Answer: In each spoke VPC, deploy a NAT Gateway in a public subnet within each of the $3$ Availability Zones, and configure the default route ( $0.0.0.0/0$ ) in the route table of each private subnet to point to the NAT Gateway in its corresponding Availability Zone.; Associate the Route 53 Private Hosted Zones in the Shared Services VPC with all spoke VPCs in both Regions. Configure Route 53 Resolver Inbound Endpoints in the Shared Services VPC to receive DNS queries from on-premises DNS servers, and Outbound Endpoints with forwarding rules to route queries for on-premises domains.

Answer

The correct architecture requires deploying a NAT Gateway in each of the three Availability Zones for each spoke VPC to ensure multi-AZ resilience and avoid cross-AZ charges, and associating the Route 53 Private Hosted Zones with all spoke VPCs in both regions while utilizing Route 53 Resolver Inbound and Outbound Endpoints in the Shared Services VPC for hybrid DNS resolution.

Deploying a local NAT Gateway in each of the three Availability Zones ensures high availability and eliminates cross-AZ charges. Associating the Route 53 Private Hosted Zones in the Shared Services VPC with all spoke VPCs across both regions enables local DNS resolution of private records, while Route 53 Resolver Inbound and Outbound Endpoints in the Shared Services VPC allow query routing between AWS and on-premises DNS servers.

Step-by-Step Solution

Evaluate NAT Gateway architecture for high availability and cost optimization.

Identify that deploying a single NAT Gateway across three Availability Zones introduces a single point of failure and incurs cross-AZ data transfer costs. A dedicated NAT Gateway per Availability Zone ensures zone isolation and eliminates cross-AZ charges for internet-bound traffic.

This guarantees that an AZ outage does not impact outbound connectivity for the entire VPC and minimizes data transfer charges.

Design the DNS resolution architecture for the Route 53 Private Hosted Zones and on-premises environments.

Determine that Private Hosted Zones (PHZs) must be explicitly associated with each VPC that needs to resolve them, even across accounts and regions. Set up Route 53 Resolver Inbound Endpoints to handle queries from on-premises to AWS, and Outbound Endpoints with forwarding rules to handle queries from AWS to on-premises.

This establishes a secure, standard pattern for hybrid bi-directional DNS resolution and ensures spoke VPCs can resolve the central PHZs directly.

Analyze transitive routing limitations of Direct Connect Gateway.

Confirm that Direct Connect Gateway cannot route traffic between attached Transit Gateways. Traffic between the regional Transit Gateways must go over the peered Transit Gateway connection rather than the Direct Connect backbone.

Understanding AWS transitive routing limits ensures the architecture relies on TGW peering for inter-region VPC communication.

Key Concept

High availability network design using regional multi-AZ NAT Gateways, cross-VPC Route 53 Private Hosted Zone associations, and hybrid bi-directional Route 53 Resolver Endpoints.

Estimated Time:3m 0s

Question 962Question →

An e-commerce company operates a high-traffic catalog search application. The application's backend database runs on an Amazon RDS for PostgreSQL DB instance configured in a Multi-AZ deployment with 3,000 Provisioned IOPS (SSD) storage. During peak shopping events, read latency on the database increases significantly, and CPU utilization on the DB instance exceeds $90\%$ , leading to slower search response times. The write volume remains low and stable. Which action should a solutions architect take to resolve the database performance bottleneck with minimal latency?

Deploy Amazon RDS Read Replicas in the active Availability Zones, and update the application configuration to route all read-only search queries to the read replica endpoints.

Configure the application to route read-only search queries to the endpoint of the existing Multi-AZ standby DB instance to balance the query load.

Request AWS Support to pre-warm the database's front-end Application Load Balancer to handle the sudden increase in connection requests during peak events.

Decrease the scale-out cooldown period on the database's Auto Scaling group to launch additional DB instances faster when CPU utilization exceeds

90\%

Show answer & explanation

Answer: Deploy Amazon RDS Read Replicas in the active Availability Zones, and update the application configuration to route all read-only search queries to the read replica endpoints.

Answer

Deploy Amazon RDS Read Replicas in the active Availability Zones, and update the application configuration to route all read-only search queries to the read replica endpoints.

Deploying Amazon RDS Read Replicas is the correct action because it directly offloads read-heavy queries from the primary DB instance. This reduces both the CPU load and Provisioned IOPS consumption on the primary database, resolving the catalog search latency bottleneck. Read replicas are designed exactly for scaling read-heavy workloads horizontally.

Step-by-Step Solution

Analyze the metrics and workload patterns.

Identify that the database has high CPU (

>90\%

) and high read latency during peak times, while write traffic remains low and stable.

This confirms that the bottleneck is read-heavy compute and storage operations, making the workload a prime candidate for read scaling.

Evaluate the current architecture capabilities.

The current Multi-AZ standby instance is passive and cannot serve read traffic.

Recognizing that Multi-AZ is for durability and failover, not read scaling, prevents incorrect routing configurations to the standby.

Select the correct horizontal scaling mechanism.

Deploy one or more RDS Read Replicas and point the application's search queries to the replica endpoints.

Read replicas run active database engines that replicate data asynchronously, allowing them to offload read operations from the primary instance, thus reducing CPU and storage utilization on the primary.

Key Concept

Scaling read performance in Amazon RDS using Read Replicas vs Multi-AZ deployments

Question 963Question →

A gaming company hosts its multiplayer matchmaking engine on Amazon EC2 instances in a shared services VPC in the $us-east-1$ Region. Multiple client-facing game VPCs in separate AWS accounts in the same Region need to establish low-latency, high-throughput connections to the matchmaking engine, which is accessible via an internal Network Load Balancer (NLB) with a private DNS name registered in an Amazon Route 53 Private Hosted Zone (PHZ). The company currently connects the game VPCs to the shared services VPC using AWS Transit Gateway. During peak gaming hours, players experience high latency and packet delivery delays, and game servers in the client VPCs intermittently fail to resolve the matchmaking engine's DNS name. The solutions architect must optimize the network to achieve the lowest possible latency and maximum throughput for game traffic, while ensuring reliable DNS resolution and minimizing data transfer costs. Which network optimization strategy should the solutions architect implement?

Establish direct VPC Peering connections between each client-facing game VPC and the shared services VPC, and authorize and accept the Route 53 Private Hosted Zone association for the game VPCs across the accounts.

Replace Transit Gateway with direct VPC Peering connections between the client VPCs and the shared services VPC, and configure a public Route 53 Hosted Zone for the matchmaking engine to allow client VPCs to resolve the name over the public internet.

Configure AWS Direct Connect Gateway to establish transitive routing directly between the game VPCs and the shared services VPC, and configure Route 53 Resolver outbound endpoints to forward queries.

Replace the internal NLB with an Application Load Balancer (ALB), request AWS Support to pre-warm the ALB to handle peak traffic bursts, and associate the Private Hosted Zone with the Transit Gateway route table.

Show answer & explanation

Answer: Establish direct VPC Peering connections between each client-facing game VPC and the shared services VPC, and authorize and accept the Route 53 Private Hosted Zone association for the game VPCs across the accounts.

Answer

Establishing VPC Peering connections between the client-facing game VPCs and the shared services VPC eliminates the processing overhead and latency hop introduced by AWS Transit Gateway, providing sub-millisecond latency. Furthermore, authorizing and accepting the Route 53 Private Hosted Zone association allows game servers in the client VPCs to natively and securely resolve the private DNS name of the internal matchmaking load balancer.

Step-by-Step Solution

Analyze latency requirements and network path options between VPCs in the same Region.

Determine that AWS Transit Gateway introduces an additional hop adding

1\text{ ms}

2\text{ ms}

of latency and data processing costs, whereas VPC Peering provides direct, sub-millisecond routing with no data processing fees.

VPC Peering is the most optimal choice for high-throughput, latency-sensitive intra-region VPC-to-VPC traffic.

Resolve private DNS resolution issues across different AWS accounts in the same Region.

Identify that the Route 53 Private Hosted Zone must be associated with the client VPCs by authorizing the association from the shared services account and accepting it in each client account.

This allows the client VPCs to natively resolve the private DNS record of the matchmaking load balancer without exposing it to the public internet.

Compare alternative solutions against the constraints of cost, performance, and complexity.

Eliminate Direct Connect Gateway (which does not support transitive routing), NAT Gateways (which add latency and costs), and public DNS zones (which compromise security).

Ensures all non-functional requirements are met while selecting the correct architecture.

Key Concept

VPC Peering vs Transit Gateway latency and cross-account Route 53 Private Hosted Zone association

Estimated Time:3m 0s

Question 964Question →

A healthcare company runs a medical image processing application. The application's backend database runs on a single Amazon RDS for PostgreSQL DB instance in a Multi-AZ deployment. The compute layer consists of Amazon EC2 instances in an Auto Scaling group that processes tasks from an Amazon SQS queue. During peak periods, the application experiences performance degradation. A Solutions Architect identifies two main bottlenecks:

1. The database CPU utilization reaches $95\%$ due to a high volume of read-only queries for historical report retrieval.
2. The Auto Scaling group launches new EC2 instances to handle the SQS queue surge, but these instances take more than $8$ minutes to bootstrap because they download heavy software packages at startup. This delay causes the Auto Scaling group to launch more instances than required before the existing ones can begin processing tasks.

Which combination of actions will resolve these performance bottlenecks? (Select TWO.)

Select all that apply

Create an Amazon RDS PostgreSQL Read Replica and update the application configuration to route read-only queries to the replica endpoint.

Create a custom Amazon Machine Image (AMI) with all application dependencies pre-packaged, and update the Auto Scaling group's launch template to use this AMI.

Configure the application to distribute read-only queries between the primary DB instance and the standby DB instance in the Multi-AZ deployment.

Submit an AWS Support request to pre-warm the Application Load Balancer (ALB) to handle the increased traffic volume and prevent dropped connections during peak periods.

Decrease the Auto Scaling group cooldown period to a value shorter than the EC2 bootstrap time to force the group to launch new instances faster.

Show answer & explanation

Answer: Create an Amazon RDS PostgreSQL Read Replica and update the application configuration to route read-only queries to the replica endpoint.; Create a custom Amazon Machine Image (AMI) with all application dependencies pre-packaged, and update the Auto Scaling group's launch template to use this AMI.

Answer

Create an Amazon RDS PostgreSQL Read Replica to handle read-only queries, and build a custom Amazon Machine Image (AMI) containing pre-packaged dependencies to speed up the Auto Scaling group's EC2 instance boot time.

To optimize the compute and storage performance of this queue-based medical application, read-heavy workloads must be offloaded from the primary database and EC2 instance bootstrap times must be reduced. Creating an Amazon RDS PostgreSQL Read Replica allows the read-only queries to be redirected to a dedicated read-only endpoint, relieving CPU pressure on the primary instance. Building a custom Amazon Machine Image (AMI) with all application software and packages pre-installed eliminates the startup delay caused by runtime package downloads, enabling new instances to scale and process SQS messages immediately without triggering over-provisioning.

Step-by-Step Solution

Identify the database read bottleneck and determine the capability of RDS Multi-AZ deployments.

Establish that the standby instance cannot serve reads, meaning an Amazon RDS Read Replica must be created to offload queries.

To reduce CPU utilization on the primary database, read queries must be redirected to a dedicated, read-capable replica endpoint.

Analyze the EC2 scaling bottleneck caused by slow bootstrapping (8+ minutes).

Build a custom AMI with all software dependencies pre-installed.

Eliminating dependency downloads during instance launch speeds up the boot process so that instances can quickly absorb SQS queue tasks and satisfy scale-out signals.

Key Concept

Scaling read capacity with database replicas and accelerating EC2 scale-out times via custom AMIs to optimize compute and storage performance.

Question 965Question →

An enterprise runs a critical banking application on Amazon EC2 instances across multiple AWS accounts within an organization in AWS Organizations. The application outputs transactional logs to `/var/log/app/transaction.log`, which is rotated hourly to `/var/log/app/transaction.log.YYYY-MM-DD-HH` and compressed. The security team requires centralizing these logs into a single Amazon S3 bucket in a dedicated logging account. A Solutions Architect deployed the unified Amazon CloudWatch agent on the EC2 instances to stream these logs to Amazon CloudWatch Logs, but notices that logs are regularly lost immediately after the hourly rotation occurs. Which of the following solutions resolves this issue and achieves centralized collection securely?

Configure the CloudWatch agent configuration file log path to use a wildcard pattern `/var/log/app/transaction.log*` to match rotated files. Create an Amazon Kinesis Data Firehose delivery stream in each application account to send logs to the centralized S3 bucket, and update the S3 bucket policy in the logging account to permit `firehose.amazonaws.com` with the organization ID condition.

Configure the CloudWatch agent configuration file log path specifically to `/var/log/app/transaction.log`. Create an Amazon Kinesis Data Firehose delivery stream in each application account to send logs to the centralized S3 bucket, and update the S3 bucket policy in the logging account to permit `firehose.amazonaws.com` with the organization ID condition.

Configure the CloudWatch agent configuration file log path to use a wildcard pattern `/var/log/app/transaction.log*` to match rotated files. Create an Amazon Kinesis Data Firehose delivery stream in each application account to send logs to the centralized S3 bucket, and update the S3 bucket policy in the logging account to allow universal write access using a wildcard principal.

Configure the CloudWatch agent configuration file log path specifically to `/var/log/app/transaction.log`. Create a cross-account IAM role in each application account that grants the CloudWatch agent direct permissions to write to the centralized S3 bucket in the logging account.

Show answer & explanation

Answer: Configure the CloudWatch agent configuration file log path to use a wildcard pattern `/var/log/app/transaction.log*` to match rotated files. Create an Amazon Kinesis Data Firehose delivery stream in each application account to send logs to the centralized S3 bucket, and update the S3 bucket policy in the logging account to permit `firehose.amazonaws.com` with the organization ID condition.

Answer

Configure the CloudWatch agent configuration file log path to use a wildcard pattern to match rotated files, use Kinesis Data Firehose to stream to the centralized S3 bucket, and restrict the S3 bucket policy to the organization ID.

The correct option addresses the agent limitation by replacing the static log path with a wildcard pattern, allowing the agent to continuously monitor rotated files. It then leverages Kinesis Data Firehose to securely stream logs across accounts into a centralized S3 bucket, utilizing the Organization ID condition in the bucket policy to restrict access to trusted internal accounts.

Step-by-Step Solution

Address the log rotation delivery issue in the agent configuration.

Change the log path in the agent configuration JSON to a wildcard pattern such as `/var/log/app/transaction.log*`.

This allows the CloudWatch agent to automatically discover and publish logs from rotated file names as they are created.

Design the cross-account log ingestion mechanism.

Stream the CloudWatch logs to Amazon Kinesis Data Firehose in each account, directed to the centralized S3 bucket.

Kinesis Data Firehose buffers and aggregates data efficiently before writing it to S3, facilitating central ingestion.

Configure the security boundaries for the central S3 bucket.

Add a bucket policy to the centralized S3 bucket that permits access from the Firehose service principal, restricted by the `aws:PrincipalOrgID` condition.

This ensures only accounts within the organization can deliver logs to the bucket, maintaining strict isolation.

Key Concept

Configuring the CloudWatch agent log path with wildcards to handle log rotation, combined with secure cross-account centralization via S3 bucket policies constrained by Organization ID.

Question 966Question →

An administrator is setting up a two-tier application in a new VPC across two Availability Zones (AZ-A and AZ-B). The application servers reside in private subnets and must access the internet to download software updates. Which of the following network configuration steps should the solutions architect perform to ensure highly available and resilient outbound internet access for the private subnets? (Select TWO.)

Select all that apply

Deploy a NAT Gateway in the public subnet of Availability Zone A and another NAT Gateway in the public subnet of Availability Zone B.

Configure the route table for the private subnet in Availability Zone A to route traffic destined for

0.0.0.0/0

to the NAT Gateway in Availability Zone A, and do the same for Availability Zone B using its respective NAT Gateway.

Deploy a single NAT Gateway in the public subnet of Availability Zone A, and configure the route tables of private subnets in both Availability Zones to target this NAT Gateway.

Create an AWS Transit Gateway, attach it to the VPC, and add a route in the private subnet route tables pointing

0.0.0.0/0

to the Transit Gateway to handle direct internet routing.

Associate a Route 53 Private Hosted Zone with the Internet Gateway to enable the private subnets to resolve external internet domains directly.

Show answer & explanation

Answer: Deploy a NAT Gateway in the public subnet of Availability Zone A and another NAT Gateway in the public subnet of Availability Zone B.; Configure the route table for the private subnet in Availability Zone A to route traffic destined for $0.0.0.0/0$ to the NAT Gateway in Availability Zone A, and do the same for Availability Zone B using its respective NAT Gateway.

Answer

To ensure highly available outbound internet access, deploy a NAT Gateway in the public subnet of each Availability Zone, and configure the private subnet route tables to direct internet-bound traffic to their local NAT Gateway.

Deploying a NAT Gateway in each Availability Zone and configuring local routing ensures that an outage in one zone does not impact the other zone's ability to reach the internet. This setup removes single points of failure and maintains high availability for outbound traffic.

Step-by-Step Solution

Determine the requirement for high availability across multiple Availability Zones.

Identify that a single NAT Gateway represents a single point of failure if its Availability Zone experiences an outage.

To design a resilient system, components should be distributed across multiple Availability Zones.

Configure routing for each private subnet to keep traffic local to its Availability Zone.

Define route table entries that direct outbound traffic (

0.0.0.0/0

) to the NAT Gateway within the same Availability Zone.

This avoids cross-AZ traffic charges and prevents one AZ's failure from impacting the other's internet access.

Key Concept

High availability in AWS networking requires deploying redundant gateways (like NAT Gateways) across multiple Availability Zones and configuring route tables to avoid cross-AZ dependencies for external access.

Question 967Question →

An application is hosted in a single AWS Region using Amazon EC2 instances in an Auto Scaling group and an Amazon RDS for PostgreSQL DB instance. The company wants to implement a cost-effective disaster recovery (DR) solution in a secondary AWS Region. The DR solution must support a Recovery Point Objective (RPO) of less than 30 minutes and a Recovery Time Objective (RTO) of less than 2 hours. Which TWO of the following actions should a solutions architect take to meet these requirements?

Select all that apply

Configure an Amazon RDS cross-Region read replica of the primary DB instance in the secondary Region, and promote it during failover.

Create Route 53 failover routing records for the application endpoint, and associate a Route 53 health check with the primary record.

Configure a daily snapshot backup strategy for the RDS DB instance, copy the snapshots to the secondary Region hourly, and restore the DB instance during failover.

Configure Route 53 failover routing records for the primary and secondary regions, but omit the health check to prevent false failover events.

Create a Route 53 Private Hosted Zone in the primary Region's VPC, and do not associate it with the secondary Region's VPC to maintain network isolation.

Show answer & explanation

Answer: Configure an Amazon RDS cross-Region read replica of the primary DB instance in the secondary Region, and promote it during failover.; Create Route 53 failover routing records for the application endpoint, and associate a Route 53 health check with the primary record.

Answer

To meet the RPO and RTO requirements, configure an Amazon RDS cross-Region read replica in the secondary Region to allow promotion within minutes, and set up Route 53 failover routing records with a health check to automate DNS failover.

The correct options are configuring an Amazon RDS cross-Region read replica and using Route 53 failover routing records with a health check. A cross-Region read replica replicates data asynchronously, meeting the 30-minute RPO, and can be promoted quickly to meet the 2-hour RTO. Associating a health check with the Route 53 failover record ensures automatic redirection of traffic to the secondary Region during a primary Region failure.

Step-by-Step Solution

Address database replication requirements by deploying an Amazon RDS cross-Region read replica in the recovery Region.

Database updates are continuously replicated asynchronously, providing a Recovery Point Objective (RPO) of seconds/minutes, well under the 30-minute requirement.

Asynchronous replication minimizes data loss during an outage and enables quick promotion to primary.

Configure Route 53 failover routing policy.

Traffic is automatically directed to the secondary Region if Route 53 health checks detect the primary Region is unavailable.

This automates the DNS failover process to achieve a low Recovery Time Objective (RTO) under 2 hours.

Key Concept

Disaster recovery strategy selection and automated DNS failover implementation using RDS cross-Region replication and Route 53 active-passive failover.

Question 968Question →

A financial technology company operates a web application that stores active user session tokens and transaction history metadata in a single-instance Amazon RDS for MySQL database. During peak trading hours, read-heavy traffic to the database spikes, causing CPU utilization to reach 95% and leading to transaction delays. The session tokens must be highly available, replicated across Availability Zones, and persisted to prevent users from being logged out in the event of an outage. The Solutions Architect needs to improve database efficiency and reduce query latency. Which combination of actions should the Solutions Architect take to resolve the performance issues? (Select TWO.)

Select all that apply

Deploy Amazon ElastiCache for Redis with replication enabled to store session tokens.

Create Amazon RDS Read Replicas to offload read queries for transaction history metadata.

Deploy Amazon ElastiCache for Memcached to store session tokens and enable multi-AZ replication.

Enable Multi-AZ on the RDS instance and configure the application to route read queries to the standby DB instance.

Purchase an EC2 Instance Savings Plan to optimize database costs while scaling operations.

Show answer & explanation

Answer: Deploy Amazon ElastiCache for Redis with replication enabled to store session tokens.; Create Amazon RDS Read Replicas to offload read queries for transaction history metadata.

Answer

Deploy Amazon ElastiCache for Redis with replication enabled to store session tokens, and create Amazon RDS Read Replicas to offload read queries for transaction history metadata.

The correct solution involves deploying ElastiCache for Redis with replication to handle persistent, highly available session data, and implementing RDS Read Replicas to handle the read-heavy queries for transaction history, directly mitigating the CPU bottleneck on the primary database.

Step-by-Step Solution

Analyze database workload constraints and performance bottlenecks.

Identify that session tokens require persistence and AZ replication, while transaction metadata reads are saturating CPU capacity.

This determines which data is suitable for in-memory caching and which data requires database read replicas.

Select the appropriate caching engine for persistent, high-availability session states.

Select Amazon ElastiCache for Redis over Memcached.

Only ElastiCache for Redis supports the required persistence and multi-AZ replication features.

Implement read scaling for the relational database layer.

Deploy Amazon RDS Read Replicas and route read-heavy transaction metadata queries to them.

This offloads read operations from the primary instance, bringing down primary CPU utilization.

Key Concept

Improving database performance and efficiency involves offloading read operations via Read Replicas and shifting transient state storage to highly available in-memory caching solutions.

Question 969Question →

A major media company operates a digital ticket-booking application. The application's web tier runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The database tier runs on an Amazon RDS for PostgreSQL DB instance configured in a Multi-AZ deployment. The company is preparing for a flash-sale event where traffic is expected to increase by $200 \times$ within $2$ minutes. During a previous similar event, users experienced connection timeouts and HTTP 503 Service Unavailable errors. Monitoring showed that:

1. The ALB dropped requests during the first $5$ minutes of the event.
2. The EC2 Auto Scaling group took over $10$ minutes to provision and bootstrap new instances due to a complex user data script that downloads dependencies and updates application assets from Amazon S3.
3. The database CPU utilization reached $100\%$ due to a high volume of read-only queries for event details.

Which set of actions should a Solutions Architect recommend to optimize the performance of the compute and storage tiers for the upcoming event?

Submit a request to AWS Support to pre-warm the Application Load Balancer prior to the event. Configure the EC2 Auto Scaling group to use a custom AMI with all dependencies pre-installed and maintain a warm pool of pre-warmed instances. Deploy an Amazon RDS for PostgreSQL read replica to offload the read-only query traffic from the primary DB instance.

Submit a request to AWS Support to pre-warm the Application Load Balancer. Configure the EC2 Auto Scaling group to use a custom AMI with all dependencies pre-installed and maintain a warm pool of pre-warmed instances. Configure the application to route the read-only queries to the standby DB instance in the secondary Availability Zone of the RDS Multi-AZ deployment.

Rely on the Application Load Balancer's automatic scaling to dynamically scale out the web tier. Configure the EC2 Auto Scaling group to use a custom AMI with all dependencies pre-installed and maintain a warm pool of pre-warmed instances. Deploy an Amazon RDS for PostgreSQL read replica to offload the read-only query traffic from the primary DB instance.

Rely on the Application Load Balancer's automatic scaling to dynamically scale out the web tier. Configure the EC2 Auto Scaling group to use a launch template that executes a user data script on new instances. Route the read-only queries to the standby DB instance in the secondary Availability Zone of the RDS Multi-AZ deployment.

Show answer & explanation

Answer: Submit a request to AWS Support to pre-warm the Application Load Balancer prior to the event. Configure the EC2 Auto Scaling group to use a custom AMI with all dependencies pre-installed and maintain a warm pool of pre-warmed instances. Deploy an Amazon RDS for PostgreSQL read replica to offload the read-only query traffic from the primary DB instance.

Answer

The correct solution optimizes the entire architecture. For the web tier, pre-warming the ALB ensures it does not drop connections during the sudden, massive traffic spike, while utilizing custom AMIs and warm pools eliminates the

10

-minute bootstrapping delay of the instances. For the database tier, deploying an RDS read replica offloads the heavy read query volume from the primary DB instance, which resolves the database CPU exhaustion.

Step-by-Step Solution

Address the entry-point traffic bottleneck by submitting an AWS Support request to pre-warm the Application Load Balancer.

The ALB has sufficient capacity provisioned upfront to handle the sudden

200 \times

traffic increase without dropping connections.

Default ALB auto-scaling is reactive and cannot scale fast enough for near-instantaneous spikes.

Optimize the compute boot performance by creating a custom AMI containing all required application dependencies and utilizing EC2 Auto Scaling Warm Pools.

EC2 instances can join the active cluster immediately without waiting for user data execution, reducing scaling latency from over

10

minutes to under a minute.

Downloading files and installing software on boot introduces severe bootstrapping delay under sudden load.

Offload read-only query traffic from the primary RDS PostgreSQL DB instance by deploying a read replica.

The read replica handles the read-only queries, reducing the CPU utilization on the primary database and ensuring write operations do not time out.

An RDS Multi-AZ standby DB instance cannot receive client query traffic; only dedicated read replicas scale read workloads.

Key Concept

Handling extreme flash traffic spikes requires a combination of proactive load balancer pre-warming, pre-baked compute resources (custom AMIs and warm pools) to avoid bootstrap latency, and read replicas to scale storage read operations.

Question 970Question →

An enterprise has a multi-tier web application running in a primary AWS Region (us-east-1). The web tier is deployed on Amazon EC2 instances inside an Auto Scaling group behind an Application Load Balancer (ALB). The database tier uses an Amazon Aurora PostgreSQL Provisioned DB cluster. The enterprise needs to implement a disaster recovery (DR) solution in a secondary AWS Region (us-west-2) using a warm standby approach. The business requires a Recovery Point Objective (RPO) of less than 15 minutes and a Recovery Time Objective (RTO) of less than 30 minutes. Which combination of actions should a solutions architect recommend to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon Aurora Global Database by adding a secondary DB cluster in the secondary region, and deploy the application tier in the secondary region using an Auto Scaling group with a minimum capacity of at least one instance.

Configure Amazon Route 53 active-passive failover routing with Route 53 health checks associated with each Application Load Balancer endpoint to automatically redirect traffic to the standby region during an outage.

Implement a pilot light disaster recovery strategy by copying daily Amazon Aurora DB cluster snapshots to the secondary region and restoring the database cluster from the snapshot only during a failover event.

Configure Amazon Route 53 failover routing records pointing to the regional Application Load Balancers, but disable Route 53 health checks to avoid split-brain scenarios and instead manually change DNS records during an outage.

Reduce disaster recovery standby costs in the secondary region by deploying a single NAT Gateway in one Availability Zone and directing outbound traffic from all secondary private subnets to this gateway.

Show answer & explanation

Answer: Create an Amazon Aurora Global Database by adding a secondary DB cluster in the secondary region, and deploy the application tier in the secondary region using an Auto Scaling group with a minimum capacity of at least one instance.; Configure Amazon Route 53 active-passive failover routing with Route 53 health checks associated with each Application Load Balancer endpoint to automatically redirect traffic to the standby region during an outage.

Answer

The correct approach is to set up an Amazon Aurora Global Database for database replication with minimal latency, maintain a scaled-down Auto Scaling group of application instances in the secondary region for the warm standby application tier, and implement Amazon Route 53 active-passive failover routing linked with ALB health checks to automate failover.

To meet the RPO of less than 15 minutes and RTO of less than 30 minutes, the architecture must support low-latency database replication and pre-provisioned application resources. Creating an Amazon Aurora Global Database ensures sub-second replication (satisfying the RPO). Keeping a minimum of one instance running in the secondary region's Auto Scaling group satisfies the warm standby model. Finally, configuring Amazon Route 53 active-passive failover routing with health checks ensures that traffic is automatically redirected to the healthy secondary region within minutes, satisfying the RTO.

Step-by-Step Solution

Address the database tier RPO and RTO requirements by setting up replication.

Amazon Aurora Global Database replicates data to the secondary region with sub-second latency, satisfying the RPO of less than 15 minutes.

This guarantees minimal data loss and makes the database available in the secondary region for rapid promotion.

Configure the application tier in the standby region to support a warm standby posture.

An Auto Scaling group is provisioned in the secondary region with a minimum capacity of at least one instance to process traffic immediately upon failover.

This avoids the delay of starting instances from scratch, keeping RTO under 30 minutes.

Establish the traffic routing mechanism for the disaster recovery architecture.

Route 53 active-passive failover routing records are configured with health checks targeting the Application Load Balancer endpoints in both regions.

This automates the redirection of client requests to the secondary region's ALB during a failure in the primary region.

Key Concept

Enhancing Reliability and Disaster Recovery via Multi-Region Database Replication and Automated Traffic Failover

Question 971Question →

A company runs a business-critical application on Amazon EC2 instances in private subnets across three Availability Zones (AZs) in a single VPC. Currently, all outbound internet traffic from the private subnets is routed through a single NAT Gateway located in public subnet A. To improve the reliability of the system, a solutions architect must eliminate the single point of failure in the outbound traffic path.

Which configuration change should the solutions architect implement to meet this reliability requirement?

Deploy a NAT Gateway in the public subnet of each Availability Zone, and configure the route table of the private subnets in each Availability Zone to route outbound traffic through the local NAT Gateway in the same zone.

Deploy a second NAT Gateway in public subnet A, and configure an Amazon Route 53 Failover routing policy to distribute outbound traffic between the two NAT Gateways based on health checks.

Deploy a NAT Instance in public subnet B, associate the instance's IP address with a Route 53 Private Hosted Zone, and point the private subnets' route tables to the hosted zone domain.

Configure an AWS Lambda function to monitor the health of the single NAT Gateway and automatically migrate the NAT Gateway to a public subnet in a different Availability Zone if a failure is detected.

Show answer & explanation

Answer: Deploy a NAT Gateway in the public subnet of each Availability Zone, and configure the route table of the private subnets in each Availability Zone to route outbound traffic through the local NAT Gateway in the same zone.

Answer

Deploying a NAT Gateway in each Availability Zone and routing the traffic from each zone's private subnets through its local NAT Gateway aligns with the AWS Well-Architected recommendation for achieving zone-level high availability and reliability for outbound traffic.

Step-by-Step Solution

Analyze the current architecture and identify the single point of failure.

The current setup uses a single NAT Gateway in public subnet A (in one Availability Zone) to serve outbound traffic for private subnets across all three Availability Zones. If the Availability Zone containing the NAT Gateway goes down, all outbound internet traffic from all private subnets will fail.

Understanding the failure domain of the current network setup is necessary to propose a high-availability design.

Select a highly available and redundant NAT architecture.

Deploy one NAT Gateway in the public subnet of each Availability Zone (three NAT Gateways in total) and ensure the private subnets in each zone route their outbound traffic to the local NAT Gateway in the same zone.

This isolates Availability Zone failures so that an outage in one zone does not impact the outbound connectivity of resources in the other zones.

Key Concept

Multi-AZ NAT Gateway Redundancy

Question 972Question →

A media streaming platform runs its transcoding engine on Amazon EC2 instances in private subnets across $2$ Availability Zones (AZ-A and AZ-B) in the `eu-west-1` Region. The transcoding instances constantly download large raw video files from external Content Delivery Networks (CDNs) on the public internet, process them, and upload them back. Currently, all outbound internet traffic from both private subnets is routed through a single NAT Gateway located in a public subnet in AZ-A.

During peak hours, transcoding instances in AZ-B experience elevated latency, connection timeouts, and packet drops. Network analysis reveals that the single NAT Gateway is hitting its throughput limit of $45\text{ Gbps}$ and experiencing port allocation errors. Additionally, the company is incurring high inter-AZ data transfer charges for all internet-bound traffic originating from AZ-B.

Which architectural modification should a Solutions Architect recommend to optimize network performance, reduce latency, and minimize inter-AZ data transfer costs?

Deploy a new NAT Gateway in a public subnet in AZ-B. Update the route table of the private subnet in AZ-B to route outbound internet traffic (

0.0.0.0/0

) to the new NAT Gateway in AZ-B, while keeping the private subnet in AZ-A routed through the existing NAT Gateway in AZ-A.

Keep the single NAT Gateway in AZ-A. Create an AWS Transit Gateway, attach the VPC to the Transit Gateway, and configure a default route (

0.0.0.0/0

) in the private subnet route tables pointing to the Transit Gateway to load-balance traffic to the NAT Gateway.

Replace the NAT Gateway in AZ-A with a multi-AZ Application Load Balancer (ALB). Route all outbound internet-bound traffic from the private subnets through the ALB, and request AWS Support to pre-warm the ALB to handle the throughput spikes.

Establish an AWS Direct Connect Gateway connection to a central egress VPC that hosts the single NAT Gateway. Update the route tables in the private subnets to route outbound traffic (

0.0.0.0/0

) transitively through the Direct Connect Gateway to the egress VPC.

Show answer & explanation

Answer: Deploy a new NAT Gateway in a public subnet in AZ-B. Update the route table of the private subnet in AZ-B to route outbound internet traffic ( $0.0.0.0/0$ ) to the new NAT Gateway in AZ-B, while keeping the private subnet in AZ-A routed through the existing NAT Gateway in AZ-A.

Answer

Deploy a new NAT Gateway in a public subnet in AZ-B. Update the route table of the private subnet in AZ-B to route outbound internet traffic to the new NAT Gateway in AZ-B, while keeping the private subnet in AZ-A routed through the existing NAT Gateway in AZ-A.

Deploying a dedicated NAT Gateway in each Availability Zone keeps outbound internet traffic local to the subnet's Availability Zone. This eliminates the inter-AZ data transfer fees and reduces latency by removing the cross-AZ network hop. Furthermore, because each NAT Gateway has an independent throughput capacity of up to

45\text{ Gbps}

(and can scale automatically), deploying a second NAT Gateway effectively doubles the overall throughput capability to

90\text{ Gbps}

, resolving the network bottleneck and eliminating port allocation errors.

Step-by-Step Solution

Identify the performance bottleneck and network paths.

Determined that the single NAT Gateway in AZ-A is throughput-limited and causing inter-AZ data transfer latency and charges.

Locating the bottleneck is essential to determine if the issue is NAT capacity or routing hops.

Select the correct target service to resolve NAT throughput limit and inter-AZ latency.

Decided to deploy a dedicated NAT Gateway in AZ-B, keeping the egress traffic local to the Availability Zone.

This scales NAT capacity to

90\text{ Gbps}

globally and eliminates cross-AZ latency and data transfer costs.

Update VPC route tables for localized routing.

Private subnet AZ-A routes to NAT Gateway AZ-A; private subnet AZ-B routes to NAT Gateway AZ-B.

Ensures route paths are zone-specific and optimized.

Key Concept

Multi-AZ NAT Gateway Redundancy and Traffic Localization

Question 973Question →

A company manages its infrastructure using AWS CloudFormation stacks. A Solutions Architect notices that some Amazon EC2 instances and security groups have been modified manually outside of CloudFormation, creating configuration drift. The Solutions Architect wants to detect these changes and ensure future configuration consistency for both the AWS resource properties and the operating system configurations inside the EC2 instances. Which two actions should the Solutions Architect take to meet these requirements?

Select all that apply

Run drift detection on the AWS CloudFormation stacks to identify which AWS resource properties have diverged from the stack templates.

Create an AWS Systems Manager State Manager association to regularly apply and enforce the desired operating system configurations on the EC2 instances.

Modify the Service Control Policies (SCPs) at the organizational level to automatically revert EC2 instance properties to their launch configuration when drift occurs.

Enable AWS Config rules with AWS KMS managed keys to automatically re-encrypt and redeploy the CloudFormation templates when template drift is detected.

Configure AWS CodeDeploy with a linear deployment strategy to recreate the CloudFormation stack resources whenever a resource status changes.

Show answer & explanation

Answer: Run drift detection on the AWS CloudFormation stacks to identify which AWS resource properties have diverged from the stack templates.; Create an AWS Systems Manager State Manager association to regularly apply and enforce the desired operating system configurations on the EC2 instances.

Answer

Run drift detection on the AWS CloudFormation stacks to identify resource-level changes, and create an AWS Systems Manager State Manager association to enforce operating system configurations on the EC2 instances.

The correct solution involves using CloudFormation's native drift detection to identify out-of-band infrastructure changes, combined with AWS Systems Manager State Manager to enforce operating system configurations on the EC2 instances.

Step-by-Step Solution

Analyze the requirement for identifying resource-level configuration changes in CloudFormation.

Identify that CloudFormation drift detection natively compares current resource states against stack templates.

This identifies out-of-band modifications to resources managed by the stack.

Analyze the requirement for ensuring OS-level configuration consistency inside EC2 instances.

Select AWS Systems Manager State Manager to define and enforce OS configurations.

SSM State Manager automatically maintains the desired configuration state (e.g., packages, settings) on target instances.

Key Concept

Continuous configuration management and drift detection across AWS resources and guest operating systems.

Question 974Question →

A retail company is launching a new hybrid Point-of-Sale (POS) backend platform on AWS. The cloud architecture consists of a primary API VPC (`vpc-api-prod` with CIDR block $10.80.0.0/20$ ) in the `us-west-2` Region, which communicates with on-premises inventory systems via a $1\text{ Gbps}$ AWS Direct Connect connection. The company has also deployed a partner integration VPC (`vpc-partner` with CIDR block $10.90.0.0/20$ ) in the same region.

The platform must satisfy the following design requirements:
1. Production API instances in `vpc-api-prod` are distributed across two Availability Zones (`us-west-2a` and `us-west-2b`). They must have highly available, resilient outbound internet access to perform third-party payment processor API calls.
2. Partner integration services in `vpc-partner` must securely connect to the API servers in `vpc-api-prod` but must be strictly prevented from accessing any on-premises networks.
3. Private DNS resolution for the internal domain `api.internal` must be resolvable from both `vpc-api-prod` and `vpc-partner`.

Which TWO network architecture decisions should a solutions architect recommend to satisfy these requirements?

Select all that apply

Deploy a NAT Gateway in the public subnet of each Availability Zone in `vpc-api-prod`. Configure the route tables of the private subnets in each Availability Zone to route

0.0.0.0/0

traffic through the NAT Gateway in the same Availability Zone.

Deploy a single NAT Gateway in the public subnet of the `us-west-2a` Availability Zone in `vpc-api-prod`. Configure the private subnet route tables in both `us-west-2a` and `us-west-2b` to route all

0.0.0.0/0

traffic through this single NAT Gateway.

Associate the Route 53 Private Hosted Zone `api.internal` directly with both `vpc-api-prod` and `vpc-partner` in the Route 53 service configuration.

Deploy Route 53 Resolver inbound endpoints in `vpc-api-prod` and outbound endpoints in `vpc-partner`, then configure a forwarding rule in `vpc-partner` to route queries for `api.internal` to the inbound endpoints.

Connect `vpc-api-prod` and `vpc-partner` to an AWS Transit Gateway, attach the Direct Connect Gateway to the Transit Gateway, and configure a single Transit Gateway route table with automatic route propagation enabled for all attachments.

Show answer & explanation

Answer: Deploy a NAT Gateway in the public subnet of each Availability Zone in `vpc-api-prod`. Configure the route tables of the private subnets in each Availability Zone to route $0.0.0.0/0$ traffic through the NAT Gateway in the same Availability Zone.; Associate the Route 53 Private Hosted Zone `api.internal` directly with both `vpc-api-prod` and `vpc-partner` in the Route 53 service configuration.

Answer

Deploy a NAT Gateway in the public subnet of each Availability Zone in the API VPC, configure private route tables to route internet traffic to the local zone's NAT Gateway, and associate the Route 53 Private Hosted Zone directly with both the API and partner VPCs.

Deploying a NAT Gateway in each Availability Zone where the API instances are hosted prevents a single Availability Zone outage from disrupting outbound internet traffic for the entire VPC. Associating the Route 53 Private Hosted Zone directly with both the production and partner VPCs allows resources in both environments to resolve the internal domain name with minimal operational overhead and zero additional infrastructure cost.

Step-by-Step Solution

Ensure highly available outbound connectivity for the API VPC.

A NAT Gateway is deployed in each Availability Zone's public subnet, and private route tables point to the corresponding local NAT Gateway.

This mitigates Availability Zone failures and avoids cross-AZ data transfer charges for internet egress.

Associate the Route 53 Private Hosted Zone with all required VPCs.

The Route 53 Private Hosted Zone is associated with both the API VPC and the partner VPC.

This allows resources in both VPCs to resolve the local private DNS names without needing DNS forwarders or endpoints.

Verify network routing isolation rules.

The partner VPC is kept isolated from the on-premises network because VPC peering is non-transitive, or because Transit Gateway routing segments the traffic.

This meets the constraint of preventing the partner VPC from accessing the Direct Connect connection to the on-premises network.

Key Concept

Designing resilient egress routing and simplified cross-VPC private DNS resolution under strict access constraints.

Question 975Question →

An enterprise operates a multi-account AWS environment managed under AWS Organizations. In the production account, a critical payment processing application runs on a fleet of Amazon EC2 instances. The application writes its logs to a local directory at /var/log/payment/app.log. To manage local disk space, the application's logging framework rotates the logs hourly by renaming the active file to app-YYYY-MM-DD-HH.log (e.g., app-2026-07-16-10.log) and creating a new empty app.log file. The CloudWatch unified agent is deployed on the EC2 instances, configured to stream /var/log/payment/app.log to a centralized CloudWatch Logs account. The security operations team reports that after the hourly rotation, the centralized log group stops receiving new log entries, and streaming only resumes after manually restarting the CloudWatch agent service on each instance. Which of the following configuration modifications is the most operationally efficient way to resolve this issue and ensure continuous log streaming?

Maintain the static file_path parameter as /var/log/payment/app.log and schedule a cron job on the EC2 instances to restart the CloudWatch agent service every hour immediately following the log rotation.

Update the CloudWatch agent configuration file on the EC2 instances by changing the file_path parameter to /var/log/payment/app-*.log to enable the agent to dynamically track and stream newly created log files matching the wildcard pattern.

Configure an Amazon Kinesis Data Firehose delivery stream to write the logs directly to a centralized Amazon S3 bucket, and apply an S3 bucket policy in the destination account that grants write permissions using only the aws:SourceOrgID condition key without specifying the Kinesis Firehose service principal.

Enable KMS encryption on the target CloudWatch log group in the central logging account using the default AWS-managed KMS key (aws/logs) and modify the key policy to delegate cross-account write permissions to the production account.

Show answer & explanation

Answer: Update the CloudWatch agent configuration file on the EC2 instances by changing the file_path parameter to /var/log/payment/app-*.log to enable the agent to dynamically track and stream newly created log files matching the wildcard pattern.

Answer

Updating the CloudWatch agent configuration to use a wildcard pattern (/var/log/payment/app-*.log) is the most operationally efficient solution. When the file_path contains a wildcard, the CloudWatch agent dynamically monitors the directory for new files matching the pattern. When log rotation renames the active file and creates a new file, the agent continues tracking the files natively without requiring any service restarts.

Step-by-Step Solution

Analyze the log rotation mechanism and current agent configuration.

The application writes to a static file but rotates logs by renaming them to timestamped files, while the agent configuration is restricted to a static path (/var/log/payment/app.log).

This configuration mismatch causes the agent to lose track of the log stream after rotation because the file descriptor changes and new content is written to a renamed file.

Identify the native CloudWatch agent solution for dynamic log files.

Using a wildcard pattern (/var/log/payment/app-*.log) enables the CloudWatch agent to dynamically monitor the directory and automatically pick up newly created log files.

This removes the need for manual restarts or operational scripts, aligning with AWS operational excellence best practices.

Evaluate and eliminate incorrect or sub-optimal distractors.

Restarting the agent hourly via cron is operationally inefficient. Modifying cross-account bucket policies without the proper principal, or using AWS-managed KMS keys for cross-account access, are invalid AWS configurations that do not address the core issue.

AWS-managed KMS keys do not support policy edits, and S3 bucket policies for cross-account access require a designated principal.

Key Concept

Dynamic log file tracking using wildcards in the unified CloudWatch agent configuration.

Question 976Question →

An enterprise runs a critical tracking application across two AWS accounts in an AWS Organization. Account A hosts the primary production workload in the ap-southeast-1 region, consisting of Amazon ECS Fargate tasks in a private VPC. The application writes to an Amazon Aurora PostgreSQL Global Database with the primary cluster in Account A (ap-southeast-1) and a secondary read-replica cluster in Account B (ap-northeast-1). A Route 53 Private Hosted Zone (PHZ) named db.logistics.internal is hosted in Account A and is associated only with Account A's VPC. During a disaster recovery drill, the primary region experienced a simulated failure. The solutions architect promoted the database cluster in ap-northeast-1 to primary, but the ECS Fargate tasks in Account B (ap-northeast-1) failed to resolve db.logistics.internal. Additionally, an earlier localized Availability Zone outage in ap-southeast-1 had caused all outbound API integration traffic from the remaining zones to fail. The business requires an RTO of 10 minutes and an RPO of 1 minute. Which combination of actions should the solutions architect take to resolve these issues and satisfy the reliability requirements?

Authorize the cross-account association of the db.logistics.internal Private Hosted Zone in Account A with Account B's VPC in ap-northeast-1 using the Route 53 API. Associate the VPC with the zone in Account B. In Account A, deploy a NAT Gateway in each Availability Zone's public subnet and update the private route tables to route outbound traffic to the local NAT Gateway within the same zone.

Create a duplicate Private Hosted Zone named db.logistics.internal in Account B's VPC in ap-northeast-1 with identical CNAME records. In Account A, deploy a NAT Gateway in each Availability Zone's public subnet and configure the private route tables to route traffic to the local NAT Gateway within each zone.

Authorize the cross-account association of the db.logistics.internal Private Hosted Zone in Account A with Account B's VPC in ap-northeast-1 using the Route 53 API. Associate the VPC with the zone in Account B. In Account A, deploy a single NAT Gateway in one public subnet and update the private route tables across all Availability Zones to route outbound traffic through this single gateway to optimize running costs.

Authorize the cross-account association of the db.logistics.internal Private Hosted Zone in Account A with Account B's VPC in ap-northeast-1 using the Route 53 API. Replace the Aurora Global Database with a nightly snapshot replication process to Account B to reduce continuous cross-region data transfer costs, and recover the database by restoring the snapshot to a new Aurora cluster during failover.

Show answer & explanation

Answer: Authorize the cross-account association of the db.logistics.internal Private Hosted Zone in Account A with Account B's VPC in ap-northeast-1 using the Route 53 API. Associate the VPC with the zone in Account B. In Account A, deploy a NAT Gateway in each Availability Zone's public subnet and update the private route tables to route outbound traffic to the local NAT Gateway within the same zone.

Answer

Authorize the cross-account association of the db.logistics.internal Private Hosted Zone in Account A with Account B's VPC in ap-northeast-1 using the Route 53 API, associate the VPC with the zone in Account B, and deploy a NAT Gateway in each Availability Zone's public subnet in Account A while updating route tables to route outbound traffic through the local NAT Gateway within each zone.

The correct action resolves both critical issues while maintaining the active-standby database replication scheme needed to satisfy the RTO and RPO. First, by authorizing the cross-account association of the Route 53 Private Hosted Zone from Account A and associating it with the VPC in Account B, the ECS Fargate tasks in the recovery region can successfully resolve the database endpoint domain. Second, by deploying a NAT Gateway in each Availability Zone's public subnet in Account A and updating the corresponding route tables, outbound internet traffic is kept within the same zone, which removes the single point of failure and ensures that an outage in one zone does not disrupt outbound integrations for tasks running in the remaining healthy zones.

Step-by-Step Solution

Authorize cross-account Private Hosted Zone (PHZ) association.

Generate a VPC association authorization from Account A (which owns the PHZ) for the VPC in Account B using the Route 53 API.

By default, Route 53 Private Hosted Zones cannot be associated with VPCs in other AWS accounts without explicit cross-account authorization.

Associate the target VPC with the authorized PHZ.

Accept the association from Account B for its VPC in the ap-northeast-1 region.

This establishes cross-account DNS resolution, allowing the ECS Fargate tasks in the recovery region to resolve the database domain.

Deploy multiple NAT Gateways for redundancy.

Provision a NAT Gateway in a public subnet for each Availability Zone in Account A's VPC.

A single NAT Gateway is localized to a single Availability Zone. To ensure that an AZ outage does not drop traffic for all other AZs, each zone must have its own NAT Gateway.

Update private route tables.

Configure the route table of each private subnet to point its 0.0.0.0/0 route to the NAT Gateway in the corresponding Availability Zone.

This ensures localized outbound traffic routing and removes the single point of failure.

Key Concept

Cross-account Route 53 Private Hosted Zone association combined with multi-AZ redundant NAT Gateway architecture for high availability and disaster recovery.

Estimated Time:3m 0s

Question 977Question →

An enterprise runs a critical trading application on Amazon EC2 instances in an Auto Scaling group. The application writes transaction logs directly to a local directory `/var/log/trading/`. Due to high transaction volumes, the application does not write to a static file; instead, it writes directly to new hourly log files named in the format `/var/log/trading/trade_YYYYMMDD_HH.log` (for example, `/var/log/trading/trade_20260716_11.log`).

A solutions architect must design a centralized logging solution to stream these logs to Amazon CloudWatch Logs, and then forward them to an Amazon S3 bucket in a centralized security account ( $111122223333$ ) using Amazon Kinesis Data Firehose. The solution must ensure that log delivery is continuous, handles the hourly file creation without missing data, and respects the principle of least privilege.

Which configuration strategy must the solutions architect implement to meet these requirements?

Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/trading/trade_*.log`. In the security account (

111122223333

), configure the S3 bucket policy to grant `s3:PutObject` and `s3:GetBucketLocation` permissions to the AWS service principal `firehose.amazonaws.com` with a condition pattern matching the application account ID.

Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/trading/trade_*.log`. In the security account (

111122223333

), configure the S3 bucket policy to grant `s3:PutObject` and `s3:GetBucketLocation` permissions to the ARN of the IAM role assumed by the Kinesis Data Firehose delivery stream in the application account.

Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/trading/trade.log`. In the security account (

111122223333

Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/trading/trade.log`. In the security account (

111122223333

Show answer & explanation

Answer: Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/trading/trade_*.log`. In the security account ( $111122223333$ ), configure the S3 bucket policy to grant `s3:PutObject` and `s3:GetBucketLocation` permissions to the ARN of the IAM role assumed by the Kinesis Data Firehose delivery stream in the application account.

Answer

Configure the CloudWatch agent with a wildcard path (`/var/log/trading/trade_*.log`) and update the destination S3 bucket policy to trust the ARN of the Kinesis Data Firehose execution role.

The correct strategy requires configuring the CloudWatch agent with a wildcard path (`/var/log/trading/trade_*.log`) to ensure all newly created hourly logs are captured. Furthermore, to enable Kinesis Data Firehose to deliver these logs to a centralized S3 bucket in a separate AWS account, the target S3 bucket policy must allow `s3:PutObject` and `s3:GetBucketLocation` with the Principal set to the specific ARN of the Firehose delivery stream's IAM execution role. This satisfies both the dynamic log collection and the least-privilege security requirements.

Step-by-Step Solution

Configure the CloudWatch agent log path parameter with a wildcard to match the hourly logs.

The agent configuration matches `/var/log/trading/trade_*.log` instead of a static filename, enabling it to tail newly created hourly files.

Since the application writes directly to dynamically timestamped files, a static configuration will not match any active log files, preventing ingestion.

Create an IAM role for Kinesis Data Firehose in the application account and configure the delivery stream.

Firehose is set up to assume this role when executing delivery tasks.

Firehose uses the execution role to perform cross-account actions, such as writing objects to S3.

Configure the S3 bucket policy in the security account to trust the Firehose execution role ARN.

The bucket policy allows `s3:PutObject` and `s3:GetBucketLocation` for the specific principal ARN from the application account.

Cross-account access must be explicitly allowed by the resource policy of the target bucket, using the specific IAM principal executing the request.

Key Concept

Continuous log file collection via wildcard matching and secure cross-account S3 log centralization.

Estimated Time:2m 30s

Question 978Question →

An enterprise is designing a new multi-VPC AWS architecture in the `us-east-1` Region. The architecture consists of a production VPC (`vpc-prod-us-1` with CIDR $10.100.0.0/16$ ) and a shared services VPC (`vpc-shared-us-1` with CIDR $10.200.0.0/16$ ). Both VPCs are deployed across two Availability Zones (`us-east-1a` and `us-east-1b`). The enterprise needs to connect this AWS environment to an on-premises datacenter using an AWS Direct Connect (DX) connection.

The network design must satisfy the following requirements:
- Enable secure, private bidirectional communication between the on-premises datacenter and both VPCs.
- Enable the production VPC to resolve hostnames in the on-premises DNS zone (`corp.internal`), and enable on-premises hosts to resolve hostnames in a Route 53 Private Hosted Zone (PHZ) for `shared.aws` associated with the shared services VPC.
- Enable high availability for outbound internet traffic from private subnets in `vpc-prod-us-1` such that an outage in a single Availability Zone does not impact internet egress from the remaining Availability Zone.
- Maintain routing isolation between `vpc-prod-us-1` and `vpc-shared-us-1` for VPC-to-VPC traffic, allowing traffic only to and from the datacenter.

Which of the following designs meets these requirements with the least operational complexity?

Deploy an AWS Direct Connect Gateway (DXGW) and associate it directly with Virtual Private Gateways (VGWs) attached to `vpc-prod-us-1` and `vpc-shared-us-1` using Private Virtual Interfaces (Private VIFs). To achieve VPC-to-VPC routing isolation on AWS, configure the on-premises router to hair-pin and transitively route traffic between the two VPCs. Associate the Route 53 Private Hosted Zone (PHZ) for `shared.aws` with both VPCs. In `vpc-shared-us-1`, deploy Route 53 Resolver Inbound and Outbound Endpoints across both Availability Zones, and configure a forwarding rule for `corp.internal` associated with both VPCs. In `vpc-prod-us-1`, deploy a NAT Gateway in a public subnet in `us-east-1a` and another in `us-east-1b` for redundant egress.

Deploy an AWS Transit Gateway (`tgw-us-east-1`) and associate it with an AWS Direct Connect Gateway (DXGW) using a Transit Virtual Interface (Transit VIF). Attach both VPCs to the Transit Gateway and configure separate Transit Gateway route tables to isolate VPC-to-VPC traffic. Associate the Route 53 PHZ for `shared.aws` only with `vpc-shared-us-1`. In `vpc-shared-us-1`, deploy Route 53 Resolver Inbound and Outbound Endpoints across both Availability Zones, and configure a Route 53 Resolver forwarding rule for `corp.internal` associated with both VPCs. In `vpc-prod-us-1`, deploy a single NAT Gateway in a public subnet in `us-east-1a`, and configure the private subnet route tables in both `us-east-1a` and `us-east-1b` to route all internet-bound traffic to this single NAT Gateway.

Deploy an AWS Transit Gateway (`tgw-us-east-1`) and associate it with an AWS Direct Connect Gateway (DXGW) using a Transit Virtual Interface (Transit VIF). Attach `vpc-prod-us-1` and `vpc-shared-us-1` to the Transit Gateway. Configure separate Transit Gateway route tables for the VPC attachments and the DXGW association, ensuring VPC-to-VPC route propagation is disabled to maintain isolation. Associate the Route 53 Private Hosted Zone (PHZ) for `shared.aws` with both `vpc-prod-us-1` and `vpc-shared-us-1`. In `vpc-shared-us-1`, deploy Route 53 Resolver Inbound and Outbound Endpoints across both Availability Zones. Configure a Route 53 Resolver forwarding rule for `corp.internal` pointing to on-premises DNS servers, and associate this rule with both VPCs. In `vpc-prod-us-1`, deploy a NAT Gateway in a public subnet in `us-east-1a` and another in `us-east-1b`, and configure the private subnet route tables to route internet-bound traffic to the local NAT Gateway in their respective Availability Zone.

Deploy an AWS Transit Gateway (`tgw-us-east-1`) and associate it with an AWS Direct Connect Gateway (DXGW) using a Transit Virtual Interface (Transit VIF). Attach both VPCs to the Transit Gateway and configure separate Transit Gateway route tables to isolate VPC-to-VPC traffic. Associate the Route 53 PHZ for `shared.aws` only with `vpc-shared-us-1`. In `vpc-shared-us-1`, deploy Route 53 Resolver Inbound and Outbound Endpoints across both Availability Zones. Configure a Route 53 Resolver forwarding rule for `corp.internal` pointing to on-premises DNS servers, and associate this rule with both VPCs. In `vpc-prod-us-1`, deploy a NAT Gateway in a public subnet in `us-east-1a` and another in `us-east-1b`, and configure the private subnet route tables to route internet-bound traffic to the local NAT Gateway in their respective Availability Zone.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway (`tgw-us-east-1`) and associate it with an AWS Direct Connect Gateway (DXGW) using a Transit Virtual Interface (Transit VIF). Attach `vpc-prod-us-1` and `vpc-shared-us-1` to the Transit Gateway. Configure separate Transit Gateway route tables for the VPC attachments and the DXGW association, ensuring VPC-to-VPC route propagation is disabled to maintain isolation. Associate the Route 53 Private Hosted Zone (PHZ) for `shared.aws` with both `vpc-prod-us-1` and `vpc-shared-us-1`. In `vpc-shared-us-1`, deploy Route 53 Resolver Inbound and Outbound Endpoints across both Availability Zones. Configure a Route 53 Resolver forwarding rule for `corp.internal` pointing to on-premises DNS servers, and associate this rule with both VPCs. In `vpc-prod-us-1`, deploy a NAT Gateway in a public subnet in `us-east-1a` and another in `us-east-1b`, and configure the private subnet route tables to route internet-bound traffic to the local NAT Gateway in their respective Availability Zone.

Answer

Deploy an AWS Transit Gateway associated with a Direct Connect Gateway and configure separate Transit Gateway route tables to prevent VPC-to-VPC routing. Associate the Route 53 Private Hosted Zone for `shared.aws` with both VPCs, deploy Route 53 Resolver Endpoints in the shared services VPC, and associate the forwarding rule for `corp.internal` with both VPCs. Deploy a NAT Gateway in each Availability Zone of the production VPC to ensure high availability for outbound internet traffic.

The correct design uses AWS Transit Gateway to centralize Direct Connect traffic and implements separate Transit Gateway route tables to enforce routing isolation between the production and shared services VPCs. To ensure resilient internet egress in the production VPC, a NAT Gateway is deployed in each Availability Zone. For DNS resolution, Route 53 Resolver Outbound Endpoints are shared by associating the forwarding rule for the on-premises domain with both VPCs, and the Private Hosted Zone for `shared.aws` is explicitly associated with both VPCs to allow direct cross-VPC resolution.

Step-by-Step Solution

Configure hybrid connectivity with routing isolation.

Deploy AWS Transit Gateway, associate it with a Direct Connect Gateway using a Transit VIF, and attach both VPCs. Create separate Transit Gateway route tables to disable VPC-to-VPC route propagation while allowing traffic to/from the on-premises datacenter.

This establishes Direct Connect access to both VPCs while enforcing routing isolation on AWS without relying on unsupported on-premises hair-pinning.

Design multi-VPC DNS resolution.

Deploy Route 53 Resolver Inbound and Outbound Endpoints in the shared services VPC. Configure a forwarding rule for `corp.internal` pointing to the on-premises DNS servers and associate it with both VPCs. Associate the Private Hosted Zone for `shared.aws` with both the production and shared services VPCs.

This allows both VPCs to resolve the on-premises domain and allows the production VPC to resolve the private hosted zone directly, which is a requirement for multi-VPC DNS access.

Implement highly available internet egress.

Deploy two NAT Gateways in the production VPC (one in each Availability Zone) and update the private subnet route tables to route outbound internet traffic through their local NAT Gateway.

This design avoids a single point of failure and ensures that an outage in one Availability Zone does not impact internet egress for the remaining zone.

Key Concept

Designing a resilient hybrid network architecture with routing isolation, multi-VPC private DNS resolution, and zone-redundant internet egress.

Estimated Time:3m 0s

Question 979Question →

An enterprise runs a distributed containerized application across multiple AWS member accounts inside an AWS Organization. The application runs on Amazon EC2 instances in an Auto Scaling group and writes logs directly to `/var/log/app/telemetry-YYYY-MM-DD-HH.log`. These log files are rotated and recreated hourly. A Solutions Architect must design a centralized logging solution to aggregate these logs in near-real-time into an Amazon S3 bucket in a central Security account ( $111122223333$ ) for security auditing. The architecture must scale automatically as new member accounts are added to the organization, enforce encryption at rest using an AWS KMS Customer Managed Key (CMK) stored in the Security account, and minimize operational overhead on the instances. Which combination of configuration steps should the Solutions Architect implement to meet these requirements?

Install the Unified CloudWatch Agent on the EC2 instances in the member accounts. Configure the agent with a `file_path` of `/var/log/app/telemetry-*.log` in the agent configuration file to monitor the hourly log files. In each member account, deploy an Amazon Kinesis Data Firehose delivery stream configured to write to the central S3 bucket in the Security account. In the Security account, configure the S3 bucket policy to grant `s3:PutObject` and `s3:PutObjectAcl` permissions to the member accounts' Firehose IAM roles, using the `aws:PrincipalOrgID` condition. Configure S3 bucket encryption using a Customer Managed Key (CMK) in the Security account, and update the KMS key policy to allow the member accounts' Firehose IAM roles `kms:GenerateDataKey` and `kms:Encrypt` permissions.

Install the Unified CloudWatch Agent on the EC2 instances in the member accounts. Configure the agent with a static `file_path` of `/var/log/app/telemetry.log` in the agent configuration file. In each member account, deploy an Amazon Kinesis Data Firehose delivery stream configured to write to the central S3 bucket in the Security account. In the Security account, configure the S3 bucket policy to grant `s3:PutObject` and `s3:PutObjectAcl` permissions to the member accounts' Firehose IAM roles, using the `aws:PrincipalOrgID` condition. Configure S3 bucket encryption using a Customer Managed Key (CMK) in the Security account, and update the KMS key policy to allow the member accounts' Firehose IAM roles `kms:GenerateDataKey` and `kms:Encrypt` permissions.

Install the Unified CloudWatch Agent on the EC2 instances in the member accounts. Configure the agent with a `file_path` of `/var/log/app/telemetry-*.log` in the agent configuration file to monitor the hourly log files. In each member account, deploy an Amazon Kinesis Data Firehose delivery stream configured to write to the central S3 bucket in the Security account. In the Security account, configure the S3 bucket policy to grant only `s3:PutObject` permissions to the member accounts' Firehose IAM roles using the `aws:PrincipalOrgID` condition, omitting `s3:PutObjectAcl`. Configure S3 bucket encryption using the default AWS-managed KMS key (`aws/s3`) to simplify key management across accounts.

Install the Unified CloudWatch Agent on the EC2 instances in the member accounts. Configure the agent with a `file_path` of `/var/log/app/telemetry-*.log` in the agent configuration file to monitor the hourly log files. In the member accounts, configure the local CloudWatch Logs log group to stream log events directly to a centralized Kinesis Data Firehose delivery stream in the Security account by specifying the Firehose ARN in the subscription filter. In the Security account, configure the S3 bucket policy to allow the centralized Firehose role access, and configure the S3 bucket to be encrypted using the KMS CMK, without updating the KMS key policy.

Show answer & explanation

Answer: Install the Unified CloudWatch Agent on the EC2 instances in the member accounts. Configure the agent with a `file_path` of `/var/log/app/telemetry-*.log` in the agent configuration file to monitor the hourly log files. In each member account, deploy an Amazon Kinesis Data Firehose delivery stream configured to write to the central S3 bucket in the Security account. In the Security account, configure the S3 bucket policy to grant `s3:PutObject` and `s3:PutObjectAcl` permissions to the member accounts' Firehose IAM roles, using the `aws:PrincipalOrgID` condition. Configure S3 bucket encryption using a Customer Managed Key (CMK) in the Security account, and update the KMS key policy to allow the member accounts' Firehose IAM roles `kms:GenerateDataKey` and `kms:Encrypt` permissions.

Answer

The correct option is the one specifying the wildcard path in the CloudWatch agent config, deploying Kinesis Data Firehose in each member account, granting S3 write and ACL permissions via the bucket policy using the organizational condition, and updating the Customer Managed Key (CMK) key policy to allow cross-account KMS access.

The correct option configures the CloudWatch Agent with the wildcard path `/var/log/app/telemetry-*.log` to ensure dynamically rotated hourly files are captured. It uses Kinesis Data Firehose in each member account to deliver the logs cross-account. In the Security account, the S3 bucket policy grants both `s3:PutObject` and `s3:PutObjectAcl` (which Firehose requires for cross-account S3 delivery to transfer ownership). It enforces encryption using a Customer Managed Key (CMK) and updates the KMS key policy to permit the member accounts' Firehose roles to encrypt the data, which is not possible using the default AWS-managed KMS key.

Step-by-Step Solution

Configure the Unified CloudWatch Agent to monitor the dynamic hourly logs using the path `/var/log/app/telemetry-*.log`.

The agent continuously discovers and tails new log files as they are generated every hour.

Static file configurations would fail to recognize the newly created timestamped files after rotation.

Deploy Kinesis Data Firehose in each member account and target the central S3 bucket in the Security account.

Logs are buffered and packaged in near-real-time before being pushed to S3.

Firehose handles network retries, buffering, and scaling automatically per account.

Add the correct S3 bucket policy in the Security account targeting the AWS Organization ID.

Allows `s3:PutObject` and `s3:PutObjectAcl` from all member accounts.

Cross-account Firehose delivery requires both permissions to successfully write objects and grant owner control.

Configure a KMS Customer Managed Key (CMK) and update its policy in the Security account.

Grants `kms:GenerateDataKey` and `kms:Encrypt` to the member accounts' Firehose IAM roles.

AWS-managed keys (`aws/s3`) cannot be used for cross-account encryption since their policies cannot be edited.

Key Concept

To establish cross-account log centralization using Kinesis Data Firehose and CloudWatch, you must configure a dynamic wildcard path for rotated logs, use a shareable KMS Customer Managed Key (CMK) with cross-account access, and grant both `s3:PutObject` and `s3:PutObjectAcl` permissions on the destination S3 bucket policy.

Question 980Question →

A multinational financial services enterprise is designing a secure, multi-region AWS network architecture using AWS Organizations. The design must connect workloads in two regions: $us-east-1$ (acting as the primary region) and $us-west-2$ (acting as the disaster recovery region).

The architecture includes:
- In $us-east-1$ : A Shared Services account containing a Route 53 Private Hosted Zone (PHZ) named $corp.internal$ , a centralized egress VPC ( $vpc-egress-east$ ) containing stateful security appliances and NAT Gateways, and two spoke VPCs ( $vpc-payment-prod$ and $vpc-ledger-prod$ ) in separate business unit accounts.
- In $us-west-2$ : A disaster recovery spoke VPC ( $vpc-payment-dr$ ) in a business unit account.
- Two peered Transit Gateways: $tgw-useast1$ in $us-east-1$ and $tgw-uswest2$ in $us-west-2$ .

The networking requirements are:
1. Spoke VPCs in both regions must route all outbound internet traffic ( $0.0.0.0/0$ ) through the stateful security appliances.
2. Outbound traffic must be highly available and resilient to single Availability Zone outages.
3. Spoke VPCs must be able to privately resolve DNS queries for $corp.internal$ .
4. The design must minimize administrative overhead while adhering to AWS routing limitations.

Which of the following designs meets these requirements?

Deploy a local egress VPC (

vpc-egress-west

) in

us-west-2

containing NAT Gateways and security appliances in multiple Availability Zones. Route outbound traffic from

vpc-payment-dr

via

tgw-uswest2

vpc-egress-west

. In

us-east-1

, configure

tgw-useast1

to route outbound traffic to

vpc-egress-east

across multiple Availability Zones with Transit Gateway appliance mode enabled. Authorize and associate the

corp.internal

Private Hosted Zone with the spoke VPCs in both regions using cross-account VPC associations.

Route all outbound traffic from

vpc-payment-dr

through the peered Transit Gateways to the central

vpc-egress-east

VPC in

us-east-1

to consolidate security inspection. In

vpc-egress-east

, route traffic to a single NAT Gateway located in the

us-east-1a

subnet to minimize NAT gateway costs. Associate the

corp.internal

Private Hosted Zone with all spoke VPCs using a single centralized Route 53 Resolver inbound endpoint.

Deploy local egress VPCs with a single NAT Gateway in each region to minimize costs. Associate the

corp.internal

Private Hosted Zone with

vpc-egress-east

and configure the spoke VPCs to route DNS queries over the Transit Gateway peering attachment without setting up Route 53 Resolver endpoints or cross-account PHZ associations.

Route all outbound traffic from

vpc-payment-dr

tgw-uswest2

, then over the peering connection to

tgw-useast1

, and out through

vpc-egress-east

using its multi-AZ NAT Gateways. To resolve DNS, copy the zone file of

corp.internal

to a new public Route 53 hosted zone in the disaster recovery account, and configure all VPCs to resolve queries against the public zone.

Show answer & explanation

Answer: Deploy a local egress VPC ( $vpc-egress-west$ ) in $us-west-2$ containing NAT Gateways and security appliances in multiple Availability Zones. Route outbound traffic from $vpc-payment-dr$ via $tgw-uswest2$ to $vpc-egress-west$ . In $us-east-1$ , configure $tgw-useast1$ to route outbound traffic to $vpc-egress-east$ across multiple Availability Zones with Transit Gateway appliance mode enabled. Authorize and associate the $corp.internal$ Private Hosted Zone with the spoke VPCs in both regions using cross-account VPC associations.

Answer

Deploy a local egress VPC in the disaster recovery region to handle local internet traffic, configure Transit Gateway appliance mode in the primary region's egress VPC, and perform cross-account Private Hosted Zone associations for private DNS resolution.

The correct design correctly implements local egress in the disaster recovery region because AWS Transit Gateway peering does not support transitive routing to NAT Gateways or firewalls in a peered region. It also achieves high availability and symmetric routing by configuring multi-AZ NAT Gateways and enabling Appliance Mode on the transit gateway attachment for the egress VPC. Furthermore, it securely resolves private DNS by utilizing Route 53 cross-account and cross-region Private Hosted Zone associations.

Step-by-Step Solution

Address the cross-region transit routing limitation for internet egress by planning local egress infrastructure in the disaster recovery region.

A local egress VPC (

vpc-egress-west

) is designed in

us-west-2

with its own multi-AZ NAT Gateways and security appliances, avoiding the invalid path over Transit Gateway peering.

AWS Transit Gateway peering does not support transitive routing to NAT Gateways or Internet Gateways in a peered region.

Ensure symmetric routing and high availability for security appliances in the primary region's egress VPC.

Transit Gateway appliance mode is enabled on the attachment for

vpc-egress-east

, and NAT Gateways are deployed in multiple Availability Zones.

Appliance mode ensures that stateful firewall inspection traffic returns to the same firewall instance, preventing routing asymmetry, while multi-AZ NAT Gateways prevent single points of failure.

Configure private DNS resolution across regions and accounts for the

corp.internal

zone.

The Shared Services account authorizes associations with the spoke VPCs in both regions, and the respective spoke accounts accept the associations.

Route 53 Private Hosted Zones can resolve DNS queries across accounts and regions only when authorized and associated using the cross-account association process.

Key Concept

AWS Transit Gateway transitive routing limitations, multi-AZ NAT Gateway resilience, stateful appliance routing with Transit Gateway appliance mode, and cross-account Private Hosted Zone association.

Estimated Time:3m 0s

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