An enterprise is designing a new multi-VPC architecture in the `us-west-2` Region. The arc… — AWS Certified Solutions Architect - Professional

An enterprise is designing a new multi-VPC architecture in the `us-west-2` Region. The architecture contains:
- `vpc-logistics-core` ( $10.120.0.0/16$ ) hosting critical backend applications across two Availability Zones.
- `vpc-egress-shared` ( $192.168.0.0/22$ ) serving as a centralized egress VPC with NAT Gateways.
- A centralized Route 53 Private Hosted Zone (PHZ) `logistics.aws.internal` hosted in a separate shared services account.

All spoke VPCs connect to `vpc-egress-shared` using an AWS Transit Gateway (`tgw-global-transit`). The solution must provide highly available outbound internet connectivity, prevent any direct network communication between spoke VPCs, and enable private DNS resolution of names within `logistics.aws.internal` for all instances in the spoke VPCs.

Which TWO configurations must a Solutions Architect implement to meet these requirements?

Associate the Route 53 Private Hosted Zone `logistics.aws.internal` with each consumer VPC by creating VPC association authorizations in the shared services account and then associating the zone with the VPCs in their respective accounts.Answer
Configure a Transit Gateway route table associated with the spoke VPC attachments that has a static route for $0.0.0.0/0$ pointing to the egress VPC attachment, and do not propagate spoke VPC routes into this route table.Answer
C
Associate the Route 53 Private Hosted Zone `logistics.aws.internal` only with the egress VPC, and configure the spoke VPCs to direct all DNS queries to a Route 53 Resolver inbound endpoint in the egress VPC via Transit Gateway routing.
D
Configure a single Transit Gateway route table associated with all VPC attachments with route propagation enabled, and deploy AWS Network Firewall in the egress VPC to block spoke-to-spoke network traffic.
E
Deploy a single NAT Gateway in one public subnet of `vpc-egress-shared`, and configure the default route ( $0.0.0.0/0$ ) in all private subnets of `vpc-egress-shared` and the spoke VPCs to point to this NAT Gateway.

Answer

To satisfy the requirements, the Solutions Architect must associate the Route 53 Private Hosted Zone with each consumer VPC using VPC association authorizations, and configure a separate Transit Gateway route table for the spokes that directs default traffic to the egress VPC without propagating spoke routes.

Associating the private hosted zone directly with each VPC allows local DNS resolution to function natively without routing queries across Transit Gateway. Using separate Transit Gateway route tables for spokes that contain only a default route to the egress VPC (and disabling propagation of spoke routes) ensures spoke-to-spoke traffic cannot be routed, while outbound traffic is successfully directed to the egress VPC.

Step-by-Step Solution

Enable cross-account DNS resolution by creating association authorizations for the Private Hosted Zone `logistics.aws.internal` with each consumer VPC using the Route 53 API in the owner account.

Authorized consumer VPCs in other accounts can now associate with the hosted zone.

This allows the instances in the spoke VPCs to resolve private domain names natively and securely.

Associate the authorized consumer VPCs with the hosted zone from their respective AWS accounts.

DNS queries for the domain are resolved locally in each VPC.

This satisfies the DNS resolution requirement without requiring complex hybrid resolver endpoints.

Create separate Transit Gateway route tables for the spoke VPCs and the egress VPC. Associate the spoke VPC attachments with the spoke Transit Gateway route table.

Traffic originating from spokes is evaluated against the spoke Transit Gateway route table.

Separating route tables is required to implement custom route propagation rules.

Add a static default route (

0.0.0.0/0

) in the spoke Transit Gateway route table pointing to the egress VPC attachment, and do not propagate spoke routes into this table.

Spokes can route outbound traffic to the egress VPC, but cannot route traffic to other spokes because they lack routes to those spokes.

This prevents transitive spoke-to-spoke communication while allowing centralized internet egress.

Key Concept

Centralized multi-account networking design with secure egress routing and private DNS resolution.

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic