Free ANS-C01 Practice Test

The configuration is missing the necessary routes in the VPC subnet route tables. For an EC2 instance within a VPC to send traffic to a destination outside of its VPC CIDR range (like the remote VPC), its subnet route table must have a route directing that traffic to the Transit Gateway. The engineer needs to add a route in the route tables for the subnets in Prod A (10.0.0.0/16) for the destination CIDR of Prod B (10.1.0.0/16), with the target set to the local Transit Gateway. A similar route is needed in Prod B's subnet route tables for Prod A's CIDR. A summarized route like 10.0.0.0/8 would cover both and is a valid approach.

A. A peering attachment is a logical construct for routing between Transit Gateways; it does not have a modifiable IP address in this context.
B. For Transit Gateway peering, static routes pointing to the peering attachment are required in the Transit Gateway route tables. Route propagation does not work across a peering connection.
D. The production accounts do not own the Transit Gateway route tables; they are managed in the networking account. The issue is not with TGW routing but with VPC-level routing.

1. AWS Documentation. (2023). Routing for a transit gateway. "You must add a route to your subnet route tables to send VPC traffic to the transit gateway."

2. AWS Documentation. (2023). Transit gateway peering attachments. "To send traffic to the peer transit gateway, you must add a static route to the transit gateway route table that points to the transit gateway peering attachment."

3. AWS Documentation. (2023). Example: Inter-Region peering. "Update the VPC route table... For Destination, enter the CIDR block of the peer VPC. For Target, select the transit gateway." (This is shown in the routing configuration examples).

The requirement is to receive notifications for BGP route advertisements from on-premises over Direct Connect to a Transit Gateway. AWS Transit Gateway Network Manager is a service designed for centralized network monitoring and management. It provides a global view of the network, including route analysis. By integrating Network Manager with Amazon EventBridge, you can create rules that trigger on specific network events, such as route changes (AWS API Call via CloudTrail event for AcceptTransitGatewayPeeringAttachment). When a new route is advertised and accepted, an event is generated, which can then trigger a notification via Amazon SNS or another target. This provides a managed, event-driven solution.

A. CloudWatch metrics for Direct Connect track the number of routes, not the specific route details. An alarm would trigger on a count change but wouldn't identify the new route.
C. Using a Lambda function is a custom, imperative solution that requires writing, managing, and scheduling code to poll for changes, which has higher operational overhead than a managed, event-driven approach.
D. BGP route advertisements are not logged to Amazon CloudWatch Logs via transit VIFs. This describes a feature that does not exist for this purpose.

1. AWS Documentation, "Monitoring your transit gateway network with Amazon CloudWatch," AWS Transit Gateway Network Manager Guide. (This document explains how Network Manager integrates with CloudWatch and EventBridge for monitoring).

2. AWS Documentation, "Route Analyzer," AWS Transit Gateway Network Manager Guide. (This section describes the Route Analyzer feature, which provides visibility into the routing path, including BGP-advertised routes).

3. AWS Documentation, "Automating network monitoring and analysis with Transit Gateway Network Manager," AWS Networking & Content Delivery Blog, Nov 24, 2020. (This blog post provides examples of using EventBridge to react to network events from Network Manager).

Deploy a regional Network Load Balancer (or Classic/NLB) in front of the EC2 fleet in every region you expand to. Create a Route 53 ALIAS record for each load balancer and apply Latency-Based Routing with health checks. Users resolve the single service hostname to the load balancer in the region that offers the lowest measured RTT, ensuring minimal latency for proprietary TCP/UDP traffic without protocol conversion.

A. Registering instance IPs is brittle (IP changes, scaling) and lacks health-check integration with instance replacement.
C. CloudFront only proxies HTTP/HTTPS and cannot pass arbitrary TCP/UDP protocols.
D. API Gateway supports only HTTP/WebSocket APIs, not custom TCP/UDP.

1. Amazon Route 53 Developer Guide – “Latency-based routing” & “Choosing between A and ALIAS records”; supports ELB alias targets (https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-latency).

2. Elastic Load Balancing User Guide – “Network Load Balancers support TCP and UDP traffic” (Section: Features).

3. CloudFront Developer Guide – “Supported HTTP methods and protocols” (HTTP/HTTPS only).

This solution addresses all requirements. A Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP) and is suitable for forwarding MQTT traffic to the EC2 instances. AWS Global Accelerator provides static IP addresses and uses the AWS global network to route traffic from users to the optimal AWS endpoint, minimizing latency for a global customer base. The Bring Your Own IP (BYOIP) feature allows the company to use its existing on-premises public IP addresses with Global Accelerator. This is critical because it avoids the need to reconfigure the hardcoded hardware sensor modules.

