Free ANS-C01 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

This solution establishes a centrally managed, shared network environment. The first step is creating a dual-stack VPC with both IPv4 and IPv6 CIDR blocks and correctly sized subnets (A). Next, to allow other teams in the workload account to use this network, the subnets must be shared using AWS Resource Access Manager (RAM) within the AWS Organization (C). Finally, to provide comprehensive dual-stack internet connectivity, an Internet Gateway (for bidirectional traffic), NAT Gateways (for IPv4 outbound), and an Egress-Only Internet Gateway (for IPv6 outbound) are required, along with the necessary route table updates (E). This combination meets all specified requirements for central management, resource sharing, and dual-stack connectivity.

B. While using an Amazon-provided IPv6 CIDR is valid, option A describes an equally valid and specific configuration that forms a complete solution when combined with C and E.

D. AWS VPC sharing is accomplished by sharing subnets via AWS RAM, not by sharing the VPC object itself. Accounts need access to subnets to launch resources.

F. This option is outdated and incomplete. It proposes NAT instances instead of managed NAT Gateways and omits the essential Egress-Only Internet Gateway required for IPv6 outbound traffic.

1. VPC and Subnet Sizing: AWS Documentation, "VPC and subnet sizing for IPv6". This guide confirms that /56 is the standard IPv6 CIDR block size for a VPC and /64 is the fixed size for subnets.

Source: AWS Documentation > Amazon VPC > User Guide > IP addressing for your VPCs and subnets > VPC and subnet sizing for IPv6.

2. VPC Sharing with AWS RAM: AWS Documentation, "Share your VPC with other accounts". This document explicitly states, "To share your VPC, you share one or more subnets with other AWS accounts... You cannot share a VPC in its entirety." This supports option C and invalidates option D.

Source: AWS Documentation > Amazon VPC > User Guide > Build a VPC > Share your VPC with other accounts.

3. Dual-Stack Internet Connectivity: AWS Documentation, "Networking in your dual-stack VPC". This page details the required components for internet access: an Internet Gateway for public subnets, NAT Gateways for IPv4 outbound from private subnets, and an Egress-Only Internet Gateway for IPv6 outbound from private subnets. This supports option E.

Source: AWS Documentation > Amazon VPC > User Guide > IP addressing for your VPCs and subnets > Dual-stack VPCs > Networking in your dual-stack VPC.

4. NAT Gateways vs. NAT Instances: AWS Documentation, "Compare NAT gateways and NAT instances". This document recommends using NAT gateways over NAT instances for better availability, higher bandwidth, and reduced administrative effort, making option E superior to F.

Source: AWS Documentation > Amazon VPC > User Guide > NAT > Compare NAT gateways and NAT instances.

The core requirements are end-to-end encryption terminated on the Amazon EC2 instances and session affinity. A Network Load Balancer (NLB) operating at the transport layer (Layer 4) is required to meet these needs. By configuring a TCP listener on port 443, the NLB passes the encrypted traffic directly to the target EC2 instances without decrypting it. This allows the TLS session to be terminated on the EC2 instances themselves, fulfilling the end-to-end encryption requirement using the application's certificate. The NLB's session affinity (sticky sessions) feature ensures that subsequent requests from the same client are routed to the same EC2 instance, satisfying the session persistence requirement.

B. An Application Load Balancer (ALB) with an HTTPS listener terminates the TLS connection at the load balancer, not the EC2 instance. Forwarding traffic via HTTP to the targets breaks the end-to-end encryption requirement.

C. A Network Load Balancer with a TLS listener terminates the TLS connection at the load balancer. This contradicts the requirement for the connection to be encrypted all the way to the application on the EC2 instance.

D. This configuration is invalid. An Application Load Balancer cannot have an HTTP listener on port 443. An HTTPS listener is required for encrypted traffic, which would terminate TLS at the load balancer, failing the end-to-end encryption requirement.

1. AWS Documentation, Elastic Load Balancing User Guide for Network Load Balancers: "Listeners for your Network Load Balancer". It states, "If you configure a TCP listener on port 443, the load balancer passes the request to the targets without decryption. The targets are responsible for decrypting the traffic." This directly supports the pass-through mechanism described in option A for end-to-end encryption.

2. AWS Documentation, Elastic Load Balancing User Guide for Network Load Balancers: "Sticky sessions for your Network Load Balancer". The documentation confirms, "By default, a Network Load Balancer routes each request independently to a registered target... If you enable sticky sessions, the requests from a client are sent to the same target." This supports the session affinity requirement.

3. AWS Documentation, Elastic Load Balancing User Guide for Application Load Balancers: "Listeners for your Application Load Balancers". It details that for an HTTPS listener, "Elastic Load Balancing uses a server certificate to terminate the front-end connection and then to decrypt requests from clients before sending them to the targets." This confirms that ALBs (Options B and D) terminate encryption, violating the requirement.

