ANS-C01 Practice Questions

The configuration is missing the necessary routes in the VPC route tables. For an instance in a VPC to send traffic to a remote network via a Transit Gateway, its subnet's route table must contain a route that directs that traffic to the Transit Gateway attachment. While the engineer configured routing within the Transit Gateways (steps 5 and 6), the initial step of getting traffic from the source VPC to its local Transit Gateway was omitted. Adding a route for the destination CIDR (or a summary route like 10.0.0.0/8 which covers both VPCs) in each VPC's route table with the target as the Transit Gateway resolves this connectivity issue.

A. Peering attachments are logical constructs and do not have configurable IP address ranges. This option is technically invalid.

B. Static routes are required in Transit Gateway route tables to direct traffic over a peering attachment. Dynamic propagation of VPC routes is not supported across peering.

D. Dynamic route propagation for VPC CIDRs is not supported across a Transit Gateway peering attachment. Static routes are mandatory for inter-region traffic.

1. AWS Documentation, Amazon VPC, User Guide, "Route tables for your VPCs", section "Routing". This document states: "Each subnet in your VPC must be associated with a route table. ... We recommend that you add a route to your subnet route tables for all traffic that is not destined for the VPC (0.0.0.0/0) that points to a gateway." In this scenario, the traffic to the other VPC is "not destined for the local VPC" and must be routed to the Transit Gateway.

2. AWS Documentation, AWS Transit Gateway, User Guide, "AWS Transit Gateway peering attachments", section "Routing for peering attachments". This document clarifies the routing requirements for peering: "To route traffic between the transit gateways, you must add a static route to your transit gateway route table that points to the transit gateway peering attachment." This confirms that step 6 in the scenario was correct and that options B and D, which suggest removing static routes, are incorrect.

3. AWS Documentation, AWS Transit Gateway, User Guide, "Examples", section "Centralized router". The diagrams and routing table examples in this section clearly show two distinct sets of routes required for connectivity: (1) routes within the VPC subnet route tables pointing to the Transit Gateway for remote CIDRs, and (2) routes within the Transit Gateway route table pointing to the appropriate attachments. The scenario is missing the first set of routes.

Amazon Transit Gateway Network Manager provides centralized monitoring and visibility for a global network, including hybrid connectivity over AWS Direct Connect. It generates events for network changes, including BGP routing updates. When a new route is advertised from on-premises, Network Manager emits an event to Amazon EventBridge. An EventBridge rule can be configured to match this specific event and trigger a target, such as an Amazon SNS topic, to send a notification. This creates an efficient, event-driven architecture that directly addresses the requirement for real-time notifications on route changes.

A. Amazon CloudWatch metrics for Direct Connect track connection health, data throughput, and BGP session state, but not the advertisement of individual routes.

C. A Lambda function would have to periodically poll the route tables and compare states. This is an inefficient, complex, and non-real-time polling approach.

D. There is no native feature to enable Amazon CloudWatch Logs on a Direct Connect transit VIF to capture BGP route advertisements.

1. AWS Transit Gateway User Guide, Network Manager, Monitoring your global network with Events: "Network Manager generates events for changes to the network topology, routing, and connection status. Events are delivered to Amazon EventBridge (formerly Amazon CloudWatch Events)... For example, you can create an event to be notified when a BGP route is learned or no longer advertised from a specific BGP peer."

2. Amazon EventBridge User Guide, Events from AWS services, Network Manager events: This section details the event patterns generated by Network Manager that can be used to trigger rules in EventBridge. The aws.networkmanager source provides events for routing updates.

3. AWS Direct Connect User Guide, Monitoring, Monitoring with Amazon CloudWatch: This page lists the available metrics for Direct Connect connections and virtual interfaces. The list includes metrics like ConnectionState and BGPPeeringState but lacks any metric for tracking the number or content of advertised routes.

The application's use of proprietary TCP and UDP protocols requires a Layer 4 networking solution. An AWS Network Load Balancer (NLB), which is a type of Elastic Load Balancer (ELB), operates at the transport layer (Layer 4) and is designed to handle high-performance TCP and UDP traffic.

