Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has many application VPCs that use AWS Site-to-Site VPN connections for connectivity to an on-premises location. The company's network team wants to gradually migrate to AWS Transit Gateway to provide VPC-to-VPC connectivity.
The network team sets up a transit gateway that uses equal-cost multi-path (ECMP) routing. The network team attaches two temporary VPCs to the transit gateway for testing. The test VPCs contain Amazon EC2 instances to confirm connectivity over the transit gateway between the on-premises location and the VPCs. The network team creates two new Site-to-Site VPN connections to the transit gateway.
...
To improve the bandwidth performance and minimize network congestion, the network team should focus on optimizing the Site-to-Site VPN connections and ensuring the AWS Transit Gateway is configured properly. Let's analyze each option:
Option A: Enable acceleration for the existing Site-to-Site VPN connections to the transit gateway.
- Enabling AWS VPN acceleration is a feature designed to boost VPN performance, especially for high-throughput traffic. It leverages the AWS global network to reduce latency and increase the available bandwidth for VPN connections.
- Enabling VPN acceleration can improve throughput and reliability, making this a good option to increase the bandwidth of the Site-to-Site VPN connections.
- Accepted: This is a valid approach to improve the VPN connection's performance.
Option B: Create new accelerated Site-to-Site VPN connections to the transit gateway.
- New accelerated Site-to-Site VPN connections would take advantage of the same performance benefits as Option A, but in this case, the team is suggesting creating entirely new connections.
- If the existing VPN connections are already in place and working, creating new accelerated connections can potentially add additional bandwidth, but this may also add complexity, especially in terms of managing multiple VPN connections.
- Accepted: This is a good option if additional bandwidth is needed, though it may require more management effort.
Option C: Advertise the on-premises prefix to AWS with the same BGP AS_PATH attribute across all the Site-to-Site VPN connections.
- The BGP AS_PATH is part of the BGP routing protocol used to determine the best path for routing. However, the AS_PATH attribute itself does not directly affect bandwidth or performance; it’s more related to routing policy and path selection.
- This step would not address bandwidth issues or congestion directly, and the same AS_PATH could potentially lead to suboptimal path selection, rather than improving the bandwidth performance.
- Rejected: This option is not directly related to improving the bandwidth performance over VPN connections.
Option D: Advertise the on-premises prefix to AWS with a different BGP AS_PATH attribute across all t...
Author: Ethan · Last updated May 16, 2026
A company is migrating its on-premises network from its data center in Virginia to its data center in New York. The AWS Direct Connect connections for the Virginia and New York data center locations are both associated to the us-east-1 Region. The company needs to migrate a private VIF on an existing Direct Connect hosted connection from Virginia to New York. The company's on-premises network uses the connection to access VPCs through a Direct Connect gateway in us-east-1.
Th...
To determine the best solution for migrating the Direct Connect connection with the least downtime, let's evaluate the options based on the following factors:
1. Minimizing downtime: The company wants to minimize downtime during the migration.
2. Utilizing existing infrastructure: The company wants to make use of the existing Direct Connect gateway.
3. Ease of implementation: The solution should avoid creating unnecessary complexity.
Option Analysis:
A) Create a new private VIF on the new Direct Connect hosted connection. Create a new Direct Connect gateway and attach the gateway to the new private VIF. Configure BGP routing on the new private VIF as a backup route. Perform the switchover during a maintenance window by shutting down BGP on the existing private VIF. Decommission the existing Direct Connect connection.
- Pros: This approach isolates the new connection by creating a new Direct Connect gateway, and it uses BGP routing to ensure a smooth failover during the switchover.
- Cons: The creation of a new Direct Connect gateway adds complexity, as it involves setting up new configurations. There is also an additional time requirement for setting up and configuring the new gateway and VIF.
- Downtime: Potential for higher downtime since you are setting up a completely new gateway and VIF, and the migration relies on shutting down the existing connection.
B) Create a new private VIF on the new Direct Connect hosted connection. Attach the new private VIF to the existing Direct Connect gateway. Configure BGP routing on the new private VIF as a backup route. Perform the switchover during a maintenance window by shutting down BGP on the existing private VIF. Decommission the existing Direct Connect connection.
- Pros: This option allows leveraging the existing Direct Connect gateway, which can simplify the process and reduce configuration overhead. By configuring BGP routing on the new VIF, you can ensure minimal downtime during the switch.
- Cons: The need to switch BGP routing during a maintenance window still introduces the possibility of temporary downtime, though it should be minimal.
- Downtime: Downtime is minimized with the use of BGP as a backup route during the migration and involves fewer changes than Option A.
...
Author: Oscar · Last updated May 16, 2026
A retail company is migrating its on-premises application to the AWS Cloud. Currently, the company has two on-premises data center locations. One data center is on the east coast of the United States, and one data center is on the west coast.
Each data center hosts four database systems. The largest database system stores 500 GB of data. The data centers are interconnected by two 10 GbE circuits for data synchronization. Each data center has two separate 1 GbE upstream internet connections. The company plans to have eight total VPCs to service its multiple business units. Four VPCs will be in the us-east-1 Region, and four will be in the us-west-2 Region.
A network engineer needs to design a connectivity solution that allows VPC-to-VPC connectivity. The solution must also allow secure connections between the on-premises data centers and AWS dur...
Let's analyze the requirements and each of the options, keeping in mind the company's needs for secure, scalable, and efficient connectivity between on-premises data centers, VPC-to-VPC communication, and a seamless migration process.
Key Requirements:
- VPC-to-VPC Connectivity: The VPCs across the two AWS Regions (us-east-1 and us-west-2) must be able to communicate with each other securely.
- Secure Connections Between On-Premises Data Centers and AWS: During the migration process, data must be securely transferred between the on-premises data centers and AWS.
- Traffic Spikes During Migration: The solution must handle spikes in traffic, particularly during database synchronization.
- Minimizing Long-Term Operational and Human Resources Costs: The company wants a cost-effective and easily manageable solution.
Option Analysis:
A) Deploy one transit gateway and attach all VPCs to it. Update the transit gateway and VPC route tables to allow any VPC to connect to any other VPC.
- Pros: Using a transit gateway simplifies inter-VPC connectivity by acting as a central hub for communication between VPCs in different regions. It's highly scalable and allows for easy routing configuration between VPCs. The transit gateway is well-suited for a multi-region, multi-VPC architecture.
- Cons: Requires the setup of a transit gateway, which introduces some initial configuration overhead.
- Scalability: This solution can scale well to handle spikes in traffic since the transit gateway is designed for large-scale data transfers.
- Why it's a good choice: This option minimizes long-term operational costs because a transit gateway simplifies network management compared to complex peering configurations.
B) Configure VPC peering between all the VPCs. Update the VPC route tables to allow connectivity.
- Pros: VPC peering is relatively straightforward and allows direct connectivity between VPCs.
- Cons: With eight VPCs, configuring peering manually would result in a large number of peering connections (28 pairings), which would become complex to manage and maintain. VPC peering doesn't scale efficiently across regions, and it lacks the central management of a transit gateway.
- Scalability: Managing 28 peering connections as the network grows is inefficient and error-prone, especially with spikes in traffic.
- Why it's rejected: This is a less scalable and manageable solution compared to a transit gateway.
C) Provision two AWS Direct Connect connections from two Direct Connect locations that serve us-east-1 and us-west-2 to provide connectivity between the data centers and AWS.
- Pros: AWS Direct Connect provides a private, dedicated connection with lower latency and more con...
Author: Ella · Last updated May 16, 2026
A company is developing an API-based application on AWS for its process workflow requirements. The API will be invoked by clients in the company's on-premises data centers. The company has set up an AWS Direct Connect connection between on premises and AWS. A network engineer decides to implement the API as a private REST API in Amazon API Gateway. The network engineer wants to ensure that clie...
Key Requirements:
- Private communication: The API must be invoked over private communication from the on-premises data centers via the Direct Connect connection to AWS.
- Minimal additional infrastructure: The solution should not require significant infrastructure changes or additional setup beyond the Direct Connect connection and API Gateway.
- Private REST API: The API is intended to be private, meaning it should not be accessible over the public internet.
Option Analysis:
A) Create an interface VPC endpoint for API Gateway with private DNS names enabled. Access the API by using the private DNS name of the endpoint.
- Pros: This solution is correct because it uses an interface VPC endpoint to allow private connectivity to API Gateway. Enabling private DNS names ensures that clients can reach the private API without routing through the public internet. The VPC endpoint allows traffic to remain within the AWS network, and the private DNS name ensures clients can access the API via the private endpoint without needing any additional DNS configuration.
- Why it works: The private DNS name setup allows seamless access via the Direct Connect connection, keeping the communication private and within the AWS network.
- Why it's a good choice: This option directly addresses the requirement for private communication over Direct Connect and does not require any additional infrastructure.
B) Create an interface VPC endpoint for API Gateway with private DNS names enabled. Access the API by using an Amazon Route 53 alias of the endpoint.
- Pros: The solution utilizes an interface VPC endpoint, and private DNS is enabled. Accessing the API via an Amazon Route 53 alias also allows for custom DNS configurations.
- Cons: Using a Route 53 alias is unnecessary in this case, as the private DNS name functionality already provides direct resolution for ...
Author: Elizabeth · Last updated May 16, 2026
A banking company has an application that must connect to specific public IP addresses from a VPC. A network engineer has configured routes in the route table that is associated with the application's subnet to the required public IP addresses through an internet gateway.
The network engineer needs to set up email notifications that will alert the network engineer when a user adds a default...
Let's evaluate each option based on the need to send email notifications when a default route (0.0.0.0/0) is added to the application subnet's route table pointing to an internet gateway, ensuring minimal implementation effort.
Key Requirements:
- Monitoring default route creation: The network engineer needs to be alerted when a default route (0.0.0.0/0) is added with the internet gateway as the target.
- Minimal implementation effort: The solution should be simple to implement without requiring complex or manual configuration.
- Email notifications: The solution should send email notifications when the specified route is added.
Option Analysis:
A) Create an AWS Lambda function that reads the routes in the route table and sends an email notification. Configure the Lambda function to send an email notification if any route is configured with 0.0.0.0/0 or ::/0 CIDRs to the internet gateway. Configure the Lambda function to run every minute.
- Pros: This approach allows for custom logic to check the routes and send email notifications via the Lambda function. It could detect if the route is added.
- Cons: Running the Lambda function every minute introduces overhead, and the solution is not event-driven. Additionally, polling every minute can introduce unnecessary latency in detecting changes and would require more manual configuration.
- Why it's rejected: The polling approach via Lambda running every minute is inefficient and increases complexity. It's not the most streamlined solution for this requirement.
B) Create an AWS Lambda function that will be invoked by an Amazon EC2 CreateRoute API call. Configure the Lambda function to send an email notification. Configure the Lambda function to send an email notification if any route is configured with 0.0.0.0/0 or ::/0 CIDRs to the internet gateway.
- Pros: This approach leverages an event-driven solution (EC2 CreateRoute API call) to trigger the Lambda function, allowing it to send email notifications in real-time when a route is added.
- Cons: This solution is somewhat complex to configure and depends on tracking API calls, which might require extra effort to ensure it's working properly with route table updates.
- Why it's rejected: While more efficient than polling, this approach might require additional setup to properly track route table modifications triggered by API calls, making it more complex than necessary for this scen...
Author: Rahul · Last updated May 16, 2026
A company is building an internet-facing application that is hosted on an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The company is using the Amazon VPC Container Network Interface (CNI) plugin for Kubernetes for pod networking connectivity. The company needs to expose its application to the internet by using a Network Load Balancer (NLB).
The pods that host the application must have visibility of the s...
Key Requirements:
- Internet-facing application: The application needs to be exposed to the internet via a Network Load Balancer (NLB).
- Source IP visibility: The pods that host the application must have visibility of the source IP address that is contained in the original packet received by the NLB.
- Amazon EKS setup: The solution needs to integrate properly with the Amazon VPC Container Network Interface (CNI) plugin for Kubernetes, which provides networking connectivity to pods.
Option Analysis:
A) Specify the ip target type for the NLB. Set the externalTrafficPolicy attribute to Local in the Kubernetes service specification.
- NLB Configuration: The ip target type is the correct choice when you want to target the pods directly (using IP addresses rather than instances). This is important for the use case of exposing the application at the pod level and ensuring that the source IP of the incoming traffic is preserved.
- Kubernetes Configuration: Setting the externalTrafficPolicy to Local ensures that traffic from the NLB will only be routed to the pods on the same node, preserving the original source IP. This is because Kubernetes will not perform NAT (Network Address Translation) when the traffic is routed locally.
- Why it's selected: This option ensures that the source IP address of the incoming request is preserved, which is a requirement of the company. The use of Local external traffic policy, together with ip target type, directly supports the desired behavior of the application.
B) Specify the instance target type for the NLB. Set the externalTrafficPolicy attribute to Cluster in the Kubernetes service specification.
- NLB Configuration: The instance target type uses EC2 instances as the targets for the NLB, which isn't ideal for this scenario, as the company is using Amazon EKS with pods.
- Kubernetes Configuration: Setting the externalTrafficPolicy to Cluster means that traffic could be forwarded to any pod in the cluster, and the source IP will be lost during NAT. This does not meet the requirement of retaining the original source IP.
- Why it's rejected: U...
Author: Amira · Last updated May 16, 2026
A company is running its application servers on Amazon EC2 instances. The EC2 instances run in separate VPCs that are connected by a transit gateway. The EC2 instances launch in a private subnet with a route to the transit gateway for internal and external connectivity. The external connectivity is provided by a VPC with firewall devices that perform an inspection for packets that ingress and egress through an internet gateway.
A network engineer needs to help the company's applica...
To address the requirement of increasing the payload size per packet delivery between EC2 instances in separate VPCs through the transit gateway, the key factors are:
1. MTU Size Considerations: MTU defines the maximum size of a packet that can be sent over a network link without requiring fragmentation. In this case, the goal is to increase the MTU size for optimal packet delivery.
2. Jumbo Frames Support: Jumbo frames refer to Ethernet frames with an MTU size greater than the standard 1500 bytes (commonly 9001 bytes). In this case, enabling jumbo frames allows larger payloads per packet.
3. Transit Gateway Compatibility: The transit gateway must support larger MTU sizes if jumbo frames are to be used. The MTU setting on the EC2 instance interfaces and the transit gateway must match.
Analysis of each option:
- A) Enable jumbo frames on the transit gateway. Instruct the application team to set the maximum transmission unit (MTU) of the systems network interfaces to 9001 bytes.
- Why this could work: The transit gateway must support jumbo frames to handle larger MTU sizes. By enabling jumbo frames on the...
Author: Kunal · Last updated May 16, 2026
A network engineer needs to monitor internet metrics for an application that is in a VPC. The metrics include user experiences such as health events, latency, and traffic insights.
The network engineer sets up Amazon CloudWatch Internet Monitor for the application. The engineer wants to push the in...
To meet the requirements of monitoring internet metrics, including user experiences like health events, latency, and traffic insights, and pushing these events to a third-party target with the least implementation effort, the key considerations are:
1. Integration with CloudWatch Internet Monitor: The solution must be able to directly capture and send internet health events to an external target (a third-party API).
2. Event Routing and Automation: We need a simple way to route these events without creating too many intermediary steps like additional Lambda functions or manual configurations.
Analysis of each option:
- A) Create a third-party API endpoint in Amazon EventBridge. Configure Internet Monitor to send the events to the third-party API endpoint in EventBridge.
- Why this could work: EventBridge can receive events from Amazon CloudWatch Internet Monitor, which simplifies event handling and routing. However, this option suggests directly configuring the endpoint in EventBridge, which may require some manual intervention for the event source and target setup, potentially adding complexity.
- Why it's less optimal: This option is not as streamlined as other choices, since EventBridge does not have a native, direct integration with Internet Monitor for automatic event forwarding, meaning additional configuration would be required.
- B) Create a third-party API endpoint in Amazon EventBridge. Create a rule in EventBridge that uses Internet Monitor as the source and the third-party API endpoint in EventBridge as the destination.
- Why this could work: This option is more refined compared to Option A. EventBridge allows you to set up event rules that automatically route events to a destination. This approach can directly integrate CloudWatch Internet Monitor as the source and route the events to the third-party API with m...
Author: John · Last updated May 16, 2026
A company has a web application that runs in eight AWS Regions. In each Region, the application is hosted on multiple compute resources behind an Application Load Balancer (ALB).
The different Regions are using different domains. Each ALB is configured to accept only HTTPS traffic. Each ALB uses a certificate from AWS Certificate Manager (ACM).
The company wants to simplify the application's appearance on the web by using a new single domain for all Regions. A network ...
The goal is to simplify the web application’s appearance by using a single domain for all eight AWS Regions, while minimizing latency for end users. Given that each Region has its own ALB and uses HTTPS, and that the company wants to improve user experience by minimizing latency, the best approach would be to use a global solution that can route traffic efficiently across Regions.
Analysis of each option:
- A) Use ACM to create an SSL/TLS certificate in the us-east-1 Region for the new domain.
- Why this could work: ACM certificates are region-specific, and many services (such as CloudFront) can use certificates from ACM to serve content globally. However, the web application is hosted in multiple Regions, and relying on a single ACM certificate in a specific region may not be sufficient for all Regions. It could cause issues with certificate management across different ALBs. Hence, this alone is not a complete solution.
- Why it’s not ideal: The certificate should ideally be available for use across all Regions where the application is deployed, which would require a broader solution than just using a certificate from a single region.
- B) Set up latency-based routing in Amazon Route 53 for the new domain. Add the ALBs from all the Regions as targets.
- Why this works: Latency-based routing in Route 53 allows users to be routed to the ALB that provides the lowest latency, which minimizes delays and improves the overall user experience. This solution leverages AWS's global DNS system and ensures users are always routed to the closest application endpoint.
- Why this is selected: This is a simple yet effective solution to minimize latency for end users. It works well with multiple Regions and uses DNS to intelligently route traffic based on the lowest latency.
- C) Create an alias record for the accelerator in Amazon Route 53 for the new domain.
- Why this could work: Alias records are often used to point a domain to an AWS resource like a CloudFront distribution or an ELB. However, this option mentions an accelerator without further context. While alias records are beneficial, they alone do not specify a method for managing multiple Regions or minimizing latency across them.
- Why it’s not ideal: While an alias record is important for routing, it is not a complete solution for reducing latency across multiple Regions. It doesn’t handle the global traffic routing efficiently.
- D) Create a standard accelerator in AWS Global Accelerator. Configure a li...
Author: Ethan · Last updated May 16, 2026
A company has a VPC that includes application workloads that run on Amazon EC2 instances in a single AWS Region. The company wants to use AWS Local Zones to deploy an extension of the application workloads that run in the Region. The extended workloads in the Local Zone need to communicate bid...
The company's goal is to deploy workloads in AWS Local Zones and have bidirectional communication between those workloads and the workloads in the existing VPC in the Region, while doing so in the most cost-effective manner. Here's a breakdown of the options:
Key considerations:
1. Cost-effectiveness: The solution should avoid introducing unnecessary resources or complexity (such as third-party appliances or redundant VPCs).
2. Direct communication: The Local Zone workloads must communicate with the workloads in the VPC in the Region, and this communication should be low-latency and efficient.
3. AWS-native solutions: Ideally, the solution should leverage AWS-native services without the need for third-party appliances or complex configurations unless necessary.
Analysis of options:
- A) Create a new VPC in the Local Zone. Attach all the VPCs to a transit gateway. Configure routing for the transit gateway and the VPCs. Deploy instances in the new VPC.
- Why it could work: This approach uses a transit gateway to connect the VPC in the Region with the new VPC in the Local Zone, which can enable bidirectional communication.
- Why it's less cost-effective: This solution involves creating a new VPC and a transit gateway, which adds complexity and additional costs for the transit gateway. While it provides good scalability and flexibility, the additional components (a whole new VPC, transit gateway) make this solution over-engineered for a simple communication setup.
- B) Deploy a third-party appliance in a new VPC in the Region. Create a new VPC in the Local Zone. Create VPN connections to the appliance for the VPCs. Deploy instances in the new VPC in the Local Zone.
- Why it could work: The solution suggests deploying a third-party appliance in the Region VPC and creating VPN connections, which would allow communication between the VPCs in the Region and the Local Zone.
- Why it’s not ideal: This introduces unnecessary complexity and cost by deploying a third-party appliance and managing VPN connections. The use of a third-party a...
Author: Henry · Last updated May 16, 2026
A company is using AWS Cloud WAN with one edge location in the us-east-1 Region and one edge location in the us-west-1 Region. A shared services segment exists at both edge locations. Each shared services segment has a VPC attachment to each inspection VPC in each Region. The inspection VPCs inspect traffic from a WAN by using AWS Network Firewall.
The company creates a new segment for a new business unit (BU) in the us-east-1 edge location. The new BU has three VPCs that are attached to the new BU segment. To comply with regulations, the BU VPCs must not communicate with each other. All internet-bound traffic must be inspected in the inspection VPC.
The company updates VPC route tabl...
The company has a business unit (BU) with specific compliance requirements, where traffic between BU VPCs must be isolated, and all internet-bound traffic must be inspected by the inspection VPC. To meet these requirements in an operationally efficient manner, we need to consider the most effective way to enforce traffic isolation and ensure compliance while minimizing complexity.
Key Requirements:
1. VPC Isolation: VPCs in the BU must not communicate with each other.
2. Internet-bound Traffic Inspection: All internet-bound traffic must go through the inspection VPC.
3. Scalability: The solution must allow for easy addition of more VPCs in the BU in the future.
4. Operational Efficiency: The solution should be as simple and automated as possible.
Analysis of Options:
- A) Update the network policy to share the shared services segment with the BU segment.
- Why it's not ideal: Sharing the shared services segment with the BU segment would allow communication between VPCs that might not be needed. Since the BU VPCs need to remain isolated from each other, this approach would break the isolation requirement by potentially enabling traffic between the BU VPCs. This option doesn’t meet the isolation needs.
- B) Create a network policy to share the inspection service segment with the BU segment.
- Why it’s not ideal: Sharing the inspection service segment with the BU segment would enable the BU to send traffic through the inspection VPC. However, this would not directly address the isolation requirement between the BU VPCs themselves. Additionally, it does not simplify the isolation enforcement between VPCs. This solution introduces complexity without fully addressing isolation needs.
- C) Set the isolate-attachments field to True for the BU segment.
- Why this works: Setting `isolate-attachments` to `True` ensures that the VPCs ...
Author: Julian · Last updated May 16, 2026
A company hosts a highly available, scalable, and resilient application on Amazon EC2 instances that are part of an Auto Scaling group. A network engineer is planning to integrate IPv6 support with the application deployment in phases. The first phase is to enable IPv6 service consumption on the public Network Load Balancers (NLBs) that are deployed across the infrastructure. The target groups for the NLBS are configured as the Auto Scaling groups of the EC2 instances that host th...
To determine the cause of the issue, we need to evaluate the potential options based on the scenario where IPv6 queries are not reaching the backend EC2 instances.
Key factors to consider:
- The NLBs are configured for dual-stack operation, which means both IPv4 and IPv6 traffic should be supported.
- The issue is that IPv6 queries are not reaching the backend EC2 instances, indicating that the problem lies somewhere in the path between the IPv6 requests and the EC2 instances.
Let's analyze each option:
A) The subnets where the EC2 instances are deployed do not have IPv6 addresses configured.
- If the EC2 instances do not have IPv6 addresses configured, they would not be able to process IPv6 traffic. However, the NLBs are configured for dual-stack operation, meaning the NLB should still route traffic to any EC2 instances that have IPv6 addresses assigned.
- This option suggests a configuration issue with the EC2 instances themselves, but it doesn't explain why the IPv6 traffic wouldn’t reach the instances if dual-stack is enabled on the NLBs.
B) The route tables for the NLB subnets do not have IPv6 routing configured.
- The route tables associated with the NLB subnets should allow traffic to reach the EC2 instances. However, this issue seems to focus on the NLB side of the traffic path. If the route tables of the NLB subnets did not have IPv6 routing configured, the NLB would not be able to forward traffic to the EC2 instances.
- This is a potential issue, but the NLBs themselves should be able to route traffic corre...
Author: Noah · Last updated May 16, 2026
A company wants to implement a distributed architecture on AWS that uses a Gateway Load Balancer (GWLB) and GWLB endpoints.
The company has chosen a hub-and-spoke model. The model includes a GWLB and virtual appliances that are deployed into a centralized appliance VPC and GWLB endpoints. The model also include...
To correctly answer this question, we need to evaluate the proper sequence of traffic flow in a hub-and-spoke model that uses a Gateway Load Balancer (GWLB) and GWLB endpoints in AWS. This model involves multiple components:
- Spoke VPC: Contains the application that will send traffic to the internet.
- Hub VPC: Hosts the Gateway Load Balancer (GWLB) and the virtual appliances that will inspect and process the traffic.
- GWLB endpoints: Allow traffic from the spoke VPC to reach the GWLB.
- Internet gateway: In each spoke VPC, used for outbound internet access.
Key factors to consider:
- Traffic from the application in the spoke VPC first goes to the GWLB endpoint, based on the route table configuration of the spoke VPC.
- The GWLB then directs the traffic to a virtual appliance in the hub VPC for inspection, such as for security, monitoring, or other purposes.
- After the inspection, the return traffic must flow back through the GWLB endpoint and ultimately exit through the internet gateway to reach the internet.
Analyzing each option:
A) 1. An application in a spoke VPC sends traffic to the GWLB endpoint based on the VPC route table configuration. 2. Traffic is delivered securely and privately to the GWLB. 3. The GWLB sends the traffic to a virtual appliance for inspection. 4. Return traffic flows back to the GWLB endpoint and out to the internet through the internet gateway.
- This sequence is correct. The application in the spoke VPC sends traffic to the GWLB endpoint. The traffic is securely routed to the GWLB and then forwarded to the virtual appliance for inspection. The return traffic follows the same path back to the GWLB endpoint and then exits through the internet gateway.
- This sequence correctly represents the expected traffic flow for outbound internet access via a Gateway Load Balancer setup in a hub-and-spoke model.
B) 1. An application in a spoke VPC sends traffic to the GWLB endpoint based on the VPC route table configuration. 2. Traffic is delivered securely and privately to the GWLB endpoint. 3. The GWLB sets the X-Forwarded-For request header and sends the traffic to a v...
Author: Abigail · Last updated May 16, 2026
A network engineer needs to provide a list of IP addresses that are sending traffic to an Amazon EC2 instance. VPC flow logs are enabled. The EC2 instance has a single network interface and two assigned IP addresses. However, the flow logs are logging traffic only for the primary IP address. The network engineer needs to determine whether any traffic ...
To identify the traffic flow for the second IP address on an EC2 instance, we need to consider how VPC flow logs capture and report traffic. In this case, the goal is to determine whether traffic is being sent to the second IP address of the EC2 instance, which means we need to focus on capturing the destination IP address.
Key factors:
- The VPC flow logs capture traffic metadata such as source IP, destination IP, and other flow-related information.
- By default, VPC flow logs show traffic related to the primary IP address of the EC2 instance.
- To track the traffic destined for the second IP address, we must ensure the flow logs are capturing the correct destination IP address for the traffic sent to that second IP.
Analyzing the options:
A) Create a new flow log that includes the pkt-dstaddr field to capture the original destination IP address of the traffic.
- The pkt-dstaddr field captures the destination IP address of the packet after it has been processed by the VPC router and is useful in identifying the destination IP at a granular level. This field can indeed help identify the second IP address if traffic is being routed to that address.
- This is a good option because it specifically captures the destination IP address at the packet level, which would allow us to track the second IP address of the EC2 instance.
B) Create a new flow log that includes the dstaddr field to capture the original destination IP address of the traffic.
- The dstaddr field provides the destination IP address of the flow, but at a bro...
Author: Maya · Last updated May 16, 2026
A company has configured an AWS Cloud WAN core network with edge locations in the us-east-1 Region and the us-west-1 Region. Each edge location has two segments: development and staging. The segments use the default core network policy.
The company has attached VPCs to the core network. A development VPC is attached to the development segment in us-east-1 and is configured to use the 10.0.0.0/16 CIDR block. A staging VPC is attached to the staging segment in us-west-1 and is configured to use the 10.5.0.0/16 CIDR block. The company has updated the route tables for both VPCs with a route that directs any traffic for 0.0.0.0/0 to the core network.
The company's network team needs to establish communication between ...
To establish communication between the two VPCs using the AWS Cloud WAN core network, let's analyze the given scenario and consider the requirements and possible solutions.
Key factors in the scenario:
- The AWS Cloud WAN core network is used, and there are two edge locations: us-east-1 (development segment) and us-west-1 (staging segment).
- Each VPC is attached to a different segment: development VPC (10.0.0.0/16 CIDR) is in the development segment in us-east-1, and staging VPC (10.5.0.0/16 CIDR) is in the staging segment in us-west-1.
- The VPCs are set up to direct all outbound traffic (0.0.0.0/0) to the core network, but the network team cannot establish communication between the two VPCs.
Analysis of the possible options:
A) Update both VPC route tables to have a new static route. Configure a route on the development VPC to direct the traffic for 10.0.0.0/16 to the development VPC attachment. Configure a route on the staging VPC to direct the traffic for 10.5.0.0/16 to the staging VPC attachment.
- This option suggests configuring static routes on each VPC to direct traffic destined for the local VPC CIDR back to the VPC attachment. However, the issue at hand is inter-VPC communication via Cloud WAN. Each VPC's route table should already have the appropriate routes to direct traffic to the core network for 0.0.0.0/0 (which is working), but additional static routes for local CIDR blocks are unnecessary for the communication between VPCs via Cloud WAN.
- This option doesn’t solve the inter-VPC communication problem; the problem is related to how Cloud WAN routes traffic between segments, not how the local VPC CIDRs are routed.
B) Update the segment filter to allow traffic on the development and staging segments.
- This option seems to suggest updating a segment filter, which could be useful if there are segment-level traffic filtering settings in place. However, there is no mention of a specific segment filter being applied in the initial configuration. The issue here is not about segment filtering; the rout...
Author: VenomousSerpent42 · Last updated May 16, 2026
A company has VPCs in the us-east-1 Region that are connected to each other through a transit gateway. A network engineer needs to establish an AWS Direct Connect connection between the company's on-premises data center and the transit gateway for the migration of a workload.
The Direct Connect connection is UP according to the ConnectionState metric in Amazon CloudWatch. However, the VIF is DOWN. The network engineer has verified the transit VIF and BGP configurations on the on-premises ...
When troubleshooting an issue where the Direct Connect virtual interface (VIF) is DOWN, but the Direct Connect connection is UP, and the network engineer cannot ping the Amazon peer IP address, the following steps should be taken. Let's analyze each option carefully to identify the most relevant troubleshooting steps.
Key factors:
- The Direct Connect ConnectionState metric is UP, which indicates the physical connection between the on-premises router and AWS is established.
- The issue seems to be at the VIF (Virtual Interface) level, preventing successful BGP peering or traffic flow.
- The network engineer is unable to ping the Amazon peer IP address, which suggests a potential configuration or network-layer issue.
Analyzing the options:
A) Verify that the correct IP address and subnet mask are in use for the subinterface on the router.
- This is a critical step. If the IP address or subnet mask on the router's subinterface is misconfigured, the on-premises router will not be able to reach the Amazon peer IP address. This would cause BGP peering to fail or the inability to ping the peer IP, as the router wouldn’t be able to route traffic to the correct destination.
- Selected: This is an important check to ensure that the router configuration matches AWS requirements for Direct Connect.
B) Ensure that VLAN trunking is disabled on the router.
- VLAN trunking allows multiple VLANs to be carried over a single physical connection, but it’s typically not required for Direct Connect configurations that use a single VLAN. AWS Direct Connect typically uses a single VLAN per virtual interface, and trunking should not be enabled on the router.
- However, this is more of a configuration check than a critical step to troubleshoot the inability to ping the peer IP, so it's not as high priority.
C) Verify that the router has a MAC address entry from the AWS endpoint in the Address Resolution Protocol (ARP) table.
- This step is relevant because ARP resolution is essential for devices to communicate on the same subnet. If the on-premises router does not...
Author: Aditya · Last updated May 16, 2026
A logistics company has multiple VPCs in an AWS Region. The company uses a transit gateway to connect the VPCs. The company has several on-premises offices that connect to the transit gateway by using AWS Site-to-Site VPN connections over the internet. The company has configured one transit gateway VPN attachment for each office.
Route propagation is enabled on all route tables. Each Site-to-Site VPN connection uses two tunnels in an active-passive configuration. The company configured each office with appropriate static routes on both the Site...
To meet the requirement of maximizing the overall VPN connection bandwidth and utilizing both IPsec tunnels in an active-active configuration, let's break down the options and identify the one that best suits the scenario.
Option A:
Create an AWS Transit Gateway Connect attachment for each office. Use the existing VPN attachments as the transport for the new Connect attachments. Set up a Generic Routing Encapsulation (GRE) tunnel on each customer gateway that terminates on the Connect attachment for each office. Move the static routes from the transit gateway VPN attachment to the customer gateway for the transit gateway Connect attachment.
- Why it's rejected: While using GRE tunnels for enhanced throughput and redundancy is a valid approach for some scenarios, this solution introduces unnecessary complexity for the use case of increasing the bandwidth of the existing Site-to-Site VPN connections. The customer is already using IPsec VPNs, and adding GRE tunnels via Transit Gateway Connect isn't required unless the customer specifically wants to use GRE for other advanced routing purposes. This would add extra steps without directly solving the issue of bandwidth optimization using the existing VPN tunnels.
Option B:
Enable equal-cost multi-path (ECMP) routing on the transit gateway. Ensure ECMP is supported by and enabled on the customer gateways. Enable ECMP on the Site-to-Site VPN connection. Ensure static routes on the customer gateways have equal metrics and administrative distance.
- Why it's rejected: ECMP routing allows for load balancing across multiple routes, but enabling it on the transit gateway alone will not necessarily maximize the usage of both IPsec tunnels. The key issue here is that Site-to-Site VPN connections over IPsec tunnels are usually managed in an active-passive manner, and ECMP may not be directly supported across the IPsec tunnels for this type of configuration (as typically, one tunnel is active while the other is in a standby role).
Option C:
...
Author: Emma · Last updated May 16, 2026
A finance company runs multiple applications on Amazon EC2 instances in two VPCs that are within a single AWS Region. The company uses one VPC for stock trading applications. The company uses the second VPC for financial applications. Both VPCs are connected to a transit gateway that is configured as a multicast router.
In the stock trading VPC, an EC2 instance that has an IP address of 10.128.10.2 sends trading data over a multicast network to the 239.10.10.10 IP address on UDP Port 5102. The company recently launched two new EC2 instances in the financi...
To meet the requirement of enabling the two new EC2 instances in the financial applications VPC to receive multicast stock trading data from the EC2 instance in the stock trading VPC, several steps need to be taken in the correct order to ensure proper multicast routing and security. Let's evaluate each option and understand how they contribute to the solution.
Option A: Add the elastic network interfaces of the two new EC2 instances as members of the multicast group by using the group IP address of 239.10.10.10.
- Why it’s selected: In order for the two new EC2 instances in the financial VPC to receive multicast data, they must be able to join the multicast group at the specified IP address (239.10.10.10). By adding the elastic network interfaces (ENIs) of these EC2 instances to the multicast group, the instances will be able to listen to the multicast traffic. This step is crucial for the EC2 instances to receive the multicast packets.
Option B: Add an inbound rule to the security groups that are attached to the multicast receiver instances. Configure the rule as follows: Protocol: IGMP Version 2. Port: 5102, and Source: 239.10.10.10/32.
- Why it’s rejected: IGMP (Internet Group Management Protocol) is used for managing multicast group memberships, but it doesn't need to be explicitly allowed in security groups for multicast data reception on the instances. Instead, security group rules should focus on the UDP traffic coming from the multicast sender (stock trading VPC). The mentioned configuration (Port 5102 and IGMP) is not relevant for multicast data reception itself. It would be more appropriate to focus on allowing the UDP traffic on Port 5102 for the required source IP (10.128.10.2), not IGMP specifically.
Option C: Create associations to two EC2 instance IDs on the financial application VPC transit gateway attachment under the transit gateway multicast domain.
- Why it’s rejected: While associations of EC2 instances within the transit gateway multicast do...
Author: StarryEagle42 · Last updated May 16, 2026
A company runs workloads in multiple VPCs in the us-east-1 Region. The VPCs are connected to a transit gateway. An AWS Direct Connect connection provides private connectivity between a data center that is in the US and the transit gateway. A Direct Connect gateway is associated with the transit gateway.
The company has recently opened a new office location in London. The company plans to launch cloud services in multiple VPCs in the eu-west-2 Region. Users in the new London office must have private access to the workloads that run in us-east-1. Users in the US data center must have access to any workloads...
The company has several key requirements, including private access for users in London to workloads in us-east-1, access for the US data center to workloads in eu-west-2, and the ability to accommodate future growth with minimal operational overhead. Let's analyze the options to see which one best meets these needs.
Option A: Create an AWS Site-to-Site VPN connection from the London office to the Direct Connect gateway in us-east-1.
- Why it's rejected: While VPN connections are a valid solution, using Site-to-Site VPNs in this case adds unnecessary complexity and operational overhead. Managing multiple VPN connections would require ongoing maintenance and can become cumbersome, especially as the company grows. Additionally, VPNs over the internet would not provide the same level of performance, reliability, and scalability as a dedicated Direct Connect solution.
Option B: Establish a new Direct Connect connection for the London office. Attach the new Direct Connect connection to the existing Direct Connect gateway. Create a transit gateway in eu-west-2. Associate the new transit gateway with the existing Direct Connect gateway. Create a peering connection between the transit gateways in us-east-1 and eu-west-2.
- Why it's selected: This option provides a direct, private, and scalable solution for connecting the London office to both us-east-1 and eu-west-2. By establishing a new Direct Connect connection for the London office and attaching it to the existing Direct Connect gateway, the company can ensure low-latency, high-performance private connectivity. The use of transit gateways in both regions allows for flexible and scalable inter-region connectivity, with the transit gateway peering providing the necessary communication between us-east-1 and eu-west-2. This option minimizes operational effort because it leverages existing infrastructure (the Direct Connect gate...
Author: Emma · Last updated May 16, 2026
A company has 10 Amazon EC2 instances that run web server software in a production VPC. The company also has 10 web servers that run in an on-premises data center. The company has a 10 Gbps AWS Direct Connect connection between the on-premises data center and the production VPC. The data center uses the 10.100.0.0/20 CIDR block.
The company needs to implement a load balancing solution that receives HTTPS traffic from thousands of external users. The solution must distribute the traffic across the web server...
Let's evaluate the options to determine the best solution for load balancing traffic across the EC2 instances in the production VPC and the web servers in the on-premises data center while ensuring session persistence (sticky sessions) for HTTPS traffic.
Key Requirements:
1. Distribute traffic across EC2 instances in AWS and on-premises servers.
2. Session persistence (stickiness) to ensure that requests from the same user are directed to the same web server throughout the session.
3. Support for HTTPS traffic.
4. Connectivity between on-premises servers and AWS instances over Direct Connect (IP address-based communication).
Option A: Deploy a Network Load Balancer (NLB) in the production VPC. Create one target group for the EC2 Instances and a second target group for the on-premises servers. Specify IP as the target type. Register the EC2 instances and the on-premises servers with the target groups. Enable connection draining on the NLB.
- Why it's rejected:
- NLB is designed for high-performance, low-latency traffic and works at the network layer (Layer 4). While it supports TCP and UDP traffic, it does not provide the capability to handle HTTP/HTTPS traffic at the application layer, nor does it support application-based sticky sessions.
- Connection draining (used to ensure that in-flight requests are properly handled when instances are deregistered or removed) is useful but does not address session persistence for HTTP/HTTPS traffic, which is required in this scenario.
Option B: Deploy an Application Load Balancer (ALB) in the production VPC. Create one target group for the EC2 Instances and a second target group for the on-premises servers. Specify IP as the target type. Register the EC2 instances and the on-premises servers with the target groups. Enable application-based sticky sessions on the ALB.
- Why it's rejected:
- ALB is designed to work at the application layer (Layer 7), which is suitable for handling HTTPS traffic. However, specifying IP as the target type for both EC2 instances and on-premises servers is not optimal.
- ALBs are generally designed to register instances (not IP addresses) in target groups. Using IP as the target type might be possible in some use cases, but it's not the most ideal configuration,...
Author: ShadowWolf101 · Last updated May 16, 2026
A global company is establishing network connections between the company's primary and secondary data centers and a VPC. A network engineer needs to maximize resiliency and fault tolerance for the connections. The network bandwidth...
To meet the requirements of maximizing resiliency and fault tolerance, while ensuring network bandwidth greater than 10 Gbps, let's evaluate each option based on its technical merits, cost-effectiveness, and suitability for this scenario.
Key Requirements:
1. Resiliency and fault tolerance: Connections should be reliable and able to handle failures gracefully.
2. Bandwidth greater than 10 Gbps: The total available bandwidth should exceed 10 Gbps.
3. Cost-effectiveness: The solution should achieve the desired result at the lowest possible cost.
Option A: Set up a 100 Gbps connection at the primary data center that terminates at an AWS Direct Connect location. Set up a second 100 Gbps connection at the secondary data center that terminates at a second Direct Connect location. Ensure the connections are managed by separate providers.
- Why it's rejected:
- While this solution provides sufficient bandwidth (100 Gbps per connection), it is highly expensive due to the significant cost associated with 100 Gbps Direct Connect links.
- It involves two separate high-capacity links, which would be an overkill for this requirement, especially when a lower-cost solution (such as two 10 Gbps links) would meet the bandwidth and fault tolerance needs.
- This solution is not cost-effective given the company's requirement for greater than 10 Gbps but without the need for such massive capacity.
Option B: Set up a 10 Gbps connection at the primary data center that terminates at an AWS Direct Connect location. Set up a second 10 Gbps connection at the secondary data center that terminates at a second Direct Connect location. Ensure the connections are managed by separate providers.
- Why it's selected:
- This solution provides resiliency and fault tolerance through the use of two separate 10 Gbps Direct Connect connections, ensuring that if one connection fails, the other can continue to provide connectivity.
- The 10 Gbps bandwidth per connection meets the requirement for bandwidth greater than 10 Gbps (total of 20 Gbps).
- The separate providers for each connection add an extra layer of fault tolerance, reducing the risk of a single point of failure.
- Cost-effectiveness: This option is far...
Author: BlazingPhoenix22 · Last updated May 16, 2026
A company's data center is connected to a single AWS Region by an AWS Direct Connect dedicated connection. The company has a single VPC in the Region. The company stores logs for all its applications locally in the data center.
The company must keep all application logs for 7 year...
To meet the requirement of copying logs from an on-premises data center to an Amazon S3 bucket while ensuring secure and reliable connectivity, let's analyze the options and the factors that influence the selection:
Key Considerations:
1. Direct Connect: Direct Connect allows private, dedicated network connections between the on-premises data center and AWS, which can be either public or private Virtual Interfaces (VIFs).
2. VPC Endpoint for S3: To securely connect your VPC to Amazon S3, you can use a VPC endpoint. There are two types of endpoints for Amazon S3:
- Gateway endpoint: Allows you to privately connect your VPC to S3.
- Interface endpoint: Allows private connections to AWS services over PrivateLink, and is typically used for services not natively supported by a gateway endpoint.
Option Breakdown:
A) Create a public VIF on the Direct Connect connection. Create an Amazon S3 gateway endpoint in the VPC.
- A public VIF is used to access AWS public services such as S3 or CloudFront over Direct Connect.
- Gateway endpoint is a perfect fit for S3 because it provides direct, private access to Amazon S3 from your VPC.
- Pros: Cost-effective, simple, and native support for S3.
- Cons: Not ideal for highly sensitive or private workloads that require more granular control over network traffic (though this is a minor concern here).
B) Create a private VIF on the Direct Connect connection. Create an Amazon S3 gateway endpoint in the VPC.
- Private VIF is used for accessing AWS services like EC2 over Direct Connect, within a VPC.
- Gateway endpoint allows you to connect privately to S3 over Direct Connect without using public internet paths.
- Pros: Fully private, avoids internet traversal...
Author: Kai · Last updated May 16, 2026
A company is planning to host a secure web application across multiple Amazon EC2 instances. The application will have an associated DNS domain in an Amazon Route 53 hosted zone.
The company wants to protect the domain from DNS poisoning attacks. The company also wants to allow web browsers to...
Key Considerations:
1. DNS Security: To protect against DNS poisoning attacks, DNS Security Extensions (DNSSEC) should be configured. DNSSEC ensures the integrity of DNS responses by cryptographically signing DNS records, allowing clients to verify the authenticity of the responses.
2. Web Application Authentication: To authenticate users to a web application using a trusted third-party, public X.509 certificates signed by a recognized certificate authority (CA) should be used. Self-signed certificates are not trusted by browsers and cannot facilitate this authentication in a secure manner.
Option Breakdown:
A) Configure the Route 53 hosted zone to use DNS Security Extensions (DNSSEC). Install self-signed X.509 certificates on the EC2 instances.
- DNSSEC is properly configured here, which protects against DNS poisoning.
- However, using self-signed X.509 certificates is not appropriate for user authentication because web browsers do not trust self-signed certificates by default. This would lead to security warnings in browsers, and users would be unable to authenticate properly.
- Cons: While DNSSEC helps protect DNS data, self-signed certificates do not provide the trusted authentication needed for the web application.
B) Configure a Name Authority Pointer (NAPTR) record in the Route 53 hosted zone. Install X.509 certificates that are signed by a public certificate authority on the EC2 instances.
- NAPTR records are typically used for services like VoIP and are not typically relevant to securing web application traffic over HTTPS.
- While X.509 certificates signed by a public C...
Author: William · Last updated May 16, 2026
A company is planning to use an AWS Transit Gateway hub and spoke architecture to migrate to AWS. The current on-premises multi-protocol label switching (MPLS) network has strict controls that enforce network segmentation by using MPLS VPNs. The company has provisioned two 10 Gbps AWS Direct Connect connections to provide resilient, high-speed, low-latency connectivity to AWS.
A security engineer needs to apply the concept of network segmentation to the AWS environment to ensure that virtual routing and forwarding (VRF) is logically separated for each of the company's software development environments. The number o...
Key Considerations:
1. Network Segmentation: The company needs to ensure that their development environments are logically separated, which includes managing overlapping address spaces.
2. MPLS VPN Integration: The company's MPLS VPNs need to be integrated with AWS and support VRF to logically segment network traffic, as the number of MPLS VPNs is expected to increase in the future.
3. Operational Overhead: The solution must minimize operational overhead, meaning it should be scalable and easy to manage as the company expands its network.
Option Breakdown:
A) Deploy a software-defined WAN (SD-WAN) head-end virtual appliance and an SD-WAN controller into a Transit Gateway Connect VPC. Configure the company's edge routers to be managed by the new SD-WAN controller and to use SD-WAN to segment the traffic into the defined segments for each of the company's development environments.
- SD-WAN is typically used for flexible, software-defined network management that simplifies connecting various sites and provides granular traffic control.
- While SD-WAN can provide network segmentation, this approach introduces additional complexity and operational overhead by introducing an SD-WAN controller and virtual appliances, which would require monitoring, management, and possible integration complexities.
- Cons: SD-WAN is a powerful tool but adds operational overhead, especially in an environment that already has complex MPLS VPN requirements. It's an unnecessary layer for the task at hand.
B) Configure IPsec VPNs on the company edge routers for each MPLS VPN for each of the company's development environments. Attach each IPsec VPN tunnel to a discrete MPLS VPN. Configure AWS Site-to-Site VPN connections that terminate at a transit gateway for each MPLS VPN. Configure a transit gateway route table that matches the MPLS VPN for each Transit Gateway VPN attachment.
- IPsec VPNs are a viable option for securely connecting on-premises networks with AWS.
- This solution requires configuring multiple Site-to-Site VPN connections, which would be cumbersome to manage and scale, especially as the number of MPLS VPNs increases. The manual management of individual VPNs, along with the required route tables for each VPN attachment, adds significant complexity and operation...
Author: Sophia Clark · Last updated May 16, 2026
A company is planning to migrate to AWS and use multiple VPCs in multiple AWS Regions. A network engineer must connect the eu-west-1 and eu-central-1 Regions to the company headquarters and branch office, respectively.
The network engineer created a production VPC, named Prod A, with a CIDR block of 10.0.0.0/16. Prod A runs in an account in eu-west-1. The network engineer then created another production VPC, named Prod B, with a CIDR block of 10.1.0.0/16. Prod =D0=92 runs in a different account in eu-central-1.
The network engineer performed the following steps to try to achieve the required connectivity:
1. Created one transit gateway in each Region
2. Shared and accepted the transit gateways with the production accounts in both Regions
3. Configured the peering attachment between both transit gateways
4. Attached both VPCs to the respective Region transit gateway
5. Created both transit gateway route tables and associated the attachments with ...
Key Considerations:
1. Transit Gateway Peering: The network engineer has already configured a peering connection between the two Transit Gateways in different regions (eu-west-1 and eu-central-1). This should allow inter-region routing, but proper route propagation and static routing must be configured to ensure traffic can flow correctly.
2. VPC Route Tables: Proper route propagation and static routes are critical for ensuring traffic is directed to the correct Transit Gateway and between the VPCs.
3. VPC CIDR Conflicts: The VPCs have distinct CIDR blocks (10.0.0.0/16 for Prod A and 10.1.0.0/16 for Prod B), so no direct IP overlap issues arise here, but proper routing must be in place.
Option Breakdown:
A) Modify the IP address of the peering attachment to a wider range.
- The peering attachment between Transit Gateways does not require a wider IP range. The CIDR blocks for the VPCs (10.0.0.0/16 and 10.1.0.0/16) are already distinct and do not conflict, so changing the IP address range of the peering attachment is unnecessary.
- Cons: This option does not directly address the problem of routing configuration between the Transit Gateways and VPCs.
B) Delete the static routes that were in the transit gateway route table to send traffic to the remote VPC and enable route propagation instead.
- Static routes in the Transit Gateway route tables are meant to direct traffic between VPCs. However, since the Transit Gateway is already connected to the VPCs and route propagation is enabled, static routes may be redundant. Enabling route propagation will allow the Transit Gateway to dynamically learn the VPC routes from the VPC route tables, making manual static routes unnecessary.
- Pros: By enabling route propagation on the Transit Gateway route tables, traffic can automatically be routed between regions wit...
Author: Liam · Last updated May 16, 2026
A company hosts an application on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are part of an Amazon EC2 Auto Scaling group.
To comply with new security standards, the company must capture all application access data, including server response codes, request paths, latency, and client...
Key Considerations:
1. Application Access Data: The company needs to capture key metrics like server response codes, request paths, latency, and client IP addresses. These are typically available through the Application Load Balancer (ALB) access logs, which provide detailed information about client requests and responses.
2. Performance Analysis: The company requires the ability to query and analyze the captured data, which suggests using a tool that supports easy querying and analysis, such as Amazon Athena.
3. Operational Simplicity: The solution should minimize complexity, be scalable, and provide a straightforward way to access the necessary data for analysis.
Option Breakdown:
A) Enable VPC flow logs on the ALB subnets. Store the logs to an Amazon S3 bucket. Query the logs in the S3 bucket by using Amazon Athena.
- VPC Flow Logs capture network-level data about traffic flowing through the VPC, including IP addresses, ports, and traffic flow. However, they do not capture detailed application-level information like request paths, server response codes, or latency.
- Cons: VPC Flow Logs are useful for network-level monitoring but do not meet the requirement of capturing detailed application access data as specified in the use case.
B) Configure Amazon VPC Traffic Mirroring on all EC2 elastic network interfaces. Deploy a third-party monitoring appliance from AWS Marketplace in a private subnet. Use Amazon Data Firehose to send all mirrored traffic to the monitoring appliance. Query the logs directly from the monitoring appliance.
- VPC Traffic Mirroring is a highly detailed solution for capturing network traffic at the packet level. While it can capture all traffic, this is more detailed than needed for the use case, and using third-party monitoring appliances introduces unnecessary complexity.
- Cons: Traffic mirroring can gener...
Author: Stella · Last updated May 16, 2026
A company has five VPCs in the us-east-1 Region. The company hosts an internal web application in us-east-1. One of the company's VPCs. named VPC-A, needs to connect to an external partner's AWS environment. The partner's environment is in the same AWS Region where the partner hosts a new version of the company's web application. The partner hosts its version of the application in a VPC named VPC-B.
The company has Amazon EC2 instances in VPC-A that need to connect to the web application in VPC-B A network engineer notices that the partner's VPC-B and the company's VPC-A use the same IP space. The network engineer needs...
To solve the issue of allowing EC2 instances in VPC-A to connect to the web application in VPC-B, while keeping the existing environment unaffected, the network engineer needs to work with VPCs that have overlapping IP address spaces. The selected solution should meet the following requirements:
- Allow connectivity between the two VPCs.
- Avoid affecting the existing infrastructure of both the company and the partner.
- Handle overlapping IP spaces between VPC-A and VPC-B.
Option analysis:
A) Establish a VPC peering connection between VPC-A to VPC-B.
- Explanation: VPC peering allows traffic to flow between two VPCs, but there are some limitations when it comes to overlapping IP ranges. VPC peering will not work if both VPCs use the same IP address range, as traffic cannot be routed properly.
- Rejection Reason: Since VPC-A and VPC-B have overlapping IP address spaces, this option will not work.
B) Ensure the partner creates a VPC endpoint service that uses a Network Load Balancer in VPC-B.
- Explanation: A VPC endpoint service allows connections from other VPCs or AWS accounts to access resources in a private VPC, but it typically requires a well-defined, non-overlapping IP space and a specific use case where a service is exposed through an NLB.
- Rejection Reason: This option doesn’t address the problem of overlapping IP spaces and is more suited for exposing services to external VPCs or accounts, not for direct communication between VPCs with overlapping IP ranges.
C) Deploy a VPC endpoint in VPC-A that uses a VPC endpoint service that is shared by the partner.
- Explanation: VPC endpoints can allow private connections between VPCs and AWS services, but they are designed primarily for services such as S3, Dynam...
Author: Zain · Last updated May 16, 2026
A company has a hybrid environment that connects an on-premises data center to the AWS Cloud. The hybrid environment uses a 10 Gbps AWS Direct Connect dedicated connection. The Direct Connect connection has multiple private VIFs that terminate in multiple VPCs.
To comply with regulations, the company must encrypt all WAN traffic, regardless of the underlying transpo...
To meet the requirement of encrypting all WAN traffic over the AWS Direct Connect connection without affecting the company's bandwidth capacity, let's analyze each option carefully.
Option analysis:
A) Create a public VIF. Configure a new AWS Site-to-Site VPN connection to use the new public VIF.
- Explanation: A public VIF (Virtual Interface) connects to public AWS services, not private VPCs. A Site-to-Site VPN connection over a public VIF would route traffic over the internet, which defeats the purpose of using Direct Connect and does not comply with the regulation requiring encryption on all WAN traffic. The VPN would also add overhead, potentially impacting bandwidth.
- Rejection Reason: This option uses a public VIF, which doesn’t meet the requirement of encrypting WAN traffic between the on-premises data center and the AWS Cloud while maintaining bandwidth.
B) Configure MAC security (MACsec) support on the port of the existing Direct Connect connection. Change the encryption mode to must_encrypt.
- Explanation: MACsec (Media Access Control Security) is a security standard for encrypting traffic at the data link layer (Layer 2). By enabling MACsec on the port of the existing Direct Connect connection, the company can encrypt all traffic between the on-premises data center and AWS over Direct Connect without affecting the underlying bandwidth. The "must_encrypt" setting ensures that encryption is always applied.
- Selected: This is the ideal solution because it meets the regulatory encryption requirement while ensuring there is no impact on the bandwidth capacity (since it works at the data link layer). Additionally, it doesn't require the company to create a new connect...
Author: Lucas Carter · Last updated May 16, 2026
A company needs to capture and log traffic for Nitro-based Amazon EC2 instances to comply with regulations. The company's network team has prepared a solution that enables VPC traffic mirroring and sends traffic to a second set of EC2 instances in an Auto Scaling group.
The network team has added a Network Load Balancer (NLB) in front of the EC2 instances the traffic will be sent to. However, the ...
To solve the issue of traffic mirroring not being sent to the EC2 instances behind the Network Load Balancer (NLB), let's break down the key points and the options provided.
Key factors to consider:
- Traffic Mirroring: Traffic mirroring captures traffic at the elastic network interface (ENI) level of Amazon EC2 instances. It is designed to capture and replicate traffic for analysis, and the mirrored traffic is sent to a specific destination for logging or analysis.
- Network Load Balancer (NLB): The NLB is a Layer 4 (Transport Layer) load balancer that operates at the TCP/UDP level. It is designed to handle high throughput and low latency. However, the traffic mirrored must be directed to an appropriate target that can handle it.
Option analysis:
A) Select the NLB as a source for traffic mirroring. Use a UDP listener.
- Explanation: NLBs operate at Layer 4 (TCP/UDP) and do not serve as a "source" for traffic mirroring. Traffic mirroring requires an ENI on an EC2 instance or a network interface as the source, not a load balancer. Using a UDP listener is also not relevant in this case because the NLB is not the correct entity to capture traffic for mirroring.
- Rejection Reason: NLB cannot act as the source for traffic mirroring. It is used as a target, not a source, for mirroring traffic.
B) Select the NLB as a target for traffic mirroring. Use a TCP listener and a UDP listener.
- Explanation: The NLB can be a valid target for traffic mirroring, but this option includes unnecessary complexity by specifying both TCP and UDP listeners. The main issue is that NLBs do not operate in a way that would support receiving mirrored traffic over both TCP an...
Author: Vivaan · Last updated May 16, 2026
A US-based company is expanding its business to Europe. A network engineer needs to extend the company's network infrastructure by setting up a new hub and spoke architecture in the eu-west-1 Region. The network engineer uses a transit gateway peering connection to connect the new resources in eu-west-1 to an existing environment in the us-east-1 Region.
The hub and spoke architecture in each AWS Region includes an inspection VPC that uses AWS Network Firewall to centralize traffic inspection for each Region. To reduce costs, the network engineer decides to inspect inter-Region traffic by using the inspection VPC in the Region that originates the traffic. The network engineer configures the transit gateway route tables accordingly for e...
The issue of inter-Region communication not working in the described architecture can be solved by addressing how traffic is routed and inspected across the Regions. Let’s analyze the provided options carefully.
Key factors to consider:
- Transit Gateway: The transit gateway connects VPCs across Regions and can route traffic between VPCs in different Regions (via peering).
- Inspection VPC with AWS Network Firewall: The goal is to inspect inter-Region traffic within the Region where the traffic originates to save costs.
- Inter-Region Routing: The issue is likely related to how traffic is being routed between the Regions and how the traffic is being inspected by the Network Firewall.
Option analysis:
A) Configure Open Shortest Path First (OSPF) routing on the transit gateway peering connection to propagate the VPC CIDR blocks from each Region to the remote peer.
- Explanation: OSPF is a dynamic routing protocol used to propagate routing information. Transit gateways in AWS don’t require dynamic routing like OSPF for inter-Region traffic; instead, static routing via the transit gateway route tables is commonly used.
- Rejection Reason: AWS Transit Gateway route propagation does not rely on OSPF. Static route configuration in the route tables of the transit gateway is sufficient, and there is no need for OSPF in this case.
B) Use AWS Resource Access Manager (AWS RAM) to share access between the transit gateways. Enable the Allow sharing with anyone setting.
- Explanation: AWS Resource Access Manager (RAM) allows sharing of AWS resources, but it is primarily used to share resources like Transit Gateways across accounts. However, in this case, the issue does not seem to be about sharing access between accounts or regions; it's about routing and traffic inspection.
- Rejection Reason: This option is irrelevant becaus...
Author: Emma · Last updated May 16, 2026
A company runs applications in two VPCs that are in separate AWS Regions. One VPC is in the us-east-1 Region. The second VPC is in the us-west-1 Region. The company needs to establish connectivity between the two VPCs. The company also needs to connect the VPCs to applications that run in an on-premises data center.
The current traffic requirement between the VPCs is 50 =D0=A2=D0=92 per month. The company expects traffic volume between the VPCs to increase. The traffic requirement from the VPCs to...
To determine the most cost-effective solution for connecting two VPCs in separate AWS Regions and connecting those VPCs to an on-premises data center, let's analyze the provided options and the requirements.
Key factors to consider:
1. Traffic between VPCs: The company expects traffic between the VPCs to increase. The current traffic requirement is 50 TB per month, which may grow, so the solution should handle high-volume traffic efficiently.
2. Traffic to the on-premises data center: The data center traffic is 10 TB per month and is expected to remain constant, so the connection to the on-premises data center needs to be stable and cost-efficient.
3. Cost-effectiveness: The solution must provide high performance and scalability without incurring high costs.
Option analysis:
A) Create a transit gateway in each Region. Create VPN connections from the transit gateways to the on-premises firewall. Create a peering connection between the transit gateways.
- Explanation: A transit gateway allows for scalable connectivity between multiple VPCs and on-premises data centers. Using peering between the transit gateways in two regions provides a cost-effective way to route traffic between the VPCs. However, using VPN connections for traffic to the on-premises data center can be costly and inefficient, especially if high throughput is required.
- Rejection Reason: While the transit gateway solution scales well and is efficient for large VPC-to-VPC communication, the VPN connections to the on-premises data center could lead to higher operational costs. VPNs are typically slower than direct connections like AWS Direct Connect, which is more suitable for large data volumes between VPCs and on-premises environments.
B) Create a virtual private gateway in each Region. Create VPN connections from the on-premises firewall to the virtual private gateways. Configure the on-premises firewall to route the traffic between the two VPCs.
- Explanation: This option involves setting up VPN connections from the on-premises data center to each VPC using virtual private gateways (VGWs). The on-premises firewall would then route traffic between the two VPCs. However, configuring the firewall to route traffic between VPCs manually can become complex and...
Author: Siddharth · Last updated May 16, 2026
A company runs workloads in multiple VPCs. The company needs to securely access a workload in one of the VPCs, named VPC-A, from an on-premises data center. A network engineer sets up an AWS Site-to-Site VPN connection to a transit gateway. The network engineer configures dynamic routing for the connection, and communication works properly.
Recently, the owner of VPC-A added another CIDR range to the VPC. The VPC-A owner created workloads that use the additional CIDR range.
The company's on-premises network is unable to reach the new workloads. The network engineer ...
The task is to ensure that network connectivity between the company's on-premises data center and the workloads in VPC-A works correctly, even after the CIDR range in VPC-A is modified or expanded. Let's analyze each option to determine the most operationally efficient solution.
Option A: Configure route propagation for VPC-A to the VPN attachment route table.
- Analysis: Route propagation automatically updates the route table in the transit gateway based on the routes advertised by the connected VPCs and VPNs. If VPC-A's CIDR range changes, the transit gateway will automatically propagate those changes, which will ensure that the network connectivity is up to date without any manual intervention.
- Why it's preferred: This option provides automatic updates whenever the CIDR of VPC-A changes, which eliminates the need for manual updates and ensures seamless scalability. It's also operationally efficient since it doesn’t require writing Lambda functions or setting up alarms, and it works automatically.
- Key factors: Automatic propagation ensures minimal human intervention, scalability with future CIDR additions, and proper handling of route updates without manual configurations.
Option B: Manually update the VPN attachment route table to include the new CIDR range.
- Analysis: Manually updating the route table would require the network engineer to keep track of any changes to VPC-A's CIDR range. While this would work, it’s labor-intensive, error-prone, and doesn't scale well when there are frequent CIDR range changes in VPC-A.
- Why it's not ideal: This option is not scalable and is prone to errors or missed updates. Additionally, it requires ongoing manual effort, which decreases operational efficiency.
Option C: Configure an Amazon EventBridge rule to invoke an AWS Lambda functio...
Author: Liam · Last updated May 16, 2026
A company is migrating its internet VPN connections to dedicated AWS Direct Connect connections. The company needs to set up the Direct Connect connections so that all network communications are encrypte...
The goal here is to ensure that all network communications over the AWS Direct Connect connections are encrypted in transit. Since Direct Connect itself doesn't encrypt traffic by default, encryption needs to be implemented either through MACsec (Media Access Control Security) or IPsec (Internet Protocol Security). Let's go through each option:
Option A: Create new Direct Connect connections while requesting MACsec ports.
- Analysis: AWS Direct Connect supports encryption through MACsec on dedicated connections, which provides encryption at Layer 2 (data link layer). By requesting MACsec-enabled ports when setting up new Direct Connect connections, the communication will be encrypted as it travels over the physical link.
- Why it's selected: This option ensures that all network communication over the Direct Connect links is encrypted at Layer 2, which is a requirement for securing transit between the on-premises network and AWS.
Option B: Create a MACsec Connectivity Association Key Name (CKN) and Connectivity Association Key (CAK) pair. Associate the pair with each new connection.
- Analysis: For MACsec to work, you need to create a CKN and CAK pair, which are used to establish and secure the encryption keys on both ends of the Direct Connect link. This is crucial for enabling MACsec encryption, as it ensures that both the AWS and on-premises devices can securely communicate using the shared encryption keys.
- Why it's selected: This step is necessary for setting up MACsec and ensuring the communication is encrypted. Without it, MACsec cannot be activated.
Option C: Update the on-premises routers to use MACsec and the shared Connectivity Association Key Name (CKN) and Connectivity Association Key (CAK) pair.
- Analysis: For MACsec to work, the on-premises router must also be configured to use the same MACsec encryption standards and the CKN/CAK pair. This step is necessary to ensure that the on-premises network can communicate securely with AWS ove...
Author: Victoria · Last updated May 16, 2026
A company has an application VPC and a networking VPC that are connected through VPC peering. The networking VPC contains a Network Load Balancer (NLB). The application VPC contains Amazon EC2 instances that run an application. The EC2 instances are part of a target group that is associated with the NLB in the networking VPC.
The company configures a third VPC and peers it to the networking VPC. The new VPC contains a new version of the existing application. The new version of the application runs on new EC2 instances in an application subnet. The new version of the application runs i...
To establish connectivity between the new version of the application in the new VPC and the Network Load Balancer (NLB) in the networking VPC, we need to address a few key considerations. The main goal is to ensure that the NLB can route traffic to the EC2 instances running the new version of the application in the newly peered VPC.
Let's go through the options:
Option A: Register the new application EC2 instances with the NLB by using the instance IDs.
- Analysis: The NLB can register EC2 instances as targets by their instance IDs or IP addresses. Using instance IDs is a valid method for registering the EC2 instances. However, when working across VPCs (especially when VPCs are in different Availability Zones or regions), using instance IDs can be problematic if the instances are in a different VPC.
- Why it's not ideal: In a multi-VPC scenario, the NLB typically registers instances using IP addresses (which are globally reachable) rather than instance IDs, as instance IDs are not accessible across VPCs unless additional configurations (such as VPC peering) are made.
- Why it’s rejected: Registering by instance ID is generally not the best practice when instances are across VPCs due to potential issues with resolving the IDs over the peering connection.
Option B: Register the new application EC2 instances with the NLB by using instance IP addresses.
- Analysis: When the NLB is used across VPCs, registering the EC2 instances by their private IP addresses is a recommended approach. This ensures that the NLB can route traffic to the correct instance in the peered VPC. Since the instances are in different Availability Zones but within the same region, the NLB will use the private IPs to reach the EC2 instances.
- Why it’s selected: Registering by IP addresses works across VPC peering and ensures that traffic can be properly routed. This is the preferred method when instances are in different VPCs and the NLB needs to send traffic to them.
Option C: Configure the NLB in the Availability Zone where the new application EC2 instances run.
- Analysis: The NLB is typically configured to route traffic to instances in different Availability Zones, and it automatically handles routing to healthy targets across these zones. However, the NLB does not need to be specifically configured to route traffic to an Availability Zone that has the new version of the application, as it should already be able to distribute traffic across multiple AZ...
Author: Victoria · Last updated May 16, 2026
A company uses AWS Site-to-Site VPN connections to encrypt traffic between the company's on-premises location and a single VPC. The Site-to-Site VPN connections use two 1 Gbps AWS Direct Connect connections with public VIFs. The company plans to add 15 additional VPCs in the same AWS Region.
The company must maintain the same level of encryption that the Site-to-Site VPN connections currently provide for each connection between the on-premises location and the new VPCs. The new connections must not use public I...
The company is looking to extend its Site-to-Site VPN connections with encryption between its on-premises location and additional VPCs, with minimal operational overhead, while maintaining the same encryption level provided by the current Site-to-Site VPN connections.
Let's analyze each option:
Option A: Create a transit gateway and a Direct Connect gateway. Associate the transit gateway with the Direct Connect gateway. Attach all the new VPCs to the transit gateway.
- Analysis: The AWS Transit Gateway allows for scalable and efficient connectivity between multiple VPCs and on-premises locations. By associating the Transit Gateway with the Direct Connect gateway, you can use private Direct Connect connections (with encryption through the Site-to-Site VPN connections) for all VPCs. The new VPCs can be easily attached to the transit gateway, avoiding the need to set up individual VPN connections for each VPC. This is a highly scalable solution that maintains the encryption level.
- Why it's selected: This option provides centralized management for the connections, reduces the number of configurations, and meets the requirement for maintaining encryption between the on-premises location and the VPCs while minimizing operational overhead. This also ensures that no public IP addresses are involved.
Option B: For each new VPC, create a new Direct Connect private VIF to a Direct Connect gateway. Associate all VPCs with the Direct Connect gateway.
- Analysis: This approach involves creating individual Direct Connect connections with private VIFs (Virtual Interfaces) for each new VPC, and then associating the VPCs with the Direct Connect gateway. Although this setup allows private IP communication and ensures encryption, it increases the complexity and operational overhead by requiring configuration for each VPC, making it less efficient.
- Why it's rejected: This approach does not scale efficiently, as it requires manual setup and management for each VPC, which increases operational overhead compared to using a transit gateway.
Option C: Assign a private IP CIDR block to the transit gateway.
- Analysis: When using a transit gateway, private IP addresses are typically used for communication between the transit gateway and VPCs. A ...
Author: FlamePhoenix2025 · Last updated May 16, 2026
A company hosts application servers on premises and on Amazon EC2 instances in a VPC. The application servers access data that is hosted in an Amazon S3 bucket through the public internet. The EC2 instances in the VPC use an AWS Site-to-Site VPN for connectivity with the on-premises application servers.
New company regulations state that all traffic between the appli...
To meet the requirement that all traffic between the application servers and the S3 bucket must remain private and not use public IP addresses, we must ensure that traffic between the on-premises servers and S3 is routed through private network paths. Let's evaluate the options based on the goal of achieving this in the most cost-effective manner:
Option A: Configure an S3 gateway endpoint. Modify the route table with the appropriate route for the endpoint. Access the S3 bucket through the gateway endpoint from the EC2 instances.
- Analysis: An S3 gateway endpoint allows private communication between the VPC and S3 over AWS's private network, without using public IP addresses or the public internet. By modifying the route table for the EC2 instances, traffic destined for S3 is routed through the gateway endpoint. This ensures that traffic between EC2 instances and the S3 bucket is kept private and secure.
- Why it's selected: This is the most cost-effective and straightforward solution because it uses a gateway endpoint, which does not incur data processing charges or require complex configurations. It meets the requirement to keep traffic private and does not use public IP addresses.
Option B: Configure an S3 interface endpoint. Update the on-premises servers and EC2 instances to use the interface endpoint DNS name to access the S3 bucket.
- Analysis: An S3 interface endpoint uses AWS PrivateLink to allow private connectivity between VPCs and S3, but it requires updating both on-premises servers and EC2 instances to use the interface endpoint's DNS name. The problem with this approach is that it requires significant changes to the configuration of the on-premises servers, which could lead to additional complexity and operational overhead.
- Why it's rejected: While this solution does ensure private communication, the requirement to update the on-premises servers and the added complexity make it less cost-effective and operationally efficient compared to Option A.
Option C: Conf...
Author: Amira · Last updated May 16, 2026
A company uses AWS Network Firewall to protect outgoing traffic for multiple VPCs that are in the same AWS account. Each VPC contains Amazon EC2 instances that host the company's applications. Each EC2 instance is tagged with the name of the application it hosts. The EC2 instances are in Auto Scaling groups.
A Network Firewall stateful rule group must remain up-to-date, even wh...
To select the best option for maintaining an up-to-date AWS Network Firewall stateful rule group, we need to focus on minimizing administrative effort and ensuring that the solution is scalable, especially with Auto Scaling groups managing EC2 instances that are frequently launched or terminated.
Option A: Create a network ACL for each application. Reference the network ACL in the stateful rule group.
- Rejection Reason: Network ACLs are typically used for controlling inbound and outbound traffic at the subnet level, not for managing stateful connections. A network ACL can't dynamically reflect changes based on EC2 instance tags, nor does it scale effectively when instances are frequently launched or terminated in Auto Scaling groups. Also, referencing the ACLs in the stateful rule group might not capture the granularity needed for application-level traffic control, as Network ACLs operate on a subnet basis.
Option B: Create a prefix list for each application. Reference the prefix list in the stateful rule group.
- Rejection Reason: Prefix lists are useful for controlling traffic at the IP address level, and they allow you to group a collection of IP addresses or CIDR blocks. However, managing dynamic EC2 instance IP addresses through prefix lists would still require an external process to regularly update the list, as Auto Scaling groups will alter instance IPs over time. This method can work, but it introduces more management overhead compared to automatic tagging-based solutions.
Option C: Create an AWS Lambda function that queries the EC2 instance tags for each application name and then updates the stateful rule group with the IP address of each instance.
- Selection Reason: This option leverages au...
Author: Noah · Last updated May 16, 2026
A company has multiple AWS Site-to-Site VPN connections between an on-premises environment and multiple VPCs. The Site-to-Site VPN connections use virtual private gateways and are configured with IPv4 addresses. The company hosts several internal applications in the VPCs.
Application users have reported that the applications are performing slowly. A network engineer notices excessi...
In this case, the goal is to resolve excessive latency in the network path used by the Site-to-Site VPN connections. Let's review each option in terms of its effectiveness and suitability for resolving the latency issue.
Option A: Use AWS Global Accelerator to deploy an accelerator on the existing Site-to-Site VPN connections.
- Rejection Reason: AWS Global Accelerator is typically used to optimize the routing of traffic for internet-facing applications by using the AWS global network to reduce latency and improve performance. However, it is not designed to accelerate or optimize Site-to-Site VPN connections, which are primarily private connections between an on-premises network and AWS VPCs. Global Accelerator does not work for VPN connections because it does not have visibility into the VPN traffic path. This solution would not address the latency within the Site-to-Site VPN itself.
Option B: Deploy a transit gateway and a new accelerated Site-to-Site VPN connection.
- Selection Reason: A Transit Gateway is an AWS service designed to provide centralized connectivity between VPCs, on-premises environments, and other networks. By deploying a transit gateway and using an accelerated Site-to-Site VPN, you can benefit from AWS's optimized network backbone to reduce latency. The accelerated Site-to-Site VPN connections are designed to optimize traffic flow by taking advantage of AWS's global network infrastructure, potentially improving the performance and reducing latency for the applications in the VPCs. This solution can be very effective in improving the overall perfor...
Author: Aria · Last updated May 16, 2026
A company has a transit gateway in a single AWS account. The company sends flow logs for the transit gateway to an Amazon CloudWatch Logs log group.
The company created an AWS Lambda function to analyze the logs. The Lambda function sends a notification to an Amazon Simple Notification Service (Amazon SNS) topic when a VPC generates traffic that is dropped by the transit gateway. Each notification contains the account ID. VPC ID, and total amount of dropped packets.
The company wants to subscribe a new Lambda function to the SNS topic. The new Lambda function must...
To meet the requirements, the goal is to create a solution where a new Lambda function is subscribed to an SNS topic, and this function should automatically apply a network ACL to the transit gateway attachment subnets to block traffic that is identified in each notification. Let's analyze the available options in detail:
Option A: Configure the existing Lambda function to add the destination IP addresses of the dropped traffic to each SNS notification. Configure the new Lambda function to create an outbound rule by using the destination IP addresses in the network ACL.
- Rejection Reason: A network ACL controls traffic entering or leaving a subnet. However, the destination IP addresses of dropped traffic should generally be blocked on the inbound side of the traffic path, not the outbound side. If the Lambda function only creates an outbound rule based on the destination IP addresses, it would not effectively prevent the traffic from reaching the VPC in the first place. Hence, this option is not appropriate.
Option B: Configure the existing Lambda function to add the source IP addresses of the dropped traffic to each SNS notification. Configure the new Lambda function to create an inbound rule by using the source IP addresses in the network ACL.
- Rejection Reason: The source IP addresses of the traffic that is dropped are irrelevant for preventing traffic from entering the VPC. By blocking inbound traffic based on the source IP, the rule would prevent the traffic from reaching the VPC. However, we need to prevent traffic from leaving the VPC, which is typically done by blocking traffic on the outbound side. This makes the use of source IP addresses for inbound rules unsuitable for the objective of blocking outgoing traffic.
Opt...
Author: Benjamin · Last updated May 16, 2026
A company has multiple VPCs with subnets that use IPv4. Traffic from the VPCs to the internet uses a NAT gateway. The company wants to transition to IPv6.
A network engineer creates multiple IPv6-only subnets in an existing testing VPC. The network engineer deploys a new Amazon EC2 instance that has an IPv6 address into one of the subnets. During testing, the network engineer discovers that the new EC2 instance is not able to communicate wit...
The goal is to enable communication between an IPv6-only EC2 instance and an IPv4-only service on the internet. Let's analyze each option and see how it addresses the requirement.
Option A: Enable DNS64 for the IPv6-only subnets. Update the route tables for the IPv6-only subnets to send traffic through the NAT gateway.
- Rejection Reason: DNS64 is a mechanism that allows IPv6 clients to communicate with IPv4 servers by synthesizing IPv6 addresses for IPv4 resources. However, simply enabling DNS64 and routing traffic through the existing NAT gateway does not solve the problem, because the NAT gateway is only designed to handle IPv4 traffic. A NAT gateway cannot natively support the translation between IPv6 and IPv4. This approach would not allow the EC2 instance to reach the IPv4-only service.
Option B: Enable NAT64 for the testing VPC. Reconfigure the existing NAT gateway to support IPv6.
- Rejection Reason: NAT64 is a mechanism that allows IPv6 clients to communicate with IPv4-only resources by performing address translation. However, NAT64 requires the use of a specific NAT64 gateway, which is not the same as a regular NAT gateway. The existing NAT gateway does not support IPv6-to-IPv4 translation. While reconfiguring the NAT gateway to support IPv6 is a necessary step, it does not directly address the need for IPv6-to-IPv4 translation, which NAT64 is specifically designed for.
Option C: Enable DNS64 for the new EC2 ...
Author: Michael · Last updated May 16, 2026
A company deployed an application in two AWS Regions in one AWS account. The company has one VPC in each Region. The VPCs use non-overlapping private CIDR ranges.
The company needs to connect both VPCs to a single on-premises data center to test the application. The application requires up to 800 Mbps of throughput. A network engineer needs to est...
To establish connectivity between the two VPCs and the on-premises data center with a throughput requirement of up to 800 Mbps, let's evaluate each solution in terms of ease of management, throughput, and overall operational complexity.
Option A: Order a 2 Gbps Direct Connect connection for the data center. Configure a virtual private gateway in each VPC. Create a private VIF for each virtual private gateway, and associate the virtual private gateways with the Direct Connect connection. Configure static routes in the VPC route tables and in the data center router.
- Rejection Reason: While Direct Connect offers a high-speed, dedicated connection with predictable performance, the need to manually configure static routes in both the VPC route tables and the data center router introduces higher operational overhead. This requires ongoing management of route configurations, which may be challenging as the network grows or changes over time. Additionally, using static routing makes it less flexible for dynamic changes or scaling.
Option B: Order a 2 Gbps Direct Connect connection for the data center. Configure a virtual private gateway in each VPC. Create a private VIF for each virtual private gateway, and associate the virtual private gateways with the Direct Connect connection. Configure Open Shortest Path First (OSPF) routing between the private VIF and the data center.
- Rejection Reason: While OSPF provides dynamic routing and better flexibility than static routing, it introduces more complexity in managing the Direct Connect connection and route exchanges. Setting up and managing OSPF requires both operational expertise and coordination between the AWS environment and the on-premises network. Additionally, this setup could be more complex than necessary, especially when simpler solutions can meet the performance requirements.
Option C: Configure a custo...
Author: Noah Williams · Last updated May 16, 2026
A company runs a workload in a single VPC on AWS. The company's architecture contains several interface VPC endpoints for AWS services, including Amazon CloudWatch Logs and AWS Key Management Service (AWS KMS). The endpoints are configured to use a shared security group. The security group is not used for any other workloads or resources.
After a security review of the environment, the company determined that the shared security group is more permissive than necessary. The company wants to make the rules associated with the security group more restrictive. The changes to the security group rules must not prevent the resources in the VPC from using AWS services through interface VPC endpoints. The changes must prevent unnecessary access.
The security group currently uses the ...
To meet the company's requirements of making the security group rules more restrictive while still allowing necessary communication between VPC resources and AWS services through the interface VPC endpoints, let's break down each rule and evaluate which ones can be removed or modified:
Inbound Rules:
- Inbound - Rule 1:
- Protocol: TCP
- Port: 443
- Source: 0.0.0.0/0 (any IP address)
- This rule allows traffic from any IP address to reach the interface VPC endpoints over port 443 (HTTPS). This is very permissive and should be tightened.
- Inbound - Rule 2:
- Protocol: TCP
- Port: 443
- Source: VPC CIDR block
- This rule allows traffic from within the VPC to the interface VPC endpoints over port 443. This is more restrictive and seems necessary for internal communication within the VPC.
Outbound Rules:
- Outbound - Rule 1:
- Protocol: All
- Port: All
- Destination: 0.0.0.0/0 (any IP address)
- This rule allows all outbound traffic to any destination. This is very permissive and should also be tightened, as it opens the door to unnecessary communication.
Evaluation of Each Option:
- A) Outbound - Rule 2:
- There's no "Outbound - Rule 2" in the original configuration, so this...
Author: Liam123 · Last updated May 16, 2026
A company uses transit gateways to route traffic between the company's VPCs. Each transit gateway has a single route table. Each route table contains attachments and routes for the VPCs that are in the same AWS Region as the transit gateway. The route tables in each VPC also contain routes to all the other VPC CIDR ranges that are available through the transit gateways. Some VPCs route to local NAT gateways.
The company plans to add many new V...
To determine the most operationally efficient solution for adding new VPC CIDR ranges to the route tables in each VPC, let's evaluate the options provided:
A) Create a new customer-managed prefix list. Add all VPC CIDR ranges to the new prefix list. Update the route tables in each VPC to use the new prefix list ID as the destination and the appropriate transit gateway ID as the target.
- Explanation: A customer-managed prefix list allows you to group multiple CIDR blocks into a single object, which can then be referenced in route tables. This would be effective if you want to manage a set of CIDR blocks and refer to them consistently across route tables. However, this approach requires manual updates to the route tables whenever a new VPC is added, which can become cumbersome and does not fully automate the process for future VPC additions. This solution is operationally efficient in the short term but can require manual updates as new VPCs are added.
B) Turn on default route table propagation for the transit gateway route tables. Turn on route propagation for each route table in each VPC.
- Explanation: This option enables automatic route propagation, meaning that the transit gateway will automatically propagate routes to the VPC route tables. When a new VPC is connected to the transit gateway, the VPC's CIDR block is automatically added to the appropriate route tables. This is a highly efficient and scalable solution because it automates the process of updating VPC route tables with the correct routes to new VPC CIDR ranges as they are connected to the transit gateway.
- Key Benefit: This solution simplifies the process and scales as the number of VPCs grows. No manual updates to the route tables are required when new VPCs are added.
C) Update the route tables in each VPC to use 0.0.0.0/0 as the destination and the appropriate transit gateway ID as the target.
- Explanation: This ...
Author: Rahul · Last updated May 16, 2026
A company has several AWS Site-to-Site VPN connections between an on-premises customer gateway and a transit gateway. The company's application uses IPv4 to communicate through the VPN connections.
The company has updated the VPC to be dual stack and wants to transition to using IPv6-only for new workloads. When the company tries to com...
To solve the issue of enabling IPv6 support for the AWS Site-to-Site VPN connections with minimal operational overhead, we need to consider the available options in the context of supporting IPv6 traffic for existing and future workloads while keeping the solution simple and efficient.
A) Create a new Site-to-Site VPN connection that supports IPv6.
- Explanation: AWS allows the creation of Site-to-Site VPN connections that support both IPv4 and IPv6 traffic. This approach involves setting up a new VPN connection that can handle IPv6 communication. This solution would require minimal changes to the existing infrastructure, as it leverages AWS’s native support for IPv6 on the VPN connection.
- Key Benefit: Creating a new Site-to-Site VPN connection that supports IPv6 is simple and straightforward. This solution does not require any significant changes to existing configurations but allows for IPv6 traffic to pass through.
- Why Rejected: This option involves creating a new connection. While this might work, it requires a bit of additional setup and changes in both the on-premises network and AWS side. It introduces some operational overhead.
B) Create a new Site-to-Site VPN connection to a self-managed Amazon EC2 instance that runs open source software.
- Explanation: This option suggests setting up a custom VPN solution where an EC2 instance runs open-source VPN software to handle IPv6. This adds complexity and operational overhead because the company would need to manage and maintain the EC2 instance and VPN software itself.
- Why Rejected: This solution introduces unnecessary complexity and operational overhead. Managing custom VPN software is not the most efficient solution, especially when AWS offers native support for IPv6 VPN connections.
C) Update the existing Site-to-Site VPN connections...
Author: Sofia · Last updated May 16, 2026
A company plans to use an Amazon Snowball Edge device to transfer files to the AWS Cloud.Which activities related to a Snowba...
To determine which activities related to an Amazon Snowball Edge device are available to the company at no cost, we need to review the pricing model and the specific usage terms associated with Snowball Edge. AWS charges for various components, such as device usage, data transfer, and the duration of usage. Let’s break down each option to understand their relevance and associated costs.
Option A: "Use of the Snowball Edge appliance for a 10-day period"
- Analysis: When a company rents a Snowball Edge device, they are generally given 10 days of usage for free. The cost is usually incurred after this 10-day period.
- Why selected: This is the correct answer as AWS provides 10 days of free usage for the Snowball Edge appliance. The company can transfer data into AWS during this period without incurring additional costs related to the duration of use.
- Scenario where it might be used: Ideal for companies transferring large amounts of data within a short time frame and aiming to avoid excessive costs. They can plan the transfer to occur within the free 10-day period.
Option B: "The transfer of data out of Amazon S3 and to the Snowball Edge appliance"
- Analysis: AWS does charge for data outbound from S3 to a Snowball Edge device. Data transfer into AWS (from the Snowball Edge device to S3) typically does not incur additional charges, but transferring data out of S3 to the device involves cost.
- Why rejected: This activity is not free and incurs charges ...