4. AWS Documentation, Elastic Load Balancing User Guide for Network Load Balancers: "TLS listeners for your Network Load Balancer". It specifies, "To use a TLS listener, you must deploy a server certificate on your load balancer. The load balancer uses this certificate to terminate the connection and decrypt requests from clients before sending them to targets." This confirms that an NLB with a TLS listener (Option C) also terminates encryption.

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.

An AWS Site-to-Site VPN connection is configured to carry either IPv4 or IPv6 traffic inside the tunnel, but not both simultaneously. This is determined by the InsideIpVersion parameter, which is immutable after the VPN connection is created. To support the new IPv6 workloads while maintaining the existing IPv4 connectivity, a new, separate Site-to-Site VPN connection must be created specifically for IPv6 traffic. This new connection will have its InsideIpVersion parameter set to ipv6. This is the standard AWS-managed approach and represents the least operational overhead compared to building and maintaining a custom solution.

B. A self-managed EC2 instance for VPN introduces significant operational overhead for patching, high availability, and management, which contradicts the requirement for the least overhead.

C. The traffic version (IPv4 or IPv6) inside a VPN tunnel is an immutable property. An existing Site-to-Site VPN connection cannot be updated to change this setting.

D. The customer gateway's public IP address is for the tunnel's outer encapsulation. Changing it does not affect the type of traffic (IPv4 vs. IPv6) allowed inside the tunnel.

1. AWS Site-to-Site VPN User Guide: In the section "IPv6 traffic over a Site-to-Site VPN connection," the documentation states, "A single Site-to-Site VPN connection tunnel supports either IPv4 or IPv6 traffic, but not both at the same time. To support both IPv4 and IPv6 traffic, create a Site-to-Site VPN connection for IPv4 traffic, and a separate Site-to-Site VPN connection for IPv6 traffic."

2. Amazon EC2 API Reference, CreateVpnConnection: The documentation for this API call specifies the VpnTunnelOptions parameter, which includes InsideIpVersion. This parameter must be set to ipv4 or ipv6 at the time of creation.

3. Amazon EC2 API Reference, ModifyVpnConnection: The documentation for modifying a VPN connection does not list InsideIpVersion or its parent VpnTunnelOptions as a modifiable parameter, confirming its immutability after creation.

The requirement is that all traffic "must be encrypted at all times." This mandates a configuration that strictly enforces encryption and prevents unencrypted traffic flow. MACsec is a point-to-point Layer 2 encryption protocol, requiring configuration on both the on-premises device and the AWS Direct Connect endpoint.

First, the same MACsec secret key (CKN/CAK pair) must be configured on the company's on-premises router to match the key generated in AWS (Option A).

Second, on the AWS side, the CKN/CAK pair must be associated with the Direct Connect connection. To meet the strict encryption requirement, the MACsec mode must be set to mustencrypt. This mode ensures that the connection will be down if a secure MACsec session is not established, thereby preventing any unencrypted traffic. The logical operational sequence is to associate the key first and then update the encryption mode (Option D).

B: While the actions are correct, the order is less logical. Associating the key before enforcing a strict encryption mode is the standard procedure to prevent configuration-related link failures.

C: The shouldencrypt mode is incorrect because it allows unencrypted traffic if MACsec negotiation fails, which violates the requirement that traffic "must be encrypted at all times."

E: The shouldencrypt mode does not meet the strict requirement for mandatory encryption, as it permits the connection to pass unencrypted traffic if a secure session is not established.

1. AWS Direct Connect User Guide, "MACsec" section: This document outlines the configuration steps and encryption modes. It states, "To enable MACsec, you must do the following: ... 2. Associate the MACsec secret key with a connection. 3. Configure your on-premises device." This supports the actions in options A and D.

2. AWS Direct Connect User Guide, "MACsec" section, under "Encryption modes": The guide defines the modes: "mustencrypt – The connection is down if the MACsec session is not established. shouldencrypt – The connection is up even if the MACsec session is not established. Traffic will flow unencrypted." This confirms that mustencrypt is the only mode that satisfies the question's strict requirement.

3. AWS CLI Command Reference, directconnect, update-connection: The documentation for the update-connection command shows that encryptionMode is a parameter that can be set to mustencrypt or shouldencrypt. This is a separate action from associating the key using the associate-mac-sec-key command, supporting the sequence described in option D.