For global expansion with low latency, the optimal architecture involves deploying the application on EC2 instances fronted by an NLB in multiple AWS regions. Amazon Route 53 can then be configured with a latency-based routing policy. Using ALIAS records in Route 53 to point to the regional NLBs allows Route 53 to resolve DNS queries by directing users to the AWS region that offers the lowest network latency, thus fulfilling the core requirement.

A. While technically feasible, directly mapping DNS records to individual EC2 instances is less scalable and harder to manage than using a load balancer, which is the best practice.

C. Amazon CloudFront is a Content Delivery Network (CDN) optimized for caching and delivering web content over HTTP/HTTPS; it does not support arbitrary TCP or UDP protocols.

D. Amazon API Gateway is a managed service for creating and managing REST, HTTP, and WebSocket APIs. It does not support generic TCP or UDP traffic.

1. Network Load Balancer Protocol Support: AWS Documentation, User Guide for Network Load Balancers, "What is a Network Load Balancer?". This document states, "A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model... It supports both TCP and UDP traffic, as well as TLS traffic...".

2. Route 53 Latency-Based Routing: AWS Documentation, Amazon Route 53 Developer Guide, "Choosing a routing policy", Section: "Latency-based routing". This section explains, "Use latency-based routing when you have resources in multiple AWS Regions and you want to route traffic to the region that provides the best latency."

3. Route 53 ALIAS Records for ELB: AWS Documentation, Amazon Route 53 Developer Guide, "Choosing between alias and non-alias records", Section: "Routing traffic to an ELB load balancer". This guide details the use of ALIAS records to map a domain name to an AWS resource, such as an Elastic Load Balancer.

4. API Gateway Protocol Limitations: AWS Documentation, Amazon API Gateway Developer Guide, "What is Amazon API Gateway?". The introduction clearly defines its purpose for "REST, HTTP, and WebSocket APIs," which excludes generic TCP/UDP protocols.

This solution correctly addresses all the company's requirements. AWS Global Accelerator is designed to improve the performance and availability of applications for a global user base by directing traffic to the optimal endpoint over the AWS global network, thus minimizing latency. Crucially, Global Accelerator supports the Bring Your Own IP (BYOIP) feature, which allows the company to use its existing hardcoded public IP addresses in AWS, eliminating the need to reconfigure the deployed IoT sensors.

The Network Load Balancer (NLB) is the appropriate choice for handling the MQTT traffic. As a Layer 4 load balancer, it supports TCP listeners and is designed for high-throughput, low-latency workloads with long-lived connections, which is characteristic of the MQTT protocol.

A. A standalone Network Load Balancer is a regional service. It would not solve the core problem of minimizing latency for a global customer base, as all traffic would still traverse the public internet to a single region.

C. An Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS) and does not support generic TCP listeners required for the MQTT protocol. Therefore, it is unsuitable for this workload.

D. Amazon CloudFront is a content delivery network (CDN) optimized for caching and delivering web content (HTTP/S). It is not the appropriate service for routing stateful, non-HTTP TCP traffic like MQTT.

1. AWS Global Accelerator Documentation, "Bring your own IP addresses (BYOIP) in AWS Global Accelerator": "You can bring part or all of your public IPv4 address range from your on-premises network to your AWS account. You can continue to access these addresses, in your AWS account, with AWS Global Accelerator." This supports the use of BYOIP with Global Accelerator to meet the no-reconfiguration requirement.

2. AWS Global Accelerator Documentation, "How AWS Global Accelerator works": "Global Accelerator uses the vast, congestion-free AWS global network to route TCP and UDP traffic to a healthy application endpoint in the closest AWS Region to your user. If there's an application failure, Global Accelerator provides instant failover to the next best endpoint." This confirms its role in reducing latency for global traffic.

3. AWS Elastic Load Balancing Documentation, "User Guide for Network Load Balancers", Section: "Network Load Balancers": "A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second. After the load balancer receives a connection request, it selects a target from the target group for the default rule. It attempts to open a TCP connection to the selected target on the port specified in the listener configuration." This confirms the NLB's suitability for TCP-based protocols like MQTT.

4. AWS Elastic Load Balancing Documentation, "User Guide for Application Load Balancers", Section: "Listeners for your Application Load Balancer": "An Application Load Balancer supports the following protocols: HTTP, HTTPS, and gRPC." This confirms that an ALB does not support the generic TCP protocol required for MQTT.