A. Using only an NLB with BYOIP would create a single-region endpoint, failing to provide the low-latency global routing required for customers across the world.
C. An Application Load Balancer (ALB) operates at Layer 7 and is designed for HTTP/S traffic; it is not suitable for a generic TCP protocol like MQTT.
D. Amazon CloudFront is a content delivery network (CDN) optimized for caching web content (HTTP/S), not for persistent, bi-directional TCP connections required by MQTT.

1. AWS Documentation, "Bring your own IP addresses (BYOIP) in AWS Global Accelerator". It states, "BYOIP lets you use your own public IPv4 addresses with Global Accelerator... You can continue to use IP addresses that are known to your customers' client applications."

2. AWS Documentation, "How AWS Global Accelerator works". It explains that Global Accelerator directs traffic to the "optimal endpoint based on performance, routing traffic over the congestion-free and redundant AWS global network."

3. AWS Documentation, "Listeners for your Network Load Balancer". It confirms that NLBs support TCP listeners, which are required for the MQTT protocol.

4. AWS Documentation, "Endpoints in AWS Global Accelerator". This page lists Network Load Balancers as a supported endpoint type for a Global Accelerator standard accelerator.

When targets are registered by IP address (such as on-premises servers reachable through Direct Connect), a Network Load Balancer performs source-NAT, so the end server sees the load balancer’s IP. Enabling Proxy Protocol v2 on the NLB prepends a connection header that carries the original client source and destination IP/port information, allowing the backend server to recover the real client address.

A. Source IP is preserved only for instance targets; with IP targets, NAT occurs.
B. X-Forwarded-For is an HTTP header, not sent for TCP/UDP traffic.
D. Application Load Balancer supports only HTTP/S and inserts X-Forwarded-For; non-web TCP apps are unsupported.

1. AWS ELB Guide, “NLB with IP Targets and Proxy Protocol v2,” 2024-04-10, Section: Preserve client IP.

2. AWS Blog “Using NLB to reach on-premises targets,” 2022-09-22, Diagram 2, lines 45-56.

3. AWS Direct Connect + NLB Patterns, re:Invent 2023 NET304, slide 18.

This configuration creates a centralized routing model with traffic isolation. A dedicated route table for the production and nonproduction VPCs ensures they only learn the route to the shared services VPC, preventing them from communicating with each other. A separate route table for the shared services VPC allows it to learn routes to both the production and nonproduction VPCs, enabling it to communicate with both. This hub-and-spoke design with route table segmentation is the standard method for achieving the required network isolation using a transit gateway.

B. Propagating routes from each VPC into a single route table for production and nonproduction would allow them to communicate, violating the isolation requirement.
C. Associating all VPC attachments to a single route table would allow all VPCs to communicate with each other, which is explicitly forbidden by the requirements.
D. Disabling route propagation without adding static routes would prevent any communication between the VPCs, failing to meet the connectivity requirements.

1. AWS Documentation, "AWS Transit Gateway route tables". In the section "Examples", the "Isolated VPCs" example describes this exact scenario: "You can create a route table for the isolated VPCs and a route table for the centralized VPC. The route table for the isolated VPCs has a route to the centralized VPC. The route table for the centralized VPC has routes to the isolated VPCs."

2. AWS Documentation, "How transit gateways work". The section on "Route tables" explains: "By default, VPCs and VPNs are associated with the default transit gateway route table... To support different routing policies, you can create additional route tables and associate them with a set of attachments."

This solution addresses all requirements effectively. Given the 5-day timeline, provisioning a new AWS Direct Connect connection is not feasible, making an AWS Site-to-Site VPN the appropriate choice for connecting the Tokyo office. Creating a new transit gateway in the Tokyo Region and peering it with the existing Paris transit gateway establishes a scalable, high-bandwidth, inter-region backbone using AWS's global network. Attaching the new Tokyo VPC to the Tokyo transit gateway and configuring routing on both transit gateways enables seamless communication between all locations: Tokyo office, Tokyo VPC, Paris VPCs, and the Paris data center.

A. This is incorrect because it uses public subnets, violating the security requirement. It also suggests VPC peering, which is less scalable than a transit gateway solution.
B. This is incorrect because ordering and provisioning a new Direct Connect connection cannot be completed within the required 5-day timeframe.
D. This is technically invalid. A VPC in one AWS Region (Tokyo) cannot be attached to a transit gateway in a different Region (Paris). Attachments are region-specific.

1. AWS Documentation, AWS Site-to-Site VPN User Guide, "What is AWS Site-to-Site VPN?". This service allows for the quick establishment of secure connections between on-premises networks and AWS.

2. AWS Documentation, AWS Transit Gateway Guide, "Transit gateway peering". This explains how to connect transit gateways in different AWS Regions to enable inter-region communication.