The requirement is to perform content inspection on all network traffic from a fleet of EC2 instances. This necessitates capturing the actual packet data, not just metadata. VPC Traffic Mirroring is the AWS feature designed for this purpose. It copies network traffic from a source (the EC2 instances' network interfaces) and sends it to a target for analysis. A Network Load Balancer (NLB) is a valid and scalable target for a mirror session, allowing traffic to be distributed to a fleet of inspection appliances. This setup directly meets the requirement for centralized content inspection.

A. VPC Flow Logs capture metadata about IP traffic (e.g., source/destination IPs, ports, packet count), not the actual packet content, making them unsuitable for content inspection.

C. Amazon Data Firehose is not a valid target for a VPC Traffic Mirroring session. The supported targets are a network interface or a Network Load Balancer.

D. This option also relies on VPC Flow Logs, which, as stated for option A, do not contain the packet payload required for content inspection.

1. AWS Documentation, VPC User Guide, "Traffic mirroring": "Traffic mirroring is an Amazon VPC feature that you can use to copy network traffic from an elastic network interface of an Amazon EC2 instance. You can then send the traffic to out-of-band security and monitoring appliances for deep packet inspection, content inspection, threat monitoring, and troubleshooting."

2. AWS Documentation, VPC User Guide, "Traffic mirroring targets": This section explicitly lists the valid targets for mirrored traffic. It states, "You can send the mirrored traffic to the following targets: A network interface [or] A Network Load Balancer that has a UDP listener." This confirms that an NLB is a supported target.

3. AWS Documentation, VPC User Guide, "VPC Flow Logs": "Flow logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC... Flow log data does not capture the contents of the traffic." This confirms that flow logs are insufficient for content inspection.

Bidirectional Forwarding Detection (BFD) is a network protocol designed for rapid detection of path failures. When used with BGP over a Direct Connect connection, BFD can detect a failure in the path in under a second, compared to the default BGP hold-down timer which can take 90 seconds or more. This allows for near-instantaneous failover to the secondary connection. According to AWS documentation, asynchronous BFD is automatically enabled on the AWS side of a Direct Connect virtual interface when it is configured on the customer's on-premises router. Therefore, configuring BFD on the on-premises router is the direct action that implements this high-speed failover mechanism, providing the largest reduction in failover time.

A. Reducing the BGP hold-down timer improves failover time but is still measured in multiple seconds and is significantly slower than BFD's sub-second detection.

B. A CloudWatch alarm and Lambda function approach is reactive and introduces significant latency from detection, alarm state change, and function invocation, resulting in a failover time of minutes.

C. While BFD must be active on the AWS side, this is enabled automatically in response to the on-premises router configuration. Therefore, this option is less precise than D.

1. AWS Direct Connect User Guide, "Bidirectional Forwarding Detection (BFD)" section: "BFD liveness detection provides a faster detection of path failures than BGP timers... Asynchronous BFD is automatically enabled for Direct Connect virtual interfaces on the AWS side when you enable it on your router." This confirms that BFD is the fastest method and the primary configuration step is on the on-premises equipment.

2. AWS Direct Connect User Guide, "Bidirectional Forwarding Detection (BFD)" section: "We recommend that you configure the BFD liveness detection minimum interval to 300, and the BFD liveness detection multiplier to 3." This configuration results in a detection time of less than one second (300ms 3 = 900ms), a significant reduction from the default BGP hold timer of 90 seconds.

3. AWS Blog, "AWS Direct Connect introduces Bidirectional Forwarding Detection (BFD) for faster failover" (Nov 19, 2019): "With BFD, path failure detection time can be reduced to less than a second, compared to the default BGP convergence time of three minutes, or 180 seconds." This highlights the magnitude of the failover time reduction provided by BFD.

The primary requirement is to find the lowest-cost solution for high-volume data transfer between VPCs. VPC Peering offers the most cost-effective data transfer rates. Data transferred over a VPC peering connection within the same Availability Zone (AZ) is free. By using the zonal DNS names of the Network Load Balancers (NLBs) in the services VPCs, the front-end application can explicitly send traffic to the NLB node located in the same AZ as the source pod. This strategy eliminates cross-AZ data transfer charges, which would be substantial given the 10 TB of monthly traffic. This makes VPC Peering the most economical choice compared to AWS Transit Gateway or AWS PrivateLink, both of which incur mandatory data processing fees regardless of the AZ.

A. A transit gateway incurs a data processing fee of $0.02 per GB, which is double the cost of cross-AZ VPC peering and significantly more expensive than same-AZ peering (which is free).

B. AWS PrivateLink has hourly costs for each VPC endpoint in each AZ, in addition to a data processing fee of $0.01 per GB. This makes it more expensive than the free same-AZ VPC peering option.

D. A transit gateway is inherently more expensive for data processing. Using Regional DNS names would distribute traffic across all AZs, guaranteeing cross-AZ data transfer costs, which contradicts the goal of minimizing cost.

1. Amazon EC2 On-Demand Pricing - Data Transfer: Under the "Data Transfer" section, it specifies the costs for data transfer via "Amazon VPC Peering". It explicitly states that for traffic within the same AWS Region, data transfer within the "Same Availability Zone" is "$0.00 per GB". Data transfer to a "Different Availability Zone" is "$0.01 per GB". This confirms that keeping traffic in the same AZ via peering is free. (Source: Official AWS EC2 Pricing Documentation).

2. AWS Transit Gateway Pricing: This page details that Transit Gateway has a "$0.02 per GB of data processed" fee, in addition to hourly attachment costs. This is demonstrably more expensive than the VPC peering model for this use case. (Source: Official AWS Transit Gateway Pricing Documentation).

3. AWS PrivateLink Pricing: This page shows that PrivateLink has a "$0.01 per GB for data processed" fee and an hourly charge for each VPC Endpoint. The combination of these costs makes it more expensive than same-AZ VPC peering. (Source: Official AWS PrivateLink Pricing Documentation).

4. Elastic Load Balancing User Guide - Load balancer DNS names: The documentation for Network Load Balancers states: "For each Availability Zone that you enable for your load balancer, the load balancer node in that zone uses a zonal DNS name... If you need to target a load balancer node in a specific zone, you can use its zonal DNS name." This confirms the technical validity of the strategy proposed in the correct answer. (Source: AWS Elastic Load Balancing User Guide, section on DNS names).

This solution requires two components: a deployment mechanism and an application design pattern.

Option C, using a CDK pipeline, provides the ideal deployment mechanism. CDK Pipelines (built on AWS CodePipeline) are purpose-built to automate deployments across multiple stages, which can be configured for different AWS accounts and Regions. This creates a consistent, repeatable process with the least manual effort, as deployments are triggered automatically from a source code repository.

Option B provides the best application design pattern. To be reusable, the CDK code should not contain hardcoded resource IDs. By using context methods like Vpc.fromLookup(), the CDK application can dynamically discover the IDs of existing resources (like VPCs and hosted zones) in the target account and Region during the synthesis stage. This makes the stack portable across any environment.

A. Using CloudFormation parameters is less dynamic than CDK context lookups for discovering existing resources and often requires more manual configuration per deployment.

D. A custom script is a less robust, less secure, and less manageable solution than a native, fully managed CDK Pipeline for CI/CD.

E. This describes a manual deployment process. Running cdk deploy with flags locally for each environment directly contradicts the requirement for automation and least manual effort.

1. AWS CDK Developer Guide, "CDK Pipelines: Continuous delivery for AWS CDK applications": This guide explains that CDK Pipelines are the recommended way to set up a robust, multi-account, multi-Region continuous deployment pipeline for CDK applications, which minimizes manual deployment steps. (Supports Option C).

2. AWS CDK Developer Guide, "Runtime context": This section details context providers. It states, "The AWS CDK can retrieve context from the AWS environment during synthesis." This includes looking up existing VPCs, Availability Zones, and Route 53 Hosted Zones, which is the mechanism described in Option B.

3. AWS CDK API Reference, awsec2.Vpc.fromLookup() method: The documentation for this static method explicitly states it is used to "Import a VPC from another stack or from the same stack by looking it up in the target account." This directly supports the lookup approach in Option B for using pre-existing network components.

4. AWS CDK Developer Guide, "Environments": This document clarifies that a CDK stack is deployed to a specific environment (account and Region). It explains how the CDK determines this context at runtime, which is essential for the context lookups in Option B to function correctly within the pipeline stages from Option C.

The requirement is to analyze logs from AWS WAF using Amazon Athena. To do this, the WAF logs must be stored in an Amazon S3 bucket, as Athena queries data directly in S3. The standard and recommended method for exporting AWS WAF logs is to configure the web ACL to send log data to an Amazon Kinesis Data Firehose delivery stream. This delivery stream can then be configured to deliver the logs to an S3 bucket in a format suitable for analysis. Once the logs are in S3, an Athena table can be created to query and analyze the WAF-detected attack patterns.

A. VPC flow logs capture IP traffic information for network interfaces. They do not contain the application-layer details of AWS WAF rule evaluations or actions, which are necessary to analyze attacks.

B. AWS CloudTrail logs API activity within your AWS account. It records actions like creating or modifying a web ACL, but not the web requests that the WAF inspects.

D. Application Load Balancer (ALB) access logs record details about requests sent to the ALB. However, in this architecture, WAF is associated with CloudFront, so it will block malicious requests at the edge before they even reach the ALB. Furthermore, ALB logs do not contain WAF-specific fields like ruleGroupId or action.

1. AWS WAF Developer Guide, Logging and monitoring web ACL traffic: "To enable logging, you configure your web ACL to send the logs to an Amazon Kinesis Data Firehose data stream... Kinesis Data Firehose can deliver your web ACL traffic logs to a number of destinations. This guide provides instructions for Amazon S3." This document outlines the exact process described in the correct answer.

2. AWS Documentation, Amazon Athena User Guide, Querying AWS WAF logs: "AWS WAF is a web application firewall that lets you monitor HTTP and HTTPS requests that are forwarded to an Amazon API Gateway API, Amazon CloudFront, or an Application Load Balancer. You can use Athena to query AWS WAF logs." The guide presupposes that logging has been configured to deliver logs to S3, typically via Kinesis Data Firehose.

3. AWS Security Blog, "How to analyze AWS WAF logs using Amazon Athena and Amazon QuickSight": This official blog post details the architecture for analysis: "This post shows you how to set up an analysis solution for AWS WAF logs. The solution uses Amazon Kinesis Data Firehose to deliver logs to Amazon Simple Storage Service (Amazon S3). From there, you can use Amazon Athena to query the logs..." This directly supports option C as the correct solution.

:

This solution meets all requirements for high availability, multi-region connectivity, and encrypted access to both private (VPC) and public (Amazon S3) resources.

Option B addresses the high availability requirement by establishing redundant AWS Direct Connect (DX) connections, one from each of the two on-premises data centers. This eliminates the DX connection as a single point of failure.

Option D correctly configures the logical connectivity. A public virtual interface (VIF) is required to access public AWS service endpoints like Amazon S3 over a DX connection. To meet the encryption requirement for traffic to the VPCs, an AWS Site-to-Site VPN is established over the public VIF. This creates an encrypted tunnel from the on-premises data centers to the Virtual Private Gateways (VGWs) or Transit Gateways (TGWs) in the AWS Regions.

A. A private VIF is used to access private IP addresses within a VPC and cannot be used to directly access public AWS service endpoints like Amazon S3.

C. A single Direct Connect connection from only one data center does not satisfy the high availability requirement, as it creates a single point of failure.

E. A transit VIF is used exclusively to connect a Direct Connect Gateway to a Transit Gateway for VPC access; it cannot be used to access public services like Amazon S3.

1. AWS Direct Connect User Guide, Resiliency Recommendations: "For critical workloads, we recommend that you have connections at more than one location. [...] You can achieve high availability by using separate connections that terminate on separate devices in more than one location." This supports establishing a DX connection from each data center (Option B).

2. AWS Direct Connect User Guide, Virtual interface types: "Public virtual interface: Access all AWS public services using public IP addresses." This documentation confirms that a public VIF is the correct choice for accessing Amazon S3 (supporting Option D).

3. AWS Direct Connect User Guide, AWS Direct Connect and VPN: "You can configure an AWS Site-to-Site VPN connection to use a public virtual interface to establish a secure, private session. This combination offers the benefits of a connection with higher bandwidth and a more consistent network experience than an internet-based VPN connection." This directly validates the pattern of using a Site-to-Site VPN over a public VIF for encrypted communication (supporting Option D).

4. AWS Direct Connect User Guide, Direct Connect gateways: "You can use a Direct Connect gateway to connect your AWS Direct Connect connection over a private virtual interface to one or more VPCs in your account that are located in the same or different Regions." While not an answer choice, this concept is relevant to how the multi-region VPC access would be implemented underneath the VPN layer. The VPN itself can terminate in any region over the public VIF.

This solution provides the most scalable, secure, and operationally efficient architecture for a SaaS provider. AWS PrivateLink is purpose-built for this use case, allowing hundreds of AWS customers to connect to the SaaS application privately and securely from their own VPCs. It creates a private endpoint in the customer's VPC, eliminating the need for VPC peering, internet gateways, or complex routing tables. This directly solves the stated problem of managing complex routing and NAT. For on-premises customers, terminating IPsec VPN connections is the required method, and using a routing appliance or an AWS Transit Gateway/Virtual Private Gateway are all viable ways to achieve this.

A. While Transit Gateway can connect hundreds of VPCs and VPNs, it is less ideal than PrivateLink for this SaaS use case as it still requires the provider to manage routing and segmentation between all connected customers.

C. VPC peering is not a scalable solution for "hundreds of customers" due to hard limits on the number of peering connections per VPC and the operational complexity of managing CIDR conflicts and individual connections.

D. Using Site-to-Site VPN for connectivity between customer VPCs and the SaaS VPC is inefficient, adds unnecessary encryption overhead, and complicates network management compared to native AWS private connectivity options.

1. AWS PrivateLink Developer Guide, "What is AWS PrivateLink?": The documentation states, "You can make your service, hosted in your own Amazon VPC, available to other AWS customers... This is referred to as an endpoint service... Your service consumers can create a connection from their VPC to your endpoint service... using an interface VPC endpoint." This describes the exact pattern for the SaaS provider and its AWS customers.

2. AWS Whitepaper, "SaaS Lens - AWS Well-Architected Framework", Page 21: Under the "Networking and Connectivity" section, the whitepaper recommends, "AWS PrivateLink is a highly secure and scalable technology that enables you to privately expose your SaaS service to customers on the AWS network... This approach simplifies the network architecture for your customers, and removes the need for an Internet Gateway, NAT devices, or firewall rules to allow traffic from the customer VPC." This directly supports the choice of PrivateLink to solve the scenario's challenges.

3. Amazon VPC User Guide, "VPC peering basics and limitations": The guide notes, "A VPC has a limit on the number of active and pending VPC peering connections that it can have." The default limit is 50, and the maximum is 125, which makes peering unsuitable for "hundreds of customers."

4. AWS Documentation, "Transit Gateway use cases": Transit Gateway is described as a "network transit hub" to interconnect VPCs and on-premises networks. While powerful, it is a general-purpose networking tool. For the specific SaaS provider-to-consumer model, PrivateLink offers superior isolation and operational simplicity by abstracting the network layer entirely.

Amazon VPC IP Address Manager (IPAM) is a managed service specifically designed to plan, track, and monitor IP addresses for AWS workloads. By creating pools in IPAM and enabling auto-import, IPAM automatically discovers and tracks the IP address usage of existing VPCs and subnets. IPAM natively publishes utilization metrics to Amazon CloudWatch. Configuring a CloudWatch alarm on the IPAM pool's utilization metric is the most direct and efficient method to trigger an Amazon Simple Notification Service (Amazon SNS) notification when a specific threshold is breached. This approach provides a fully managed monitoring and alerting solution, fulfilling the requirements with the least operational overhead.

B. This solution requires developing, deploying, and maintaining a custom AWS Lambda function and associated logging/metric filtering, which creates significantly more operational overhead than using the purpose-built IPAM service.

C. Similar to option B, this approach relies on a custom Lambda function. While publishing custom metrics is more direct than logging, it still constitutes a custom-built solution with higher operational overhead than the managed IPAM service.

D. While IPAM is the correct service, Amazon EventBridge is primarily for event-driven architectures that react to state changes (e.g., a pool's state changes to 'depleted'). For continuous monitoring against a specific numeric threshold, Amazon CloudWatch alarms are the more appropriate and direct tool.

1. AWS Documentation, VPC IP Address Manager (IPAM) User Guide, "Monitor IP address usage with IPAM": "VPC IPAM makes it easier for you to monitor IP address usage throughout your network and provides alerts when there is a potential for IP address exhaustion." This confirms IPAM is the purpose-built service for the scenario.

2. AWS Documentation, VPC IP Address Manager (IPAM) User Guide, "Monitor IPAM metrics using CloudWatch": This section details the metrics that IPAM sends to CloudWatch, including IpamPoolAllocation, which represents the percentage of the pool's address space that is allocated. It explicitly states, "You can use these metrics to set up alarms that notify you when you're close to exhausting the address space in a pool." This directly supports the solution in option A.

3. AWS Documentation, Amazon CloudWatch User Guide, "Using Amazon CloudWatch alarms": "You can create a CloudWatch alarm that watches a single CloudWatch metric... If the metric breaches the threshold for a specified number of evaluation periods, the alarm performs one or more actions," such as sending a notification to an SNS topic. This confirms the mechanism described in option A is the standard and intended method for threshold-based alerting.

4. AWS Well-Architected Framework, "Operational Excellence Pillar" (Whitepaper), Design Principle OPS 8: "Use managed services to reduce the operational burden of managing physical or virtual servers." This principle supports choosing a managed service like IPAM over a custom solution involving Lambda functions (as in options B and C) to minimize operational overhead.

The question requires improving the network performance of a security appliance running on a single Amazon EC2 instance. The most direct methods to enhance an EC2 instance's network capabilities are by selecting an instance type with better underlying hardware features and by scaling it vertically.

Using an EC2 instance that supports enhanced networking (SR-IOV) provides significantly higher packets per second (PPS), lower inter-instance latency, and less network jitter. Increasing the EC2 instance size directly correlates to higher available network bandwidth. Larger instance types are allocated a greater share of network capacity, which is crucial for a device acting as a network chokepoint for all outbound traffic.

B. Send outbound traffic through a transit gateway.

A transit gateway is a network transit hub for interconnecting VPCs and on-premises networks. It simplifies routing but does not inherently increase the network performance of the EC2 security appliance itself.

D. Place the EC2 instance in a placement group within the VPC.

Placement groups optimize network performance between instances within the group. This does not improve performance for traffic flowing from the instance to an external location like an on-premises data center.

E. Attach multiple elastic network interfaces to the EC2 instance.

The total network bandwidth for an EC2 instance is determined by its type, not the number of network interfaces. Multiple ENIs do not increase the aggregate throughput of the instance.

1. Amazon EC2 Documentation - Enhanced networking on Linux: "Enhanced networking uses single root I/O virtualization (SR-IOV) to provide high-performance networking capabilities on supported instance types. SR-IOV is a method of device virtualization that provides higher I/O performance and lower CPU utilization when compared to traditional virtualized network interfaces." (Source: AWS Documentation, Enhanced networking on Linux, Section: "Enhanced networking").

2. Amazon EC2 Documentation - Amazon EC2 instance types: The instance type specifications clearly show that network bandwidth scales with instance size. For example, for M5 instances, m5.large has "Up to 10 Gbps" while m5.24xlarge has "100 Gbps". This demonstrates the direct relationship between instance size and network performance. (Source: AWS Documentation, Amazon EC2 Instance Types, Section: "General Purpose").

3. Amazon EC2 Documentation - Placement groups: "A cluster placement group is a logical grouping of instances within a single Availability Zone. ... A cluster placement group is recommended for applications that benefit from low network latency, high network throughput, or both, and if the majority of the network traffic is between the instances in the group." (Source: AWS Documentation, Placement groups, Section: "Cluster placement groups").

The most efficient solution with minimal changes is to establish a Transit Gateway (TGW) peering connection. TGW peering is a feature designed specifically to connect two Transit Gateways, enabling routing between their respective networks. Since both the company's TGW (TGW-C) and the partner's TGW (TGW-P) are in the same AWS Region (us-east-1), an intra-region peering attachment can be created. This approach allows both organizations to maintain their independent network architectures and routing domains while enabling secure, high-bandwidth connectivity. The process involves creating a peering request from one TGW, accepting it from the other, and then updating the TGW route tables to direct traffic over the peering connection.

A. This describes a complex "transit VPC" pattern. It requires deploying and managing a third-party router, which is significantly more complex and costly than using the native TGW peering feature.

B. An IPsec VPN is a viable but suboptimal solution. It introduces encryption overhead and typically has lower bandwidth limits compared to a TGW peering connection, which is the purpose-built, higher-performance option for this scenario.

D. This would force the partner to abandon their own Transit Gateway (TGW-P) and attach their VPCs to the company's TGW. This constitutes a major architectural change for the partner, violating the "minimum changes" requirement.

1. AWS Transit Gateway User Guide - Peering attachments: "You can create a peering attachment between your transit gateways in the same AWS Region... A transit gateway peering attachment enables you to route traffic between the transit gateway route tables." This document explicitly describes the functionality used in the correct answer.

Source: AWS Documentation, Transit Gateway User Guide, "Transit gateway peering attachments".

2. AWS Transit Gateway User Guide - How transit gateways work: This guide explains that Transit Gateway acts as a cloud router to simplify network architectures. The peering feature is an extension of this simplification for inter-TGW communication, making complex workarounds like a router in a separate VPC (Option A) unnecessary.

Source: AWS Documentation, Transit Gateway User Guide, "How transit gateways work".

3. AWS Transit Gateway User Guide - Example: Peered transit gateways: "The owner of TGW A creates a peering attachment... The owner of TGW B accepts the peering attachment request... The owners update their transit gateway route tables to send traffic to the peering attachment." This section details the exact steps required for the solution in option C.

Source: AWS Documentation, Transit Gateway User Guide, "Example: Peered transit gateways".

4. AWS Resource Access Manager (RAM) User Guide - Shareable AWS resources: This document confirms that a Transit Gateway can be shared (as in Option D). However, it clarifies that sharing allows another account to create attachments to the shared TGW, not merge two TGWs. This confirms the mechanism for Option D but highlights why it would require a significant change to the partner's network.

Source: AWS Documentation, AWS RAM User Guide, "Shareable AWS resources".

The primary goal is to route users to the game servers with the optimal response time, which is determined by network latency. Amazon Route 53's latency-based routing policy is specifically designed for this use case. It directs traffic to the AWS Region that provides the lowest network latency for the end user. Route 53 determines the lowest latency region by using a continuously updated database of latency measurements from various parts of the internet to each AWS Region. This ensures that each user is connected to the server that will provide the most responsive gameplay experience, directly addressing the reported problem.

A. Weighted routing distributes traffic based on predefined static ratios, not on real-time user latency, and would not optimize individual user response times.

C. Multivalue answer routing returns multiple records to the client, which does not inherently guarantee a connection to the lowest latency endpoint.

D. Geolocation routing uses the user's geographic origin, which is an approximation for latency but is less precise than direct latency-based measurements.

1. AWS Documentation, Amazon Route 53 Developer Guide: "Latency-based routing lets you route your traffic to the AWS Region that provides the lowest latency... When Route 53 receives a query for your domain... it checks its latency records and determines which AWS Region you're serving your content from that has the lowest latency for that resolver's network." (See section: "Choosing a routing policy," subsection: "Latency-based routing").

2. AWS Documentation, What Is Amazon Route 53?: "Latency-based routing – When your application is hosted in multiple AWS Regions, you can use latency-based routing to route users to the Region that provides the lowest latency." (See section: "How Amazon Route 53 routes traffic for your domains").

3. AWS Whitepaper, Amazon Route 53 and DNS (Page 11): "Latency-based routing policy – Use when you have resources in multiple AWS Regions and you want to route traffic to the Region that provides the best latency." (See section: "Routing Policies").

The root cause of the issue is a lack of high availability in the inspection fleet. With only one inspection instance per Availability Zone (AZ), maintenance on that instance creates a single point of failure for all traffic originating within that AZ. By default, a Gateway Load Balancer (GWLB) only sends traffic to targets within the same AZ.

Deploying an additional inspection instance in each AZ (B) provides intra-AZ redundancy, ensuring that if one instance is down for maintenance, the other can process the traffic.

Enabling cross-zone load balancing (C) provides inter-AZ redundancy. If all inspection instances in one AZ become unhealthy, the GWLB will route traffic to healthy instances in other enabled AZs, preventing session timeouts.

A. Deploying instances in other, unused AZs does not solve the single point of failure within the two AZs where the application and traffic originate.

D. A CPU-based scaling policy addresses performance, not the availability failure described during maintenance. The problem is an insufficient number of instances, not high load.

E. Attaching the GWLB to more AZs is ineffective without also deploying target instances in them or enabling cross-zone load balancing to use targets in other AZs.

1. Elastic Load Balancing User Guide - Cross-zone load balancing for Gateway Load Balancers: "By default, each Gateway Load Balancer node distributes traffic only to the registered targets in its Availability Zone. If you enable cross-zone load balancing, each Gateway Load Balancer node distributes traffic to the registered targets in all enabled Availability Zones." This directly supports option C as a solution for AZ-level target failure.

Source: AWS Documentation, Elastic Load Balancing User Guide, "Gateway Load Balancers", Section: "Cross-zone load balancing".

2. AWS Well-Architected Framework - Reliability Pillar: "Withstand component failure: Ensure that you have a strategy to withstand component failure. For example, you can use redundant components..." Deploying a second inspection instance in each AZ (Option B) is a direct implementation of this principle to achieve high availability.

Source: AWS Well-Architected Framework, Reliability Pillar, Design Principle: "REL 3: How do you design your workload architecture to be highly available?", Section: "Withstand component failure".

3. AWS Blog - Scaling network traffic inspection using AWS Gateway Load Balancer: "For high availability, we recommend deploying the security appliances in an Auto Scaling group, distributed across multiple Availability Zones. You can also enable cross-zone load balancing on your Gateway Load Balancer to distribute traffic across appliances in all Availability Zones." This reference explicitly recommends both deploying multiple appliances per AZ (achieved by Option B) and enabling cross-zone load balancing (Option C) for high availability.

Source: AWS Networking & Content Delivery Blog, "Scaling network traffic inspection using AWS Gateway Load Balancer", November 10, 2020.

The two new VPC CIDRs, 10.0.32.0/21 and 10.0.40.0/21, are contiguous and can be summarized into a single supernet: 10.0.32.0/20. To advertise routes from AWS to an on-premises network via a Direct Connect Gateway (DXGW), the prefixes must be added to the DXGW's "allowed prefixes" list. Since there is only one entry remaining before the prefix list quota is reached, adding the single summary route 10.0.32.0/20 is the only solution that meets all requirements. This allows the DXGW to advertise the summarized route over BGP to the on-premises location, providing connectivity to both new VPCs while consuming only one entry in the list.

A: This requires two entries, violating the quota, and incorrectly refers to "AWS managed prefix lists" instead of the DXGW's allowed prefixes.

B: This requires two entries, which violates the one-entry-remaining quota for the prefix list.

C: This incorrectly refers to "AWS managed prefix lists." The correct mechanism is the Direct Connect Gateway's allowed prefixes list.

1. AWS Documentation, Direct Connect User Guide: "Working with Direct Connect gateways - Allowed prefixes". This section states, "When you specify an allowed prefix list on a Direct Connect gateway, only routes that match the prefixes are advertised over the Border Gateway Protocol (BGP) sessions for the attached transit virtual interfaces... You can summarize the prefixes from the attached VPCs and VPNs." This confirms that using a summarized prefix in the allowed prefixes list is the correct method.

2. AWS Documentation, Direct Connect User Guide: "AWS Direct Connect quotas". This document lists the "Prefixes advertised from a Direct Connect gateway to an on-premises network per BGP session" quota, which is 100 by default. The question's scenario of reaching this quota limit necessitates a strategy like route summarization.

3. AWS Documentation, AWS Transit Gateway User Guide: "Route evaluation order". This document explains how routes are evaluated, but for hybrid connectivity with Direct Connect, the advertisement to on-premises is ultimately controlled by the Direct Connect Gateway's configuration, specifically the allowed prefixes. The TGW propagates its routes to the DXGW, which then filters them.

A private-only VPC with a Site-to-Site VPN is the only design that

1) gives EC2 instances L3 reachability to the on-premises subnets for data sharing,

2) prevents the instances from being reachable from (or egressing directly to) the Internet because the VPC has no internet/NAT gateway, and