A Network Load Balancer (NLB) is the appropriate choice for a non-web (Layer 4) application. When an NLB routes traffic to on-premises targets via AWS Direct Connect, it acts as a proxy, and by default, the on-premises server sees the NLB's private IP address as the source. To preserve the original client IP address in this scenario, you must enable Proxy Protocol on the NLB's target group. The NLB then prepends a Proxy Protocol v2 header to the TCP connection, which contains the original client connection information, including the source IP. The on-premises application must be configured to parse this header to retrieve the client's IP address.

A. This is incorrect because an NLB only preserves the source IP automatically for targets within its VPC (registered by instance ID or IP). For on-premises targets, it does not.

B. The X-Forwarded-For header is an HTTP (Layer 7) concept used by Application Load Balancers. A Network Load Balancer operates at Layer 4 and does not process or add HTTP headers.

D. An Application Load Balancer is designed for web traffic (HTTP/HTTPS) and is unsuitable for a generic non-web application. It would be the wrong type of load balancer for this use case.

1. AWS Documentation: Elastic Load Balancing User Guide for Network Load Balancers - Source IP addresses.

Under the section "Client IP address preservation," it states: "When you register targets by IP address, the source IP addresses of the clients are preserved for targets in the load balancer VPC... For targets in a peered VPC, on-premises (through a VPN or AWS Direct Connect)... the source IP addresses of the clients are the private IP addresses of the load balancer nodes. If you need the client IP addresses, enable proxy protocol..." This directly refutes option A and supports option C for the on-premises scenario.

2. AWS Documentation: Elastic Load Balancing User Guide for Network Load Balancers - Proxy protocol.

The guide explains, "You can enable Proxy protocol on your load balancer and then get the client's connection information from the header that is added to the request." It further details that the Proxy Protocol v2 header includes the source IP address, destination IP address, source port, and destination port. This confirms that enabling Proxy Protocol (specifically v2 for NLB) is the correct mechanism.

3. AWS Documentation: Elastic Load Balancing User Guide for Application Load Balancers - Request routing.

This document describes how ALBs handle requests, stating, "Application Load Balancers support the X-Forwarded-For... headers." This confirms that X-Forwarded-For is an ALB feature, making options B and D incorrect in the context of an NLB or a non-web application.

This configuration creates a network segmentation model using two distinct Transit Gateway (TGW) route tables. The first route table is for the production and nonproduction VPCs. By associating both VPC attachments with this table and only propagating the route from the shared services VPC, traffic originating from production or nonproduction is only permitted to travel to the shared services VPC. This effectively isolates them from each other.

The second route table is exclusively for the shared services VPC. By associating the shared services attachment with this table and propagating routes from both the production and nonproduction VPCs, it allows the shared services VPC to send return traffic to both environments, thus fulfilling all communication requirements.

B. Propagating routes from each VPC into the production/nonproduction route table would create routes between them, directly violating the requirement for isolation.

C. Associating all VPC attachments with the first route table is incorrect. The shared services VPC would use a route table that lacks routes back to production and nonproduction.

D. Disabling propagation without adding equivalent static routes would prevent the production and nonproduction VPCs from learning the path to the shared services VPC, breaking connectivity.

1. AWS Documentation: Amazon VPC User Guide, "Examples for Transit Gateway route tables". The subsection "Isolated VPCs with a shared services VPC" describes this exact scenario: "You can create a configuration in which your transit gateway has a route table for the isolated VPCs and a route table for the shared services VPC... The route table for the isolated VPCs has a route to the shared services VPC... The route table for the shared services VPC has routes to the isolated VPCs." This directly validates the two-route-table approach in answer A.

2. AWS Documentation: Amazon VPC User Guide, "How transit gateways work". This section explains the core concepts of association and propagation. It states, "Each attachment is associated with exactly one route table. Each attachment can propagate its routes to one or more route tables." The correct answer (A) properly utilizes these two distinct functions to control the flow of traffic as required.

3. AWS Whitepaper: "Building a Scalable and Secure Multi-VPC AWS Network Infrastructure" (July 2020). In the section "Network segmentation" (page 16), the paper discusses using AWS Transit Gateway to create network segments. It states, "With TGW, you can create fine-grained routing rules by creating multiple TGW route tables... This allows you to create network segments where workloads can only communicate with approved VPCs," which is the principle applied in this question.