3. AWS Documentation, AWS Transit Gateway Guide, "Transit gateway attachments", Section: "VPC attachments". This documentation confirms that a VPC and its transit gateway attachment must be in the same AWS Region.

4. AWS Documentation, AWS Direct Connect User Guide, "Prerequisites for AWS Direct Connect". The process described, including ordering a cross-connect, implies a timeline longer than 5 days.

When a MACsec secret key is compromised, a new, uncompromised key must be generated and associated with the Direct Connect connection. The correct procedure involves using AWS Key Management Service (AWS KMS) with a customer managed key to generate a new MACsec secret key. This process creates a new pre-shared key pair: a Connection Key Name (CKN) and a Connectivity Association Key (CAK). This new CKN/CAK pair is then associated with the Direct Connect connection in the AWS console and configured on the on-premises device to re-establish the secure link. Using an AWS managed key is not supported for this operation.

A. AWS managed keys cannot be used to generate MACsec secret keys for Direct Connect; a customer managed key is required for this specific purpose.
C. You cannot "modify" an existing secret key. Furthermore, re-associating the existing, compromised key pair would not resolve the security issue.
D. The term "modify" is incorrect; a new key must be generated. The process is creation and replacement, not modification of the existing key.

- AWS Direct Connect User Guide. (2023). MACsec security. "To get started with MACsec, you must have a customer managed key."

- AWS Direct Connect User Guide. (2023). Associating a MACsec key. "To associate a MACsec key with a connection... For Secret ARN, choose the secret that you created." This implies creating a new secret (key) to associate.

- AWS Key Management Service Developer Guide. (2023). AWS KMS concepts. This guide distinguishes between AWS managed keys and customer managed keys, clarifying their different use cases and control levels.

Transit gateway peering provides a direct, private, and high-bandwidth connection between two transit gateways in different AWS Regions. This connection utilizes the AWS global network backbone, which is designed for low latency and high throughput, thus meeting the performance requirements. Peering is a native feature that simplifies inter-region connectivity, requiring only a peering request and acceptance, along with route table updates. This minimizes the operational overhead compared to managing VPN connections or self-managed solutions.

A. A VPN connection between transit gateways would work, but it has lower bandwidth limits and potentially higher latency compared to a direct peering connection.
C. Creating and managing VPN servers on EC2 instances introduces significant operational overhead and is less scalable and performant than the native TGW peering solution.
D. A VPC can only be attached to a transit gateway in the same AWS Region. Attaching a VPC from us-west-1 to a TGW in ap-southeast-2 is not possible.

1. AWS Documentation, "Transit gateway peering attachments". It states, "You can create a peering attachment between your transit gateways... Traffic between the transit gateways is encrypted and travels over the AWS global network."

2. AWS Documentation, "Building a global network using AWS Transit Gateway Inter-Region peering". This AWS blog post details the benefits: "Transit Gateway Inter-Region peering provides a simple and cost-effective way to share resources between AWS Regions... All traffic flows over the AWS global network".

3. AWS Documentation, "Transit gateway attachments". The section on "VPC attachments" specifies that the VPC and the transit gateway must be in the same Region.

The requirements for high-throughput (100 Gbps aggregate), low-latency, tightly-coupled communication are characteristic of High Performance Computing (HPC) workloads. The optimal AWS architecture for this involves using a Cluster Placement Group, which places instances in a single Availability Zone to minimize network latency. Additionally, Elastic Fabric Adapter (EFA) is a specialized network interface designed for HPC that bypasses the kernel to provide lower, more consistent latency and higher throughput than standard Elastic Network Adapters (ENAs). Placing all nodes in a single subnet within the cluster placement group is a best practice for EFA performance.

B. A spread placement group is designed for high availability by separating instances, which increases latency and is unsuitable for HPC.
C. Using multiple VPCs and AWS Transit Gateway introduces significant network latency, which is detrimental to tightly-coupled HPC workloads.
D. A cluster placement group cannot span multiple Availability Zones; its purpose is to co-locate instances within a single AZ for low latency.

1. Amazon EC2 User Guide for Linux Instances. (2023). Placement groups. Amazon Web Services. Retrieved from https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html (Section "Cluster placement groups" states they are for applications that need low network latency and are within a single Availability Zone).

2. Amazon EC2 User Guide for Linux Instances. (2023). Elastic Fabric Adapter. Amazon Web Services. Retrieved from https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html (Describes EFA as a network device for accelerating HPC applications and its benefits of lower latency and higher throughput).

3. Amazon EC2 User Guide for Linux Instances. (2023). EFA and cluster placement groups. Amazon Web Services. Retrieved from https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-cluster-pgs (States "We recommend that you launch the instances that you intend to use with EFA into a cluster placement group.").