3) forwards all Internet-destined traffic (0.0.0.0/0) across the VPN to the on-prem firewall, which can then reach the third-party web application.

Adding the default route to the virtual private gateway in the private-subnet route table satisfies the “all traffic to the Internet must route through the on-premises firewall” requirement.

A. NAT gateway lets instances reach the Internet directly from AWS; violates requirement to send Internet traffic through on-prem firewall.

C. Public subnets plus internet gateway expose the EC2 instances to inbound Internet access; violates “servers must not be accessible from the Internet.”

D. Private subnets lack a default (0.0.0.0/0) route to the virtual private gateway, so instances cannot reach the third-party web app; requirement unmet.

1. “Adding a route for 0.0.0.0/0 to the virtual private gateway forwards all Internet-bound traffic over the Site-to-Site VPN.” – AWS Site-to-Site VPN User Guide, Routing, Section “Add and propagate routes” (2023-10-10).

2. “Instances in a private subnet are not reachable from the Internet when the route table has no path to an internet gateway or NAT device.” – Amazon VPC User Guide, Chapter “Subnet routing,” ‘Private subnet’ example (2023-11-27).

3. AWS Whitepaper: “Hybrid Connectivity Options for Amazon VPC,” Pattern: VPN backhaul of Internet traffic, p.6–7 (2022).

4. Stanford CS244B Lecture Notes, “Enterprise VPN Design – backhauling Internet traffic,” slide 14 (2021).