Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company's network engineer needs to design a new solution to help troubleshoot and detect network anomalies. The network engineer has configured Traffic Mirroring. However, the mirrored traffic is overwhelming the Amazon EC2 instance that is the traffic mirror target. The EC2 instance hosts tools that the company's security team uses to analyze the traffic. The netwo...
The scenario involves designing a solution for handling traffic mirroring that addresses performance, scalability, and high availability. Let's evaluate the options:
Option A: Deploy a Network Load Balancer (NLB) as the traffic mirror target. Behind the NLB, deploy a fleet of EC2 instances in an Auto Scaling group. Use Traffic Mirroring as necessary.
- Analysis:
- NLBs are designed for handling large volumes of traffic with low latency and high throughput. NLBs operate at the network layer (Layer 4), which is ideal for traffic mirroring that does not need content-based routing.
- Auto Scaling EC2 instances behind the NLB ensure that the system scales to accommodate high or variable traffic loads, providing high availability and scaling as needed.
- Traffic mirroring needs to be handled as per the system's demands, and NLB can forward mirrored traffic to the Auto Scaling EC2 fleet efficiently.
- Why it works:
- The NLB can efficiently distribute traffic to a fleet of EC2 instances, ensuring the system is highly available and scalable. This is ideal when the mirrored traffic volume is high, as the NLB can handle large-scale traffic distribution without creating bottlenecks.
- Key factors:
- Traffic mirroring can be handled continuously, scaling dynamically with the Auto Scaling group behind the NLB.
Option B: Deploy an Application Load Balancer (ALB) as the traffic mirror target. Behind the ALB, deploy a fleet of EC2 instances in an Auto Scaling group. Use Traffic Mirroring only during non-business hours.
- Analysis:
- ALBs operate at Layer 7 (the application layer) and are designed to route traffic based on content, such as URLs or headers. However, Traffic Mirroring generally focuses on capturing raw traffic data, which doesn't require the detailed content inspection that ALBs provide.
- The decision to use Traffic Mirroring only during non-business hours limits the flexibility of the solution and is not ideal for continuous or high-demand traffic mirroring scenarios.
- Why it's less ideal:
- ALBs are not optimized for handling raw network traffic at scale (Layer 4). Additionally, limiting Traffic Mirroring to non-business hours is a restrictive approach, especially if the company needs real-time anomaly detection or troubleshooting.
- Key factors:
- The focus on non-business hours may not meet the demand for continuous monitoring, and using ALBs for traf...
Author: William · Last updated May 16, 2026
A company uses a hybrid architecture and has an AWS Direct Connect connection between its on-premises data center and AWS. The company has production applications that run in the on-premises data center. The company also has production applications that run in a VPC. The applications that run in the on-premises data center need to communicate with the applications that run in the VPC. The company is using corp.example.com as the domain name for the on-premises resources and is using an Amazon Route 53 private hosted zone for aws.example.com to host the VPC resources.
The company is using an open-source recursive DNS resolver in a VPC subnet and is using a DNS resolver in the on-premises data center. The company's on-premises DNS resolver has a forwarder that directs requests for the aws.example.com domain name to the DNS resolver in the VPC. Th...
To replace the open-source recursive DNS resolver with Amazon Route 53 Resolver endpoints and ensure that DNS resolution works correctly between on-premises and VPC applications, the following steps need to be taken:
Option A: Create a Route 53 Resolver rule to forward aws.example.com domain queries to the IP addresses of the outbound endpoint.
- Analysis:
- In this case, the Route 53 Resolver rule can be created in the VPC to forward DNS queries for the aws.example.com domain to the outbound endpoint.
- The outbound endpoint is responsible for forwarding DNS queries from the VPC to the on-premises DNS resolver. This setup allows DNS queries from the VPC for on-premises domains to be sent correctly to the on-premises data center DNS server.
- Why it's selected:
- This configuration is correct because the outbound endpoint facilitates communication from the VPC to the on-premises DNS resolver. Therefore, queries for aws.example.com need to be forwarded to the outbound endpoint.
Option B: Configure the on-premises DNS resolver to forward aws.example.com domain queries to the IP addresses of the inbound endpoint.
- Analysis:
- The on-premises DNS resolver should forward queries for the aws.example.com domain to the inbound endpoint in the VPC.
- The inbound endpoint in the VPC is responsible for accepting DNS queries from the on-premises resolver and resolving them for AWS resources in the VPC.
- Why it's selected:
- The on-premises resolver should forward DNS queries for aws.example.com to the inbound endpoint so that it can resolve DNS queries for AWS resources.
Option C: Create a Route 53 Resolver inbound endpoint and a Route 53 Resolver outbound endpoint.
- Analysis:
- Both an inbound endpoint and an outbound endpoint are required for DNS resolution between the on-premises and AWS environments:
- The inbound endpoint allows DNS queries from the on-premises DNS resolver to reach the VPC.
- The outbound endpoint allows DNS queries from the VPC to reach the on-premises DNS resolver.
- Why it's selected:
- This option is correct because both endpoints are essential for bidirectional DNS communication between the on-premises environment and the VPC.
Option D: Create a Route 53 Resolver rule to forward aws.example.com domain ...
Author: Elijah · Last updated May 16, 2026
A government contractor is designing a multi-account environment with multiple VPCs for a customer. A network security policy requires all traffic between any two VPCs to be transparently inspected by a third-party appliance.
The customer wants a solution that features AWS Transit Gateway. The setup must be highly available across multiple Availability Zones, and the solution needs to support automated failov...
To design a multi-account environment with multiple VPCs that requires traffic inspection by a third-party appliance, the solution needs to meet the requirements for high availability, automated failover, and transparent inspection while avoiding asymmetric routing. Let’s review and select the correct steps for this solution.
Option A: Deploy two clusters that consist of multiple appliances across multiple Availability Zones in a designated inspection VPC. Connect the inspection VPC to the transit gateway by using a VPC attachment. Create a target group, and register the appliances with the target group. Create a Network Load Balancer (NLB), and set it up to forward to the newly created target group. Configure a default route in the inspection VPC's transit gateway subnet toward the NLB.
- Analysis:
- This option sets up multiple appliances in highly available clusters across multiple Availability Zones. The use of a Network Load Balancer (NLB) is appropriate for forwarding traffic to the appliances in the inspection VPC because the NLB can distribute traffic across the appliance clusters.
- The default route in the inspection VPC towards the NLB ensures that traffic is directed to the inspection appliances for inspection.
- Why it's selected:
- The design provides high availability and failover by distributing appliances across multiple Availability Zones. Using an NLB ensures transparent traffic inspection without introducing asymmetric routing.
- Why it's rejected:
- This is a solid option for most use cases but it does not use a Gateway Load Balancer, which is specifically optimized for network appliance scenarios.
Option B: Deploy two clusters that consist of multiple appliances across multiple Availability Zones in a designated inspection VPC. Connect the inspection VPC to the transit gateway by using a VPC attachment. Create a target group, and register the appliances with the target group. Create a Gateway Load Balancer, and set it up to forward to the newly created target group. Configure a default route in the inspection VPC's transit gateway subnet toward the Gateway Load Balancer endpoint.
- Analysis:
- This option also sets up high availability by deploying appliance clusters across multiple Availability Zones. The key difference here is the use of a Gateway Load Balancer (GLB), which is specifically designed for scenarios like traffic inspection.
- The GLB is a better fit for forwarding traffic to third-party appliances for transparent inspection because it is built to work seamlessly with network appliances and supports automated failover and scaling.
- Why it's selected:
- Gateway Load Balancer is the most suitable option for routing traffic to network appliances, as it offers integration with security and monitoring appliances. The GLB also supports automated failover and high availability across multiple Availability Zones.
Option C: Configure two route tables on the transit gateway. Associate one route table with all the attachments of the application VPCs. Associate the other route table with the inspection VPC's attachment. Propagate all VPC attachments into t...
Author: Noah · Last updated May 16, 2026
A company has deployed Amazon EC2 instances in private subnets in a VPC. The EC2 instances must initiate any requests that leave the VPC, including requests to the company's on-premises data center over an AWS Direct Connect connection. No resources outside the VPC can be allowed to open communications directly to the EC2 instances.
The on-premises data center's customer gateway is configured with a stateful firewall device that filters for incoming and outgoing requests to and from multiple VPCs. In addition, the company ...
Let's evaluate the best solution that satisfies the requirement with the least operational overhead.
Key Requirements:
1. EC2 instances need to initiate outbound traffic to both the internet and the on-premises data center.
2. No resources outside the VPC (including the on-premises data center) should directly communicate with the EC2 instances.
3. The on-premises firewall should allow only outbound traffic from EC2 instances to the data center, using a single IP address.
4. We want a solution with the least operational overhead.
Option A: Create a VPN connection over the Direct Connect connection by using the on-premises firewall. Use the firewall to block all traffic from on-premises to AWS. Allow a stateful connection from the EC2 instances to initiate the requests.
- Analysis:
- This option creates a VPN connection over the Direct Connect connection. While it ensures that the EC2 instances can initiate requests to the on-premises data center, the operational complexity increases with the need to configure a VPN connection and manage additional stateful firewall rules on the on-premises side.
- Stateful firewall would allow responses to the EC2 instance's outbound requests, but this adds operational overhead for VPN management and firewall configuration, especially considering Direct Connect is already in use.
- Why it's rejected:
- The requirement mentions using the least operational overhead, and managing a VPN connection on top of Direct Connect would increase complexity and overhead.
Option B: Configure the on-premises firewall to filter all requests from the on-premises network to the EC2 instances. Allow a stateful connection if the EC2 instances in the VPC initiate the traffic.
- Analysis:
- This solution suggests using the on-premises firewall to filter inbound traffic from the on-premises network to EC2 instances, which would meet the requirement of preventing incoming traffic from the on-premises data center to EC2 instances. However, it still requires management of firewall rules on the on-premises side.
- The firewall needs to support stateful connections, but there is no mention of how EC2 instances will communicate with the on-premises data center. This solution is vague on how the IP match rule will be applied or how to ensure the EC2 instances' outbound connections are correctly routed.
- Why it's rejected:
- This option is incomplete in addressing how to route outbound traffic to the on-premises data center while using the least overhead. It doesn't fully explain the mechanism for allowing outbound traffic through the firewall.
Option C: Deploy a ...
Author: StarlightBear · Last updated May 16, 2026
A global company operates all its non-production environments out of three AWS Regions: eu-west-1, us-east-1, and us-west-1. The company hosts all its production workloads in two on-premises data centers. The company has 60 AWS accounts and each account has two VPCs in each Region. Each VPC has a virtual private gateway where two VPN connections terminate for resilient connectivity to the data centers. The company has 360 VPN tunnels to each data center, resulting in high management overhead. The total VPN throughput for each Region is 500 Mbps.
The company wants to migrate the production environments to AWS. The company needs a s...
Let's evaluate the options for simplifying the network architecture, supporting future growth, and addressing the need to reduce management overhead in a highly scalable way, while accommodating the increased traffic of 2 Gbps per Region.
Key Requirements:
1. Simplification of the network architecture.
2. Reduced management overhead.
3. Scalability to handle an increase in traffic (2 Gbps per Region).
4. The solution should allow future growth and provide resilience between the data centers and AWS.
Option A: Set up an AWS Direct Connect connection from each data center to AWS in each Region. Create and attach private VIFs to a single Direct Connect gateway. Attach the Direct Connect gateway to all the VPCs. Remove the existing VPN connections that are attached directly to the virtual private gateways.
- Analysis:
- Direct Connect (DX) is a managed, high-throughput, and low-latency solution for connecting on-premises data centers to AWS. It would provide better performance (2 Gbps per Region or more) compared to VPN connections.
- The use of a single Direct Connect gateway is a good idea for managing connectivity to multiple VPCs and Regions from the data centers, reducing the complexity and overhead of managing multiple VPN tunnels.
- Removing existing VPNs and replacing them with Direct Connect reduces VPN tunnel management overhead and simplifies the architecture.
- Scalability is addressed by Direct Connect’s ability to support high-throughput traffic and offer resilience via redundant connections.
- Why it's selected:
- Direct Connect provides a dedicated, high-bandwidth solution, which is ideal for supporting future growth and the increased traffic (2 Gbps per Region).
- This solution dramatically reduces management overhead by consolidating the network connections to a single managed service (Direct Connect).
- Why other options are rejected:
- Direct Connect is the most suitable solution in this case because it is designed for high-throughput, dedicated network traffic. It simplifies network architecture, improves reliability, and allows for growth, all without the complexities of managing multiple VPN connections.
Option B: Create a single transit gateway with VPN connections from each data center. Share the transit gateway with each account by using AWS Resource Access Manager (AWS RAM). Attach the transit gateway to each VPC. Remove the existing VPN connections that are attached directly to the virtual private gateways.
- Analysis:
- A single transit gateway consolidates traffic routing between multiple VPCs and accounts, improving manageability.
- However, VPN connections to the data centers will still be used, and this doesn’t fully address the requirement for high throughput (2 Gbps) in each Region.
- Transit gateways with VPN connections can be a good option for simplifying routing and reducing the number of connections, but they still rely on VPN tunn...
Author: David · Last updated May 16, 2026
A company is building its website on AWS in a single VPC. The VPC has public subnets and private subnets in two Availability Zones. The website has static content such as images. The company is using Amazon S3 to store the content.
The company has deployed a fleet of Amazon EC2 instances as web servers in a private subnet. The EC2 instances are in an Auto Scaling group behind an Application Load Balancer. The EC2 instances will serve traffic, and they must pull content from an S3 bucket to render the webpages. The company is using AWS Direct Connect with a public VIF for on-premises connectivity to the S3 bucket.
A network engineer notices that traffic between the EC2 instances and Amaz...
To address the network engineer's concern regarding increasing NAT gateway costs due to traffic between EC2 instances and Amazon S3, let's analyze each option:
A) Create a Direct Connect private VIF. Migrate the traffic from the public VIF to the private VIF.
- Why it’s rejected: Direct Connect provides a dedicated network connection between an on-premises data center and AWS. A public VIF (Virtual Interface) enables communication with public AWS services like S3, while a private VIF allows communication with AWS resources that are within the VPC. However, since the EC2 instances in the VPC are already using a public VIF to access Amazon S3 (which is a public service), simply moving traffic to a private VIF would not directly address the issue of reducing NAT gateway costs for traffic between EC2 and S3. A private VIF does not solve the problem of routing S3 traffic through a NAT gateway.
B) Create an AWS Site-to-Site VPN tunnel over the existing public VIF.
- Why it’s rejected: Setting up a VPN tunnel over an existing public VIF is a method for securely connecting an on-premises network to AWS, but it would add unnecessary complexity and cost. The VPN would primarily be used for on-premises to AWS communication, not for reducing costs related to EC2-to-S3 traffic. Additionally, VPN connections are generally not as efficient as direct access methods like VPC endpoints for Amazon S3.
C) Implement interface VPC endpo...
Author: ShadowWolf101 · Last updated May 16, 2026
A company wants to improve visibility into its AWS environment. The AWS environment consists of multiple VPCs that are connected to a transit gateway. The transit gateway connects to an on-premises data center through an AWS Direct Connect gateway and a pair of redundant Direct Connect connections that use transit VIFs. The company must receive notif...
To address the network engineer's requirement for receiving notifications whenever a new route is advertised to AWS from on-premises over Direct Connect, let's analyze each option:
A) Enable Amazon CloudWatch metrics on Direct Connect to track the received routes. Configure a CloudWatch alarm to send notifications when routes change.
- Why it’s rejected: While CloudWatch metrics can help monitor the performance of Direct Connect (e.g., connection health, traffic volume), they do not provide detailed visibility into the specific routes being advertised over the connection. CloudWatch metrics primarily monitor the link status and data throughput but not the actual routes themselves. Therefore, this option does not meet the requirement to track and notify when routes change.
B) Onboard Transit Gateway Network Manager to Amazon CloudWatch Logs Insights. Use Amazon EventBridge (Amazon CloudWatch Events) to send notifications when routes change.
- Why it’s rejected: While EventBridge (formerly CloudWatch Events) can indeed send notifications when changes occur, Transit Gateway Network Manager does not directly support route change notifications over Direct Connect. Transit Gateway Network Manager is more about providing visibility into the overall transit network and its connectivity status. Although you can track some network state changes, it does not natively offer direct tracking or notifications for route advertisements over Direct Connect.
C) Configure an AWS Lambda function to periodically check the routes on the Direct Connect gateway and to send notifications when routes change.
- Why it’s rejected: This solution would involve wri...
Author: ShadowWolf101 · Last updated May 16, 2026
A software company offers a software-as-a-service (SaaS) accounting application that is hosted in the AWS Cloud The application requires connectivity to the company's on-premises network. The company has two redundant 10 GB AWS Direct Connect connections between AWS and its on-premises network to accommodate the growing demand for the application.
The company already has encryption between its on-premises network and the colocation. The company needs to encrypt traffic between AWS and...
The goal of the network engineer is to encrypt traffic between AWS and the on-premises network using existing 10 GB Direct Connect connections and without introducing unnecessary operational overhead. Let’s evaluate each option based on these requirements:
A) Deploy a new public VIF with encryption on the existing Direct Connect connections. Reroute traffic through the new public VIF.
- Why it’s rejected: A public VIF (Virtual Interface) is designed for accessing public AWS services, not for private connections between AWS and an on-premises network. Encrypting traffic through a public VIF wouldn’t achieve the required private connectivity for the accounting application or meet the encryption requirement between the on-premises network and AWS. Also, public VIF cannot be used to directly encrypt the traffic over the existing Direct Connect private connections. Thus, this option is unsuitable.
B) Create a virtual private gateway. Deploy new AWS Site-to-Site VPN connections from on premises to the virtual private gateway. Reroute traffic from the Direct Connect private VIF to the new VPNs.
- Why it’s rejected: This option introduces unnecessary complexity and would add additional latency by routing traffic through VPN tunnels. The VPN would encrypt the traffic, but VPNs are typically used for lower bandwidth, less reliable connections, and would add extra overhead to manage, especially for the required 10 GB bandwidth. Using VPNs in this case is less efficient compared to using the native encryption method that Direct Connect offers with MACsec.
C) Deploy a new pair of 10 GB Direct Connect connections with MACsec. Configure MACsec on the edge routers. Reroute traffic to the new Direct Connect connections. Decommission the original Direct Connect connections.
- Why it’s selected: MACsec (Media ...
Author: Sofia2021 · Last updated May 16, 2026
A company hosts an application on Amazon EC2 instances behind an Application Load Balancer (ALB). The company recently experienced a network security breach. A network engineer must collect and analyze logs that include the client IP address, target IP address, target port, and user agent ...
To select the most operationally efficient solution for collecting and analyzing logs that include the client IP address, target IP address, target port, and user agent, let’s evaluate each option:
A) Configure the ALB to store logs in an Amazon S3 bucket. Download the files from Amazon S3, and use a spreadsheet application to analyze the logs.
- Why it’s rejected: Storing the logs in an S3 bucket and manually downloading them to analyze in a spreadsheet application is highly inefficient for real-time analysis, especially for large datasets. It introduces significant operational overhead in terms of manual processing and doesn't scale well. Additionally, this method lacks automation and would not allow for timely or effective monitoring of traffic, which is critical in post-breach scenarios.
B) Configure the ALB to push logs to Amazon Kinesis Data Streams. Use Amazon Kinesis Data Analytics to analyze the logs.
- Why it’s rejected: While Kinesis Data Streams and Kinesis Data Analytics can provide real-time processing and analysis of data, this solution is more complex than needed for log analysis in this case. It involves setting up and managing a streaming data pipeline, which may introduce additional operational overhead and is more suitable for real-time data processing applications rather than log analysis.
C) Configure Amazon Kinesis Data Streams to stream data from the ALB to Amazon OpenSearch Service (Amazon Elasticsearch Service). Use search operations in Amazon OpenSearch Service (Amazon Elasticsearch Service) to analyze the data.
- Why it’s rejected: While Amazon OpenSearch S...
Author: Ethan Smith · Last updated May 16, 2026
A media company is implementing a news website for a global audience. The website uses Amazon CloudFront as its content delivery network. The backend runs on Amazon EC2 Windows instances behind an Application Load Balancer (ALB). The instances are part of an Auto Scaling group. The company's customers access the website by using service example com as the CloudFront custom domain name. The CloudFront origin points to an ALB that uses service-alb.example.com as the domain name.
The company's ...
To ensure that the traffic between users and the backend is encrypted in transit, let's evaluate the proposed options and select the best ones based on security requirements:
A) Create a self-signed certificate for service.example.com. Import the certificate into AWS Certificate Manager (ACM). Configure CloudFront to use this imported SSL/TLS certificate. Change the default behavior to redirect HTTP to HTTPS.
- Why it’s rejected: Self-signed certificates are not recommended for production environments because they are not trusted by clients. CloudFront needs a trusted SSL/TLS certificate to establish secure connections with clients. Additionally, while redirecting HTTP to HTTPS is good practice, using a self-signed certificate would not meet the company’s security policy of using trusted certificates.
B) Create a certificate for service.example.com by using AWS Certificate Manager (ACM). Configure CloudFront to use this custom SSL/TLS certificate. Change the default behavior to redirect HTTP to HTTPS.
- Why it’s selected: This option is ideal for the public-facing CloudFront distribution. A trusted certificate from AWS Certificate Manager (ACM) ensures that CloudFront uses HTTPS for secure communication with clients. By redirecting HTTP to HTTPS, this configuration ensures that all traffic is encrypted in transit between the users and CloudFront, meeting the security policy requirements.
C) Create a certificate with any domain name by using AWS Certificate Manager (ACM) for the EC2 instances. Configure the backend to use this certificate for its HTTPS listener. Specify the instance target type during the creation of a new target group that uses the HTTPS protocol for its targets. Attach the existing Auto Scaling group to this new target group.
- Why it’s rejected: While this option proposes configuring HTTPS for the backend, it is using a certificate for any domain name, which is not aligned with the service-alb.example.com domain name for the backend. This setup could lead to certificate mismatches and security warnings, which can compromise trust and violate security policies. A certificate must match the correct domain (service-alb.example.com) used by the ALB for backend traffic.
D) Create a public certificate from a third-party certificate provider with any domain name for the EC2 instances. Configure the backend to us...
Author: Andrew · Last updated May 16, 2026
A company is hosting an application on Amazon EC2 instances behind a Network Load Balancer (NLB). A solutions architect added EC2 instances in a second Availability Zone to improve the availability of the application. The solutions architect added the instances to the NLB target group.
The company's operations team notices that traffi...
To address the issue where traffic is being routed only to the instances in the first Availability Zone, we need to ensure that the Network Load Balancer (NLB) is properly distributing traffic to the EC2 instances across both Availability Zones. Let’s evaluate each option:
Option A: Enable the new Availability Zone on the NLB
- Explanation: When you add EC2 instances in a new Availability Zone (AZ) to an NLB target group, you need to ensure that the NLB is configured to route traffic to all available AZs. This can be done by explicitly enabling the new AZ in the NLB configuration.
- Why it works: By default, an NLB only routes traffic to instances in AZs that are enabled in the NLB configuration. Enabling the new AZ ensures that traffic can be routed to instances in both the original and the new AZ.
- Why it is preferred: This option is the most operationally efficient solution because it directly addresses the issue without requiring additional changes like creating new NLBs or target groups. It maintains the current setup and simply updates the AZs.
Option B: Create a new NLB for the instances in the second Availability Zone
- Explanation: Creating a new NLB would involve setting up a completely new load balancer to handle traffic for the instances in the second AZ. This option is inefficient as it would require maintaining two separate NLBs.
- Why it's not ideal: It introduces unnecessary complexity by using multiple NLBs for what should be a single load balancing solution, making it harder to manage and maintain. Additionally, you’d lose the benefits of a single global load balancing configuration across all AZs.
Option C: Enable proxy protocol on the NLB
- Explanation: The proxy protocol all...
Author: Krishna · Last updated May 16, 2026
A network engineer needs to set up an Amazon EC2 Auto Scaling group to run a Linux-based network appliance in a highly available architecture. The network engineer is configuring the new launch template for the Auto Scaling group.
In addition to the primary network interface the network appliance requires a second network interface that will be used exclusively by the application to exchange traffic with hosts over the internet. The company has set up a Bring Your...
Let's evaluate each of the options provided for setting up an Amazon EC2 Auto Scaling group with a second network interface (ENI) that uses an Elastic IP address from the BYOIP pool:
Option A: Configure the two network interfaces in the launch template. Define the primary network interface to be created in one of the private subnets. For the second network interface, select one of the public subnets. Choose the BYOIP pool ID as the source of public IP addresses.
- Explanation: This option configures both network interfaces directly in the launch template. The primary ENI is associated with a private subnet, and the second ENI is associated with a public subnet, where the Elastic IP address from the BYOIP pool is used as the public IP.
- Why it works: This is a straightforward and efficient solution for setting up a highly available architecture where the second network interface is exposed to the public subnet with the desired BYOIP Elastic IP address.
- Why it’s preferred: By configuring both ENIs in the launch template, you automate the process of instance creation and network interface attachment without additional scripts or manual intervention. It's highly operationally efficient because everything is handled automatically when the Auto Scaling group launches instances.
Option B: Configure the primary network interface in a private subnet in the launch template. Use the user data option to run a cloud-init script after boot to attach the second network interface from a subnet with auto-assign public IP addressing enabled.
- Explanation: This option uses the cloud-init script in the user data to attach a second network interface to the instance after it boots. The network interface would be in a subnet with auto-assign public IPs enabled.
- Why it's not ideal: This approach introduces complexity because it requires a post-launch script to manage the second network interface attachment. While this can work, it complicates the architecture and may cause delays in instance initialization, which could be a concern for high availability and scaling.
- Why it’s less efficient: Handling network interfaces after boot adds operational complexity and potential failure points. Moreover, it doesn’t offer the same level of control over the network interface as Option A, which directly associates the second ENI during launch.
Option C: Create an AWS Lambda function to run as a lifecycle hook of the Auto Scaling group when an instance is launching. In the Lambda function, assign a network interface to an AWS Glob...
Author: Harper · Last updated May 16, 2026
A company delivers applications over the internet. An Amazon Route 53 public hosted zone is the authoritative DNS service for the company and its internet applications, all of which are offered from the same domain name.
A network engineer is working on a new version of one of the applications. All the application's components are hosted in the AWS Cloud. The application has a three-tier design. The front end is delivered through Amazon EC2 instances that are deployed in public subnets with Elastic IP addresses assigned. The backend components are deployed in private subnets from RFC1918.
Components of the application need to be able to access other components of the application within the application's V...
Let's evaluate each option in detail and determine which steps will best meet the requirements for delivering the application with a consistent DNS experience both internally (within the VPC) and externally (over the internet).
Key Requirements:
1. Access application components within the VPC using the same hostnames that are used over the public internet.
2. Future DNS changes should be accommodated easily (like introducing new hostnames or retiring DNS entries).
3. The application components are in public subnets with Elastic IP addresses, and backend components are in private subnets.
Option A: Add a geoproximity routing policy in Route 53.
- Explanation: A geoproximity routing policy in Route 53 routes traffic based on the geographic location of the requestor and the resources. This option is used for routing traffic based on geographic proximity, not for managing internal and external DNS resolution.
- Why it's rejected: This is not relevant to the need for DNS resolution for both internal and external access to application components. The requirement here focuses on having the same DNS names for internal and external access, not on geographic routing.
Option B: Create a Route 53 private hosted zone for the same domain name. Associate the application’s VPC with the new private hosted zone.
- Explanation: A private hosted zone will allow you to resolve DNS names internally within the VPC. You can create the same domain name in the private hosted zone as in the public hosted zone, but with private IP addresses (for internal communication within the VPC).
- Why it works: By associating the private hosted zone with the VPC, you ensure that internal components of the application can resolve the same hostnames that are used publicly, but they will resolve to private IP addresses for internal traffic. This solution aligns with the requirement to access application components within the VPC using the same hostnames.
- Why it’s selected: This solution directly addresses the need to have the same DNS names for both internal and external use.
Option C: Enable DNS hostnames for the application's VPC.
- Explanation: Enabling DNS hostnames for the VPC ensures that EC2 instances in the VPC can be assigned DNS hostnames. This is necessary for allowing DNS resolution within the VPC.
- Why it works: Enabling DNS hostnames ensures that all the EC2 instances within the VPC can be accessed using DNS names, and it’s a necessary step to ensure that instances can be resolved to their private IP addresses within the VPC.
- Why it’s selected: This is a fundamental step in ensuring that instances can resolve DNS names within the VPC, making it a necessary configuration.
Option D: Create entries in the private hosted zone for each name in the public hosted zone by using the corresponding private IP addresses.
- Explanation: In the private hosted zone, you can manually create DNS entries that match those in the public hosted zone but point to ...
Author: Emily · Last updated May 16, 2026
A company is deploying an application. The application is implemented in a series of containers in an Amazon Elastic Container Service (Amazon ECS) cluster. The company will use the Fargate launch type for its tasks. The containers will run workloads that require connectivity initiated over an SSL connection. Traffic must be able to flow to the application from other AWS acco...
Let's evaluate each of the options based on the requirements and constraints of the given scenario:
Requirements Recap:
- The containers run in an ECS cluster using the Fargate launch type.
- Traffic must be initiated over SSL connections.
- The application must scale as more consumers use the application.
- Private connectivity is needed from other AWS accounts.
- The solution must allow for easy and efficient scaling.
Option A: Choose a Gateway Load Balancer (GLB) as the type of load balancer for the ECS service. Create a lifecycle hook to add new tasks to the target group from Amazon ECS as required to handle scaling. Specify the GLB in the service definition. Create a VPC peer for external AWS accounts. Update the route tables so that the AWS accounts can reach the GLB.
- Explanation: A Gateway Load Balancer (GLB) is typically used to direct traffic to specialized appliances, like security appliances, but it is not the best choice for a standard application load balancing setup. GLBs are designed for use cases like traffic inspection, firewalling, and VPNs, rather than general web traffic routing.
- Why it’s not ideal: GLBs are not designed for SSL traffic and web application load balancing. The GLB solution would also add unnecessary complexity by introducing VPC peering, which is not the most efficient solution for a scenario where SSL and scalable load balancing are needed.
Option B: Choose an Application Load Balancer (ALB) as the type of load balancer for the ECS service. Create path-based routing rules to allow the application to target the containers that are registered in the target group. Specify the ALB in the service definition. Create a VPC endpoint service for the ALB. Share the VPC endpoint service with other AWS accounts.
- Explanation: An Application Load Balancer (ALB) supports SSL termination and path-based routing, which makes it a good fit for web applications. Additionally, it can be used with ECS and Fargate to route traffic to container tasks. A VPC endpoint service for the ALB allows private connectivity from other AWS accounts.
- Why it works: The ALB provides the SSL functionality and scalability required by the application, while the VPC endpoint service allows private connectivity from other AWS accounts. This solution enables scaling, SSL support, and private connectivity in a straightforward manner.
- Why it’s preferred: The ALB is a highly suitable choice because it provides the necessary application-layer routing, SSL handling, and private connectivity with ease.
Option C: Choose an Application Load Balancer (ALB) as the type of load balancer for the ECS service. Create path-bas...
Author: Suresh · Last updated May 16, 2026
A company's development team has created a new product recommendation web service. The web service is hosted in a VPC with a CIDR block of 192.168.224.0/19. The company has deployed the web service on Amazon EC2 instances and has configured an Auto Scaling group as the target of a Network Load Balancer (NLB).
The company wants to perform testing to determine whether users who receive product recommendations spend more money than users who do not receive product recommendations. The company has a big sales event in 5 days and needs to integrate its existing production environment with the recommendation engine by then. The existing...
To meet the requirement of integrating the systems with the least disruption while ensuring a smooth connection between the web service VPC (192.168.224.0/19) and the production VPC (192.168.128.0/17), let's evaluate each option in detail:
Option A: Create a VPC peering connection between the web service VPC and the existing production VPC. Add a routing rule to the appropriate route table to allow data to flow to 192.168.224.0/19 from the existing production environment and to flow to 192.168.128.0/17 from the web service environment. Configure the relevant security groups and ACLs to allow the systems to communicate.
- Explanation: VPC peering establishes a direct network connection between two VPCs, enabling instances in either VPC to communicate with each other as long as appropriate route tables and security groups are configured.
- Why it works: This solution is simple to implement and allows traffic to flow between the two VPCs. It also results in minimal disruption since the existing infrastructure remains unchanged. The routing rules and security configurations ensure that only authorized communication happens between the VPCs.
- Why it’s preferred: VPC peering is a straightforward solution for this use case, as it allows for easy and direct communication between the web service VPC and the production VPC. It is also fast to set up and involves minimal disruption to the existing environment.
- Limitations: The main limitation is that VPC peering does not support transitive routing (i.e., routing between VPCs through a third VPC), but this is not a problem in this scenario because only the two specific VPCs are involved.
Option B: Ask the development team of the web service to redeploy the web service into the production VPC and integrate the systems there.
- Explanation: This option suggests moving the web service to the production VPC, which would involve significant changes to the deployment architecture, reconfiguration of security settings, and potential downtime during the redeployment process.
- Why it’s rejected: This solution would be disruptive because it requires redeploying the web service into the production VPC, which is not ideal when there are only five days left to integrate the systems. It introduces risk, and the redeployment may cause significant delays or complications, especially given that the integration needs to be completed soon.
Option C: Create a VPC endpoint service. Associate the VPC endpoint service with the NLB for the web service. Create an interface VPC endpoint for the web service in the existing production VPC.
- Explanation: A VPC endpoint...
Author: ShadowWolf101 · Last updated May 16, 2026
A network engineer needs to update a company's hybrid network to support IPv6 for the upcoming release of a new application. The application is hosted in a VPC in the AWS Cloud. The company's current AWS infrastructure includes VPCs that are connected by a transit gateway. The transit gateway is connected to the on-premises network by AWS Direct Connect and AWS Site-to-Site VPN. The company's on-premises devices have been updated to support the new IPv6 requirements.
The company has enabled IPv6 for the existing VPC by assigning a new IPv6 CIDR block to the VPC and by assigning IPv6 to the subnets for dual-stack support. The company has launched new Amazon EC2 instances for the new application in the updated subnets.
When updating the hybrid network to support IPv6 the network eng...
Analysis:
To determine the best solution, we need to consider several key factors:
1. IPv6 Connectivity Between VPC and On-Premises:
The company wants to support IPv6 without changing the current infrastructure. This means the solution should not involve making changes to existing VPC connections, Direct Connect, or Site-to-Site VPN, except to add IPv6 support where necessary.
2. Blocking Direct Internet Access to EC2 Instances via IPv6:
The engineer must block direct inbound internet access to the EC2 instances' IPv6 addresses. However, outbound internet access needs to be allowed.
3. Operational Efficiency:
The solution should minimize operational overhead, ensuring that the existing setup is utilized as much as possible and does not involve unnecessary steps or resources.
---
Option Breakdown:
- Option A:
- Update the Direct Connect transit VIF and configure BGP peering with the AWS-assigned IPv6 peering address.
- Create a new VPN connection that supports IPv6.
- Add an egress-only internet gateway.
- Update security groups and route tables.
Analysis:
- Direct Connect and VPN Update: This is fine since both are capable of supporting IPv6 and can be updated without impacting existing infrastructure.
- Egress-only Internet Gateway: This is the correct way to block direct inbound access to the instances' IPv6 addresses while allowing outbound internet access.
- Security Group and Route Table Updates: Updating these to ensure proper IPv6 communication is standard practice.
- Pros: Efficient solution that avoids making major changes to the infrastructure.
- Cons: This requires creating a new VPN connection, which might be slightly cumbersome compared to reusing existing connections.
- Option B:
- Same as Option A but updates the existing VPN connection to support IPv6 connectivity instead of creating a new VPN connection.
Analysis:
- This is the more efficient choice compared to Option A because it avoids the need for a new VPN connection and le...
Author: Amira · Last updated May 16, 2026
A network engineer must provide additional safeguards to protect encrypted data at Application Load Balancers (ALBs) through the use of a unique random sessio...
Analysis:
To meet the requirement of providing additional safeguards to protect encrypted data at Application Load Balancers (ALBs) using a unique random session key, the network engineer needs to focus on ensuring that the encryption at the ALB leverages strong session key protection, ideally through mechanisms like forward secrecy (FS) or encryption keys that are unique and robust.
---
Option Breakdown:
- Option A: Change the ALB security policy to a policy that supports TLS 1.2 protocol only.
- Analysis: TLS 1.2 is a widely used protocol that provides secure communication, but it does not necessarily involve the concept of a unique random session key or forward secrecy. It mainly ensures the confidentiality and integrity of data during transmission.
- Pros: Ensures secure encryption using TLS 1.2, which is considered strong.
- Cons: This option does not specifically address the requirement for a unique random session key or safeguards related to forward secrecy. It only addresses the protocol used for encryption, without adding the layer of security that would protect the session keys in the way forward secrecy would.
- Use Case: While TLS 1.2 is necessary for security, this option alone does not meet the unique session key requirement.
- Option B: Use AWS Key Management Service (AWS KMS) to encrypt session keys.
- Analysis: AWS KMS is a fully managed service that allows for the creation and control of encryption keys. Using KMS to encrypt session keys would add an additional layer of protection to the session keys used by the ALB. However, session keys are typically generated dynamically and used for short durations, so the emphasis should be on forward secrecy to ensure that session keys are not compromised.
- Pros: AWS KMS is an excellent way to manage and protect keys, and it can provide strong encryption.
- Cons: While KMS is a powerful tool for key management, it does not directly address the requirement for forward secrecy or a unique random session key in the context of protecting data in transit during the TLS handshake.
- Use Case: KMS can be beneficial for protecting keys in a broader sense, but forward secrecy would be the better approach for ensuring s...
Author: Ella · Last updated May 16, 2026
A company has deployed a software-defined WAN (SD-WAN) solution to interconnect all of its offices. The company is migrating workloads to AWS and needs to extend its SD-WAN solution to support connectivity to these workloads.
A network engineer plans to deploy AWS Transit Gateway Connect and two SD-WAN virtual appliances to provide this connectivity. According to company policies, only...
Analysis:
To meet the company's requirements of routing traffic through a single SD-WAN virtual appliance at a given time, the network engineer needs to configure routing in such a way that only one SD-WAN appliance handles traffic to/from the AWS workloads, while still allowing flexibility in the network architecture.
Here’s a breakdown of the options:
---
Option A: Add a static default route in the transit gateway route table to point to the secondary SD-WAN virtual appliance. Add routes that are more specific to point to the primary SD-WAN virtual appliance.
- Analysis:
- Static Routes: By using static routes, the engineer can ensure that specific traffic is directed to the primary or secondary SD-WAN appliance.
- Default Route to Secondary Appliance: Pointing the default route to the secondary appliance could work for backup traffic, ensuring it handles traffic only when no more specific routes are available for the primary appliance.
- More Specific Routes to Primary Appliance: Specific routes to workloads or subnets could direct traffic through the primary appliance, as required by the company policy.
- Pros: This setup would ensure that the primary appliance handles the normal workload, with the secondary appliance being used as a backup. It’s simple and straightforward.
- Cons: The downside is the manual management of routes, which might be less scalable or flexible if the network grows or changes frequently.
- Use Case: This is an ideal option for a simple setup where traffic needs to be statically routed to a primary appliance and failover to a secondary appliance in case of issues.
---
Option B: Configure the BGP community tag 7224:7300 on the primary SD-WAN virtual appliance for BGP routes toward the transit gateway.
- Analysis:
- BGP Community Tags: Community tags in BGP are typically used to signal routing preferences between peers, such as preferring one route over another.
- BGP Preferences: By using the community tag to prefer routes from the primary appliance, the network engineer can influence routing decisions. However, this approach doesn’t inherently restrict routing to a single appliance; instead, it would only prioritize one appliance's routes over the other.
- Pros: This method provides some control over which appliance is preferred.
- Cons: It doesn’t guarantee that only one appliance handles traffic at a given time, which is the requirement. There could still be scenarios where both appliances handle traffic simultaneously.
- Use Case: While useful for controlling route preference, it doesn't meet the requirement of ensuring only one appliance is handling traffic at ...
Author: Noah · Last updated May 16, 2026
A company is planning to deploy many software-defined WAN (SD-WAN) sites. The company is using AWS Transit Gateway and has deployed a transit gateway in the required AWS Region. A network engineer needs to deploy the SD-WAN hub virtual appliance into a VPC that is connected to the transit gateway. The solution must support at least 5 Gbps of t...
Analysis:
The company needs a solution that supports at least 5 Gbps of throughput from the SD-WAN hub virtual appliance to other VPCs connected to the AWS Transit Gateway. Given this high throughput requirement, the solution must be capable of handling substantial traffic efficiently.
Let’s review each option:
---
Option A: Create a new VPC for the SD-WAN hub virtual appliance. Create two IPsec VPN connections between the SD-WAN hub virtual appliance and the transit gateway. Configure BGP over the IPsec VPN connections.
- Analysis:
- IPsec VPN Connections: Using IPsec VPNs over the Transit Gateway to connect the SD-WAN hub virtual appliance is not ideal for handling the required throughput (5 Gbps). IPsec VPNs typically have performance limitations, especially when dealing with high throughput.
- BGP over VPN: While BGP can be used to manage the routing over the VPN connections, IPsec VPNs are not optimized for very high throughput, making this option unsuitable for meeting the 5 Gbps requirement.
- Pros: Relatively simple setup, widely used in smaller-scale deployments.
- Cons: IPsec VPNs introduce performance bottlenecks for high-throughput scenarios.
- Use Case: Best for smaller throughput requirements or simpler setups.
---
Option B: Assign a new CIDR block to the transit gateway. Create a new VPC for the SD-WAN hub virtual appliance. Attach the new VPC to the transit gateway with a VPC attachment. Add a transit gateway Connect attachment. Create a Connect peer and specify the GRE and BGP parameters. Create a route in the appropriate VPC for the SD-WAN hub virtual appliance to route to the transit gateway.
- Analysis:
- Transit Gateway Connect Attachment: The use of the Transit Gateway Connect attachment is a scalable and efficient solution for connecting SD-WAN appliances to the Transit Gateway. It supports high throughput and is optimized for SD-WAN traffic.
- GRE and BGP: GRE (Generic Routing Encapsulation) and BGP are suitable for handling dynamic routing with high throughput, and this setup supports the required bandwidth and performance.
- Pros: The Transit Gateway Connect attachment is specifically designed for high-throughput SD-WAN solutions, making this option well-suited for the 5 Gbps requirement.
- Cons: The setup involves multiple components, such as CIDR block assignments and route configuration, but it is still efficient and scalable.
- Use Cas...
Author: Mia · Last updated May 16, 2026
A company is deploying a new application on AWS. The application uses dynamic multicasting. The company has five VPCs that are all attached to a transit gateway Amazon EC2 instances in each VPC need to be able to register dynamically to receive a mu...
Analysis:
The company is deploying an application that uses dynamic multicasting, where EC2 instances across multiple VPCs must be able to register dynamically to receive multicast transmissions. AWS Transit Gateway supports multicast, but the configuration must consider the protocols and traffic types involved, as well as proper routing and multicast group management.
Let’s break down the options:
---
Option A: Create a static source multicast domain within the transit gateway. Associate the VPCs and applicable subnets with the multicast domain. Register the multicast senders' network interface with the multicast domain. Adjust the network ACLs to allow UDP traffic from the source to all receivers and to allow UDP traffic that is sent to the multicast group address.
- Analysis:
- Static Source Multicast Domain: A static multicast domain is typically used for scenarios where multicast sources and receivers are pre-configured and not subject to dynamic changes. However, dynamic multicast registration is required in this case.
- UDP Traffic: Multicast typically uses UDP for transmission of data, as it's a connectionless protocol well-suited for multicast traffic. This configuration is correct in allowing UDP traffic for multicast.
- Network ACLs: Allowing UDP traffic for multicast group addresses is correct for multicast to function properly.
- Pros: Configures multicast in a static way, which would be suitable for certain use cases but not for dynamic registration.
- Cons: This option is not dynamic enough to support the dynamic registration of EC2 instances as required.
- Use Case: This might work for environments with static multicast sources and receivers, but dynamic registration is a key requirement that this option does not address.
---
Option B: Create a static source multicast domain within the transit gateway. Associate the VPCs and applicable subnets with the multicast domain. Register the multicast senders' network interface with the multicast domain. Adjust the network ACLs to allow TCP traffic from the source to all receivers and to allow TCP traffic that is sent to the multicast group address.
- Analysis:
- TCP Traffic: Multicast traffic is typically transmitted using UDP, not TCP. Multicast over TCP is not a standard approach, as TCP is connection-oriented, which contradicts the nature of multicast communications.
- Static Multicast Domain: As mentioned earlier, a static multicast domain does not support the dynamic registration that is required for the EC2 instances to register automatically.
- Network ACLs: The inclusion of TCP traffic in the network ACLs is incorrect for multi...
Author: Madison · Last updated May 16, 2026
A company is creating new features for its ecommerce website. These features will use several microservices that are accessed through different paths. The microservices will run on Amazon Elastic Container Service (Amazon ECS). The company requires the use of HTTPS for all of its public websites. The application requires the customer's source IP addresses.
A network engineer must im...
In this scenario, the company needs to implement a load balancing strategy that supports HTTPS for all public websites, and also allows retrieval of the customer's source IP addresses. Let's break down the options based on the requirements:
1. HTTPS support: The company requires all public-facing websites to use HTTPS, which implies the need for TLS/SSL termination at the load balancer level.
2. Retrieving customer source IP addresses: The microservices need to access the customer's original IP address, which means we need to ensure that the load balancer forwards the correct source IP address to the microservices.
Option Analysis:
A) Use a Network Load Balancer (NLB)
- Explanation: A Network Load Balancer (NLB) operates at the Layer 4 (Transport) level, handling TCP/UDP traffic. It doesn't provide built-in support for terminating HTTPS requests or reading headers like `X-Forwarded-For`. It forwards requests to backend services without inspecting HTTP headers. This option doesn't support HTTPS termination or provide the ability to retrieve client IP addresses via HTTP headers.
- Rejection: While it can forward traffic based on IP, it doesn't meet the requirement for HTTPS termination and passing the client IP as needed.
B) Retrieve client IP addresses by using the X-Forwarded-For header
- Explanation: The `X-Forwarded-For` header is commonly used by HTTP/HTTPS load balancers to pass the original client IP address. This header is typically used in conjunction with an Application Load Balancer (ALB) or a Reverse Proxy. The header allows microservices to access the client's real IP address, which is crucial for logging, geolocation, and other purposes.
- Selection Reason: This option is suitable as it directly addresses the requirement to retrieve the customer’s original IP address.
C) Use ...
Author: MoonlitPantherX · Last updated May 16, 2026
A company is migrating its containerized application to AWS. For the architecture the company will have an ingress VPC with a Network Load Balancer (NLB) to distribute the traffic to front-end pods in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The front end of the application will determine which user is requesting access and will send traffic to 1 of 10 services VPCs. Each services VPC will include an NLB that distributes traffic to the services pods in an EKS cluster.
The company is concerned about overall cost. User traffic will be responsib...
Let's analyze each solution option in terms of cost, scalability, and meeting the requirements for high-volume traffic transfer:
Key Requirements:
1. Cost-Effective Solution: The company is concerned about costs, especially with over 10 TB of data transfer monthly. Any solution that minimizes inter-VPC traffic costs will be ideal.
2. Traffic Distribution: Traffic from the ingress VPC to the 10 service VPCs needs to be managed in a way that minimizes data transfer costs.
3. AWS Architecture: We need to ensure communication is secure, scalable, and efficient between the VPCs, without unnecessarily increasing costs.
Option Analysis:
A) Create a transit gateway. Peer each VPC to the transit gateway. Use zonal DNS names for the NLB in the services VPCs to minimize cross-AZ traffic from the ingress VPC to the services VPCs.
- Explanation: A Transit Gateway is a highly scalable solution for inter-VPC communication. By using zonal DNS names, the NLB in the services VPCs can ensure that traffic is routed within the same Availability Zone (AZ), minimizing cross-AZ traffic and associated costs.
- Cost Considerations: Transit Gateway pricing depends on the data transfer between VPCs. While it's scalable, the transit gateway charges for data transfer between VPCs, and the additional VPC peering costs can make this option more expensive for large-scale traffic like 10 TB/month.
- Rejection Reason: Even though a Transit Gateway allows for easy inter-VPC communication, its data transfer costs and the fact that each VPC will be directly connected to the gateway (with charges based on transfer volume) make this a potentially higher-cost solution.
B) Create an AWS PrivateLink endpoint in every Availability Zone in the ingress VPC. Each PrivateLink endpoint will point to the zonal DNS entry of the NLB in the services VPCs.
- Explanation: AWS PrivateLink enables private connectivity between VPCs via endpoints. It ensures secure and private communication, but also incurs PrivateLink data processing and hourly charges for each endpoint. Each VPC would require multiple endpoints in each AZ.
- Cost Considerations: While PrivateLink provides secure connectivity, its pricing model for data processing and the creation of multiple endpoints in each AZ could lead to high costs, particularly for the significant amount of traffic (10 TB/month) expected in this architecture.
- Rejection Reason: While PrivateLink offers security and private communication, the data transfer costs associated with high-volume traffic across many endpoints would make this a more expensive option, especially for a setup that requires 10 TB of data transfer monthly.
C) Create a VPC peering connection between the ingress VPC and each of the 10 services V...
Author: Amira · Last updated May 16, 2026
A company has stateful security appliances that are deployed to multiple Availability Zones in a centralized shared services VPC. The AWS environment includes a transit gateway that is attached to application VPCs and the shared services VPC. The application VPCs have workloads that are deployed in private subnets across multiple Availability Zones. The stateful appliances in the shared services VPC inspect all east west (VPC-to-VPC) traffic.
Users report that inter-VPC traffic to different Availability Zones is dropping. A network engineer verified this claim by issuing Internet Control Message Protocol (I...
Let's analyze the given scenario and the options one by one to understand the cause of the dropped traffic.
Scenario Breakdown:
- Stateful security appliances: These appliances inspect all east-west (VPC-to-VPC) traffic between application VPCs.
- Transit Gateway: It connects the application VPCs to the shared services VPC where the stateful appliances are deployed.
- Traffic dropping: The inter-VPC traffic between different Availability Zones in the application VPCs is dropping. ICMP pings from workloads across Availability Zones are failing.
The network engineer has ruled out security groups, stateful device configurations, and network ACLs as the cause of the issue. This leaves us with the potential cause being something related to the transit gateway or how it interacts with the stateful appliances in the shared services VPC.
Option Analysis:
A) The stateful appliances and the transit gateway attachments are deployed in a separate subnet in the shared services VPC.
- Explanation: Deploying the stateful appliances and the transit gateway attachments in separate subnets within the shared services VPC might create communication issues if the routing between these subnets is not set up correctly. However, this would not cause the dropping of traffic as described unless there's a routing or security issue between the subnets.
- Rejection Reason: While this setup could cause communication issues between subnets, it doesn't directly explain why traffic between different Availability Zones is dropping.
B) Appliance mode is not enabled on the transit gateway attachment to the shared services VPC.
- Explanation: Appliance mode on a transit gateway attachment allows traffic to be routed through stateful appliances such as firewalls, intrusion detection systems, etc. If appliance mode is not enabled on the attachment to the shared services VPC, the traffic would bypass the appliances and not be inspected. This would cause issues with east-west traffic inspection, and traffic might not be properly handled by the appliances, resulting in drops or lack of inspection.
- Selection Reason...
Author: Maya · Last updated May 16, 2026
A company has hundreds of Amazon EC2 instances that are running in two production VPCs across all Availability Zones in the us-east-1 Region. The production VPCs are named
VPC A and VPC B.
A new security regulation requires all traffic between production VPCs to be inspected before the traffic is routed to its final destination. The company deploys a new shared VPC that contains a stateful firewall appliance and a transit gateway with a VPC attachment across all VPCs to route traffic between VPC A and VPC B through the firewall appliance for ins...
To address the issue of traffic being dropped when traversing between different Availability Zones (AZs) through the transit gateway, we need to focus on the root cause of the problem. The main issue is that traffic between different AZs is not correctly being routed through the firewall appliance in the shared VPC for inspection.
Let's break down the options:
A) In the shared VPC, replace the VPC attachment with a VPN attachment. Create a VPN tunnel between the transit gateway and the firewall appliance. Configure BGP.
- Explanation: This option introduces VPN tunnels and BGP, which adds complexity and overhead. VPNs between the transit gateway and firewall appliance would not address the core requirement of inspecting inter-VPC traffic efficiently. The use of VPN connections would introduce unnecessary complexity and operational overhead, particularly for routing large volumes of traffic between VPCs.
- Rejection Reason: This solution adds significant management overhead and is not the most effective or efficient way to route traffic between VPCs through a firewall appliance. It's not aligned with the goal of minimizing management overhead.
B) Enable transit gateway appliance mode on the VPC attachment in VPC A and VPC B.
- Explanation: Transit Gateway appliance mode ensures that the traffic between VPCs is directed to a stateful appliance for inspection. Enabling appliance mode on the VPC attachment to VPC A and VPC B would ensure that the traffic from both VPCs is routed through the firewall appliance in the shared VPC for inspection.
- Selection Reason: This option would ensure that all traffic between VPC A and VPC B is correctly routed through the firewall appliance for inspection. However, this approach does not address the issue if the firewall appliance is in the shared VPC, which may require appliance mode to be enabled on the VPC attachment in the shared VPC to properly route traffic through it.
- Rejection Reason: While enabling appliance mode on VPC A and VPC B is ...
Author: Stella · Last updated May 16, 2026
A company has deployed a critical application on a fleet of Amazon EC2 instances behind an Application Load Balancer. The application must always be reachable on port 443 from the public internet. The application recently had an outage that resulted from an incorrect change to the EC2 security group.
A network engineer needs to automate a way to verify the network connectivity between the public internet and the EC2 instances ...
Let's analyze each option based on the requirement to automate the verification of network connectivity between the public internet and EC2 instances whenever a change is made to the security group and notify the network engineer if the change impacts connectivity.
Requirements:
- The application must always be reachable on port 443 from the public internet.
- The solution must automate the verification of connectivity whenever a change is made to the EC2 security group.
- The solution must notify the network engineer if the change affects connectivity.
Option Analysis:
A) Enable VPC Flow Logs on the elastic network interface of each EC2 instance to capture REJECT traffic on port 443. Publish the flow log records to a log group in Amazon CloudWatch Logs. Create a CloudWatch Logs metric filter for the log group for rejected traffic. Create an alarm to notify the network engineer.
- Explanation: VPC Flow Logs capture network traffic metadata, including whether traffic is allowed or rejected. Enabling flow logs to capture rejected traffic specifically for port 443 allows the engineer to detect when traffic is being blocked. However, this solution only provides reactive monitoring and is not triggered automatically by changes to security groups. It also may result in high data volumes, and you would need to manually configure and monitor the rejected traffic metrics.
- Rejection Reason: Although VPC Flow Logs could provide valuable information, this solution doesn't meet the requirement for automatic notification based on security group changes. It also doesn't proactively test connectivity in real-time.
B) Enable VPC Flow Logs on the elastic network interface of each EC2 instance to capture all traffic on port 443. Publish the flow log records to a log group in Amazon CloudWatch Logs. Create a CloudWatch Logs metric filter for the log group for all traffic. Create an alarm to notify the network engineer.
- Explanation: This option captures all traffic on port 443, which could generate a lot of flow log data, especially if the application experiences high traffic. It then uses CloudWatch Logs metric filters to monitor for any changes in traffic. While this can provide some level of monitoring, it doesn't automate the verification of the actual connectivity whenever a change is made to the security group. It would also result in monitoring all traffic, not specifically targeting issues arising from security group changes.
- Rejection Reason: While it can capture traffic patterns, this approach lacks automation in verifying connectivity based on security group changes. It is more passive and doesn't fully meet the requirement.
C) Create a VPC Reachability Analyzer path on port 443. Specify the security group as the source. Specify the EC2 instances as the destination. Create an Amazon Simple Notification Service (Amazon SNS) top...
Author: Sofia · Last updated May 16, 2026
A security team is performing an audit of a company's AWS deployment. The security team is concerned that two applications might be accessing resources that should be blocked by network ACLs and security groups. The applications are deployed across two Amazon Elastic Kubernetes Service (Amazon EKS) clusters that use the Amazon VPC Container Network Interface (CNI) plugin for Kubernetes. The clusters are in separate subnets within the same VPC and have a Cluster Autoscaler configured.
The security team needs to determine which POD IP addresses are communicating...
Key Factors in Reasoning:
1. VPC Flow Logs Format:
- The flow logs can be configured in either the default format or custom format. The default format provides basic information, whereas the custom format allows for specific field selections, like source and destination IP addresses of the packets (`pkt-srcaddr`, `pkt-dstaddr`), which would be critical for the security team in identifying application-level traffic.
2. Traffic Source and Destination:
- The security team is interested in monitoring traffic from the two applications deployed in EKS clusters. To minimize the number of flow logs and focus on relevant traffic, it is crucial to narrow the logs to the application-specific resources.
3. Resource Selection:
- EKS nodes (or EC2 instances running EKS) could be monitored using VPC flow logs, but in a Kubernetes environment, it’s more relevant to focus on application-specific subnets or Pod IPs to pinpoint the traffic between specific applications.
4. Operational Overhead:
- Limiting the flow logs to only the relevant application traffic and using a custom format reduces unnecessary log data, reducing operational overhead and storage costs.
Analyzing the Options:
- Option A:
- VPC flow logs in the default format can capture basic information but does not provide the specific packet-level data (like `pkt-srcaddr` and `pkt-dstaddr`) that is crucial for identifying application-specific communication. Also, this option limits the scope to EKS nodes, which may not capture traffic between pods directly.
- Rejected: Not sufficient for monitoring traffic between specific ...
Author: Mia · Last updated May 16, 2026
A data analytics company has a 100-node high performance computing (HPC) cluster. The HPC cluster is for parallel data processing and is hosted in a VPC in the AWS Cloud. As part of the data processing workflow, the HPC cluster needs to perform several DNS queries to resolve and connect to Amazon RDS databases, Amazon S3 buckets, and on-premises data stores that are accessible through AWS Direct Connect. The HPC cluster can increase in size by five to seven times during the company's peak event at the end of the year.
The company is using two Amazon EC2 instances as primary DNS servers for the VPC. The EC2 instances are configured to forward queries to the default VPC resolver for Amazon Route 53 hosted domains and to the on-premises DNS ...
Key Factors in Reasoning:
1. Scalability:
- The HPC cluster is expected to scale from 100 nodes to 500-700 nodes during peak events. Any DNS solution must be able to handle this growth efficiently without introducing bottlenecks or failure points.
2. DNS Query Resolution for AWS Services:
- The HPC cluster needs to resolve DNS names for AWS services like Amazon RDS and S3, as well as on-premises services through AWS Direct Connect. The solution must support resolution of AWS resources as well as external on-premises resources reliably.
3. Reliability:
- DNS failures in an HPC environment can lead to job failures, making it critical to have a highly available and fault-tolerant DNS service.
4. Operational Simplicity:
- The solution should simplify DNS management, reduce overhead, and avoid complexity in scaling out DNS services manually as the cluster grows.
Analyzing the Options:
- Option A:
- Scaling out the DNS service by adding two additional EC2 instances: This option suggests manually adding more EC2 instances as DNS servers, then reconfiguring the HPC nodes to use these new servers. The HPC cluster will still be dependent on EC2-based DNS servers, which requires manual scaling and configuration. This approach introduces operational overhead as the cluster grows, and does not scale automatically.
- Rejected: While it provides a solution for scaling, it requires manual intervention for scaling and management, which increases complexity and operational overhead as the cluster grows.
- Option B:
- Scaling up the existing EC2 instances by changing their instance size: This option suggests resizing the existing EC2 DNS servers to the largest possible instance size. While this may improve performance for the current load, it will not solve the scalability problem in the long term, especially when the cluster increases in size by 5 to 7 times during peak events. This ...
Author: IronLion88 · Last updated May 16, 2026
A company's network engineer is designing an active-passive connection to AWS from two on-premises data centers. The company has set up AWS Direct Connect connections between the on-premises data centers and AWS. From each location, the company is using a transit VIF that connects to a Direct Connect gateway that is associated with a transit gateway.
The network engineer must ensure that traffic from AWS to the data cen...
Key Factors in Reasoning:
1. BGP Routing and Traffic Flow:
- The company needs to control the routing of traffic from AWS to its on-premises data centers. This requires influencing BGP route preference to ensure that traffic is routed primarily to the primary data center and only fails over to the failover data center in the event of an outage.
2. BGP Community Tags:
- BGP community tags are a mechanism used to influence routing decisions in a network. By assigning different community tags to routes from the primary and failover data centers, the network engineer can set preferred routes.
3. Active-Passive Failover:
- In an active-passive setup, the primary connection (from the primary data center) should be preferred under normal conditions, and only if it becomes unavailable, should the traffic failover to the secondary connection (failover data center). This is usually achieved by setting lower-preference community tags for the primary data center and higher-preference tags for the failover data center.
Analyzing the Options:
- Option A:
- Primary data center: BGP community tag `7224:7100`.
- Failover data center: BGP community tag `7224:7300`.
- Typically, lower values for the BGP community tag are preferred in routing. Since the primary data center has the tag `7224:7100` (which is lower than `7224:7300`), traffic will be routed primarily to the primary data center. If there’s an issue with the primary data center, the failover data center, tagged with a higher community value (`7224:7300`), will be used.
- Selected: This option works because it assigns a lower community tag to the primary data center, ensuring traffic is routed to it first, and the failover data center is used only when the primary is unavailable.
- Option B:
- Primary data cent...
Author: Ravi Patel · Last updated May 16, 2026
A real estate company is building an internal application so that real estate agents can upload photos and videos of various properties. The application will store these photos and videos in an Amazon S3 bucket as objects and will use Amazon DynamoDB to store corresponding metadata. The S3 bucket will be configured to publish all PUT events for new object uploads to an Amazon Simple Queue Service (Amazon SQS) queue.
A compute cluster of Amazon EC2 instances will poll the SQS queue to find out about newly uploaded objects. The cluster will retrieve new objects, perform proprietary image and video recognition and classifica...
Key Factors in Reasoning:
1. No Public IP Addresses on EC2 Instances:
- The company does not want public IP addresses on the EC2 instances, which means the instances must be in a private subnet.
2. Internet Access for EC2 Instances:
- The EC2 instances need to access services like Amazon SQS, Amazon S3, and Amazon DynamoDB. The method of accessing these services should not involve using public IP addresses or require NAT gateways unless absolutely necessary.
3. Cost Efficiency:
- As the application usage increases, it's important to choose a solution that scales cost-effectively. This includes minimizing the need for NAT gateways or public IP addresses, as both can add significant costs.
4. AWS Service Endpoints:
- Using VPC endpoints for Amazon SQS, S3, and DynamoDB allows the EC2 instances to access these services directly through private IP addresses, ensuring security and reducing the need for internet-bound traffic.
Analyzing the Options:
- Option A:
- Public subnet with disabled public IP address: While this approach would allow EC2 instances to access the internet via an internet gateway, it contradicts the requirement to avoid using public IP addresses. Disabling the public IP assignment on the EC2 instances doesn’t solve the need for a secure and cost-effective method to access services like SQS, S3, and DynamoDB.
- Rejected: This setup involves unnecessary complexity with public access and doesn't meet the cost-efficient, private networking requirements.
- Option B:
- Private subnet with NAT gateway: This solution involves placing the EC2 instances in a private subnet and using a NAT gateway to provide internet access. However, NAT gateways are costly, especially as traffic scales. Also, the NAT gateway doesn’t...
Author: Manish · Last updated May 16, 2026
A company has an AWS Direct Connect connection between its on-premises data center in the United States (US) and workloads in the us-east-1 Region. The connection uses a transit VIF to connect the data center to a transit gateway in us-east-1.
The company is opening a new office in Europe with a new on-premises data center in England. A Direct Connect connection will connect the new data center with some workloads that are running in a single VPC in the eu-west-2 Region. The company needs to connect the US data center and us-east-1 with the Europe da...
Key Factors in Reasoning:
1. Connectivity Between Data Centers and Regions:
- The company needs to establish connectivity between the on-premises data centers in the US and Europe, and between workloads in the us-east-1 and eu-west-2 Regions. This requires a design that supports inter-region and inter-data center communication with low latency.
2. AWS Direct Connect Gateways and Transit Gateways:
- The Direct Connect gateway allows for cross-region connectivity, and a transit gateway can provide centralized routing for multiple VPCs and on-premises connections.
- SiteLink enables direct communication between VPCs and on-premises networks connected via Direct Connect without going through the internet.
3. Latency Considerations:
- Minimizing latency is crucial, so the design should avoid unnecessary hops and leverage the lowest-latency path for inter-region traffic.
4. Solution Flexibility and Scalability:
- The solution must be flexible and scalable to support future growth and potentially more regions or data centers.
Analyzing the Options:
- Option A:
- Connect the VPC in eu-west-2 to the Europe data center via a Direct Connect gateway and a private VIF. Then, associate the transit gateway in us-east-1 with the same Direct Connect gateway and enable SiteLink for both the transit VIF and private VIF.
- This solution uses the Direct Connect gateway to bridge the Europe data center and the VPC in eu-west-2, and it connects the US transit gateway to this Direct Connect gateway. However, it doesn't fully address the requirement of direct, low-latency communication between the US and Europe regions because the two regions (us-east-1 and eu-west-2) may need separate, dedicated connections.
- Rejected: While it achieves inter-region connectivity, the method might not be as efficient for high-performance, low-latency traffic between the two regions.
- Option B:
- Connect the VPC in eu-west-2 to a new transit gateway and the Europe data center to the new transit gateway using a Direct Connect gateway and a new transit VIF. Peer this new transit gateway with the us-east-1 transit gateway, and enable SiteLink for both transit VIFs.
- This ...
Author: FrozenWolf2022 · Last updated May 16, 2026
A network engineer has deployed an Amazon EC2 instance in a private subnet in a VPC. The VPC has no public subnet. The EC2 instance hosts application code that sends messages to an Amazon Simple Queue Service (Amazon SQS) queue. The subnet has the default network ACL with no modification applied. The EC2 instance has the default security grou...
To diagnose why the EC2 instance is not able to send messages to Amazon SQS, let’s consider the key components that could impact connectivity and functionality:
Option A: The EC2 instance is not attached to an IAM role that allows write operations to Amazon SQS.
- Reasoning: This is a valid cause. An IAM role is needed for the EC2 instance to interact with AWS services like SQS. If the EC2 instance does not have the correct IAM permissions to write to SQS, it won't be able to send messages, even if the network configuration is correct.
- Scenario: This is a common scenario where an IAM role might not be properly configured or attached to the EC2 instance. This would prevent the EC2 instance from interacting with SQS.
- Conclusion: This is a possible cause.
Option B: The security group is blocking traffic to the IP address range used by Amazon SQS.
- Reasoning: This is not a likely cause. By default, EC2 instances in a default security group can send traffic to any destination, as outbound traffic is allowed. Unless the security group is specifically modified to restrict outbound traffic (which is not mentioned here), the security group would not block SQS communication.
- Scenario: This would apply only if outbound traffic rules on the security group were explicitly restrictive, but that’s not stated in the problem.
- Conclusion: This is not a likely cause.
Option C: There is no interface VPC endpoint configured for Amazon SQS.
- Reasoning: This could be a valid cause if the EC2 instance is in a private subnet without access to the internet. Without a VPC endpoint for SQS, the EC2 instance would not be able to send messages to SQS since there is no direct route to the SQS service.
- Scenario:...
Author: Julian · Last updated May 16, 2026
A network engineer needs to standardize a company's approach to centralizing and managing interface VPC endpoints for private communication with AWS services. The company uses AWS Transit Gateway for inter-VPC connectivity between AWS accounts through a hub-and-spoke model. The company's network services team must manage all Amazon Route 53 zones and interface endpoints within a shared services AWS account. The company wants to use this centralized m...
To address the requirement of centralizing and managing interface VPC endpoints for private communication with AWS services (such as AWS Key Management Service or AWS KMS) in a hub-and-spoke architecture using AWS Transit Gateway, let's analyze each option carefully.
Key Factors to Consider:
- Centralized Management: The company wants to centralize the management of interface VPC endpoints in the shared services AWS account.
- AWS Transit Gateway: Since the company uses AWS Transit Gateway in a hub-and-spoke model, VPCs must be able to communicate via the Transit Gateway without traffic going over the public internet.
- Private DNS: The private DNS for AWS services like KMS must remain functional so that AWS resources can access KMS through the interface endpoint.
Option A: In the shared services account, create an interface endpoint for AWS KMS. Modify the interface endpoint by disabling the private DNS name. Create a private hosted zone in the shared services account with an alias record that points to the interface endpoint. Associate the private hosted zone with the spoke VPCs in each AWS account.
- Explanation: This option creates a centralized interface endpoint for KMS in the shared services account. It then disables the private DNS name and creates a private hosted zone in the shared services account, which is associated with the spoke VPCs. This approach ensures that the shared services account manages the interface endpoint and the DNS records, and it also centralizes the management of the KMS access.
- Reasoning: By centralizing the DNS management in the shared services account and associating the private hosted zone with the spoke VPCs, the approach fits the company's goal of centralization.
- Conclusion: This is a valid option.
Option B: In the shared services account, create an interface endpoint for AWS KMS. Modify the interface endpoint by disabling the private DNS name. Create a private hosted zone in each spoke AWS account with an alias record that points to the interface endpoint. Associate each private hosted zone with the shared services AWS account.
- Explanation: This option proposes creating a private hosted zone in each spoke account and associating it with the shared services account. However, this is not ideal for centralizing DNS management, as it requires managing separate hosted zones in each spoke account.
- Reasoning: The company’s requirement is to centralize t...
Author: Nathan · Last updated May 16, 2026
A development team is building a new web application in the AWS Cloud. The main company domain, example.com, is currently hosted in an Amazon Route 53 public hosted zone in one of the company's production AWS accounts.
The developers want to test the web application in the company's staging AWS account by using publicly resolvable subdomains under the example.com domain with the ability to create and delete DNS records as needed. Developers have full access to Route 53 hosted zones within the staging account, but the...
In this scenario, the goal is to allow the development team in the staging AWS account to create and manage DNS records under the `example.com` domain while maintaining the production account's control over the domain. The developers are prohibited from accessing the production account, and they only have full access to Route 53 hosted zones within the staging account.
Key Points to Consider:
- The developers need to create and manage records under the `example.com` domain.
- They do not have access to the production AWS account where the `example.com` public hosted zone resides.
- The `staging.example.com` subdomain should be handled in the staging AWS account, and developers should be able to add and remove records.
- Any changes in the staging account should not interfere with production resources or DNS management.
Option A: Create a public hosted zone for example.com in the staging account.
- Reasoning: This is not a valid solution. A public hosted zone for `example.com` should only exist in the production account where the actual `example.com` domain is managed. If the staging account had its own public hosted zone for `example.com`, it would conflict with the existing production domain, potentially causing DNS resolution issues.
- Conclusion: Not selected.
Option B: Create a staging.example.com NS record in the example.com domain. Populate the value with the name servers from the staging.example.com domain. Set the routing policy type to simple routing.
- Reasoning: This is a valid option. By adding an `NS` record for `staging.example.com` in the `example.com` public hosted zone (managed in the production account), the `staging.example.com` subdomain can be delegated to a new hosted zone in the staging account. This allows the developers to create and manage records under `staging.example.com` without affecting the `example.com` domain. The `NS` record in `example.com` will point to the name servers of the hosted zone created for `staging.example.com` in the staging account.
- Conclusion: Selected option.
...
Author: Emma · Last updated May 16, 2026
A company plans to deploy a two-tier web application to a new VPC in a single AWS Region. The company has configured the VPC with an internet gateway and four subnets. Two of the subnets are public and have default routes that point to the internet gateway. Two of the subnets are private and share a route table that does not have a default route.
The application will run on a set of Amazon EC2 instances that will be deployed behind an external Application Load Balancer. The EC2 instances must not be directly accessible from the internet. The application will use an Amazon S3 bucket in the ...
To determine the most cost-effective and efficient solution, let's analyze the given requirements and options:
Key Requirements:
- The EC2 instances must not be directly accessible from the internet.
- The EC2 instances should be able to perform S3 GET and PUT operations.
- Minimize data transfer costs.
Data Transfer Considerations:
- Data transfer from EC2 instances to S3 within the same AWS region is free if done via a VPC endpoint.
- Data transfer over the internet (via the public internet or through a NAT gateway) can incur additional costs, so we need to avoid routing S3 traffic over the public internet.
Option A: Deploy the EC2 instances in the public subnets. Create an S3 interface endpoint in the VPC. Modify the application configuration to use the S3 endpoint-specific DNS hostname.
- Reasoning: This option would place the EC2 instances in the public subnets, which is contrary to the requirement that the instances should not be directly accessible from the internet. Although the S3 interface endpoint would route S3 traffic directly to S3, the EC2 instances would still be publicly accessible, which is not desired.
- Conclusion: This option is not suitable because it violates the requirement of keeping the EC2 instances private.
Option B: Deploy the EC2 instances in the private subnets. Create a NAT gateway in the VPC. Create default routes in the private subnets to the NAT gateway. Connect to Amazon S3 by using the NAT gateway.
- Reasoning: This option suggests using a NAT gateway, which would allow EC2 instances in the private subnets to access the internet, including Amazon S3. However, this would incur data transfer costs because the traffic from the private subnets to S3 would go through the NAT gateway, resulting in additional data transfer costs for outgoing traffic.
- Conclusion: This option is not ideal because it increases costs due to the NAT gateway, which we want to minimize.
Option C: Deploy the EC2 instances in the private subnets. Create an S3 gateway endpoint in the VPC. Specify the route table of the private...
Author: Maya · Last updated May 16, 2026
A company has two AWS accounts one for Production and one for Connectivity. A network engineer needs to connect the Production account VPC to a transit gateway in the Connectivity account. The feature to auto accept shared attachments is not enabled on the transi...
To meet the requirements of connecting a VPC in the Production account to a transit gateway in the Connectivity account, while the feature to auto-accept shared attachments is not enabled, the network engineer needs to manually share the necessary resources and create attachments.
Key Requirements:
1. The Production account's VPC should be connected to the transit gateway in the Connectivity account.
2. The auto-accept shared attachments feature is not enabled, so manual acceptance of resource shares and attachments is required.
Key Components:
- AWS Resource Access Manager (RAM): Used to share resources (such as a transit gateway or VPC subnets) across AWS accounts.
- Attachment to Transit Gateway: This is required to connect the VPC to the transit gateway.
Option A: 1. In the Production account: Create a resource share in AWS Resource Access Manager for the transit gateway. Provide the Connectivity account ID. Enable the feature to allow external accounts. 2. In the Connectivity account: Accept the resource. 3. In the Connectivity account: Create an attachment to the VPC subnets. 4. In the Production account: Accept the attachment. Associate a route table with the attachment.
- Explanation: This approach first creates a resource share for the transit gateway in the Production account, which is not correct because the transit gateway belongs to the Connectivity account. In the next steps, the Connectivity account would accept the resource and create an attachment, which is also not the ideal flow.
- Conclusion: This is incorrect because the resource share and attachment creation must start in the Connectivity account, not the Production account.
Option B: 1. In the Production account: Create a resource share in AWS Resource Access Manager for the VPC subnets. Provide the Connectivity account ID. Enable the feature to allow external accounts. 2. In the Connectivity account: Accept the resource. 3. In the Production account: Create an attachment on the transit gateway to the VPC subnets. 4. In the Connectivity account: Accept the attachment. Associate a route table with the attachment.
- Explanation: This option starts by sharing the VPC subnets in the Production account, but the resource share should be for the transit gateway (in the Connectivity account), not the VPC subnets. Creating an attachment in the Production account also doesn’t align with how resources are typically shared and attached to a...
Author: Noah · Last updated May 16, 2026
A company is running multiple workloads on Amazon EC2 instances in public subnets. In a recent incident, an attacker exploited an application vulnerability on one of the EC2 instances to gain access to the instance. The company fixed the application and launched a replacement EC2 instance that contains the updated application.
The attacker used the compromised application to spread malware over the internet. The company became aware of the compromise through a notification f...
To determine the most effective solution with the least operational effort for identifying when an application deployed on an EC2 instance is spreading malware, let’s analyze each option in detail:
A) Use Amazon GuardDuty to analyze traffic patterns by inspecting DNS requests and VPC flow logs.
- Explanation: Amazon GuardDuty is a threat detection service that continuously monitors for malicious or unauthorized behavior by analyzing AWS CloudTrail event logs, VPC Flow Logs, and DNS logs. By inspecting traffic patterns such as DNS requests and VPC flow logs, GuardDuty can identify suspicious activities like botnet communication or unusual traffic patterns indicative of malware spreading.
- Why Selected: This option provides an automated, low-maintenance solution. GuardDuty is a fully managed service, which minimizes operational overhead. It can help identify malware spreading across instances by analyzing network traffic and DNS activity. It also provides timely alerts and requires little configuration.
- Why Other Options Are Rejected:
- Option B (AWS managed decoy systems): Using decoy systems is effective for detecting unauthorized access but involves more operational effort, such as managing decoys, updating signatures, and handling alerts.
- Option C (IDS appliance): While intrusion detection systems (IDS) are powerful for detecting suspicious activity, setting up and maintaining an IDS appliance involves operational overhead in terms of configuration, monitoring, and performance management.
- Option D (Amazon Inspector): Amazon Inspector primarily focuses on security assessments (e.g., vulnerabilities, compliance) rather than inspecting network traffic. I...
Author: Aria · Last updated May 16, 2026
A company deploys a new web application on Amazon EC2 instances. The application runs in private subnets in three Availability Zones behind an Application Load Balancer (ALB). Security auditors require encryption of all connections. The company uses Amazon Route 53 for DNS and uses AWS Certificate Manager (ACM) to automate SSL/TLS certificate provisioning. SSL/TLS connections are terminated on the ALB.
The company tests the application with a single EC2 instance and does not observe any problems. How...
To resolve the issue where users can log in but cannot use the application (with each new request restarting the login process), the problem is likely related to session stickiness. Stickiness ensures that requests from the same user are routed to the same EC2 instance, which is critical for maintaining session state during the login process. Without stickiness, each request may be routed to a different EC2 instance, resulting in the loss of session data and causing the login process to restart.
Let’s analyze each option to determine the best solution:
A) Modify the ALB listener configuration. Edit the rule that forwards traffic to the target group. Change the rule to enable group-level stickiness. Set the duration to the maximum application session length.
- Explanation: This option suggests enabling group-level stickiness on the Application Load Balancer (ALB). However, ALB stickiness operates based on a cookie, and configuring group-level stickiness is not a standard term in ALB. It seems the intent is to modify the listener rules to support session persistence, but the proper configuration would involve target group stickiness (not group-level). This could work but the terminology and approach are slightly misdirected.
- Why Rejected: Although the idea of enabling session persistence is correct, the way this is phrased is not the best practice for ensuring session continuity.
B) Replace the ALB with a Network Load Balancer. Create a TLS listener. Create a new target group with the protocol type set to TLS. Register the EC2 instances. Modify the target group configuration by enabling the stickiness attribute.
- Explanation: A Network Load Balancer (NLB) is designed for high performance and operates at the transport layer (Layer 4). It is not ideal for managing HTTP/HTTPS traffic with session stickiness because NLB does not offer built-in support for application-level cookies required for session stickiness. NLB is bet...
Author: Isabella1 · Last updated May 16, 2026
A company recently migrated its Amazon EC2 instances to VPC private subnets to satisfy a security compliance requirement. The EC2 instances now use a NAT gateway for internet access. After the migration, some long-running database queries from private EC2 instances to a publicly accessible third-party database no longer receive responses. The database query logs reveal that the queries successfully c...
The issue described involves long-running database queries from private EC2 instances, where the queries eventually complete, but the responses are never received by the client EC2 instances. This suggests that the connection between the client EC2 instance and the third-party database is timing out before the response is received. Let's analyze each option and determine the best solution:
A) Configure the NAT gateway timeout to allow connections for up to 600 seconds.
- Explanation: The NAT gateway is responsible for forwarding traffic from the private subnet EC2 instances to the internet. However, NAT gateways do not have direct control over TCP connection timeouts, and they typically use connection tracking with timeouts that might be set to a lower value, resulting in dropped connections. Configuring the timeout on the NAT gateway is not a typical solution because the NAT gateway timeout configuration is not directly adjustable in terms of TCP session duration.
- Why Rejected: NAT gateways typically manage traffic efficiently, but they don’t directly handle or allow modification of TCP session timeouts for the duration of connections in the way needed here. So, changing the NAT gateway timeout would likely not resolve the issue.
B) Enable enhanced networking on the client EC2 instances.
- Explanation: Enhanced networking uses the Elastic Network Adapter (ENA) or the Intel 82599 Virtual Function (VF) interface to improve the performance of EC2 instances, especially for high throughput and low latency. While this is beneficial for overall network performance, it does not directly address the issue of TCP connection timeouts for long-running queries.
- Why Rejected: While enhanced networking improves general performance, it doesn't solve the is...
Author: Oscar · Last updated May 16, 2026
A company uses AWS Direct Connect to connect its corporate network to multiple VPCs in the same AWS account and the same AWS Region. Each VPC uses its own private VIF and its own virtual LAN on the Direct Connect connection. The company has grown and will soon surpass the limit...
In this scenario, the company is running into the AWS service limit for VPCs and private virtual interfaces (VIFs) on Direct Connect and needs a scalable solution to connect multiple VPCs to their corporate network over Direct Connect. Let’s analyze each option in detail to determine the most appropriate solution:
A) Provision a new Direct Connect connection to handle the additional VPCs. Use the new connection to connect additional VPCs.
- Explanation: Adding a new Direct Connect connection can increase the number of VPCs that can be connected to the corporate network, but this approach doesn't solve the core issue. AWS imposes limits on the number of private VIFs per Direct Connect connection, so adding additional connections doesn’t scale efficiently as the number of VPCs grows. Each new Direct Connect connection will require manual setup and maintenance, leading to operational overhead.
- Why Rejected: This approach does not scale well because each new Direct Connect connection requires additional setup, and you would still hit service limits. It introduces unnecessary complexity as the number of VPCs increases.
B) Create virtual private gateways for each VPC that is over the service quota. Use AWS Site-to-Site VPN to connect the virtual private gateways to the corporate network.
- Explanation: This option involves using AWS Site-to-Site VPN in conjunction with virtual private gateways for each VPC that exceeds the limit. While VPN connections can provide a solution, they are typically less reliable and have higher latency and bandwidth limits compared to Direct Connect. This might not be the most efficient or scalable solution, especially for a growing number of VPCs.
- Why Rejected: VPN connections are generally less scalable and have higher overhead, and would not be the most efficient or high-performance solution when the company is expanding its infrastructure.
C) Create a Direct Connect gateway, and add virtual private gateway associations to the VPCs. Configu...
Author: Andrew · Last updated May 16, 2026
A network engineer is designing a hybrid architecture that uses a 1 Gbps AWS Direct Connect connection between the company's data center and two AWS Regions: us-east-1 and eu-west-1. The VPCs in us-east-1 are connected by a transit gateway and need to access several on-premises databases. According to company policy, only one VPC in eu-west-1 can be connected to one on-premises server. The on-pr...
In this scenario, the network engineer needs to design a hybrid architecture using AWS Direct Connect to connect a data center with two AWS Regions (us-east-1 and eu-west-1). The design must accommodate specific requirements, including using a transit gateway in us-east-1 and private VIF for the VPC in eu-west-1, and ensure proper routing from Direct Connect to the AWS Regions while maintaining the separation of traffic. Let’s break down each option and determine the best fit.
A) Create one hosted connection. Use a transit VIF to connect to the transit gateway in us-east-1. Use a private VIF to connect to the VPC in eu-west-1. Use one Direct Connect gateway for both VIFs to route from the Direct Connect locations to the corresponding AWS Region along the path that has the lowest latency.
- Explanation: In this option, a single hosted connection is used, which may not be ideal for the scalability and redundancy requirements. A single Direct Connect gateway is used for routing traffic to both us-east-1 and eu-west-1, which could work under normal conditions but might not provide the necessary flexibility and reliability for handling distinct routing between different regions.
- Why Rejected: A single Direct Connect gateway for both VIFs may not fully meet the requirement of isolating traffic between regions or properly segmenting traffic between the VPCs and on-premises databases. Also, a hosted connection might not provide the required performance and flexibility for the design.
B) Create one hosted connection. Use a transit VIF to connect to the transit gateway in us-east-1. Use a private VIF to connect to the VPC in eu-west-1. Use two Direct Connect gateways, one for each VIF, to route from the Direct Connect locations to the corresponding AWS Region along the path that has the lowest latency.
- Explanation: This option uses two Direct Connect gateways, one for each VIF. It isolates the traffic to ensure that the two AWS regions (us-east-1 and eu-west-1) use separate paths, which increases flexibility and scalability. However, using two Direct Connect gateways for a single hosted connection could complicate the routing and introduce unnecessary complexity.
- Why Rejected: Using two Direct Connect gateways with a hosted conne...
Author: Kai · Last updated May 16, 2026
A company has deployed an application in a VPC that uses a NAT gateway for outbound traffic to the internet. A network engineer notices a large quantity of suspicious network traffic that is traveling from the VPC over the internet to IP addresses that are included on a deny list. The network engineer must implement a solution to determine which AWS re...
To solve the problem of identifying the AWS resources generating suspicious traffic, we need a solution that minimizes cost and administrative overhead while providing the necessary visibility. Let's evaluate each option.
Option A: Launch an EC2 instance with Traffic Mirroring
- How it works: Traffic Mirroring can be set up to capture network traffic at the VPC level. The EC2 instance is the destination for the mirrored traffic, and the captured traffic is analyzed using open-source tools.
- Advantages:
- Provides detailed visibility into network traffic.
- Allows deep packet inspection.
- Disadvantages:
- Requires launching and managing an EC2 instance for capturing traffic.
- Can be costly due to traffic mirroring at the VPC level and the need for additional compute resources.
- Involves administrative overhead of setting up and maintaining tools on the EC2 instance.
- Not the most cost-effective for large-scale or long-term monitoring.
Why it’s not selected: Traffic mirroring is a more granular approach but can be resource-intensive and costly, especially for continuous monitoring. It also requires manual analysis and management.
Option B: Use VPC flow logs with a SIEM solution
- How it works: VPC flow logs capture metadata about network traffic, and these logs can be ingested by a Security Information and Event Management (SIEM) solution to run queries to identify suspicious traffic.
- Advantages:
- SIEM solutions are designed for security analysis and can correlate events across various sources.
- VPC flow logs provide visibility into traffic flow and can easily be linked to security threats.
- Disadvantages:
- SIEM solutions can be expensive, especially if running on an enterprise scale.
- Requires integration with the SIEM solution, which can add complexity and administrative overhead.
- It may not be the most cost-effective option for a smaller environment or for minimizing operational complexity.
Why it’s not selected: While powerful, SIEM solutions can be costly and require significant administrative effort to maintain and configure. This solution might be overkill for simply identifying sources of suspicious traffic.
Option C: Use VPC flow logs with CloudWatch Logs Insights
- How it works: VPC flow logs capture metadata about network traffic, and the logs are published...
Author: FlamePhoenix2025 · Last updated May 16, 2026
A company has its production VPC (VPC-A) in the eu-west-1 Region in Account 1. VPC-A is attached to a transit gateway (TGW-A) that is connected to an on-premises data center in Dublin, Ireland, by an AWS Direct Connect transit VIF that is configured for an AWS Direct Connect gateway. The company also has a staging VPC (VPC-B) that is attached to another transit gateway (TGW-B) in the eu-west-2 Region in A...
In this scenario, the company needs to establish connectivity between a staging VPC (VPC-B) in the eu-west-2 Region and an on-premises data center in Dublin, Ireland, leveraging a Direct Connect connection already established in the eu-west-1 Region (VPC-A).
Let's evaluate each option:
---
Option A: Configure inter-Region VPC peering between VPC-A and VPC-B. Add the required VPC peering routes. Add the VPC-B CIDR block in the allowed prefixes on the Direct Connect gateway association.
- How it works: Inter-region VPC peering connects VPC-A (in eu-west-1) to VPC-B (in eu-west-2), allowing traffic between the two VPCs. The VPC-B CIDR would need to be included in the allowed prefixes list on the Direct Connect gateway.
- Advantages:
- Allows communication between VPC-A and VPC-B.
- Relatively simple to configure if both VPCs are in different regions.
- Disadvantages:
- This approach only connects VPC-A and VPC-B. It doesn’t directly allow traffic from VPC-B to the on-premises data center. The Direct Connect gateway for VPC-A is configured for connectivity from VPC-A to the data center, not VPC-B.
Why it’s not selected: While inter-region VPC peering would connect VPC-A and VPC-B, it does not solve the primary issue of routing traffic from VPC-B to the on-premises data center in Dublin, Ireland. It lacks a direct connection between VPC-B and the data center.
---
Option B: Associate TGW-B with the Direct Connect gateway. Advertise the VPC-B CIDR block under the allowed prefixes.
- How it works: This option configures TGW-B to advertise VPC-B's CIDR block over Direct Connect. By associating TGW-B with the Direct Connect gateway, the on-premises data center can reach VPC-B.
- Advantages:
- Directly connects VPC-B to the on-premises data center using the existing Direct Connect connection, making the solution straightforward.
- Disadvantages:
- While this would work in some cases, VPC-B is in a different region, and Direct Connect gateway associations are region-specific. You cannot directly associate a VPC's transit gateway (TGW-B) in one region with a Direct Connect gateway in another region.
Why it’s not selected: This solution won’t work because Direct Connect gateway associations are regional. TGW-B in eu-west-2 cannot be associated directly with a Direct Connect gateway in eu-west-1.
---
Option C: Configure another transit VIF on the Direct Connect connection and associate TGW-B. Advertise the VPC-B CIDR block under the allowed prefixes.
- How it works: This solution creates an additional transit virtual interface (VIF) on the Direct Connect connection, which is associated with TGW-B (in the eu-west-2 region). The VPC-B CIDR block is advertised to the on-premises data center.
- Advantages:
- This allows VPC-B to be directly accessible from the on-premises data center via Direct Connect.
- It avoids the need for complex configurations such as inter-region peering.
- Disadvantages:
- It requires an additional transit VIF, which incurs ex...
Author: Sara · Last updated May 16, 2026
A company's network engineer is designing a hybrid DNS solution for an AWS Cloud workload. Individual teams want to manage their own DNS hostnames for their applications in their development environment. The solution must integrate the application-specific hostnames with the centrally managed DNS hostnames from the on-premises network and must provide bidirectional name resolu...
To meet the requirements of a hybrid DNS solution with bidirectional name resolution, integrating application-specific hostnames from the AWS environment with on-premises DNS, while minimizing management overhead, the network engineer must implement the following steps.
Let's break down each option:
---
Option A: Use an Amazon Route 53 Resolver inbound endpoint
- How it works: An inbound endpoint allows DNS queries from the on-premises network to be routed to AWS-hosted DNS services, such as Route 53 private hosted zones.
- Advantages:
- Enables on-premises DNS servers to resolve AWS resources and applications in private hosted zones.
- Supports bidirectional resolution by allowing DNS queries from on-premises to AWS.
- Disadvantages:
- The setup is straightforward and is required if you want the on-premises network to resolve AWS-hosted DNS names.
Why it’s selected: The inbound endpoint is necessary to allow on-premises DNS servers to resolve AWS-hosted DNS records, enabling bidirectional resolution between the on-premises network and the AWS Cloud environment.
---
Option B: Modify the DHCP options set by setting a custom DNS server value
- How it works: Modifying the DHCP options set to point to specific DNS servers ensures that instances in the VPC use the correct DNS resolver (e.g., the Route 53 Resolver for integration with the on-premises DNS).
- Advantages:
- Ensures that VPC resources use the proper DNS servers, like those configured for hybrid resolution.
- Disadvantages:
- It only addresses DNS resolution on the AWS side, not the integration of DNS from on-premises to AWS.
Why it’s rejected: While modifying the DHCP options is useful for controlling DNS resolution within the AWS VPC, it does not directly address the hybrid name resolution with the on-premises network. This option alone won't provide bidirectional resolution, which is crucial in the scenario.
---
Option C: Use an Amazon Route 53 Resolver outbound endpoint
- How it works: An outbound endpoint allows DNS queries from AWS to be forwarded to on-premises DNS servers. This supports bidirectional name resolution, enabling AWS-hosted resources to resolve names from on-premises DNS servers.
- Advantages:
- Facilitates name resolution from AWS to on-premises DNS resources, completing the bidirectional DNS integration.
- Works in conjunction with the inbound endpoint for full hybrid DNS resolution.
- Disadvantages:
- Requires setup of the outbound endpoint along with an inbound endpoint to achieve bidirectional resolution.
Why it’s selected: The outbound endpoint is required to ensure that AWS can resolve on-premises DNS records. This works together with the inbound endpoint to provide full bidirectional resolution between on-premises and AWS-hosted applications.
---
Option D: Create DNS proxy servers
- How i...
Author: Ava · Last updated May 16, 2026
A company hosts a web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The ALB is the origin in an Amazon CloudFront distribution. The company wants to implement a custom authentication system that will provide a token for its authenticated customers.
The web application must ensure that the GET/POST requests come from authenticated customers before it delivers the content. A network enginee...
To solve the problem of providing authenticated access to a web application hosted on EC2 instances behind an Application Load Balancer (ALB), we need a solution that ensures GET/POST requests come from authenticated customers. The goal is to implement the custom authentication system in an operationally efficient manner, ensuring the web application can identify authorized customers.
Let’s evaluate each option:
---
Option A: Use the ALB to inspect the authorized token inside the GET/POST request payload. Use an AWS Lambda function to insert a customized header to inform the web application of an authenticated customer request.
- How it works: This approach involves using the ALB to inspect the token in the request, then triggering a Lambda function to add a custom header that informs the web application of the authentication status.
- Advantages:
- Lambda is flexible and can perform token validation and header insertion.
- ALB and Lambda work well together and can be integrated with minimal overhead.
- Disadvantages:
- The ALB itself cannot natively inspect the request payload or body (it can inspect only headers and some metadata). This requires more complex integration and might involve additional steps (e.g., custom Lambda functions) to parse and validate the token inside the request body.
Why it’s rejected: The primary limitation here is that the ALB cannot directly inspect the request payload or body. While Lambda can be used, additional complexity is added by the need to handle the token inspection outside the ALB itself. This makes the solution less efficient.
---
Option B: Integrate AWS WAF with the ALB to inspect the authorized token inside the GET/POST request payload. Configure the ALB listener to insert a customized header to inform the web application of an authenticated customer request.
- How it works: AWS WAF can be used to inspect the request for a valid token, and if valid, the ALB can insert a custom header to indicate the authentication status.
- Advantages:
- AWS WAF can inspect both headers and payloads for custom rules, making it a powerful tool for security purposes.
- The ALB can be configured to pass headers to the web application.
- Disadvantages:
- AWS WAF has some limitations in processing payloads, especially for complex or large bodies, and might not be as efficient as a Lambda-based solution for more complex validation scenarios.
Why it’s rejected: AWS WAF is powerful, but it may not be as flexible for detailed or complex validation tasks, especially when inspecting GET/POST request payloads with custom authentication tokens. It would be a good solution for simple token validation but is less suitable for the fine-grained control and customization needed in this case.
---
Option C: Use an AWS Lambda@Edge funct...
Author: ShadowWolf101 · Last updated May 16, 2026
A company has created three VPCs: a production VPC, a nonproduction VPC, and a shared services VPC. The production VPC and the nonproduction VPC must each have communication with the shared services VPC. There must be no communication between the production VPC and the nonproduction VPC. A transit gateway is de...
To meet the requirements where:
- The production VPC and the nonproduction VPC must have communication with the shared services VPC.
- There must be no communication between the production VPC and the nonproduction VPC.
A transit gateway is used to facilitate communication between the VPCs, but we must carefully configure the route tables on the transit gateway to prevent unintended communication while allowing the required communication.
Key considerations:
- Propagation of routes: Propagating routes means that the VPC will be aware of the networks in other VPCs attached to the transit gateway. We need to carefully control which VPCs are allowed to communicate with each other.
- No communication between production and nonproduction VPCs: This is a critical constraint. The production VPC and nonproduction VPC should not see each other’s routes in the route table.
- Communication with shared services VPC: Both the production and nonproduction VPCs must be able to communicate with the shared services VPC.
Let's evaluate each option:
---
Option A: Configure a route table with the production and nonproduction VPC attachments associated with propagated routes for only the shared services VPC. Create an additional route table with only the shared services VPC attachment associated with propagated routes from the production and nonproduction VPCs.
- How it works:
- One route table is configured for production and nonproduction VPCs, with routes only propagated for the shared services VPC.
- A second route table is configured for the shared services VPC, propagating routes for production and nonproduction VPCs.
- Advantages:
- This ensures that the production and nonproduction VPCs can only reach the shared services VPC and cannot communicate with each other.
- Disadvantages:
- This configuration creates two route tables, but there is a possibility that it could inadvertently allow routing that doesn't strictly enforce separation between the production and nonproduction VPCs.
Why it’s rejected: The second route table could potentially propagate routes for both the production and nonproduction VPCs into the shared services VPC, making it possible for both VPCs to see each other. While the separation is attempted, it's not completely clear how this setup would fully enforce isolation.
---
Option B: Configure a route table with the production and nonproduction VPC attachments associated with propagated routes for each VPC. Create an additional route table with only the shared services VPC attachment associated with propagated routes from each VPC.
- How it works:
- A route table is created for both production and nonproduction VPCs, with propagated routes for each VPC, allowing communication.
- A second route table is created for the shared services VPC, propagating routes from both the production and nonproduction VPCs.
- Advantages:
- Allows VPCs to route traffic to the shared services VPC, but it would inadvertently allow the production VPC and nonproduction VPC to see each other’s routes, which violates the...
Author: Zara · Last updated May 16, 2026
A company is using an AWS Site-to-Site VPN connection from the company's on-premises data center to a virtual private gateway in the AWS Cloud Because of congestion, the company is experiencing availability and performance issues as traffic travels across the internet before the traffic reaches AWS. A network engineer must re...
Key Factors for Consideration:
- Availability and Performance Issues: The main challenge is congestion on the internet affecting the VPN's availability and performance.
- Minimum Administration Effort: The solution must minimize complexity and avoid a lot of manual intervention.
- VPN vs. Direct Connection: The solution must be appropriate for reducing congestion in an existing VPN connection without requiring major infrastructure changes unless absolutely necessary.
Evaluation of Options:
A) Edit the existing Site-to-Site VPN connection by enabling acceleration. Stop and start the VPN service on the customer gateway for the new setting to take effect.
- Pros: This solution is relatively simple. It involves minimal configuration changes by enabling acceleration, which is designed to improve performance.
- Cons: It does not solve the issue of congestion on the internet backbone that the VPN traffic is experiencing. Acceleration may help, but it may not be enough to overcome the inherent internet congestion causing the problem.
- Scenario: This option works well when the issue is related to latency or minor congestion but does not directly address significant performance degradation due to internet congestion.
- Rejection Reason: While acceleration can help optimize traffic, it doesn’t resolve the underlying problem of internet congestion which is significantly affecting performance.
B) Configure a transit gateway in the same AWS Region as the existing virtual private gateway. Create a new accelerated Site-to-Site VPN connection. Connect the new connection to the transit gateway by using a VPN attachment. Update the customer gateway device to use the new Site-to-Site VPN connection. Delete the existing Site-to-Site VPN connection.
- Pros: Using a transit gateway could optimize network traffic routing within AWS, and creating a new accelerated VPN connection could potentially enhance performance.
- Cons: This approach is complex and requires additional configuration, including transit gateway setup, VPN connection attachment, and deletion of the existing VPN connection. This introduces a higher level of administration effort than necessary for solving a congestion issue.
- Scenario: This solution might be useful in scenarios where there is a complex network topology and multiple VPCs need to be interconnected. However, for the case at hand, where the issue is related to congestion, this approach seems over-engineered.
- Rejection Reason: The complexity of adding a transit gateway may not be justified for simply improving VPN performance. This option involves more administrative overhead than necessary for resolving internet congestion issues.
C) Create a new...
Author: Joseph · Last updated May 16, 2026
An Australian ecommerce company hosts all of its services in the AWS Cloud and wants to expand its customer base to the United States (US). The company is targeting the western US for the expansion.
The company's existing AWS architecture consists of four AWS accounts with multiple VPCs deployed in the ap-southeast-2 Region. All VPCs are attached to a transit gateway in ap-southeast-2. There are dedicated VPCs for each application service. The company also has VPCs for centralized security features such as proxies, firewalls, and logging.
The company plans to duplicate the infrastructure from ap-southeas...
Key Factors for Consideration:
- Maximize Bandwidth: The solution must ensure high bandwidth to meet performance needs between regions.
- Minimize Latency: Reducing latency is critical to providing a seamless experience for customers in the US.
- Minimize Operational Overhead: The solution should be easy to manage and require minimal manual intervention or configuration changes.
- Scale and Flexibility: Since the company plans to duplicate its infrastructure and possibly expand further in the future, the solution should scale well.
- Security: As the company has centralized security features in the architecture, maintaining a secure and isolated connection between regions is important.
Evaluation of Options:
A) Create VPN attachments between the two transit gateways. Configure the VPN attachments to use BGP routing between the two transit gateways.
- Pros: VPN connections between transit gateways can provide secure connectivity across regions.
- Cons: VPN connections tend to have higher latency and lower bandwidth compared to other solutions like AWS Direct Connect or transit gateway peering. The VPN connection would also require managing BGP routing, adding complexity and operational overhead.
- Scenario: This solution might be useful for a low-cost, temporary setup but isn’t ideal for high bandwidth or low-latency connections between regions.
- Rejection Reason: While this option provides secure connectivity, it introduces potential performance limitations and more complexity for routing configuration, which doesn’t meet the requirement to minimize latency and operational overhead.
B) Peer the transit gateways in each Region. Configure routing between the two transit gateways for each Region's IP addresses.
- Pros: Transit gateway peering between regions offers high bandwidth and low-latency connectivity between VPCs in different regions. It is a fully managed solution with reduced operational overhead compared to VPN-based solutions.
- Cons: Peering may require careful routing setup, especially in complex environments with multiple VPCs. However, this is a standard practice for establishing inter-region connectivity in AWS.
- Scenario: This solution works well for high-performance inter-region communication, especially when multiple VPCs in each region need to communicate efficiently.
- Rejection Reason: There are no significant drawbacks to this option. ...
Author: Alexander · Last updated May 16, 2026
An IoT company sells hardware sensor modules that periodically send out temperature, humidity, pressure, and location data through the MQTT messaging protocol. The hardware sensor modules send this data to the company's on-premises MQTT brokers that run on Linux servers behind a load balancer. The hardware sensor modules have been hardcoded with public IP addresses to reach the brokers.
The company is growing and is acquiring customers across the world. The existing solution can no longer scale and is introducing additional latency because of the company's global presence. As a result, the company decides to migrate its entire infrastructure from on premises to the AWS Cloud. ...
Key Factors for Consideration:
- Global Presence and Latency: The company needs to minimize latency as they have a global customer base. The existing infrastructure introduces latency, so the new solution should ensure low-latency access for global customers.
- No Change to Hardware Sensor Modules: The hardware sensor modules are hardcoded with public IP addresses to connect to the brokers. This means the solution should not require changes to the existing modules.
- Scalability: The solution should be scalable to accommodate future growth as the company expands globally.
- Operational Overhead: The solution should minimize the need for reconfiguring or managing additional components that could increase operational complexity.
Evaluation of Options:
A) Place the EC2 instances behind a Network Load Balancer (NLB). Configure TCP listeners. Use Bring Your Own IP (BYOIP) from the on-premises network with the NLB.
- Pros:
- Using an NLB with TCP listeners is appropriate for MQTT, as it supports the protocol natively and can handle high-throughput, low-latency connections.
- Bring Your Own IP (BYOIP) allows you to keep the same public IP addresses, which is ideal since the hardware sensor modules are hardcoded with those IPs.
- Cons:
- This solution doesn’t address the global latency issue. Since NLB only distributes traffic to a single region, customers far from that region will experience higher latency.
- It does not provide global routing or acceleration.
- Scenario: This solution is good for migrating existing services, but it does not optimize global performance or minimize latency across regions.
B) Place the EC2 instances behind a Network Load Balancer (NLB). Configure TCP listeners. Create an AWS Global Accelerator accelerator in front of the NLB. Use Bring Your Own IP (BYOIP) from the on-premises network with Global Accelerator.
- Pros:
- The NLB with TCP listeners is well-suited for MQTT traffic.
- Global Accelerator improves global access by routing traffic to the optimal AWS region based on latency and health, which reduces the latency and improves performance for global customers.
- BYOIP allows the hardware sensor modules to continue using the existing public IP addresses.
- Cons:
- There m...
Author: Isabella · Last updated May 16, 2026
A company has deployed a web application on AWS. The web application uses an Application Load Balancer (ALB) across multiple Availability Zones. The targets of the ALB are AWS Lambda functions. The web application also uses Amazon CloudWatch metrics for monitoring.
Users report that parts of the web application are not loading properly. A network engineer needs to troublesho...
Key Factors for Consideration:
- Troubleshooting the ALB Errors: The goal is to determine which errors the ALB is receiving. Access logs can help identify issues like 4xx or 5xx responses from targets, which will provide insights into what is going wrong.
- Log Storage and Querying: Efficient ways to store and query ALB logs are crucial for troubleshooting. The solution should allow the network engineer to easily view and analyze the logs for error patterns.
- Operational Simplicity: The solution should be easy to set up and query without introducing unnecessary complexity, particularly as the company is troubleshooting an issue in production.
Evaluation of Options:
A) Send the logs to Amazon CloudWatch Logs. Review the ALB logs in CloudWatch Insights to determine which error messages the ALB is receiving.
- Pros:
- CloudWatch Logs and CloudWatch Logs Insights offer a powerful way to store and query logs in real-time. CloudWatch Insights allows for interactive querying, which can help the network engineer analyze logs and identify errors quickly.
- This solution provides a streamlined approach for troubleshooting within AWS and doesn’t require additional tools.
- Cons:
- While CloudWatch Logs Insights is powerful, querying large log volumes can become expensive if not managed properly. However, this is less of a concern for typical troubleshooting tasks.
- Scenario: This is the most efficient and integrated solution within AWS, leveraging CloudWatch's querying capabilities directly.
B) Configure the Amazon S3 bucket destination. Use Amazon Athena to determine which error messages the ALB is receiving.
- Pros:
- Storing ALB logs in Amazon S3 and querying with Amazon Athena can provide fast and scalable querying of large datasets.
- Athena is designed to query large volumes of data quickly, making it ideal for large-scale log analysis.
- Cons:
- This approach introduces more complexity because the network engineer would need to set up the S3 bucket as a destination for the ALB logs, and Athena would need to be configured to query those logs.
- The added setup could lead to more overhead compared to using CloudWatch Logs Insights.
- Scenario: This option is useful for handling very larg...
Author: Sam · Last updated May 16, 2026
A company is planning to use Amazon S3 to archive financial data. The data is currently stored in an on-premises data center. The company uses AWS Direct Connect with a Direct Connect gateway and a transit gateway to connect to the on-premises data center. The data cannot b...
Key Factors for Consideration:
- Encryption in Transit: The solution must ensure that data is encrypted during transfer from the on-premises data center to Amazon S3, as it cannot be transported over the public internet.
- Direct Connect and Transit Gateway: The company is using AWS Direct Connect with a Direct Connect gateway and a transit gateway, which indicates that a private, low-latency, and high-throughput connection is required.
- Data Access Restrictions: The data cannot be sent over the public internet, so any solution using internet-based connections (such as a public VIF or internet VPN) would not meet the requirements.
- S3 Access: The solution must involve Amazon S3 access, which should be done securely and efficiently, without relying on public internet access.
Evaluation of Options:
A) Create a Direct Connect public VIF. Set up an IPsec VPN connection over the public VIF to access Amazon S3. Use HTTPS for communication.
- Pros:
- IPsec VPN would encrypt the data in transit.
- HTTPS can be used for secure communication to Amazon S3.
- Cons:
- The Direct Connect public VIF is designed for accessing AWS public services over the public internet. It does not provide private access to Amazon S3, which is necessary in this case. Public VIFs are generally used for accessing services like AWS public APIs, not private resources like S3 over a private connection.
- This approach violates the requirement of not using the public internet for data transfer, even though the VPN provides encryption.
- Rejection Reason: The use of a public VIF does not align with the need for private data transfer, especially when dealing with sensitive data.
B) Create an IPsec VPN connection over the transit VIF. Create a VPC and attach the VPC to the transit gateway. In the VPC, provision an interface VPC endpoint for Amazon S3. Use HTTPS for communication.
- Pros:
- An IPsec VPN connection would encrypt the traffic, and using a VPC endpoint ensures that traffic to S3 stays within the AWS private network, avoiding the public internet.
- HTTPS ensures secure communication.
- Cons:
- The use of a transit VIF is not necessary when you already have a Direct Connect connection that can be used with a private VIF to achieve the same goal. The ...