This solution provides a scalable and timely architecture. A Transit Gateway (TGW) in the Tokyo Region creates a regional network hub, similar to the existing Paris setup. Peering the Tokyo TGW with the Paris TGW enables secure, private, and high-bandwidth connectivity between the two AWS regions over the AWS global backbone. For connecting the on-premises Tokyo office, an AWS Site-to-Site VPN is the most appropriate choice given the 5-day deadline, as it can be provisioned rapidly. In contrast, a new Direct Connect connection typically takes weeks to provision. This design correctly uses the TGWs as central hubs to route traffic between all required locations: Tokyo office, Tokyo VPC, Paris VPCs, and the Paris data center.

A: This option violates the requirement that workloads not be directly accessible from the internet by using public subnets and an internet gateway.

B: A new AWS Direct Connect connection cannot be provisioned within the 5-day timeline; the process typically takes several weeks or longer.

D: This architecture is invalid. A Transit Gateway can only have VPC attachments within the same AWS Region. It cannot directly attach to a VPC in another region.

1. AWS Documentation, Amazon VPC User Guide, "Transit gateway peering attachments": "You can create a peering attachment between your transit gateways. The transit gateways can be in the same AWS Region or in different AWS Regions. ... Traffic between the Regions is sent over the AWS global network and is automatically encrypted." This supports the use of TGW peering for inter-region connectivity as proposed in option C.

2. AWS Documentation, AWS Site-to-Site VPN User Guide, "Site-to-Site VPN connections": "You can create a Site-to-Site VPN connection and configure it to work with a transit gateway. You can connect multiple VPCs and your on-premises networks to a common transit gateway, which acts as a network hub." This confirms that a Site-to-Site VPN is a valid and standard method for connecting an on-premises site to a Transit Gateway.

3. AWS Documentation, AWS Direct Connect User Guide, "Requesting a cross connect": The process described for establishing a Direct Connect connection involves coordination with an AWS Direct Connect partner and can take a significant amount of time, making it unsuitable for a 5-day deadline. The guide states, "After you have requested a connection, the AWS Direct Connect partner works with you to provision a circuit."

4. AWS Documentation, Amazon VPC User Guide, "Transit gateway attachments": Under the "VPC attachments" section, the documentation states, "You can attach a VPC in the same AWS Region as the transit gateway." This rule makes the architecture proposed in option D technically impossible.

When a MACsec secret key is compromised, the only secure course of action is to replace it entirely. This involves generating a new pre-shared key, which consists of a new Connection Key Name (CKN) and a new Connectivity Association Key (CAK). This new key must then be associated with the AWS Direct Connect connection, which replaces the compromised key. While the secret can be stored in AWS Secrets Manager and encrypted with either an AWS managed or customer managed key from AWS KMS, using an AWS managed key is the default, simpler configuration, making it the most suitable choice when no other compliance requirements are specified.

B. Using a customer managed key is a valid but more complex option. The AWS managed key is the default and simpler choice, making it the better general answer.

C. Re-associating the existing, compromised key is insecure and fails to address the security breach. A new, uncompromised key must be generated.

D. The process involves creating and associating a new key, which replaces the old one. The term "modify" is inaccurate for this replacement operation.

1. AWS Direct Connect User Guide, "Work with MACsec keys": Under the "Associate a MACsec key" section, the documentation states, "You can associate a new MACsec key with a connection at any time. When you do, the new key replaces the existing key." This confirms that creating and associating a new key is the correct procedure to replace an existing one.

2. AWS Direct Connect API Reference, AssociateMacSecKey: The documentation for this API action shows that the required parameters include connectionId, ckn, and cak. This demonstrates that a new CKN/CAK pair is provided to AWS to establish the new key association, effectively replacing any prior key.

3. AWS Secrets Manager User Guide, "Encryption at rest": This guide explains how secrets are protected. It states, "By default, Secrets Manager encrypts the secret value with the AWS managed key aws/secretsmanager." This supports the choice of an AWS managed key (Option A) as the standard, default mechanism for protecting the secret key material.

