Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company uses a 1 Gbps AWS Direct Connect connection to connect its AWS environment to its on-premises data center. The connection provides employees with access to an application VPC that is hosted on AWS. Many remote employees use a company-provided VPN to connect to the data center. These employees are reporting slowness when they access the application during business hours. On-premises users have started to report similar slowness while they are in the office.
The company plans to build an additional application on AWS. On-site and remote employees will use the additional application. After the deployment of this additional application, the company will need 20% more bandwidth than the compa...
To solve the problem, we need to consider the following key requirements and constraints:
1. Current Issue: Remote employees and on-premises users are experiencing slowness when accessing the application hosted on AWS. This is likely due to congestion on the 1 Gbps Direct Connect connection.
2. Future Growth: The company expects a 20% increase in bandwidth usage, and they want to add resiliency to the AWS connectivity.
3. Budget Constraints: The company has a limited budget, so the solution needs to be cost-effective.
Now let's evaluate each option:
Option A: Set up a new 1 Gbps Direct Connect dedicated connection to accommodate the additional traffic load from remote employees and the additional application. Create a link aggregation group (LAG).
- Analysis: This option involves adding another 1 Gbps Direct Connect connection and aggregating the two connections into a Link Aggregation Group (LAG). This would increase bandwidth capacity by 1 Gbps, giving a total of 2 Gbps. LAG would also provide some level of redundancy and increased reliability. This is a scalable solution that addresses the bandwidth issue.
- Pros:
- It increases the available bandwidth by 1 Gbps, which helps with the increased usage.
- LAG provides resiliency (failover capability) between the two connections, ensuring higher reliability.
- This is a cost-effective solution, as it only requires the addition of a 1 Gbps connection.
- Cons:
- The company would still be limited to 2 Gbps total bandwidth, which might not be enough after the 20% increase, especially with increased usage over time. However, this option is the most balanced in terms of cost and benefit.
Option B: Deploy an AWS Site-to-Site VPN connection to the application VPC. Configure the on-premises routing for the remote employees to connect to the Site-to-Site VPN connection.
- Analysis: This option introduces a VPN connection as an additional way for remote employees to access the application VPC. However, VPN connections are typically less efficient and slower than Direct Connect, especially when dealing with high traffic volumes. Adding a VPN connection could help offload some traffic, but it would introduce additional latency and potential bandwidth limits, which would not fully resolve the slowne...
Author: FrostFalcon88 · Last updated Jul 24, 2026
A company has a global network and is using transit gateways to connect AWS Regions together. The company finds that two Amazon EC2 instances in different Regions are unable to communicate with each other. A network engineer needs to t...
To troubleshoot the connectivity issue between Amazon EC2 instances in different AWS Regions connected via transit gateways, the network engineer needs to:
1. Analyze routing in both the transit gateways and VPC route tables to ensure proper connectivity.
2. Analyze network traffic to ensure that security groups and network ACLs are not blocking the communication.
3. Use the right AWS tools to diagnose both routing and security issues effectively.
Let's evaluate each option:
Option A: Use AWS Network Manager Route Analyzer to analyze routes in the transit gateway route tables and in the VPC route tables. Use VPC flow logs to analyze the IP traffic that security group rules and network ACL rules accept or reject in the VPC.
- Analysis: This option uses AWS Network Manager Route Analyzer, which is designed to help troubleshoot routing issues in global networks using transit gateways. It also uses VPC flow logs to inspect traffic based on security group rules and network ACLs.
- Pros:
- The Route Analyzer is appropriate for analyzing routing between regions via transit gateways.
- VPC flow logs provide insights into whether traffic is allowed or denied by security groups and network ACLs.
- Cons:
- This option is a comprehensive and practical solution, but it doesn't mention a tool specifically designed to verify VPC-level connectivity, which would be helpful in this case.
Option B: Use AWS Network Manager Route Analyzer to analyze routes in the transit gateway route tables. Verify that the VPC route tables are correct. Use AWS Firewall Manager to analyze the IP traffic that security group rules and network ACL rules accept or reject in the VPC.
- Analysis: This option uses AWS Network Manager Route Analyzer to analyze transit gateway routes, but it uses AWS Firewall Manager, which is primarily a tool for managing security policies across accounts. Firewall Manager isn't designed to analyze specific traffic flows or inspect security groups or ACLs in the same detailed way as VPC flow logs.
- Rejected because AWS Firewall Manager is not the right tool for analyzing...
Author: Leah · Last updated Jul 24, 2026
A company needs to transfer data between its VPC and its on-premises data center. The data must travel through a connection that has dedicated bandwidth. The data also must be encrypted in transit. The company has been working with an AWS Partner Network (APN) ...
Let's break down the requirements and look at each option to determine which ones meet the company's needs:
Requirements:
1. Dedicated bandwidth: The data must travel through a connection that has dedicated bandwidth.
2. Encryption in transit: The data must be encrypted while traveling.
3. Working with an APN Partner: The company is working with an AWS Partner Network (APN) Partner to establish the connection.
Analysis of Each Option:
1. A) Request a hosted connection from the APN Partner:
- Explanation: A hosted connection from an APN Partner typically provides dedicated bandwidth. It involves a partner managing the network connection, such as through Direct Connect, to AWS. Since this is usually a private connection, encryption can be handled via an additional layer, but the main characteristic is the dedicated bandwidth.
- Why it's Selected: Meets the dedicated bandwidth requirement, and encryption can be added (typically with IPsec over the dedicated connection).
2. B) Request a hosted public VIF from the APN Partner:
- Explanation: A hosted public Virtual Interface (VIF) is typically used for accessing public AWS services (like S3, DynamoDB) over Direct Connect. However, this type of VIF is not intended for private connectivity to the VPC.
- Why it's Rejected: The requirement specifies a connection to the VPC, so a public VIF is inappropriate. It also does not provide encryption by default.
3. C) Create an AWS Site-to-Site VPN connection:
- Explanation: AWS Site-to-Site VPN allows for encrypted connections over the public internet. This provides encryption, but it does not ensure dedicated bandwidth, as the connection is still subject to internet routing and is not a private, dedicated link.
- Why it's Rejected: Although it provides encryption, it does not meet th...
Author: Leo · Last updated Jul 24, 2026
A company's security guidelines state that all outbound traffic from a VPC to the company's on-premises data center must pass through a security appliance. The security appliance runs on an Amazon EC2 instance. A network engineer needs to improve the network performance between the on-premises dat...
Requirements:
1. Outbound traffic must pass through a security appliance: The appliance runs on an EC2 instance, and all outbound traffic must go through it.
2. Improve network performance: The network engineer needs to enhance the performance of the connection between the on-premises data center and the security appliance, which is running on EC2.
Analysis of Each Option:
1. A) Use an EC2 instance that supports enhanced networking:
- Explanation: EC2 instances that support enhanced networking (using Elastic Network Adapter or ENA) provide higher throughput and lower latency than standard EC2 instances. This is essential for improving the performance of the network traffic that passes through the security appliance.
- Why it's Selected: Enhanced networking improves the EC2 instance's network performance, which directly benefits the traffic flowing through the security appliance, meeting the performance improvement requirement.
2. B) Send outbound traffic through a transit gateway:
- Explanation: A transit gateway can centralize routing and simplify network architecture by connecting VPCs, VPNs, and on-premises networks. However, it does not directly improve the performance of traffic passing through the EC2 security appliance; it is primarily for routing and centralizing network management.
- Why it's Rejected: Although a transit gateway might be useful for routing, it doesn’t specifically enhance network performance between the on-premises data center and the EC2 instance hosting the security appliance.
3. C) Increase the EC2 instance size:
- Explanation: Increasing the EC2 instance size might provide more CPU, RAM, and network throughput, which can improve performance. However, the main focus here is on network performance. Simply increasing the EC2 instance size may not necessarily maximize network throughput compared to enabling enhanced networking.
- Why it's Rejected: While increasing the EC2 inst...
Author: Sofia · Last updated Jul 24, 2026
A company's application team is unable to launch new resources into its VPC. A network engineer discovers that the VPC has run out of usable IP addresses. The VPC CIDR block is 172.16.0....
Requirements:
The VPC has run out of usable IP addresses, and the network engineer needs to add an additional CIDR block to the VPC to resolve the issue.
Analysis of Each Option:
1. A) 172.17.0.0/29:
- Explanation: A `/29` subnet provides only 8 IP addresses (6 usable IP addresses for hosts, 1 network address, and 1 broadcast address). This would provide a very small number of IP addresses, which likely wouldn't address the VPC’s scalability needs, as a larger CIDR block is needed.
- Why it's Rejected: The `/29` block only provides a few IP addresses, which would not significantly help resolve the problem of running out of IP addresses in a `/16` block.
2. B) 10.0.0.0/16:
- Explanation: The `10.0.0.0/16` CIDR block is a private IP address range that is completely distinct from the `172.16.0.0/16` block. It is entirely valid to add this as an additional CIDR block to the VPC. This block provides 65,536 IP addresses, which can significantly expand the available IPs for resources in the VPC.
- Why it's Selected: This is a valid option because it's a new, non-overlapping CIDR block that is not part of the original `172.16.0.0/16` block and provides a large number of IP addresses for future use.
3. C) 172.17.0.0/16:
- Explanation: The `172.17.0.0/16` CIDR block is part o...
Author: Ethan Smith · Last updated Jul 24, 2026
A financial trading company is using Amazon EC2 instances to run its trading platform. Part of the company's trading platform includes a third-party pricing service that the EC2 instances communicate with over UDP on port 50000.
Recently, the company has had problems with the pricing service. Some of the responses from the pricing service appear to be incorrectly formatted and are not being processed successfully. The third-party vendor requests access to the data that the pricing service is returning. The third-party vendor wants to capture request and response data for debugging by logging in to an EC2 instance that ...
Requirements:
1. Capture the traffic between the EC2 instance and the third-party pricing service, particularly the UDP traffic on port 50000.
2. Log analysis should be performed in a dedicated monitoring account, not directly on the production EC2 instances.
3. Prohibit direct access to production systems, and provide the captured data to the third-party vendor for debugging.
Analysis of Each Option:
---
A) 1. Configure VPC flow logs to capture the data that flows in the VPC. 2. Send the data to an Amazon S3 bucket. 3. In the monitoring account, extract the data that flows to the EC2 instance's IP address and filter the traffic for the UDP data. 4. Provide the data to the third-party vendor.
- Explanation: VPC flow logs can capture metadata about traffic (source/destination IPs, ports, protocols, etc.), but VPC flow logs do not capture the actual content of the UDP traffic—they only provide metadata. VPC flow logs are good for basic traffic analysis, but they don't give full visibility into the UDP packets, which is necessary for debugging the format of the pricing service responses.
- Why it's Rejected: This option will not capture the actual content of the UDP traffic, which is essential for identifying issues in the responses from the pricing service. It only gives metadata, not the actual payload, which doesn't meet the requirements.
---
B) 1. Configure a traffic mirror filter to capture the UDP data. 2. Configure Traffic Mirroring to capture the traffic for the EC2 instance's elastic network interface. 3. Configure a packet inspection package on a new EC2 instance in the production environment. Use the elastic network interface of the new EC2 instance as the target for the traffic mirror. 4. Extract the data by using the packet inspection package. 5. Provide the data to the third-party vendor.
- Explanation: Traffic Mirroring captures the actual packet-level data for inspection. This is appropriate for capturing UDP traffic and analyzing the packet content, which is exactly what the third-party vendor needs for debugging. However, performing the packet inspection on an EC2 instance in the production environment contradicts the company's policy of prohibiting direct access to production systems.
- Why it's Rejected: While it captures the correct data, performing the packet inspection within the production environment violates the company's security policy of prohibiting direct access to production systems.
---
C) 1. Configure a traffic mirror filter to capture the UDP data. 2...
Author: VioletCheetah55 · Last updated Jul 24, 2026
A company's network engineer is configuring an AWS Site-to-Site VPN connection between a transit gateway and the company's on-premises network. The Site-to-Site VPN connection is configured to use BGP over two tunnels in active/active mode with equal-cost multi-path (ECMP) routing activated on the transit gateway.
When the network engineer attempts to send traffic from the on-premises network to an Amazon EC2 instance, traffic is sent over the first tunnel. However, return traffic ...
Problem Overview:
The network engineer has set up an AWS Site-to-Site VPN connection using BGP with two active tunnels in active/active mode and ECMP routing. Traffic from the on-premises network is flowing over the first tunnel, but return traffic is coming over the second tunnel and being dropped at the customer gateway, likely because of asymmetric routing. The goal is to resolve the issue without reducing the overall VPN bandwidth.
Key Factors to Consider:
1. Asymmetric Routing: Asymmetric routing occurs when outbound and inbound traffic take different paths, which can lead to dropped packets, especially if the return path (in this case, the second tunnel) isn’t expected or properly configured at the customer gateway.
2. Active/Active Mode with ECMP: Equal-cost multi-path (ECMP) allows traffic to flow over multiple paths with equal cost. However, if the return traffic is routed back on a different tunnel, the customer gateway must be capable of handling that scenario.
Analysis of Each Option:
---
A) Configure the customer gateway to use AS PATH prepending and local preference to prefer one tunnel over the other.
- Explanation: AS path prepending and local preference are BGP techniques to influence routing decisions. By modifying these parameters, the customer gateway can prefer one tunnel for inbound and outbound traffic. While this could solve the asymmetric routing issue by controlling the return path, it may reduce the overall available bandwidth by making one tunnel more preferred, which is against the requirement of maintaining overall VPN bandwidth.
- Why it's Rejected: This option introduces preference to one tunnel, potentially reducing the redundancy and load balancing advantages of the active/active setup. It goes against the requirement to preserve the overall bandwidth utilization by using both tunnels effectively.
---
B) Configure the Site-to-Site VPN options to set the first tunnel as the primary tunnel to eliminate asymmetric routing.
- Explanation: This would force all traffic to flow over the first tunnel, which would eliminate asymmetric routing issues. However, it eff...
Author: Daniel · Last updated Jul 24, 2026
A company runs an application on Amazon EC2 instances. A network engineer implements a NAT gateway in the application's VPC to replace self-managed NAT instances. After the network engineer shifts traffic from the self-managed NAT instances to the NAT gateway, users begin to report issues.
During troubleshooting, the network engineer discovers that...
In this scenario, the users are experiencing connection drops after about 6 minutes of inactivity. This issue is likely related to how the NAT gateway and the application EC2 instances are handling network traffic and idle connections. Let's analyze each option in detail:
Option A:
Check for increases in the IdleTimeoutCount Amazon CloudWatch metric for the NAT gateway. Configure TCP keepalive on the application EC2 instances.
- Why selected?
The NAT gateway has an idle timeout value for connections. When a connection remains idle for a specific period, it might be closed. By checking the IdleTimeoutCount metric in CloudWatch, you can confirm if this is causing the disconnection. Configuring TCP keepalive on the EC2 instances ensures that periodic "pings" are sent to keep the connection active, preventing idle timeouts.
- Why other options are rejected?
- Option B suggests configuring an HTTP timeout, but this is not directly related to TCP connections or idle timeouts managed by the NAT gateway. Also, HTTP timeouts typically apply to web servers rather than ...
Author: Isabella · Last updated Jul 24, 2026
A software-as-a-service (SaaS) company is migrating its private SaaS application to AWS. The company has hundreds of customers that connect to multiple data centers by using VPN tunnels. As the number of customers has grown, the company has experienced more difficulty in its effort to manage routing and segmentation of customers with complex NAT rules.
After the migration to AWS is complete, the company's AWS customers must be able to access the SaaS...
In this scenario, the SaaS company is migrating its private application to AWS and needs to facilitate direct access from AWS customer VPCs and maintain connectivity for on-premises customers through IPsec VPN tunnels. The solution needs to address both customer routing and segmentation efficiently. Let's analyze each option:
Option A:
Connect the AWS customer VPCs to a shared transit gateway. Use AWS Site-to-Site VPN connections to the transit gateway for the on-premises customers.
- Why selected?
A transit gateway is a highly scalable and flexible solution for managing multiple VPCs, allowing AWS customer VPCs to connect to it directly. With this setup, AWS customers can easily access the SaaS application VPC. Additionally, the Site-to-Site VPN connections from the transit gateway provide secure connectivity for on-premises customers. This solution allows for efficient routing and segmentation between AWS customers and on-premises customers while minimizing the need for complex NAT rules or individual VPC peering.
- Why other options are rejected?
- Option B: AWS PrivateLin...
Author: StarlightBear · Last updated Jul 24, 2026
A company's existing AWS environment contains public application servers that run on Amazon EC2 instances. The application servers run in a VPC subnet. Each server is associated with an Elastic IP address.
The company has a new requirement for firewall inspection of all traffic from the internet before the traffic reaches any EC2 instances. A security engineer has deployed and configured a Gateway Load Balancer (GLB...
In this scenario, the company needs to route all incoming traffic from the internet through a fleet of third-party firewalls deployed via a Gateway Load Balancer (GLB). The goal is to ensure that the traffic is inspected before reaching the EC2 instances. Let’s break down the options and determine the most suitable solution.
Option A:
Deploy a transit gateway. Attach a GLB endpoint to the transit gateway. Attach the application VPC to the transit gateway. Update the application subnet route table's default route destination to be the GLB endpoint. Ensure that the EC2 instances' security group allows traffic from the GLB endpoint.
- Why rejected?
- A transit gateway would allow connectivity between multiple VPCs, but this setup would require more complexity, as you’d need to manage additional routing between VPCs (application VPC and standalone VPC for firewalls).
- The transit gateway is best suited for scenarios involving multiple VPCs, but here, since the requirement is only to route internet traffic to firewalls in a standalone VPC, this solution adds unnecessary complexity.
Option B:
Update the application subnet route table to have a default route to the GLB. On the standalone VPC that contains the firewall fleet, add a route in the route table for the application VPC's CIDR block with the GLB endpoint as the destination. Update the EC2 instances' security group to allow traffic from the GLB.
- Why rejected?
- This option suggests modifying the application subnet route table, but it lacks the necessary steps for directing traffic from the internet to the GLB for firewall inspection. It also doesn't address routing traffic between the GLB endpoint and the firewall fleet. It would require further adjustments to ensure traffic flows correctly through the firewall fleet before reaching the application servers.
Option C:
Provision a GLB endpoint in the application VPC in a new subnet. Create a gateway route table with a route that specifies the application subnet CIDR block as the destination and the GLB endpoint as the target. Associate the gateway route table with the internet gateway in the application VPC. Update the application...
Author: Noah · Last updated Jul 24, 2026
A company has an AWS Site-to-Site VPN connection between its office and its VPC. Users report occasional failure of the connection to the application that is hosted inside the VPC. A network engineer discovers in the customer gateway logs that the Internet Key Exchange (IKE) session ends when the con...
When a Site-to-Site VPN connection fails and the Internet Key Exchange (IKE) session goes down, it's essential to bring the session back up as soon as possible to restore connectivity. The Dead Peer Detection (DPD) feature helps detect when the peer (the other end of the VPN connection) is no longer responsive and can trigger an action to either clear, restart, or cancel the session. Let’s analyze the options in detail:
Option A:
Set the dead peer detection (DPD) timeout action to Clear. Initiate traffic from the VPC to on-premises.
- Why rejected?
- DPD action: Clear will immediately clear the VPN connection when the peer is unresponsive. While this can detect an issue and remove the current session, it doesn’t attempt to restart the session. This might result in the connection being terminated without automatically bringing it back up, which doesn’t help with the goal of restoring the IKE session immediately.
- Initiating traffic from the VPC to on-premises does not address the root cause of the issue. If the IKE session has already gone down, the connection would still fail even if traffic is initiated from the VPC.
Option B:
Set the dead peer detection (DPD) timeout action to Restart. Initiate traffic from on-premises to the VPC.
- Why selected?
- DPD action: Restart is the correct approach to automatically attempt to bring the IKE session back up if it goes down. When the IKE session is lost, this action triggers an automatic reconnection, which helps to re-establish the VPN connection without manual intervention.
- Initiating traffic from on-premises to the VPC is a good ...
Author: StarryEagle42 · Last updated Jul 24, 2026
A network engineer is designing a hybrid networking environment that will connect a company's corporate network to the company's AWS environment. The AWS environment consists of 30 VPCs in 3 AWS Regions.
The network engineer needs to implement a solution to centrally filter traffic by using a firewall that the company's security team has approved. The solution must give all the VPCs the ability to ...
The company needs a solution that ensures the ability to centrally filter traffic with a firewall, connects all VPCs across multiple regions, and meets the bandwidth requirement of at least 2 Gbps for connectivity between the corporate network and the AWS environment. Let's break down the options and evaluate which one best meets these requirements.
Option A:
Deploy an IPsec VPN connection between the corporate network and a new transit gateway. Connect all VPCs to the transit gateway. Associate the approved firewall with the transit gateway.
- Why rejected?
- While an IPsec VPN connection is a valid solution for connectivity, it has limitations in terms of scalability and bandwidth. The required 2 Gbps bandwidth might not be achievable with a VPN, especially when connecting multiple VPCs across different regions.
- VPN connections are also less reliable and may introduce latency and packet loss compared to other direct connection options, especially at higher throughput levels.
- The transit gateway would allow central routing, but the VPN tunnel would limit the overall bandwidth and performance.
Option B:
Deploy a single 10 Gbps AWS Direct Connect connection between the corporate network and virtual private gateway of each VPC. Connect the virtual private gateways to a Direct Connect gateway. Build an IPsec tunnel to a new transit VPC. Deploy the approved firewall to the transit VPC.
- Why rejected?
- A single 10 Gbps Direct Connect connection between the corporate network and the virtual private gateway of each VPC is not ideal because Direct Connect should provide a reliable, high-throughput connection. However, this option involves creating IPsec tunnels to a new transit VPC, which complicates the design unnecessarily.
- The IPsec tunnel may limit the throughput and introduce extra overhead compared to using direct connections for routing traffic to the firewall.
- The design also requires traffic to be routed via the transit VPC, which may introduce additional points of failure or performance bottlenecks.
Option C:
Deploy two 1 Gbps AWS Direct Connect connections in different Direct Connect locations to connect to the corporate network. Build a transit VIF on each connection to a Direct Connect gateway. Associate the Direct Connect gateway with a new transit gateway for each Region. Configure the VIFs to use equal-cost multipath (ECMP) routing. Connect all the VPCs in the three Regions to the transit gateway. Configure the transit ga...
Author: Kai · Last updated Jul 24, 2026
A company uses an AWS Direct Connect private VIF with a link aggregation group (LAG) that consists of two 10 Gbps connections. The company's security team has implemented a new requirement for external network connections to provide layer 2 encryption. The company's network team plans to use MACsec support for Direct Conne...
To meet the requirement of enabling MACsec support for Direct Connect using a Link Aggregation Group (LAG), the network team needs to take specific steps. Let's break down the options and reasoning behind them:
Option Analysis:
- A) Create a new Direct Connect LAG with new circuits and ports that support MACsec.
- Reasoning: This is a valid option if the existing LAG does not support MACsec, or if the Direct Connect connections do not have ports or circuits capable of supporting MACsec encryption. This ensures that the Direct Connect connections are built with MACsec support from the start. However, if the existing LAG already supports MACsec, creating a new LAG might not be necessary.
- Rejection: If the current Direct Connect setup already supports MACsec and no hardware or configuration changes are needed for MACsec, this step could be redundant.
- B) Associate the MACsec Connectivity Association Key (CAK) and the Connection Key Name (CKN) with the new LAG.
- Reasoning: MACsec requires the use of a CAK (Connectivity Association Key) for encryption and a CKN (Connection Key Name) to define the key identity. This association is necessary to configure MACsec on the Direct Connect connections. It is required for both new and existing LAGs that use MACsec, but typically, this would apply when creating or modifying an existing LAG to support MACsec.
- Rejection: This option is necessary but only in combination with the correct setup. Without creating or configuring the MACsec encryption mode, just associating CAK and CKN isn't sufficient.
- C) Associate the Internet Key Exchange (IKE) with the existing LAG.
- Reasoning: IKE is typically used for IPsec VPNs, not for MACsec. MACsec doesn't use IKE for key exchange. MACsec uses the CAK for encryption. Therefore, this option is irrelevant for the task of enabling MACsec on Direct Connect.
- Rejection: IKE is unrelated to MACsec and does not apply here.
- D) Configure the MACsec encryption mode on the existing LAG.
- Reasoning: This is a valid step if the existing LAG supports MACsec encryption. Enabling MACsec encryption on the existing LAG e...
Author: Liam · Last updated Jul 24, 2026
A company recently implemented a security policy that prohibits developers from launching VPC network infrastructure. The policy states that any time a NAT gateway is launched in a VPC, the company's network security team must immediately receive an alert to terminate the NAT gateway. The network security team needs to implement a solution that can be deployed across AWS accounts with the least possible ...
Let's analyze the provided options based on the given requirements:
Key Requirements:
1. Alert Network Security Team: An immediate alert should be sent whenever a NAT gateway is launched.
2. Terminate NAT Gateway: The solution must have the capability to terminate the NAT gateway.
3. Minimal Administrative Overhead: The solution should minimize complexity in deployment and management across multiple AWS accounts.
4. View Compliance History: A simple way to track and review the history of compliance actions (such as termination of NAT gateways) is needed.
Option Breakdown:
- A) Develop a script that programmatically checks for NAT gateways in an AWS account, sends an email alert, and terminates the NAT gateway if a NAT gateway is detected. Deploy the script on an Amazon EC2 instance in each account. Use a cron job to run the script every 5 minutes. Log the results of the checks to an Amazon RDS for MySQL database.
- Reasoning: This option requires manually deploying and maintaining an EC2 instance in every AWS account, along with scheduling a cron job to check for NAT gateways. While it technically meets the requirement, this approach introduces significant administrative overhead because of the need to manage EC2 instances, cron jobs, and a separate MySQL database to log results. Additionally, the logs are not as easily accessible or centralized, which increases complexity for compliance tracking.
- Rejection: High administrative overhead, especially for managing EC2 instances in multiple accounts.
- B) Create an AWS Lambda function that programmatically checks for NAT gateways in an AWS account, sends an email alert, and terminates the NAT gateway if a NAT gateway is detected. Deploy the Lambda function to each account by using AWS Serverless Application Model (AWS SAM) templates. Store the results of the checks on an Amazon OpenSearch Service cluster in each account.
- Reasoning: This solution is more serverless, reducing the need to manage EC2 instances. It also uses AWS Lambda, which can scale automatically and be managed centrally. However, deploying the Lambda function in every account using AWS SAM templates still requires a bit of setup. Storing the logs in OpenSearch Service is a feasible option, but OpenSearch might be overkill for simple compliance tracking and alerting.
- Rejection: The complexity of using OpenSearch for logging might be unnecessary, and deploying Lambda functions in each account using SAM templates still requires additional overhead.
...
Author: Vikram · Last updated Jul 24, 2026
A company is running an online game on AWS. The game is played globally and is gaining popularity. Users are reporting problems with the game's responsiveness. Replay rates are dropping, and the company is losing subscribers. Game servers are located in the us-west-2 Region and use an Elastic Load Balancer to distribute client traffic.
The company has decided to deploy game servers to 11 additional AWS Regions to reduce the round-trip times of network traffic to game clients. A network en...
To address the company's need to optimize user traffic and reduce network latency for their game servers deployed across multiple AWS Regions, the network engineer needs to design a DNS solution that ensures users are routed to the game servers with the optimal response time.
Let's evaluate the options:
Option Analysis:
- A) Create Route 53 records for the Elastic Load Balancers in each Region. Specify a weighted routing policy. Calculate the weight by using the number of clients in each Region.
- Reasoning: A weighted routing policy allows routing traffic based on predefined weights. While this approach can distribute traffic based on the number of clients, it does not directly account for latency or network responsiveness. Therefore, the round-trip times to each Region may still be suboptimal for some users, and the solution would not ensure that users are routed to the closest or most responsive servers.
- Rejection: This option does not optimize for low latency, as it relies on client count rather than actual response times or network performance.
- B) Create Route 53 records for the Elastic Load Balancers in each Region. Specify a latency routing policy. Set the Region to the Region where the Elastic Load Balancer is deployed.
- Reasoning: A latency routing policy ensures that traffic is directed to the server with the lowest network latency for the user. Route 53 automatically measures the latency to each Region and routes traffic to the game server with the best performance. This is the best option to meet the requirement of reducing round-trip times and ensuring optimal response times for users, as it dynamically routes traffic based on current network conditions.
- Selection: This option optimizes for the required outcome, directing traffic based on actual latency.
- C) Create Route 53 records for the Elastic Load Balancers in eac...
Author: Benjamin · Last updated Jul 24, 2026
A network engineer needs to build an encrypted connection between an on-premises data center and a VPC. The network engineer attaches the VPC to a virtual private gateway and sets up an AWS Site-to-Site VPN connection. The VPN tunnel is UP after configuration and is working. However, during rekey for phase 2 of the VPN negotiation, the customer gateway device is receiving different parameters than the parameters that the device is configured to support.
The network engineer checks the IPsec configuration of the VPN tunnel. The network engine...
Understanding the Situation:
The issue involves a mismatch in VPN parameters during the phase 2 rekey negotiation, where the customer gateway device is receiving different parameters than what it supports. This can be due to the configuration differences between the on-premises customer gateway device and the AWS Virtual Private Gateway. The customer gateway device is configured with the most secure encryption algorithms offered in the AWS Site-to-Site VPN configuration file.
Key Considerations:
- Phase 2 Rekeying: This refers to the process where the encryption keys for the IPsec VPN tunnel are periodically renegotiated.
- Customer Gateway Configuration: The customer gateway device may be set to use more secure algorithms than what is required or supported by the virtual private gateway.
- Troubleshooting: The issue appears to be caused by a mismatch between the parameters supported by the customer gateway device and the virtual private gateway. This needs to be resolved by ensuring that both sides agree on the encryption algorithms and other parameters used during the tunnel negotiation.
Option Breakdown:
- A) Check the native virtual private gateway logs. Restrict the VPN tunnel options to the specific VPN parameters that the virtual private gateway requires.
- Reasoning: The virtual private gateway is controlled by AWS, and the logs might provide insights into why the negotiation fails. However, it’s more likely that the issue lies with the customer gateway device being configured to use algorithms that are too strong or mismatched with what the virtual private gateway is offering. Restricting the parameters on the AWS side might not be the best option unless it's clear that the virtual private gateway is enforcing restrictions that conflict with the customer gateway settings.
- Rejection: This option focuses on AWS side configurations, but the issue seems to be on the customer gateway side due to parameter mismatches.
- B) Check the native customer gateway logs. Restrict the VPN tunnel options to the specific VPN parameters that the customer gateway requires.
- Reasoning: The customer gateway device is where the mismatch is occurring, and reviewing its logs will give us insight into what parameters it supports and how it is handling the phase 2 rekeying process. If the customer gateway is set to use stronger encrypti...
Author: Ella · Last updated Jul 24, 2026
A company is growing rapidly. Data transfers between the company's on-premises systems and Amazon EC2 instances that run in VPCs are limited by the throughput of a single AWS Site-to-Site VPN connection between the company's on-premises data center firewall and an AWS Transit Gateway.
A network engineer must resolve the throttling by designing a solution that is highly available and secure....
Problem Breakdown:
The company’s current AWS Site-to-Site VPN connection is being throttled due to throughput limitations. The network engineer needs to resolve this issue by scaling the VPN throughput, ensuring high availability, security, and supporting increasing traffic between the on-premises data center and VPC resources.
Key Requirements:
- High Availability: The solution must ensure that there are no single points of failure, ensuring constant connectivity even in case of network issues.
- Secure: The solution should maintain the security of the data transferred between the on-premises network and the VPC.
- Scalable: The solution should allow for increased throughput as traffic grows.
Let’s evaluate the proposed options:
Option Analysis:
- A) Configure multiple dynamic BGP-based Site-to-Site VPN connections to the transit gateway. Configure equal-cost multi-path routing (ECMP).
- Reasoning: This solution involves configuring multiple VPN connections with dynamic BGP (Border Gateway Protocol) for routing and enabling ECMP for load balancing. This provides high availability and scales the throughput by distributing traffic across multiple connections. BGP ensures that the routing between the on-premises data center and AWS is adaptive and efficient. ECMP allows for better utilization of available VPN links, enhancing throughput.
- Selection: This option meets all the key requirements—high availability (multiple connections), security (VPN is inherently secure), and scalability (multiple paths with ECMP for increased throughput).
- B) Configure multiple static routing-based Site-to-Site VPN connections to the transit gateway. Configure equal-cost multi-path routing (ECMP).
- Reasoning: While static routing with ECMP can also scale throughput and provide high availability, it is less flexible than dynamic BGP-based routing. Static routes need to be manually adjusted if network changes occur, and this approach does not dynamically adapt to changes in the network, unlike BGP. BGP is more efficient in handling routing changes, especially in dynamic ...
Author: Maya · Last updated Jul 24, 2026
A company uses Amazon Route 53 to host a public hosted zone for example.com. A network engineer recently reduced the TTL on several records to 60 seconds. The network engineer wants to assess whether the change has increased the number of queries to Route 53 beyond the expected levels that the company identified before the change. The network e...
To determine which solution provides the necessary information about the number of DNS queries made to the example.com public hosted zone, let's review each option:
A) Create a new trail in AWS CloudTrail to include Route 53 data events. Send logs to Amazon CloudWatch Logs. Set up a CloudWatch metric filter to count the number of queries and create graphs.
- CloudTrail logs events related to API activity, but it does not log every individual DNS query. While CloudTrail can be used to track API requests (e.g., record changes to Route 53 records), it does not log DNS queries themselves. Therefore, this option will not provide accurate data regarding the number of DNS queries made to the hosted zone. Rejected for DNS query tracking.
B) Use Amazon CloudWatch to access the AWS/Route 53 namespace and to check the DNSQueries metric for the public hosted zone.
- CloudWatch provides a DNSQueries metric for Route 53 in the AWS/Route 53 namespace. This metric tracks the total number of queries made to a public hosted zone, which is exactly what the network engineer needs to assess the impact of the TTL reduction. This is a direct, relevant metric for monitoring the number of queries for the hosted zone. Selected for DNS query tracking.
C) Use Amazon CloudWatch to access the AWS/Route 53 Resolver namespace and to check the InboundQuery...
Author: Amira · Last updated Jul 24, 2026
A company is establishing connectivity between its on-premises site and an existing VPC on AWS to meet a new security requirement. According to the new requirement, all public DNS queries must use an on-premises DNS security solution. The company's security team has allowed an exception for the AWS service endpoints because the company is using VPC endpoints to...
To meet the security requirement where all public DNS queries should use an on-premises DNS security solution, while allowing exceptions for AWS service endpoints, the network engineer needs to configure a solution that forwards DNS queries from the VPC to the on-premises DNS solution, while ensuring that AWS service endpoints are excluded. Let’s break down the options:
A) Create a system rule for the domain name “.” (dot) with a target IP address of the on-premises DNS security solution.
- A system rule with a domain name of `"."` (the root domain) can be used to forward all DNS queries to the on-premises DNS security solution. This is a broad rule that ensures all queries (for both public and private domains) are directed to the on-premises DNS, except for any exceptions (like service endpoints).
- Selected because this ensures that all DNS queries are routed to the on-premises DNS solution, except where exceptions are configured.
B) Create a new DHCP options set that provides the IP address of the on-premises DNS security solution. Update the VPC to use this new DHCP options set.
- The DHCP options set in a VPC can be used to define custom DNS settings for instances in the VPC. By specifying the IP address of the on-premises DNS security solution in this options set, the instances in the VPC will use the on-premises DNS solution for all DNS queries.
- Selected because this will ensure that the VPC instances are using the on-premises DNS solution for resolving DNS queries, fulfilling the security requirement.
C) Create an Amazon Route 53 Resolver inbound endpoint. Associate this endpoint with the VPC.
- An inbound endpoint in Amazon Route 53 Resolver is used to allow DNS queries to be forwarded from on-premises systems to AWS. However, this is not directly relevant to the requirement of using the on-premises DNS solution for VPC queries. Inbound endpoints are used to resolve DNS queries from on-premises networks into the VPC, which is the opposite direction of what is required in this case.
- Rejected because inbound endpoints are not needed for forwarding DNS queries from the VPC to the on-premises ...
Author: Siddharth · Last updated Jul 24, 2026
A network engineer is designing the DNS architecture for a new AWS environment. The environment must be able to resolve DNS names of endpoints on premises, and the on-premises systems must be able to resolve the names of AWS endpoints. The DNS architecture must give individual accounts the ability to manage subdomains.
The network engineer needs to create a single set of rules that will work across multiple accounts to control this behavi...
To design the DNS architecture to meet the requirements of resolving DNS names between AWS and on-premises systems, while allowing individual accounts to manage subdomains, the network engineer must configure a combination of Amazon Route 53, AWS Directory Service, and Route 53 Resolver rules. Here’s an analysis of each option:
A) Create an Amazon Route 53 private hosted zone for the overall cloud domain. Plan to create subdomains that align to other AWS accounts that are associated with the central Route 53 private hosted zone.
- This option aligns with the requirement of enabling individual accounts to manage subdomains. A central private hosted zone can be created in one AWS account, and subdomains can be delegated to other AWS accounts. This configuration ensures that each account can manage its portion of the DNS namespace while maintaining a central point of control.
- Selected because this architecture supports the delegation of subdomains to individual accounts, which aligns with the requirement for multiple accounts to manage their subdomains.
B) Create AWS Directory Service for Microsoft Active Directory server endpoints in the central AWS account that hosts the private hosted zone for the overall cloud domain. Create a conditional forwarding rule in Microsoft Active Directory DNS to forward traffic to a DNS resolver endpoint on premises. Create another rule to forward traffic between subdomains to the VPC resolver.
- Using AWS Directory Service to manage DNS for Microsoft Active Directory (AD) is helpful in certain enterprise environments, but it's not necessary for the DNS architecture described here. The solution should focus on Amazon Route 53 Resolver for DNS resolution across AWS and on-premises, not necessarily for AD-specific DNS forwarding. Also, the conditional forwarding rule within AD DNS does not provide the flexibility of managing subdomains for individual accounts in AWS.
- Rejected because it introduces unnecessary complexity with AWS Directory Service and is not directly aligned with the requirements.
C) Create Amazon Route 53 Resolver inbound and outbound endpoints in the central AWS account that hosts the private hosted zone for the overall cloud domain. Create a forwarding rule to forward traffic to a DNS resolver endpoint on premises. Create another rule to forward traffic between subdomains to the Resolver inbound endpoint.
- This solution involves Route 53 Resolver inbound and outbound endpoints, which are key for enabling DNS resolution between AWS and on-premises systems. The outbound endpoint forwards DNS queries from the VPC to the on-premises DNS system, while the inbound endpoint allows on-premises systems to resolve AWS-hosted domains. Addition...
Author: Isabella · Last updated Jul 24, 2026
A company wants to migrate its DNS registrar and DNS hosting to Amazon Route 53. The company website receives tens of thousands of visits each day, and the company's current DNS provider cannot keep up. The company wants to migrate as ...
To meet the requirement of migrating DNS hosting to Amazon Route 53 without any downtime, it's crucial to carefully plan the transfer process. Let's analyze each option:
A) Transfer the domain name to Route 53. Create a Route 53 private hosted zone, and copy all the existing DNS records. Update the name servers on the domain to use the name servers that are specified in the newly created private hosted zone.
- Private Hosted Zone is not appropriate for a public-facing domain. A private hosted zone is used for DNS resolution within a VPC and is not accessible from the public internet. Since the company’s website needs to be publicly accessible, a public hosted zone should be used instead.
- Rejected because a private hosted zone would not work for public DNS resolution.
B) Copy all DNS records from the existing DNS servers to a Route 53 private hosted zone. Update the name servers with the existing registrar to use the private hosted zone name servers. Transfer the domain name to Route 53. Ensure that all the changes have propagated.
- Similar to option A, this solution uses a private hosted zone, which is not suitable for a public website. Additionally, even if the domain is transferred later, using a private hosted zone for a public domain would result in DNS resolution issues.
- Rejected because private hosted zones cannot be used for public DNS queries.
C) Transfer the domain name to Route 53. Create a Route 53 public hosted zone, and copy all the existing DNS records. Set the TTL value on each record to 1 second. Update the name servers on the domain to use the name servers that are specified in the newly created public hosted zone.
- Public Hosted Zone is appropriate for the company's domain since it’s a public website. However, this approach may cause DNS propagation delays, as transferring the domain to Route 53 and updating...
Author: Deepak · Last updated Jul 24, 2026
A company has an AWS account with four VPCs in the us-east-1 Region. The VPCs consist of a development VPC and three production VPCs that host various workloads.
The company has extended its on-premises data center to AWS with AWS Direct Connect by using a Direct Connect gateway. The company now wants to establish connectivity to its production VPCs and development VPC from on premises. The production VPCs are allowed to route data to each other. However, the development VPC must be isolated from the production VPCs. No data can flow between the development VPC and the production VPCs.
In preparation to implement this solution, a network engineer creates a transit gateway with a single transit gateway route table. Default route table association and default route table propagation are turned off. The net...
To meet the requirement of establishing connectivity between the on-premises data center and the VPCs while isolating the development VPC from the production VPCs, the network engineer needs to carefully configure the transit gateway and route tables. Let's break down each option and determine the best course of action:
A) Associate the production VPC attachments with the existing transit gateway route table. Propagate the routes from these attachments.
- Production VPC attachments should be associated with the existing transit gateway route table to allow routing between the production VPCs and the on-premises network. Propagating the routes from these attachments ensures that the production VPCs can route traffic to each other and to the on-premises network via the transit gateway.
- Selected because this step ensures that the production VPCs are correctly routed and able to communicate with on-premises through the transit gateway.
B) Associate all the attachments with the existing transit gateway route table. Propagate the routes from these attachments.
- Associating all attachments with the existing route table and propagating the routes might seem logical, but this would violate the isolation requirement between the development and production VPCs. The development VPC should not be able to route traffic to production VPCs, so including all attachments in the same route table would allow undesired communication between the development and production VPCs.
- Rejected because this would break the isolation between the development and production VPCs.
C) Associate the Direct Connect gateway attachment with the existing transit gateway route table. Propagate the Direct Connect gateway attachment to this route table.
- Associating the Direct Connect gateway with the transit gateway allows on-premises traffic to flow into AWS via Direct Connect. Propagating this attachment ensures that on-premises traffic can reach the VPCs via the transit gateway. This is a necessary step to enable connectivity between on-premises and AWS.
- Selected because this is required for on-premises connectivity.
D) Change the security group inbound rules on the existing transit gateway network interfaces in the development VPC to allow connections to and from the on-premises CIDR range only.
- Security group changes...
Author: Liam · Last updated Jul 24, 2026
A network engineer needs to provide dual-stack connectivity between a company's office location and an AWS account. The company's on-premises router supports dual-stack connectivity, and the VPC has been configured with dual-stack support. The company has set up two AWS Direct Connect connections to the office location. This connecti...
To meet the dual-stack connectivity requirements between a company's office location and AWS with high availability and low latency, let's break down the solutions provided and evaluate them based on the key factors such as dual-stack support, high availability, and performance.
Key Factors:
1. Dual-Stack Support: The solution must support both IPv4 and IPv6 to meet the dual-stack requirement. This means both IPv4 and IPv6 must be properly peered and advertised over AWS Direct Connect.
2. High Availability: The solution must ensure high availability through redundancy. The use of two AWS Direct Connect connections implies the need for routing failover between these connections, which can be achieved using Border Gateway Protocol (BGP) and potentially Bidirectional Forwarding Detection (BFD).
3. Low Latency: The solution must minimize any latency due to configuration or network failover.
Option Breakdown:
- A) Configure a single private VIF on each Direct Connect connection. Add both IPv4 and IPv6 peering to each private VIF. Configure the on-premises equipment with the AWS provided BGP neighbors to advertise IPv4 routes on the IPv4 peering and IPv6 routes on the IPv6 peering. Enable Bidirectional Forwarding Detection (BFD) on all peering sessions.
- Explanation: This solution uses a single private VIF per Direct Connect connection for both IPv4 and IPv6. While this approach allows dual-stack support, it does not provide redundancy for both IPv4 and IPv6 peering separately, which could lead to a potential single point of failure if one of the VIFs fails. It does meet the requirement of high availability via BFD, but redundancy is compromised because there is only one VIF per connection.
- Rejected: This solution doesn't provide the desired redundancy and separation of the IPv4 and IPv6 address families across different VIFs, which is important for a highly available, low-latency solution.
- B) Configure two private VIFs on each Direct Connect connection: one private VIF with the IPv4 address family and one private VIF with the IPv6 address family. Configure the on-premises equipment with the AWS provided BGP neighbors to advertise IPv4 routes on the IPv4 peering and IPv6 routes on the IPv6 peering. Enable Bidirectional Forwarding Detection (BFD) on all peering sessions.
- Explanation: This option provides separate VIFs for IPv4 and IPv6, which enhances redundancy and ensures that each address family has a dedicated path. It also supports the use of BFD for fast detection of failures and high availability. This configuration also provides better performance, as failure or issues with one address family (IPv4 or IPv6) won’t affect the other.
- Selected: This is a good option as it meets the requirements of dual-stack connectivity, high availability (via BFD), and redundancy (separate VIFs for each address family).
- C) Configure a single private VIF and IPv4 peering on each Direct Connect connection. Configure the on-premises equipment with this peering to advertise the IPv6 routes in the same BGP neighbor configuration. Enable Bidirectional Forwarding Detection (BFD) on all peering sessions.
- Explanation: This option only provides IPv4 peering on the VIF a...
Author: Krishna · Last updated Jul 24, 2026
A company recently started using AWS Client VPN to give its remote users the ability to access resources in multiple peered VPCs and resources in the company's on-premises data center. The Client VPN endpoint route table has a single entry of 0.0.0.0/0. The Client VPN endpoint is using a new security group that has no inbound rules and a single outbound rule that allows all traffic to 0.0.0.0/0.
Multiple remote users report that web search results are showing i...
The issue here involves remote users experiencing incorrect geographic location information when performing web searches while connected via AWS Client VPN. This is likely caused by traffic routing through the VPN and using the AWS region's public IP address, which results in location discrepancies. We need to resolve this issue with minimal disruption.
Key Factors:
1. Geographic Location Information Issue: This suggests that the users’ traffic is being routed through the AWS region, not their actual geographic location.
2. Service Interruption: The solution should minimize service disruption for remote users, as the goal is to avoid downtime or major changes.
3. Network Traffic Routing: Since the Client VPN is configured with a `0.0.0.0/0` route, it implies that all traffic from the remote users is being routed through the VPN tunnel, causing all traffic to appear to come from the AWS region.
Option Breakdown:
- A) Switch users to AWS Site-to-Site VPNs.
- Explanation: AWS Site-to-Site VPN is designed for site-to-site connectivity, not for remote users. Switching to this would require significant changes to the infrastructure, and it would cause service disruption. It does not directly address the issue of geographic location.
- Rejected: Not the best option, as it changes the setup to something that is not suited for individual remote users and introduces unnecessary complexity.
- B) Enable the split-tunnel option on the Client VPN endpoint.
- Explanation: Enabling split tunneling allows remote users' traffic to be routed to the internet directly (bypassing the VPN) while only the traffic destined for the VPC or on-premises data center goes through the VPN. This would allow users to access the internet from their actual geographic location, fixing the geographic issue in web searches.
- Selected: This option addresses the geographic location issue and reduces traffic through the VPN for internet-bound traffic, providing a simple solution with minimal disruption.
- C) Add routes for the peered VPCs and for the on-premises data center to the Client VPN route table.
- Explanation: Adding the necessary routes for the peered VPCs and on-premises data center will allow proper routing to those networks. However, this does not address the geographic issue directly and will only affect the internal routing within AWS or between AWS and on-premises networks. It doesn’t resolve the root cause of incorrect geographic ...
Author: Sofia · Last updated Jul 24, 2026
A company has set up hybrid connectivity between its VPCs and its on-premises data center. The company has the on-premises.example.com subdomain configured at its DNS server in the on-premises data center. The company is using the aws.example.com subdomain for workloads that run on AWS across different VPCs and accounts. Resources in both environments can access each other by using IP addresses. The company wants workloads in...
The company wants to allow workloads in its VPCs to access on-premises resources using the `on-premises.example.com` DNS names, with minimal management of resources. Let's analyze the options based on key factors such as ease of setup, scalability, and management overhead.
Key Factors:
1. DNS Resolution: The solution must ensure that DNS queries from the VPC can resolve `on-premises.example.com` to the correct on-premises resources.
2. Minimal Management: The company aims to minimize management overhead. This suggests a solution that integrates seamlessly with existing AWS infrastructure and avoids the need to manage custom EC2 instances or manual configurations.
3. Hybrid Connectivity: The solution should leverage the existing hybrid connectivity (e.g., VPN, Direct Connect) between the VPC and on-premises data center.
Option Breakdown:
- A) Create an Amazon Route 53 Resolver outbound endpoint. Configure a Resolver rule that conditionally forwards DNS queries for on-premises.example.com to the on-premises DNS server. Associate the rule with the VPCs.
- Explanation: This option creates an outbound endpoint for Amazon Route 53 Resolver, which allows DNS queries from AWS VPCs to be forwarded to the on-premises DNS server. By configuring a conditional forwarding rule, queries for `on-premises.example.com` will be forwarded to the on-premises DNS server. This is a highly scalable and managed solution, as AWS handles the DNS forwarding and resolution without requiring custom instances.
- Selected: This option is the most efficient because it minimizes the need for manual management (no need to launch and manage EC2 instances). It integrates well with AWS DNS services and requires minimal setup, while being scalable for multiple VPCs and environments.
- B) Create an Amazon Route 53 Resolver inbound endpoint and a Resolver outbound endpoint. Configure a Resolver rule that conditionally forwards DNS queries for on-premises.example.com to the on-premises DNS server. Associate the rule with the VPCs.
- Explanation: This solution involves both an inbound and outbound Route 53 Resolver endpoint. The inbound endpoint is typically used for resolving DNS queries from on-premises to AWS, while the outbound endpoint is used for sending DNS queries from AWS to on-premises. While it allows bidirectiona...
Author: Nia · Last updated Jul 24, 2026
A company is in the early stage of AWS Cloud adoption. The company has an application that is running in an on-premises data center in Asia. The company needs to deploy new applications in the us-east-1 Region. The applications in the cloud need connectivity to the on-premises data center.
The company needs to set up a communication channel between AWS and the data center. The solution must improve latency, minimize the possibi...
The company needs a communication channel between its AWS infrastructure (in the us-east-1 region) and its on-premises data center in Asia. The primary goals are to improve latency, minimize performance impact due to transcontinental routing over the public internet, and encrypt data in transit. Additionally, the solution must be set up in the least amount of time.
Key Factors for Decision:
1. Latency: Since the data center is in Asia, the solution should avoid relying on the public internet for transcontinental routing as much as possible. This reduces latency and minimizes performance degradation.
2. Encryption: The solution must ensure secure communication between AWS and the on-premises data center.
3. Time to Deploy: The solution should be fast to implement, ideally using fully managed services.
4. Scalability: The solution should allow for easy expansion as the company scales its applications.
Option Breakdown:
- A) Create an AWS Site-to-Site VPN connection with acceleration turned on. Create a virtual private gateway. Attach the Site-to-Site VPN connection to the virtual private gateway. Attach the virtual private gateway to the VPC where the applications will be deployed.
- Explanation: This option involves creating a Site-to-Site VPN with acceleration turned on, which uses AWS's VPN acceleration feature to optimize the connection performance. It uses a virtual private gateway to attach the VPN to the VPC. This option would be fast to deploy, as AWS VPN connections are simple to configure and do not require a physical infrastructure setup. However, it still relies on the public internet, so it might not completely minimize latency or prevent potential performance issues over transcontinental routing, despite the use of VPN acceleration.
- Rejected: While VPN with acceleration is a good solution for secure connections, it still relies on the public internet, which could be susceptible to latency and performance degradation.
- B) Create an AWS Site-to-Site VPN connection with acceleration turned on. Create a transit gateway. Attach the Site-to-Site VPN connection to the transit gateway. Create a transit gateway attachment to the VPC where the applications will be deployed.
- Explanation: This option introduces a transit gateway, which simplifies network management, especially when dealing with multiple VPCs or complex networking configurations. However, using VPN acceleration over a transit gateway does not address the concern of minimizing latency from transcontinental routing. The transit gateway adds complexity without solving the main issue of reducing latency between regions.
...
Author: Sofia · Last updated Jul 24, 2026
A company is moving its record-keeping application to the AWS Cloud. All traffic between the company's on-premises data center and AWS must be encrypted at all times and at every transit device during the migration.
The application will reside across multiple Availability Zones in a single AWS Region. The application will use existing 10 Gbps AWS Direct Connect dedicated connections with a MACsec capable port. A network engineer must ensure that the Direct Connect connection is secured accordingly at every transit device.
The net...
The company is moving its record-keeping application to AWS and needs to ensure that all traffic between its on-premises data center and AWS is encrypted using MACsec (Media Access Control Security) for encryption at every transit device during the migration. The company already has 10 Gbps AWS Direct Connect dedicated connections with MACsec capable ports and has created the Connection Key Name (CKN) and Connectivity Association Key (CAK) pair for the MACsec secret key.
The engineer needs to configure the Direct Connect connection with the appropriate encryption settings to ensure security at every transit device.
Key Factors:
1. MACsec Encryption: To ensure encryption, MACsec must be enabled on the Direct Connect connection.
2. CKN/CAK Pair: This pair must be associated with the connection to enable MACsec encryption.
3. Encryption Mode: The MACsec encryption mode defines how encryption is applied. There are different levels of enforcement:
- must_encrypt: Traffic must be encrypted.
- should_encrypt: Encryption is recommended, but not strictly required.
Option Breakdown:
- A) Configure the on-premises router with the MACsec secret key.
- Explanation: While configuring the on-premises router with the MACsec secret key is essential to establish MACsec encryption, this step alone does not directly involve AWS Direct Connect. The network engineer is tasked with configuring AWS settings, not the on-premises router.
- Rejected: Although configuring the router with the MACsec secret key is necessary for the encryption to work, it is not part of the specific steps required for setting up the connection within AWS.
- B) Update the connection's MACsec encryption mode to must_encrypt. Then associate the CKN/CAK pair with the connection.
- Explanation: Setting the encryption mode to must_encrypt enforces that all traffic between the AWS environment and the on-premises data center is encrypted using MACsec. Associating the CKN/CAK pair ensures that the proper secret key is used for encryption. This ensures the highest level of security.
- Selected: Thi...
Author: Deepak · Last updated Jul 24, 2026
A network engineer is designing hybrid connectivity with AWS Direct Connect and AWS Transit Gateway. A transit gateway is attached to a Direct Connect gateway and 19 VPCs across different AWS accounts. Two new VPCs are being attached to the transit gateway. The IP address administrator has assigned 10.0.32.0/21 to the first VPC and 10.0.40.0/21 to the second VPC. The prefix list has one CIDR block remaining before th...
In this scenario, the network engineer is managing the integration of AWS Direct Connect with AWS Transit Gateway and has encountered a situation where there is a constraint on the maximum number of CIDR blocks in a prefix list. Specifically, the engineer must find a way to advertise routes to on-premises while adhering to this constraint.
Let's evaluate the options:
A) Add 10.0.32.0/21 and 10.0.40.0/21 to both AWS managed prefix lists.
- Problem: AWS managed prefix lists have a limit on the number of CIDR blocks they can contain. By adding two additional /21 blocks (10.0.32.0/21 and 10.0.40.0/21) to the AWS-managed prefix list, the network engineer would quickly hit the quota for the number of entries in the prefix list. Since only one CIDR block is available before the prefix list reaches its limit, this option would not be feasible.
- Rejection Reason: This option is rejected because it will exceed the quota for entries in the AWS managed prefix list.
B) Add 10.0.32.0/21 and 10.0.40.0/21 to the allowed prefix list.
- Problem: The allowed prefix list is used to control the prefixes that can be advertised to AWS resources. However, the problem lies in the fact that the prefix list can only hold a limited number of entries, and with the remaining quota being one CIDR block, adding two separate /21 blocks would exceed this limit.
- Rejection Reason: This option is rejected because adding both /21 CIDR blocks would exceed the remaining capacity of the prefix list.
C) Add 10.0.32.0/20 to bo...
Author: IceDragon2023 · Last updated Jul 24, 2026
Two companies are merging. The companies have a large AWS presence with multiple VPCs and are designing connectivity between their AWS networks. Both companies are using AWS Direct Connect with a Direct Connect gateway. Each company also has a transit gateway and multiple AWS Site-to-Site VPN connections from its transit gateway to on-premise...
In this scenario, the two companies are merging, and the goal is to optimize network visibility, throughput, logging, and monitoring. The companies already have AWS Direct Connect with transit gateways and Site-to-Site VPN connections. To meet these objectives, we need to consider how to best integrate the two networks and enhance visibility and monitoring.
Let’s evaluate each option carefully:
A) Configure a Site-to-Site VPN connection between each company's transit gateway to establish reachability between the respective networks. Configure VPC Flow Logs for all VPCs. Publish the flow logs to Amazon CloudWatch. Use VPC Reachability Analyzer to monitor connectivity.
- Explanation: This option establishes Site-to-Site VPN connections between each company’s transit gateway, which can provide connectivity. It also configures VPC Flow Logs to track network traffic and publishes them to CloudWatch for monitoring. VPC Reachability Analyzer is useful for testing connectivity between VPCs or resources. However, while the VPC Reachability Analyzer helps with testing specific routes, it doesn’t provide ongoing, real-time monitoring or centralized visibility of all transit gateways, connections, or peering links.
- Rejection Reason: This option lacks a comprehensive monitoring solution for the entire transit gateway setup, especially across multiple VPCs and AWS environments. It is not optimized for monitoring at a larger scale (e.g., peering links, overall network visibility).
B) Configure a Site-to-Site VPN connection between each company's transit gateway to establish reachability between the respective networks. Configure VPC Flow Logs for all VPCs. Publish the flow logs to Amazon CloudWatch. Use AWS Transit Gateway Network Manager to monitor the transit gateways and their respective connections.
- Explanation: This option uses Site-to-Site VPN connections for reachability and VPC Flow Logs to monitor traffic. AWS Transit Gateway Network Manager is a centralized tool for monitoring and managing AWS Transit Gateways. It provides visibility into the network, monitoring connections, and understanding the health and status of each transit gateway and its links. While it’s a better solution than option A for monitoring, it still relies on VPNs for interconnectivity, which may not be the most optimized solution for throughput and performance.
- Rejection Reason: While this option improves monitoring and visibility, using VPNs for in...
Author: Sofia2021 · Last updated Jul 24, 2026
A company has a single VPC in the us-east-1 Region. The company is planning to set up a new VPC in the us-east-2 Region. The existing VPC has an AWS Site-to-Site VPN connection to the company's on-premises environment and uses a virtual private gateway.
A network engineer needs to implement a solution to establish connectivity between the existing VPC and the new VPC. The solution also must implement support ...
To meet the requirements of connecting the existing VPC in the us-east-1 region with the new VPC in the us-east-2 region, while also ensuring IPv6 support and facilitating on-premises access, let’s evaluate the options:
A) Create a new virtual private gateway in us-east-1. Attach the new virtual private gateway to the new VPC. Create two new Site-to-Site VPN connections to the new virtual private gateway with IPv4 and IPv6 support. Configure routing between the VPCs by using VPC peering.
- Explanation: This option suggests creating a new virtual private gateway in us-east-1 and connecting it to the new VPC in us-east-2. It uses Site-to-Site VPN connections with both IPv4 and IPv6 support. While VPC peering could be used for routing between the two VPCs, VPC peering does not support IPv6 routing across regions, and VPC peering is not ideal for cross-region connectivity if VPN connections are involved. Additionally, it introduces complexity by requiring the management of two separate VPN connections and the virtual private gateway, which would not be scalable.
- Rejection Reason: VPC peering across regions does not support IPv6, and this approach would require managing two different Site-to-Site VPN connections for the IPv4 and IPv6 traffic separately, which is inefficient.
B) Create a transit gateway in us-east-1 and in us-east-2. Attach the existing VPC and the new VPC to each transit gateway. Create a new Site-to-Site VPN connection to each transit gateway with IPv4 and IPv6 support. Configure transit gateway peering. Configure routing between the VPCs and the on-premises environment.
- Explanation: This option involves creating a transit gateway in both regions, attaching the respective VPCs to each, and establishing Site-to-Site VPN connections with IPv4 and IPv6 support. Transit gateway peering would be used to allow the two transit gateways to communicate with each other. While this solution allows for multi-region connectivity, it introduces the complexity of managing two separate transit gateways and associated VPN connections. This is a feasible solution but may be an overcomplicated approach when simpler options are available.
- Rejection Reason: While this solution can work, using two transit gateways increases complexity and cost, especially when only a single transit gateway per region can suffice.
C) Create a new virtual private gateway in us-east-2. Attach the new...
Author: Matthew · Last updated Jul 24, 2026
A network engineer is working on a private DNS design to integrate AWS workloads and on-premises resources. The AWS deployment consists of five VPCs in the eu-west-1 Region that connect to the on-premises network over AWS Direct Connect. The VPCs communicate with each other by using a transit gateway. Each VPC is associated with a private hosted zone that uses the aws.example.internal domain. The network engineer creates an Amazon Route 53 Resolver outbound endpoint in a shared services VPC and attaches the shared services VPC to the transit gateway.
The network engineer is implementing a solution for D...
In this scenario, the network engineer needs to implement a solution that resolves DNS queries for AWS-hosted workloads using private hosted zones and forwards all other DNS queries to an on-premises DNS resolver. Let’s evaluate the options in detail:
A) Add a forwarding rule for “” that targets the on-premises server's DNS IP address. Add a system rule for aws.example.internal that targets Route 53 Resolver.
- Explanation:
- The rule for “” would forward all queries to the on-premises DNS resolver, which would handle any DNS queries that do not match the `aws.example.internal` domain.
- The system rule for `aws.example.internal` would ensure that queries for the AWS workloads are resolved using the private hosted zone in Route 53.
- Accepted Reasoning: This option ensures that DNS queries for `aws.example.internal` are resolved by the Route 53 Resolver, while all other queries are forwarded to the on-premises DNS server.
- Why it's correct: This solution meets the requirement to use the private hosted zone for `aws.example.internal` and forward all other queries to the on-premises DNS resolver.
B) Add a forwarding rule for aws.example.internal that targets Route 53 Resolver. Add a system rule for “.” that targets the Route 53 Resolver outbound endpoint.
- Explanation:
- The forwarding rule for `aws.example.internal` would direct these queries to Route 53 Resolver, which is appropriate for AWS-related DNS queries.
- The system rule for “.” targets the Route 53 Resolver outbound endpoint, meaning it would forward all root domain queries (including any queries that don't match the private hosted zone for `aws.example.internal`) to the Route 53 Resolver.
- Rejection Reason: This approach is incorrect because the system rule for “.” targets all DNS queries, including `aw...
Author: Daniel · Last updated Jul 24, 2026
A global film production company uses the AWS Cloud to encode and store its video content before distribution. The company's three global offices are connected to the us-east-1 Region through AWS Site-to-Site VPN links that terminate on a transit gateway with BGP routing activated.
The company recently started to produce content at a higher resolution to support 8K streaming. The size of the content files has increased to three times the size of the content files from the previous ...
To reduce the upload times for large video files from the global offices to Amazon EC2 instances, it’s essential to address factors such as bandwidth, latency, and network efficiency. Let’s analyze the options based on these criteria:
A) Create a second VPN tunnel from each office location to the transit gateway. Activate equal-cost multi-path (ECMP) routing.
- Explanation: Adding a second VPN tunnel from each office and enabling ECMP routing would effectively distribute the traffic load between two separate tunnels, increasing overall bandwidth and improving the upload speed. With ECMP, traffic can be load-balanced across multiple paths, which can help optimize the network for large file transfers.
- Why it’s selected: This option improves network capacity and redundancy, which could significantly reduce the upload times by utilizing multiple VPN paths. This approach directly addresses the issue of slow uploads by enhancing throughput.
B) Modify the transit gateway to activate Jumbo MTU on the VPN tunnels to each office location.
- Explanation: Jumbo MTU allows for larger packet sizes (up to 9001 bytes, compared to the default 1500 bytes). This can reduce the number of packets that need to be sent over the network, thereby improving efficiency and reducing the overhead of packet fragmentation. Larger MTU sizes can optimize the transfer of large files, such as video content.
- Why it’s selected: Enabling Jumbo MTU could improve the performance of file transfers, especially for large files like video content, by reducing overhead and improving efficiency.
C) Replace the existing VPN tunnels with new tunnels that have acceleration activated.
- Explanation: AWS Site-to-Site VPN supports AWS VPN acceleration, which helps improve the performance of VPN connections, particularly for high-throughput applications. VPN acceleration uses a combination of AWS hardware and software optimizations to enhance throughput, reduce latency, and speed up data transfers.
- Why it’s rejected: While VPN acceleration can help with th...
Author: Lucas Carter · Last updated Jul 24, 2026
An application team for a startup company is deploying a new multi-tier application into the AWS Cloud. The application will be hosted on a fleet of Amazon EC2 instances that run in an Auto Scaling group behind a publicly accessible Network Load Balancer (NLB). The application requires the clients to work with UDP traffic and TCP traffic.
In the near term, the application will serve only users within the same geographic location. The application team plans to extend the application to a global audience and will move the deployment to multiple AWS Regions around the world to bring the application closer to the end users. The application team wants to use the new Regions to deploy new versions of the application and wants to be ...
In this scenario, the application team needs to deploy a multi-tier application across multiple AWS Regions and manage traffic distribution during rollouts. The team also wants to minimize latency and jitter and ensure precise traffic control. Let’s break down each option based on the requirements:
A) Create an Amazon CloudFront distribution to align to each Regional deployment. Set the NLB for each Region as the origin for each CloudFront distribution. Use an Amazon Route 53 weighted routing policy to control traffic to the newer Regional deployments.
- Pros:
- CloudFront can help with global content delivery by caching content at edge locations, reducing latency for users.
- Route 53 weighted routing gives the ability to control the amount of traffic going to each region during rollouts.
- Cons:
- CloudFront is designed for HTTP/HTTPS traffic primarily, which may not be optimal for handling UDP traffic (which is a requirement for this application). While CloudFront can handle TCP traffic, it doesn't natively support UDP traffic.
- Managing traffic across multiple regions could be more complex since CloudFront is best suited for static content, not as much for dynamic application traffic in this specific use case.
Rejected: Not ideal due to CloudFront’s lack of native UDP support and the complexity of routing for dynamic application traffic.
B) Create an AWS Global Accelerator accelerator and listeners for the required ports. Configure endpoint groups for each Region. Configure a traffic dial for the endpoint groups to control traffic to the newer Regional deployments. Register the NLBs with the endpoint groups.
- Pros:
- Global Accelerator is optimized for both TCP and UDP traffic, which is a requirement for this application.
- Provides low-latency routing based on global health and geography.
- Traffic dials offer precise control over traffic distribution to newer Regional deployments.
- Can handle both UDP and TCP protocols, ensuring minimal jitter and latency.
- Directly integrates with NLBs, making it well-suited for managing EC2 instances and their auto scaling groups.
- Cons:
- Global Accelerator introduces additional cost for using its service, but this is justified given its low-latency routing capabilities and support for both TCP and UDP.
Selected option: This option is well-suited to the application’s needs because it suppo...
Author: Ella · Last updated Jul 24, 2026
A company is deploying a new stateless web application on AWS. The web application will run on Amazon EC2 instances in private subnets behind an Application Load Balancer. The EC2 instances are in an Auto Scaling group. The web application has a stateful management application for administration that will run on EC2 instances that are in a separate Auto Scaling group.
The company wants to access the management application by using the same URL as the web application, with a path prefix of/management. The protocol, hostname, and port number must be the same for the web application and the management application. Access to the managem...
Understanding the Requirements:
- Web application: Stateless, running in an Auto Scaling group behind an Application Load Balancer (ALB) in private subnets.
- Management application: Stateful, running in a separate Auto Scaling group behind the same ALB but accessed by appending `/management` to the same URL.
- Access restriction: Only on-premises IP addresses should have access to the management application.
- SSL/TLS: AWS Certificate Manager (ACM) will be used to protect the web application.
Breakdown of the Options:
A) Insert a rule for the load balancer HTTPS listener. Configure the rule to check the path-pattern condition type for the /management prefix and to check the source-ip condition type for the on-premises IP address space. Forward requests to the management application target group if there is a match. Edit the management application target group and enable stickiness.
- Explanation:
- This option inserts a rule into the ALB HTTPS listener, which matches requests with the `/management` path pattern.
- It adds a source IP condition to restrict access to the management application to the on-premises IP address space.
- Stickiness is enabled for the management application target group, ensuring that a user’s requests are routed to the same EC2 instance for the duration of their session.
- Why selected: This solution meets the key requirements: routing based on both path prefix and IP source, and restricting access to the management application to on-premises IPs. The path `/management` will match the management application, and the source IP restriction ensures that only on-premises clients can access it.
Selected: This option addresses the required functionality correctly.
B) Modify the default rule for the load balancer HTTPS listener. Configure the rule to check the path-pattern condition type for the /management prefix and to check the source-ip condition type for the on-premises IP address space. Forward requests to the management application target group if there is not a match. Enable group-level stickiness in the rule attributes.
- Explanation:
- Modifying the default rule changes how the ALB handles requests that do not match `/management`, which is unnecessary in this case. You want requests with the `/management` path to go to the management application.
- This rule forwards requests without the `/management` prefix to the management application, which is incorrect and could lead to unintended routing of non-management traffic to the management target group.
- Stickiness is enabled, but the routing behavior is flawed because the condition for `/management` is not applied correctly.
Rejected: The routing logic here is incorrect and doesn’t match the required conditions for the `/management` path prefix.
...
Author: VenomousSerpent42 · Last updated Jul 24, 2026
A company deploys a software solution on Amazon EC2 instances that are in a cluster placement group. The solution's UI is a single HTML page. The HTML file size is 1,024 bytes. The software processes files that exceed 1,024 MB in size. The software shares files over the network to clients upon request. The files are shared with the Don't Fragment flag set. Elastic network interfaces of the EC2 instances are set up with jumbo frames.
The UI is always accessible from all allowed source IP addresses, regardless of whether the source IP addresses are within a VPC, on the in...
Understanding the Problem:
- The software solution is deployed on Amazon EC2 instances in a cluster placement group, which ensures high network performance between instances.
- The solution's UI is a small HTML file (1,024 bytes), while the software processes large files (over 1,024 MB) that need to be transferred over the network to clients.
- The Don't Fragment flag is set, which means that the packets must not be fragmented, requiring the entire packet to fit within the maximum transmission unit (MTU) for the network.
- Jumbo frames are enabled on the EC2 instances, meaning the MTU is likely set to 9001 bytes.
- The clients sometimes do not receive files because the files fail to travel successfully from the EC2 instances to the clients.
Key Points:
- Don't Fragment flag: If the network path has a lower MTU than the file size or if the jumbo frames are not properly supported along the entire path, packets will be dropped due to the flag.
- Jumbo frames: These require all network devices along the path to support them. If any part of the network path does not support jumbo frames, the transfer will fail.
Analyzing the Options:
A) The source IP addresses are from on-premises hosts that are routed over AWS Direct Connect.
- Explanation:
- AWS Direct Connect supports jumbo frames, but it is possible that the on-premises network devices or the connection from on-premises to AWS may not support jumbo frames.
- If there is an MTU mismatch between the EC2 instances (configured with jumbo frames) and the on-premises network (not supporting jumbo frames), the packets will fail to transmit successfully because the Don't Fragment flag will prevent packet fragmentation.
- Why selected: This option is a potential root cause if the on-premises network does not support jumbo frames or the MTU is mismatched between AWS and on-premises devices.
B) The source IP addresses are from on-premises hosts that are routed over AWS Site-to-Site VPN.
- Explanation:
- AWS Site-to-Site VPN does not inherently support jumbo frames. If the VPN tunnel is used, the MTU is typically 1,500 bytes, which is the standard for IP traffic. If jumbo frames are used in the EC2 instances (with an MTU of 9001 bytes), the packets will need to be fragmented, but the Don't Fragment flag prevents this.
- This mismatch in MTU between the EC2 insta...
Author: SilverBear · Last updated Jul 24, 2026
A company has users who work from home. The company wants to move these users to Amazon WorkSpaces for additional security visibility.
The company has deployed WorkSpaces in its own AWS account in VPC A. A network engineer decides to provide the security visibility by using two firewall appliances behind a Gateway Load Balancer (GWLB). The network engineer provisions another VPC, VPC B, in a separate ...
Solution Breakdown:
The company is deploying Amazon WorkSpaces in VPC A and wants to route traffic through firewall appliances deployed in VPC B (in a separate AWS account). The firewall appliances are set up behind a Gateway Load Balancer (GWLB), and the goal is to configure secure and proper network connectivity to route traffic from the WorkSpaces in VPC A through the firewall appliances in VPC B.
Key considerations for this solution:
1. VPC A (WorkSpaces) needs to send its traffic through VPC B (firewall appliances).
2. GWLB should be set up in VPC B to manage traffic through the firewall appliances.
3. The connection between VPC A and VPC B should be configured using VPC endpoints and appropriate routing.
4. The security should ensure that only WorkSpaces from the WorkSpaces account can route traffic through the firewall appliances.
Detailed Option Analysis:
A) Create a GWLB in VPC A with the firewall appliance instances as targets. Use the GWLB to create a GWLB endpoint. Add the AWS principal ARN of the WorkSpaces account to the principal allow list of the GWLB endpoint. In the WorkSpaces account, create a VPC endpoint and specify the service name that the AWS Management Console provides for the GWLB endpoint. Modify the route tables of VPC A to point the default route to the VPC endpoint.
- Explanation:
- This option proposes creating a GWLB in VPC A with the firewall appliances as targets.
- GWLB should be in VPC B (where the firewall appliances reside), not VPC A.
- The routing should direct WorkSpaces' traffic through the firewall appliances in VPC B, not through a GWLB in VPC A.
- Why rejected: The GWLB should be in VPC B, not VPC A since the firewall appliances reside in VPC B. Routing through the GWLB in VPC A would not route traffic correctly.
B) Create a GWLB in VPC B with the firewall appliance instances as targets. Use the GWLB to create a GWLB endpoint. Add the AWS principal ARN of the WorkSpaces account to the principal allow list of the GWLB endpoint. In the WorkSpaces account, create a VPC endpoint and specify the service name that the AWS Management Console provides for the GWLB endpoint. Modify the route tables of VPC A to point the default route to the GWLB endpoint.
- Explanation:
- This option correctly places the GWLB in VPC B, where the firewall appliances are deployed.
- It involves creating a VPC endpoint in the WorkSpaces account and adding the correct routing in VPC A to route traffic to the GWLB endpoint.
- Why selected: This is a valid solution. It ensures t...
Author: Siddharth · Last updated Jul 24, 2026
A company plans to run a computationally intensive data processing application on AWS. The data is highly sensitive. The VPC must have no direct internet access, and the company has applied strict network security to control access.
Data scientists will transfer data from the company's on-premises data center to the instances by using an AWS Site-to-Site VPN connection. The on-premises data center uses the network range 172.31.0.0/20 and will use the network range 172.31.16.0/20 in the application VPC.
The data scientists report that they can start new instances of the application but that they cannot transfer any data from the on-premises data center. A network engineer enables VPC flow...
Understanding the Problem:
- The company is running a computationally intensive data processing application in AWS, and the VPC must have no direct internet access.
- The data is highly sensitive, and strict network security is in place to control access.
- Data scientists are unable to transfer data from the on-premises data center to the AWS instances over a Site-to-Site VPN connection.
- The on-premises data center has the network range `172.31.0.0/20`, and the application VPC uses `172.31.16.0/20`.
The flow logs show that the data scientists can start new instances of the application but cannot transfer data. This implies there might be a misconfiguration in the network security settings (security groups, network ACLs) blocking the inbound or outbound traffic between the on-premises data center and the VPC.
Key Factors to Consider:
- VPC Flow Logs indicate some traffic is being blocked, so the issue likely resides in security configurations like security groups or network ACLs.
- The issue seems to be related to traffic flow between the on-premises network and the VPC, either inbound or outbound.
- Network ACLs control both inbound and outbound traffic, while Security Groups are stateful and only control the traffic flowing in/out of specific EC2 instances.
Analyzing the Options:
A) Modify the security group for the application. Add an inbound rule to allow traffic from the on-premises data center network range to the application.
- Explanation:
- Security groups are stateful, meaning that if inbound traffic is allowed, the response traffic is automatically allowed as well.
- If the on-premises data center is trying to send data to the application instances, inbound traffic must be allowed by the security group for the instances.
- Why selected: This is a valid option since the data is being transferred from the on-premises data center to the AWS instances, which requires allowing inbound traffic from the on-premises range to the application instances.
B) Modify the network ACLs for the VPC subnet. Add an inbound rule to allow traffic from the on-premises data center network range to the VPC subnet range.
-...
Author: FrozenWolf2022 · Last updated Jul 24, 2026
A company needs to temporarily scale out capacity for an on-premises application and wants to deploy new servers on Amazon EC2 instances. A network engineer must design the networking solution for the connectivity and for the application on AWS.
The EC2 instances need to share data with the existing servers in the on-premises data center. The servers must not be accessible from the internet. All traffic to the internet...
Let's analyze the key requirements and constraints of the problem to determine the best solution:
1. Temporary scaling: The company wants to deploy EC2 instances temporarily, so flexibility in scaling is essential.
2. Connectivity to on-premises servers: The EC2 instances need to share data with existing on-premises servers, meaning there must be a secure network connection between the AWS VPC and the on-premises data center.
3. No direct internet access: The EC2 instances must not be accessible from the internet, meaning the instances should reside in private subnets.
4. Routing through the on-premises firewall: All internet traffic from the EC2 instances should route through the on-premises data center firewall, meaning the EC2 instances should have no direct access to the internet.
5. Access to third-party web applications: The EC2 instances need to access external services, such as third-party web applications.
Option Analysis:
- Option A:
- The VPC contains both public and private subnets.
- The AWS Site-to-Site VPN connects the VPC to the on-premises data center.
- EC2 instances are deployed in private subnets, ensuring they aren't directly accessible from the internet.
- A NAT gateway in the public subnet provides a route for instances in the private subnet to access the internet, but not directly, ensuring traffic routes through the on-premises firewall.
- Routes are configured for both the internet and on-premises data center subnets.
- Selection rationale: This option allows the EC2 instances to access the internet through the on-premises firewall (via the NAT gateway) while also maintaining secure connectivity to the on-premises servers. The EC2 instances are not exposed to the internet.
- Option B:
- The VPC contains only private subnets.
- The AWS Site-to-Site VPN connects the VPC to the on-premises data center.
- EC2 instances are deployed in private subnets.
- Routing is configured to route traffic through the virtual private gateway to th...
Author: Olivia · Last updated Jul 24, 2026
A company is deploying a web application into two AWS Regions. The company has one VPC in each Region. Each VPC has three Amazon EC2 instances as web servers behind an Application Load Balancer (ALB). The company already has configured an Amazon Route 53 public hosted zone for example.com. Users will access the application by using the fully qualified domain name (FQDN) of app.example.com.
The company needs a DNS solution that allows global users to access the application. The solution must route the users' requests to the Region that pr...
To determine the best solution, let's break down the key requirements of the problem:
Requirements:
1. Global access to the web application: Users from any location should be able to access the web application in the closest AWS Region to them.
2. Lowest response time: The solution must route traffic to the Region that provides the lowest response time, which suggests a latency-based routing policy.
3. Failover capability: If the primary Region is unavailable, the solution must fail over to the next-best Region.
Option Analysis:
- Option A:
- Geolocation routing: This option uses a geolocation routing policy, which routes traffic based on the location of the user. However, this method is not based on latency, and would route users based on geographic regions, not by the fastest response time.
- Health checks: It also includes a health check monitoring the ALBs by IP address.
- Rejection rationale: While geolocation routing could route users to a specific Region, it does not address the requirement for routing traffic to the Region with the lowest response time. Additionally, the failover strategy is not guaranteed in a geolocation-based routing solution.
- Option B:
- Geolocation routing with health checks: Similar to Option A, this option uses a geolocation routing policy but also includes a health check for each ALB by IP address.
- Rejection rationale: Again, this uses geolocation routing, which routes traffic based on the user's location rather than response time. The failover logic is not latency-based, and thus, it does not meet the requirement of routing traffic to the region with the lowest response time.
- Option C:
- Latency-based routing: This option uses latency-based routing, which routes traffic to the Region with the lowest response time. It also includes a health check that monitors TCP port 80 of each ALB by IP address.
...
Author: Olivia Johnson · Last updated Jul 24, 2026
A consulting company manages AWS accounts for its customers. One of the company's customers needs to add intrusion prevention for its environment without having to re-architect the environment. The customer's environment includes five VPCs in two AWS Regions in the United States. VPC-to-VPC connectivity is achieved through VPC peering. The customer does not pla...
Let's break down the requirements and the options to determine the best solution:
Requirements:
1. Intrusion prevention: The solution must provide intrusion prevention to enhance the security of the customer's environment.
2. No re-architecture: The solution must be implemented without needing to change the architecture of the customer's environment.
3. Multiple VPCs in multiple AWS Regions: There are five VPCs in two regions with VPC-to-VPC peering.
4. Unencrypted traffic: The solution must support unencrypted traffic.
5. Future VPC expansion: The customer does not plan to increase the number of VPCs in the next two years.
Option Analysis:
- Option A: Configure VPC security groups and network ACLs:
- VPC security groups and network ACLs are standard mechanisms to control traffic between instances and subnets within a VPC. They provide basic traffic filtering and protection.
- Rejection rationale: While security groups and network ACLs help control traffic, they do not offer dedicated intrusion prevention capabilities, such as detecting and blocking malicious traffic. These tools alone would not meet the customer's requirement for intrusion prevention.
- Option B: Use an AWS Network Firewall centralized deployment model in each VPC:
- AWS Network Firewall is a managed service designed for network traffic filtering, providing intrusion prevention and detection features, such as deep packet inspection, filtering, and blocking of malicious traffic.
- A centralized deployment model refers to deploying a single instance of the firewall in a central VPC to manage all traffic between other VPCs, possibly using VPC peering or transit gateways.
- Rejection rationale: The centralized deployment model could be challenging for the customer since they have VPC peering in place. For the centralized model to work, routing and VPC configurations might need to be reworked, which would involve re-architecting the environment. The solution needs to avoid this.
- Option C: Use...
Author: Aarav2020 · Last updated Jul 24, 2026
A company hosts its IT infrastructure in an on-premises data center. The company wants to migrate the infrastructure to the AWS Cloud in phases. A network engineer wants to set up a 10 Gbps AWS Direct Connect dedicated connection between the on-premises data center and VPCs. The company's network provider needs 3 months to provision the Direct Connect connection.
In the meantime, the network engineer implements a temporary solution by deploying an AWS Site-to-Site VPN connection that terminates to a virtual private gateway. The network engineer observes that the ban...
Problem Overview:
- The company is migrating infrastructure to AWS and has set up a temporary AWS Site-to-Site VPN connection to the VPC while waiting for the Direct Connect connection to be provisioned.
- The VPN bandwidth is capped at 1.25 Gbps, even though the customer gateway device should be capable of more. The network engineer needs to increase the VPN bandwidth to meet business needs before Direct Connect is available.
Key Factors:
- Bandwidth Limitation: The VPN connection is limited to 1.25 Gbps. This is likely due to AWS's default limit or the limitations of the Site-to-Site VPN connection itself.
- Temporary Solution: The Direct Connect connection will be implemented later, so the focus is on improving the existing VPN connection in the meantime.
- Multiple VPN Connections: AWS supports creating multiple VPN connections to improve bandwidth, but the solution must be easy to implement and efficient.
Option Analysis:
Option A: Contact AWS Support to request a bandwidth quota increase for the existing Site-to-Site VPN connection.
- Explanation: AWS typically sets default bandwidth limits for Site-to-Site VPN connections, and it's possible to request an increase in the limit by contacting AWS Support.
- Rejection rationale: The bandwidth limitation is usually due to the VPN tunnel's configuration, and it's unlikely that AWS Support can increase the VPN connection bandwidth beyond the set maximum (1.25 Gbps per tunnel). Therefore, this is not the most effective solution.
Option B: Discuss the issue with the hardware vendor. Buy a bigger and more powerful customer gateway device that has faster encryption and decryption capabilities.
- Explanation: Upgrading the customer gateway device could improve performance if the current device is the bottleneck.
- Rejection rationale: While upgrading the customer gateway device may improve encryption/decryption performance, it does not directly address the underlying AWS VPN limitations. AWS's VPN service itself may have inherent throughput caps, so this approach is unlikely to resolve the issue.
Option C: Create several additional Site-to-Site VPN connections that terminate on the same virtual gateway. Configure equal-cost multi-path (ECMP) ro...
Author: Krishna · Last updated Jul 24, 2026
A company has business operations in the United States and in Europe. The company's public applications are running on AWS and use three transit gateways. The transit gateways are located in the us-west-2, us-east-1, and eu-central-1 Regions. All the transit gateways are connected to each other in a full mesh configuration.
The company accidentally removes the route to the eu-central-1 VPCs from the us-west-2 transit gateway route table. The company also a...
Problem Overview:
- The company is using AWS Transit Gateways in multiple regions: us-west-2, us-east-1, and eu-central-1, with a full mesh configuration between the transit gateways.
- Route removal: Routes to the VPCs in eu-central-1 were removed from the us-west-2 transit gateway route table, and routes to the VPCs in us-west-2 were removed from the eu-central-1 transit gateway route table.
- The goal is to identify the misconfiguration with the least operational overhead.
Key Considerations:
1. Operational Overhead: The solution should minimize manual intervention and provide an automated or easily actionable way to pinpoint the issue.
2. Network Troubleshooting: The misconfiguration is related to route tables, so tools that help track network traffic or analyze route mappings are ideal.
3. Ease of Use: The chosen option should help identify missing routes without requiring in-depth manual packet capture or flow analysis.
Option Analysis:
Option A: Use the Route Analyzer feature for AWS Transit Gateway Network Manager.
- Explanation: AWS Transit Gateway Network Manager includes a Route Analyzer feature that helps identify and visualize issues in the transit gateway route tables. This tool can be used to examine and troubleshoot connectivity problems across multiple regions and transit gateways.
- Selection rationale: This is the most effective solution for the issue. The Route Analyzer is specifically designed for this type of scenario, where there are route configuration issues between transit gateways. It automatically detects route misconfigurations and provides an easy-to-understand view of the affected routes, making it the least operationally intensive solution.
- Why this is preferred: It is built for the exact use case of identifying misconfigurations in route tables, and it automates much of the diagnostic process.
Option B: Use the AWSSupport-SetupIPMonitoringFromVPC AWS Systems Manager Automation runbook. Push network telemetry data to Amazon CloudWatch Logs for analysis.
- Explanation: This runbook automates the collection of network telemetry data from VPCs and pushes it to CloudWatch Logs. The dat...
Author: FrozenWolf2022 · Last updated Jul 24, 2026
A marketing company is using hybrid infrastructure through AWS Direct Connect links and a software-defined wide area network (SD-WAN) overlay to connect its branch offices. The company connects multiple VPCs to a third-party SD-WAN appliance transit VPC within the same account by using AWS Site-to-Site VPNs.
The company is planning to connect more VPCs to the SD-WAN appliance transit VPC. However, the company faces challenges of scalability, route table limitations, and higher costs wit...
To solve the company's scalability, route table limitations, and cost challenges, the solution must provide an architecture that simplifies management, reduces operational overhead, and enables seamless connectivity between multiple VPCs and the SD-WAN appliance transit VPC. Let’s analyze the provided options based on these factors:
Option A:
Configure a transit gateway to attach the VPCs. Configure a Site-to-Site VPN connection between the transit gateway and the third-party SD-WAN appliance transit VPC. Use the SD-WAN overlay links to connect to the branch offices.
- Pros:
- Transit Gateway (TGW) is highly scalable and simplifies routing between multiple VPCs.
- Using Site-to-Site VPN ensures secure connectivity between the TGW and the SD-WAN appliance.
- Cons:
- While this solution resolves scalability issues for VPCs, the reliance on Site-to-Site VPN introduces potential performance and cost concerns, especially if the SD-WAN appliance supports better integration options.
- Site-to-Site VPNs are typically less efficient and may create higher operational overhead due to the need for additional configuration and management of VPN tunnels.
Option B:
Configure a transit gateway to attach the VPCs. Configure a transit gateway Connect attachment for the third-party SD-WAN appliance transit VPC. Use transit gateway Connect native integration of SD-WAN virtual hubs with AWS Transit Gateway.
- Pros:
- The Transit Gateway Connect feature is designed for integrating SD-WAN solutions directly with AWS Transit Gateway, reducing complexity and eliminating the need for Site-to-Site VPNs.
- Transit Gateway Connect offers better scalability, performance, and cost-efficiency, with native support for SD-WAN integration.
- It removes the dependency on traditional VPN connections and provides more robust routing capabilities.
- Cons:
- This requires that the third-party SD-WAN appliance supports Transit Gateway Connect natively. If the appliance doesn't support this feature, this option would be nonviable.
Option C:
Configure a transit gateway to attach the VPCs. Configure VPC peering between the VPCs and the third-party SD-WAN appliance transit VPC. Use the SD-WAN overlay links to con...
Author: Carlos Garcia · Last updated Jul 24, 2026
A company is running a hybrid cloud environment. The company has multiple AWS accounts as part of an organization in AWS Organizations. The company needs a solution to manage a list of IPv4 on-premises hosts that will be allowed to access resources in AWS. The solution must provide version control for the list of ...
To meet the company's requirement of managing a list of IPv4 on-premises hosts that will be allowed to access resources in AWS, while also ensuring version control and making the list available to all AWS accounts within the organization, let’s analyze each option:
Option A:
Create a customer-managed prefix list. Add entries for the initial list of on-premises IPv4 hosts. Create a resource share in AWS Resource Access Manager. Add the managed prefix list to the resource share. Share the resource with the organization.
- Pros:
- Customer-managed prefix lists are designed to store and manage IP address ranges for use in AWS services like security groups and route tables.
- By sharing the prefix list through AWS Resource Access Manager (RAM), the list can be easily shared across multiple accounts in the AWS organization.
- Provides version control because you can update the prefix list entries and they can be immediately available to all accounts within the organization.
- Cons:
- This method may be more complex than necessary for organizations that don't already use prefix lists or if there are no services like security groups or route tables explicitly leveraging this feature.
Option B:
Create a customer-managed prefix list. Add entries for the initial list of on-premises IPv4 hosts. Use AWS Firewall Manager to share the managed prefix list with the organization.
- Pros:
- Using AWS Firewall Manager allows central management and distribution of security policies, including IP lists, across multiple accounts.
- AWS Firewall Manager integrates with prefix lists, providing version control, and it ensures that the list is updated and applied across the organization.
- Cons:
- This approach is designed for organizations already using Firewall Manager to manage security policies. If the company doesn't have it set up, the solution might require additional configuration and overhead.
- This option may be overkill if the company's needs are focused purely on managing the IP list, not on broader firewall policy management.
Option C:
Create a security group. Add inbound rule entries for the initial list of on-premises IPv4 hosts. Create a resource share in AWS Resource Access Manager. Add the security group to the resource share. Share the resource with the organization.
- Pros:
- Security groups are simple to manage and provide a way to control inbound traffic based on IP addresses.
- Cons:
- Security groups are not ideal for version control or managing a list of IP addresses. Managing large lists of IP addresses directly in s...
Author: Amira · Last updated Jul 24, 2026
A company's application is deployed on Amazon EC2 instances in a single VPC in an AWS Region. The EC2 instances are running in two Availability Zones. The company decides to use a fleet of traffic inspection instances from AWS Marketplace to inspect traffic between the VPC and the internet. The company is performing tests before the company deploys the architecture into production.
The fleet is located in a shared inspection VPC behind a Gateway Load Balancer (GWLB). To minimize the cost of the solution, the company deployed only one inspection instance in each Availability Zone that the application uses.
During tests, a network engineer notices that traffic inspection works a...
To address the issue where traffic inspection works as expected under normal conditions but fails during maintenance (likely due to the unavailability of inspection instances), the solution must focus on improving availability and redundancy of the inspection instances, ensuring that traffic can still be routed through inspection instances even if one instance is undergoing maintenance or fails.
Let’s analyze each option:
Option A: Deploy one inspection instance in the Availability Zones that do not have inspection instances deployed.
- Pros:
- This approach would help ensure that all Availability Zones (AZs) have at least one inspection instance, increasing redundancy.
- By having inspection instances in both AZs where the application runs, traffic would be properly routed to a functioning instance in the event of a failure or maintenance.
- Cons:
- While deploying instances in the second AZ would increase redundancy, this doesn't fully address the issue of load balancing across AZs and the potential for timeouts during instance failures.
- This step alone does not guarantee a seamless failover experience for traffic.
Option B: Deploy one additional inspection instance in each Availability Zone where the inspection instances are deployed.
- Pros:
- By deploying two inspection instances per AZ, you achieve redundancy within each Availability Zone.
- This ensures that if one inspection instance fails or is in maintenance, the other can take over seamlessly, preventing session timeouts.
- This solution also improves fault tolerance and ensures the application instances can continue functioning during maintenance or failures.
- Cons:
- The downside is that it requires additional cost since you're deploying more inspection instances in each AZ. However, this trade-off is necessary to ensure high availability and avoid session timeouts.
Option C: Enable the cross-zone load balancing attribute for the GWLB.
- Pros:
- Cross-zone load balancing would allow the Gateway Load Balancer to distribute traffic evenly across inspection instances in multiple AZs, improving the overall load distribution.
- This could help prevent session timeouts because traffic would be balanced and routed to the available inspection instances.
- Cons:
- This does not address the lack of redundancy in a single AZ during maintenance. Even with cross-zone load balancing, if an AZ doesn't have a functioning inspection ...
Author: StarlightBear · Last updated Jul 24, 2026
A company has developed a new web application on AWS. The application runs on Amazon Elastic Container Service (Amazon ECS) on AWS Fargate behind an Application Load Balancer (ALB) in the us-east-1 Region. The application uses Amazon Route 53 to host the DNS records for the domain. The content that is served from the website is mostly static images and files that are not updated frequently. Most of the traffic to the website from end users will originate from the United States. Some traffic will originate from Canada and Europe.
A network engineer ...
To meet the requirements of reducing latency for end users while ensuring all traffic is encrypted in transit until it reaches the Application Load Balancer (ALB), we must consider factors like low-latency content delivery, security (encryption), and cost efficiency.
Option A: Configure the ALB to use an AWS Global Accelerator accelerator in us-east-1. Create a secure HTTPS listener. Create an alias record in Amazon Route 53 for the custom domain name. Configure the alias record to route to the DNS name that is assigned to the accelerator for the ALB.
- Pros:
- AWS Global Accelerator improves latency by routing traffic through the AWS global network, directing users to the nearest AWS edge location.
- This approach minimizes latency by using the AWS backbone network and automatically selects the best regional endpoint.
- Traffic would be encrypted in transit with HTTPS, ensuring compliance with the encryption requirement.
- Cons:
- Global Accelerator is a premium service and may introduce additional costs, particularly when serving traffic globally.
- It is more suited for global applications, but if the majority of users are in the United States with only some traffic from Canada and Europe, this could be overkill, especially in terms of cost.
Option B: Configure the ALB to use a secure HTTPS listener. Create an Amazon CloudFront distribution. Set the origin domain name to point to the DNS record that is assigned to the ALB. Configure the CloudFront distribution to use an SSL certificate. Set all behaviors to force HTTPS. Create an alias record in Amazon Route 53 for the custom domain name. Configure the alias record to route to the DNS name that is assigned to the ALB.
- Pros:
- CloudFront is a content delivery network (CDN) that can distribute static content to edge locations worldwide, reducing latency for users in Canada, Europe, and the United States.
- Traffic will be encrypted in transit until it reaches the ALB (via HTTPS), meeting the security requirement.
- CloudFront is designed to reduce the cost of serving static content, improving performance, and reducing the load on the ALB.
- Cons:
- CloudFront would incur additional cost, especially for caching and delivering content to global edge locations. However, this cost is generally lower than using Global Accelerator.
Option C: Configure the ALB to use a secure HTTPS listener. Create an Amazon CloudFront distribution. Set the origin domain name to point to the DNS record that is assigned to the ALB. Configure the CloudFront distribution to use an SSL certificate and redirect HTTP to HTTPS. Create an alias record in Amazon Route 53 for the custom domain name. Configure the alias record to route to the CloudFront distribution.
- Pros:
- This solution is similar to Option B but w...
Author: Jack · Last updated Jul 24, 2026
A company deploys an internal website behind an Application Load Balancer (ALB) in a VPC. The VPC has a CIDR block of 172.31.0.0/16. The company creates a private hosted zone for the domain example.com for the website in Amazon Route 53. The company establishes an AWS Site-to-Site VPN connection between its office network and the VPC.
A network engineer needs to set up a DNS solution so that employees can v...
To allow employees to access the internal website by visiting a private domain URL (`https://example.com`), the DNS solution needs to route the traffic to the internal Application Load Balancer (ALB) behind the VPC. The company has established a Site-to-Site VPN connection, and the goal is to ensure that employees on the office network can resolve the domain name to the ALB inside the VPC.
Let's analyze the options step by step:
Option A: Create an alias record that points to the ALB in the Route 53 private hosted zone.
- Pros:
- Alias records are a special type of record in Route 53 that allow mapping domain names to AWS resources (like ALB) without needing an IP address. An alias record in a private hosted zone will resolve the domain to the ALB internally.
- Since the ALB is private (with an internal DNS name), the alias record will ensure the domain name resolves correctly within the VPC.
- This method is highly suitable because it directly resolves the private domain to the internal ALB.
- Cons:
- No significant drawbacks here, as this is the recommended approach for associating domain names with ALBs in Route 53 private hosted zones.
Option B: Create a CNAME record that points to the ALB internal domain in the Route 53 private hosted zone.
- Pros:
- A CNAME record can be used to alias the domain to the ALB's internal DNS name.
- Cons:
- CNAME records are typically used to alias domain names to other domain names, but alias records are a better fit for associating domain names with AWS resources like ALBs. Route 53 also has a limit on CNAME usage in certain scenarios (like the root domain), making alias records more flexible in this case.
- Although it would work, it's not the most efficient or recommended method within AWS, especially when working with AWS resources like ALBs.
Option C: Create a Route 53 Resolver inbound endpoint. On the office DNS server, configure a conditional forwarder to forward the DNS queries to the Route 53 Resolver inbound endpoint.
- Pros:
- The Route 53 Resolver inbound endpoint would allow DNS queries from the office network (outside AWS) to resolve the private domain.
- Cons:
- This is a more complex solution. The inbound endpoint is typically used when you need to forward DNS queries from a non-AWS network (like the office network) to a private hosted zone in Route 53.
- This solution might be overkill because there’s a simpler way to solve this using a conditiona...
Author: Oscar · Last updated Jul 24, 2026
A company is deploying AWS Cloud WAN with edge locations in the us-east-1 Region and the ap-southeast-2 Region. Individual AWS Cloud WAN segments are configured for the development environment, the production environment, and the shared services environment at each edge location. Many new VPCs will be deployed for the environments and will be configured as attachments to the AWS Cloud WAN core network.
The company's network team wants to ensure that VPC attachments are configured for the correct segment. The network team will tag the VPC attachments by using the Environment key with a value ...
Let's break down each option and determine which one best meets the requirements:
Requirements:
1. Production Environment in us-east-1 must require acceptance for attachment requests.
2. All other attachment requests should not require acceptance.
3. The Environment tag will be used to specify the segment (Development, Production, Shared Services).
Key Considerations:
- Condition Logic: The "and" condition logic requires that both conditions (the tag and the region) be true for the rule to apply. The "or" condition logic allows for either condition (tag or region) to be true.
- Acceptance Requirement: Only the production environment in us-east-1 should require acceptance.
Option Analysis:
A) Create a rule with a number of 100 that requires acceptance for attachments to the production segment. In the rule, set the condition logic to the "or" value. Include conditions that require a tag:Environment value of Production or a Region value of us-east-1. Create a rule with a number of 200 that does not require acceptance to map any tag:Environment values to their respective segments.
- Problem: The "or" logic means that any attachment with a tag:Environment value of "Production" or in the "us-east-1" region will trigger acceptance, which is not ideal. This will cause all production environments (even outside of us-east-1) to require acceptance, which is not desired.
- Rejection Reason: This rule does not meet the requirement for the production environment in other regions (e.g., ap-southeast-2) not to require acceptance.
B) Create a rule with a number of 100 that requires acceptance for attachments to the production segment. In the rule, set the condition logic to the "and" value. Include conditions that require a tag:Environment value of Production and a Region value of us-east-1. Create a rule with a number of 200 that does not require acceptance to map any tag:Environment values to their respective segments.
- Problem: This approach is correct for requiring acceptance for production attachments only in the us-east-1 region. The "and" condition ensures that both the tag ("Production") and the region ("us-east-1") must match for the rule to apply, which is exactly what...
Author: Harper · Last updated Jul 24, 2026
A company is migrating applications from a data center to AWS. Many of the applications will need to exchange data with the company's on-premises mainframe.
The company needs to achieve 4 Gbps transfer speeds to meet peak traffic demands. A network engineer must design a highly available solution that maximi...
To address the requirements outlined in the problem, the solution must satisfy the following criteria:
1. Achieve 4 Gbps transfer speeds to meet peak traffic demands.
2. Maximize resiliency by being able to withstand the loss of circuits or routers.
3. High availability solution with redundancy, ideally involving multiple connections across multiple locations.
Key Considerations:
- Bandwidth Requirement: The company needs 4 Gbps of total bandwidth to meet the peak traffic demands. This means the combined capacity from AWS Direct Connect connections must be at least 4 Gbps.
- Redundancy: The solution should support high availability. This means using multiple connections across multiple locations and routers to ensure that if one connection or router fails, traffic can continue to flow.
- Resiliency: To ensure resiliency, we need to ensure that connections from multiple Direct Connect locations are utilized and terminated on different routers in the company’s data center.
Option Analysis:
A) Order four 10 Gbps AWS Direct Connect connections that are evenly spread over two locations. Terminate one connection from each Direct Connect location to a router at the company location. Terminate the other connection from each Direct Connect location to a different router at the company location.
- Bandwidth: This provides 40 Gbps of total bandwidth, far exceeding the 4 Gbps requirement. This is ideal in terms of bandwidth as it exceeds the need.
- Redundancy: This option uses multiple locations and multiple routers, which provides high availability and resiliency. If one circuit or router fails, traffic can still flow through the other connections or routers.
- Resiliency: With four 10 Gbps connections across two locations and two routers, this solution ensures maximum resiliency, satisfying the requirement to withstand the loss of circuits or routers.
- Conclusion: This option is over-provisioned in terms of bandwidth but perfectly meets the resiliency and redundancy requirements.
B) Order two 10 Gbps AWS Direct Connect connections that are evenly spread over two locations. Terminate the connection from each Direct Connect location to a different router at the company location.
- Bandwidth: This provides 20 Gbps of total bandwidth, which is also more than sufficient to meet the 4 Gbps requirement. However, it only provides two connections, which might not be as resilient as four.
- Resiliency...
Author: Sam · Last updated Jul 24, 2026
A company has 10 web server Amazon EC2 instances that run in an Auto Scaling group in a production VPC. The company has 10 other 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 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 servers on AWS and the w...
Let's go through each option and evaluate how it addresses the company's requirements:
Key Requirements:
1. Distribute traffic across web servers in both AWS (EC2 instances) and on-premises data center.
2. The solution must ensure that HTTPS requests go to the same server for the entire session (sticky sessions).
3. The solution should be able to handle high-volume HTTPS traffic (thousands of external users).
4. Maintain a connection between on-premises servers and EC2 instances via AWS Direct Connect.
Option Analysis:
A) Create a Network Load Balancer (NLB) in the production VPC. Create a target group. Specify IP as the target type. Register the EC2 instances and the on-premises servers with the target group. Enable connection draining on the NLB.
- Target Type: The IP target type in NLB means that you can register both EC2 instances (with IPs) and on-premises servers (with IPs), which works for hybrid cloud setups.
- Sticky Sessions: NLB does not support sticky sessions out of the box. Connection draining is supported, but it only helps gracefully remove instances, not sticky sessions for session persistence.
- Conclusion: NLB does not support sticky sessions for HTTPS traffic, which is a key requirement. Therefore, this option does not meet the sticky session requirement.
B) Create an Application Load Balancer (ALB) in the production VPC. Create a target group. Specify IP as the target type. Register the EC2 instances and the on-premises servers with the target group. Enable application-based session affinity (sticky sessions) on the ALB.
- Target Type: Using the IP target type on an ALB allows you to register both EC2 instances and on-premises servers by their IP addresses.
- Sticky Sessions: ALB supports application-based session affinity (sticky sessions) which is essential for ensuring that HTTPS requests from the same client always go to the same server during the session.
- Conclusion: Th...