The most effective solution is to create a peering connection between the Transit Gateway in ap-southeast-2 and the new Transit Gateway in us-west-1. Transit Gateway inter-region peering uses the AWS global network backbone, which is designed for high bandwidth and low, predictable latency, directly addressing the performance requirements. This is a fully managed AWS feature, which significantly minimizes the operational overhead associated with managing complex network connections, such as self-managed VPNs or multiple individual tunnels. Once peered, routes can be configured in each Transit Gateway's route table to enable seamless communication between the VPCs in both regions.

A. Creating VPN attachments over the public internet does not maximize bandwidth or minimize latency compared to using the AWS global network. It also introduces more management overhead.

C. A self-managed VPN server on EC2 instances introduces significant operational overhead for patching, scaling, and maintaining high availability, and it would not perform as well as a native AWS managed service.

D. A VPC can only be attached to a Transit Gateway that exists in the same AWS Region. This option describes a technically impossible configuration.

1. AWS Documentation, AWS Transit Gateway, "Transit gateway peering attachments": "Traffic using an inter-region transit gateway peering attachment always travels over the AWS global network and never traverses the public internet. This reduces threat vectors, such as distributed denial of service (DDoS) attacks and common exploits, such as SQL injection and cross-site scripting." This supports the performance and security benefits of peering.

2. AWS Documentation, AWS Transit Gateway, "How transit gateways work": "A transit gateway peering attachment enables you to connect two transit gateways. You can connect transit gateways in the same AWS Region or in different AWS Regions." This confirms the capability described in the correct answer.

3. AWS Documentation, AWS Transit Gateway, "Transit gateway attachments": Under the "VPC attachment" section, it states: "You can attach a VPC to your transit gateway. The VPC and the transit gateway must be in the same Region." This directly invalidates option D.

4. AWS Whitepaper, "Building a Scalable and Secure Multi-VPC AWS Network Infrastructure" (June 2020): On page 18, it discusses inter-region connectivity, stating, "AWS Transit Gateway now supports the ability to establish peering connections between Transit Gateways in different AWS Regions. This allows you to extend your connectivity and build global networks..." This highlights peering as the intended solution for this use case.

The question requires a solution for a High-Performance Computing (HPC) workload with high-throughput (100 Gbps) and low-latency requirements. The optimal architecture for this is a cluster placement group, which co-locates instances on the same rack within a single Availability Zone to provide the lowest possible inter-node latency. The Elastic Fabric Adapter (EFA) is a network interface specifically designed for HPC and machine learning. It uses OS-bypass and the Scalable Reliable Datagram (SRD) protocol to deliver lower, more consistent latency and higher throughput than standard TCP/IP communication over an Elastic Network Adapter (ENA), making it essential for tightly-coupled HPC applications.

B: A spread placement group is designed for high availability by placing instances on distinct hardware, which increases latency and is counterproductive for HPC.

C: Routing traffic between VPCs via AWS Transit Gateway introduces significant network latency, making it unsuitable for tightly-coupled, low-latency HPC workloads.

D: A cluster placement group cannot span multiple Availability Zones. Its purpose is to group instances physically close together, which is only possible within a single AZ.

1. AWS Documentation, Amazon EC2 User Guide for Linux Instances, "Placement groups": "A cluster placement group is a logical grouping of instances within a single Availability Zone. ... This strategy enables workloads to achieve the low-latency network performance necessary for tightly-coupled node-to-node communication that is typical of HPC applications." This supports the use of a cluster placement group in a single AZ.

2. AWS Documentation, Amazon EC2 User Guide for Linux Instances, "Elastic Fabric Adapter": "An Elastic Fabric Adapter (EFA) is a network device that you can attach to your Amazon EC2 instance to accelerate High Performance Computing (HPC) and machine learning applications. EFA enables you to achieve the application performance of an on-premises HPC cluster, with the scalability, flexibility, and elasticity of the AWS Cloud." This confirms EFA is the correct network adapter.

3. AWS Documentation, Amazon EC2 User Guide for Linux Instances, "EFA basics": "To take full advantage of the EFA capabilities for tightly-coupled applications, launch all of your EFA-enabled instances in the same cluster placement group." This reference explicitly recommends the combination of EFA and cluster placement groups, as described in the correct answer.