Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company is developing a new application that is deployed in multiple VPCs across multiple AWS Regions. The VPCs are connected through AWS Transit Gateway. The VPCs contain private subnets and public subnets.
All outbound internet traffic in the private subnets must be audited and logged. The company's network engineer plans to use AWS Network Firewall and must ensure that all traffic t...
To meet the requirements of auditing and logging all outbound internet traffic in the private subnets and ensuring that the Network Firewall logs all traffic for auditing and alerting, let's evaluate each option:
Key Requirements:
1. Audit and log outbound internet traffic: This involves capturing logs of all outbound traffic from private subnets.
2. Use of AWS Network Firewall: The logs should come from AWS Network Firewall, which should capture both alerts and traffic flow.
3. Logging for alerting and auditing: The logs must be integrated into a system that allows for efficient alerting, analysis, and auditing.
Option Analysis:
- Option A: Configure Network Firewall logging in Amazon CloudWatch to capture all alerts. Send the logs to a log group in Amazon CloudWatch Logs.
- Pros:
- This option enables logging alerts to CloudWatch, which is useful for generating metrics and creating CloudWatch alarms for alerting.
- Cons:
- This configuration will only capture alerts, not the full traffic flow data. Alerts are useful for detecting malicious or anomalous behavior, but they don't provide the granular information needed for full traffic auditing.
- Missing the actual traffic flow logs, which are needed for complete auditing of outbound traffic.
- Option B: Configure Network Firewall logging in Network Firewall to capture all alerts and flow logs.
- Pros:
- This option enables logging both alerts and traffic flow logs. Flow logs provide detailed data on network traffic, including source and destination IP addresses, ports, protocols, etc.
- Capturing both types of logs meets the requirement of auditing all traffic, as flow logs record all traffic passing through the Network Firewall.
- Cons:
- None significant; this is the most comprehensive solution.
- Best Fit: This option is the most suitable as it captures both alerts and traffic flow logs, providing a complete and ...
Author: Emma · Last updated May 16, 2026
A company has set up a NAT gateway in a single Availability Zone (AZ1) in a VPC (VPC1) to access the internet from Amazon EC2 workloads in the VPC. The EC2 workloads are running in private subnets in three Availability Zones (AZ1, AZ2, AZ3). The route table for each subnet is configured to use the NAT gateway to access the internet.
Recently during an outage, internet access stopped working for the EC2 workloads because of the NAT gateway's unavai...
Key Factors:
1. Redundancy: The current architecture has a single NAT gateway, which creates a single point of failure (SPOF). We need a solution that removes this SPOF and ensures internet access even if one NAT gateway becomes unavailable.
2. High Availability: The solution should provide built-in redundancy across multiple Availability Zones (AZs) to ensure that the EC2 workloads in all AZs have internet access.
3. Simple Configuration: The solution should be simple to configure, not requiring significant changes or complex routing setups.
Option Analysis:
- Option A:
- Set up two NAT gateways in different AZs (AZ2 and AZ3).
- Configure a single route table to route traffic to the virtual IP addresses of the two NAT gateways.
- Pros:
- This provides two NAT gateways in different AZs, which is good for redundancy.
- The virtual IP approach is useful for handling failover between the two NAT gateways.
- Cons:
- AWS does not allow routing to multiple NAT gateways through a single route table without more complex setup such as route precedence and failover logic.
- This would require a custom solution to handle failover, complicating the configuration.
- Option B:
- Set up two NAT gateways in AZ2 and AZ3, with each NAT gateway serving traffic for a specific set of private subnets.
- Configure separate route tables for each AZ’s private subnets, pointing to the NAT gateway in the same AZ.
- Pros:
- This provides redundancy across two AZs and ensures that private subnets in each AZ will use a NAT gateway in their respective AZs.
- Simple configuration of route tables per AZ, making the solution easy to manage.
- Cons:
- There is no failover between AZs. If the NAT gateway in AZ2 go...
Author: RadiantPhoenixX · Last updated May 16, 2026
A company has a total of 30 VPCs. Three AWS Regions each contain 10 VPCs. The company has attached the VPCs in each Region to a transit gateway in that Region. The company also has set up inter-Region peering connections between the transit gateways.
The company wants to use AWS Direct Connect to provide access from its on-premises location for only four VPCs across the three Regions. The company has...
To meet the requirements of providing access from on-premises to only four VPCs across three AWS Regions with the most cost-effective solution, let's evaluate each option:
Key Considerations:
1. On-premises access: The company wants to use AWS Direct Connect to provide access to only four VPCs.
2. Cost-effectiveness: We want to minimize the number of resources and connections to save on costs.
3. Inter-Region setup: There are inter-Region peering connections set up for the transit gateways, so some resources will already be in place to facilitate communication across Regions.
4. Direct Connect connections: The company has provisioned four Direct Connect connections at two locations, so we need to optimize the use of these connections.
Option Evaluation:
A) Create four virtual private gateways. Attach the virtual private gateways to the four VPCs.
- Rejection: Virtual Private Gateways (VGWs) are used to connect a VPC to an external network (like Direct Connect or VPN). Since the company is using a transit gateway architecture (already attached to VPCs in each Region), this would be redundant and less efficient. Creating separate VGWs for each VPC would increase cost and complexity, making it an undesirable option.
B) Create a Direct Connect gateway. Associate the four virtual private gateways with the Direct Connect gateway.
- Rejection: This option is not appropriate because the company is using transit gateways, not individual VGWs. A Direct Connect gateway is typically used when connecting multiple VGWs or a VPN, but in this case, the transit gateway is the key to interconnecting the VPCs. Associating it with VGWs would not be optimal.
C) Create four transit VIFs on each Direct Connect connection. Associate the transit VIFs with the Direct Connect gateway.
- Acceptance: A transit VIF (Virtual Interface) is the correct approach when connecting a Direct Connect connection to a Direct Connect gateway. Each Direct Connect connection can have m...
Author: Ahmed · Last updated May 16, 2026
A company needs to manage Amazon EC2 instances through command line interfaces for Linux hosts and Windows hosts. The EC2 instances are deployed in an environment in which there is no route to the internet. The company must implement role-based access control for management of the instances. The comp...
Let's break down the options to find the best solution that meets the requirements with the least maintenance overhead.
Key Requirements:
1. No route to the internet: The EC2 instances cannot be directly accessed over the public internet.
2. Role-based access control (RBAC): The solution should allow for fine-grained access control for management of EC2 instances.
3. Command line management: The solution should allow for command-line access to both Linux and Windows EC2 instances.
4. Standalone on-premises environment: The company has an existing on-premises environment that should integrate with the solution.
Option Evaluation:
A) Set up an AWS Direct Connect connection between the on-premises environment and the VPC where the instances are deployed. Configure routing, security groups, and ACLs. Connect to the instances by using the Direct Connect connection.
- Rejection: While Direct Connect would provide a dedicated network connection between the on-premises environment and AWS, it does not inherently provide role-based access control (RBAC) or an easy way to manage EC2 instances without additional configuration. It would also require managing routing, security groups, and ACLs, which could result in higher complexity and maintenance overhead compared to other solutions. It also doesn't meet the requirement for an internet-independent solution as Direct Connect could be cumbersome to set up in an environment where AWS management should be simpler.
B) Deploy and configure AWS Systems Manager Agent (SSM Agent) on each instance. Deploy VPC endpoints for Systems Manager Session Manager. Connect to the instances by using Session Manager.
- Acceptance: This is the most efficient and least maintenance-intensive option. AWS Systems Manager (SSM) enables management of EC2 instances without requiring internet access. By using Session Manager, the company can securely connect to both Linux and Windows EC2 instances for command-line management without the need for SSH or RDP acces...
Author: Olivia · Last updated May 16, 2026
A network engineer needs to improve the network security of an existing AWS environment by adding an AWS Network Firewall firewall to control internet-bound traffic. The AWS environment consists of five VPCs. Each VPC has an internet gateway, NAT gateways, public Application Load Balancers (ALBs), and Amazon EC2 instances. The EC2 instances are deployed in private subnets. The architecture is deployed across two Availability Zones.
The network engineer must be able to configure rules for the public IP addresses in the environment, regardless of the direction of traffic. The network engineer must ...
To improve the network security of the AWS environment by adding AWS Network Firewall and controlling internet-bound traffic, we need to carefully assess how to deploy the firewall in a way that ensures high availability, minimizes changes to the existing infrastructure, and allows for inspection and filtering of traffic in a scalable manner.
Key Requirements:
1. Control internet-bound traffic: We need to manage traffic going to/from the internet for the EC2 instances in private subnets and public-facing resources like ALBs.
2. High availability: The firewall solution should be resilient across multiple Availability Zones.
3. Minimal changes: The solution must not require significant changes to the existing production environment.
4. Inspect traffic based on public IPs: Rules should be configurable based on traffic direction, with a focus on internet-bound traffic.
Option Evaluation:
A) Create a centralized inspection VPC with subnets in two Availability Zones. Deploy Network Firewall in this inspection VPC with an endpoint in each Availability Zone.
- Acceptance: This is a commonly used approach when implementing AWS Network Firewall to centralize traffic inspection. A centralized inspection VPC in two Availability Zones ensures high availability by placing firewall endpoints in multiple AZs. This solution minimizes changes to the existing VPCs because the firewall is implemented in a dedicated VPC, and only routing changes are needed to redirect traffic through the firewall. This approach ensures that all internet-bound traffic can be inspected and controlled in a single location, providing centralized management and minimal disruption to the production environment.
- Why accepted: Meets high availability, minimal changes, and centralized traffic inspection requirements. This approach is best suited for handling traffic control from multiple VPCs without disrupting the existing architecture.
B) Configure new subnets in two Availability Zones in each VPC. Deploy Network Firewall in each VPC with an endpoint in each Availability Zone.
- Rejection: While this approach also ensures high availability by deploying firewall endpoints in each VPC and AZ, it introduces more complexity. Creating new subnets in every VPC and placing the firewall within each VPC would require more configuration and changes to the existing envir...
Author: Deepak · Last updated May 16, 2026
A company is planning to migrate an internal application to the AWS Cloud. The application will run on Amazon EC2 instances in one VPC. Users will access the application from the company's on-premises data center through AWS VPN or AWS Direct Connect. Users will use private domain names for the application endpoint from a domain name that is reserved explicitly for use in the AWS Cloud.
Each EC2 instance must have automatic failover to another EC2 in...
To meet the requirements of the scenario, let’s evaluate the solution based on the following needs:
Key Requirements:
1. Private DNS for the application: The application should use private domain names, and the DNS should not expose the application to the public internet.
2. Automatic failover: Each EC2 instance must have automatic failover to another EC2 instance in case of failure.
3. On-premises access: Users will access the application from the company's on-premises data center via AWS VPN or Direct Connect.
4. Same VPC and AWS account: The EC2 instances will be deployed in the same VPC and AWS account.
Option Analysis:
A) Assign public IP addresses to the EC2 instances. Create an Amazon Route 53 private hosted zone for the AWS reserved domain name. Associate the private hosted zone with the VPC. Create a Route 53 Resolver outbound endpoint. Configure conditional forwarding in the on-premises DNS resolvers to forward all DNS queries for the AWS domain to the outbound endpoint IP address for Route 53 Resolver. In the private hosted zone, configure primary and failover records that point to the public IP addresses of the EC2 instances. Create an Amazon CloudWatch metric and alarm to monitor the application's health. Set up a health check on the alarm for the primary application endpoint.
- Rejection: This approach requires assigning public IP addresses to the EC2 instances, which contradicts the requirement to not expose the application to the internet. Additionally, using a Route 53 Resolver outbound endpoint is more suitable when forwarding DNS queries to external DNS resolvers, which is not necessary for this scenario, where the DNS queries are being forwarded from the on-premises environment to AWS. Hence, this solution is not ideal.
B) Place the EC2 instances in private subnets. Create an Amazon Route 53 public hosted zone for the AWS reserved domain name. Associate the public hosted zone with the VPC. Create a Route 53 Resolver inbound endpoint. Configure conditional forwarding in the on-premises DNS resolvers to forward all DNS queries for the AWS domain to the inbound endpoint IP address for Route 53 Resolver. In the public hosted zone, configure primary and failover records that point to the IP addresses of the EC2 instances. Create an Amazon CloudWatch metric and alarm to monitor the application's health. Set up a health check on the alarm for the primary application endpoint.
- Rejection: This option suggests using a public hosted zone, which means the domain name would be publicly resolvable, which contradicts the ...
Author: Ahmed · Last updated May 16, 2026
A company uses Amazon Route 53 for its DNS needs. The company's security team wants to update the DNS infrastructure to provide the most recent security posture.
The security team has configured DNS Security Extensions (DNSSEC) for the domain. The security team wants a network engineer to explain who ...
Key Concepts for DNSSEC and Key Management:
- DNSSEC (DNS Security Extensions): DNSSEC is used to protect against certain types of attacks, such as cache poisoning, by ensuring that DNS responses are authentic and haven't been tampered with. It does so by using cryptographic signatures, which rely on two types of keys:
- Zone-Signing Key (ZSK): This key is used to sign DNS records in the zone (domain). The ZSK is rotated more frequently because it is used for signing individual records.
- Key-Signing Key (KSK): This key is used to sign the ZSK itself. The KSK is rotated less frequently but is crucial for the overall integrity of the DNSSEC process.
- Key Management: Key rotation is a necessary process to ensure security, and it is the responsibility of the zone owner (the company in this case) to manage this process. The KSK and ZSK must be rotated according to best practices to ensure that keys are not compromised.
Option Evaluation:
A) AWS rotates the zone-signing key (ZSK). The company rotates the key-signing key (KSK).
- Rejection: AWS does not automatically manage key rotation for DNSSEC keys in Route 53. The responsibility for rotating both the ZSK and the KSK falls to the customer (the company). This option is incorrect because it incorrectly assigns the responsibility of rotating t...
Author: FrozenWolf2022 · Last updated May 16, 2026
A company has agreed to collaborate with a partner for a research project. The company has multiple VPCs in the us-east-1 Region that use CIDR blocks within 10.10.0.0/16. The VPCs are connected by a transit gateway that is named TGW-C in us-east-1. TGW-C has an Autonomous System Number (ASN) configuration value of 64520.
The partner has multiple VPCs in us-east-1 that use CIDR blocks within 172.16.0.0/16. The VPCs are connected by a transit gateway that is named TGW-P in us-east-1. TGW-P has an ASN configuration va...
To solve this problem efficiently, we need to establish network connectivity between the company's VPCs (using CIDR blocks within 10.10.0.0/16) and the partner's VPCs (using CIDR blocks within 172.16.0.0/16) within the us-east-1 region using the transit gateway (TGW) configurations described. Let's break down the options to determine the one with the least complexity and changes while achieving the desired connectivity.
Option Analysis:
Option A: Create a new VPC in a new account. Deploy a router from AWS Marketplace. Share TGW-C and TGW-P with the new account by using AWS Resource Access Manager (AWS RAM). Associate TGW-C and TGW-P with the new VPC. Configure the router in the new VPC to route between TGW-C and TGW-P.
- Pros:
- This solution introduces an isolated VPC in a new account, creating a controlled environment.
- Cons:
- The need for a new VPC and external router introduces unnecessary complexity and costs.
- Deploying and managing the router from the AWS Marketplace can lead to operational overhead.
- This is a more complicated solution than required, as it involves additional AWS resources, routing configurations, and possible management of an external router.
Conclusion: Rejected. This option is unnecessarily complex for the given requirements.
Option B: Create an IPsec VPN connection between TGW-C and TGW-P. Configure the routing between the transit gateways to use the IPsec VPN connection.
- Pros:
- IPsec VPNs can provide secure connectivity.
- Cons:
- IPsec VPN connections are typically used for securing traffic between on-premises networks or hybrid-cloud scenarios. Setting this up between two AWS Transit Gateways could introduce unnecessary overhead, potentially making the routing between the transit gateways more complex.
- IPsec VPNs may introduce latency and performance considerations that are not ideal in this case.
Conclusion: Rejected. The need for an IPsec VPN connection between two transit gateways introduces unnecessary complexity and performance concerns. This is not the best solution for VPC-to-VPC connectivity.
Option C: Configure a cross-account transit gateway peering attachment between TGW-C and TGW-P. Configure the routing between the transit gateways to use the peering attachment.
- ...
Author: Alexander · Last updated May 16, 2026
A company has a public application. The application uses an Application Load Balancer (ALB) that has a target group of Amazon EC2 instances.
The company wants to protect the application from security issues in web requests. The traff...
The company has an application that requires end-to-end encryption and protection from web security issues. The solution needs to ensure that traffic is encrypted from the client to the load balancer and from the load balancer to the backend EC2 instances. Additionally, the company wants to implement security features like AWS WAF for web request protection.
Let's analyze each option to determine which one meets these criteria:
Option A: Configure a Network Load Balancer (NLB) that has a target group of the existing EC2 instances. Configure TLS connections to terminate on the EC2 instances that use a public certificate. Configure an AWS WAF web ACL. Associate the web ACL with the NLB.
- Pros:
- The Network Load Balancer (NLB) can handle high traffic and provide end-to-end encryption if TLS is terminated at the EC2 instances.
- AWS WAF can be associated with the NLB to protect against security issues like SQL injection, cross-site scripting (XSS), etc.
- Cons:
- The NLB does not support TLS termination natively. The TLS must be terminated at the EC2 instances, which could lead to performance issues, and managing certificates on EC2 instances manually could increase operational complexity.
- End-to-end encryption is achieved, but terminating TLS on EC2 instances is not the most efficient or scalable solution.
Conclusion: Rejected. While this option achieves end-to-end encryption, it involves manual TLS certificate management on EC2 instances and does not use the NLB's full capabilities.
Option B: Configure TLS connections to terminate at the ALB that uses a public certificate. Configure AWS Certificate Manager (ACM) certificates for the communication between the ALB and the EC2 instances. Configure an AWS WAF web ACL. Associate the web ACL with the ALB.
- Pros:
- Application Load Balancer (ALB) supports TLS termination directly, which means it can manage the SSL/TLS handshake and handle the encryption/decryption of traffic efficiently.
- The communication between the ALB and the backend EC2 instances can be encrypted using AWS ACM certificates, which simplifies certificate management.
- AWS WAF can be associated with the ALB to provide protection against common web attacks.
- This solution offers end-to-end encryption if TLS is terminated at the ALB and communication to EC2 instances is secured.
- Cons:
- This option requires the ALB to terminate the TLS connection, and the connection from the ALB to the EC2 instances would be encrypted with an ACM certificate, which is easy to manage.
Conclusion: Selected. This option provides a secure, scalable, and efficient appro...
Author: Joseph · Last updated May 16, 2026
A company has an application that hosts personally identifiable information (PII) of users. All connections to the application must be secured by HTTPS with TLS certificates that implement Elliptic Curve Cryptography (ECC).
The application uses stateful connections between the web tier and the end users. Multiple instances host the application. A ne...
To meet the requirements of securing connections with HTTPS, Elliptic Curve Cryptography (ECC) certificates, and offloading TLS connections to a load balancer, we need to carefully evaluate each option. The key requirements are:
1. Use of ECC certificates for encryption.
2. Offloading TLS connections to a load balancer, which means the load balancer should handle the encryption and decryption.
3. The application uses stateful connections, so session affinity (sticky sessions) is needed to maintain the state between the client and the server.
4. Health checks to monitor the health of the backend web hosts.
Option Analysis:
Option A: Provision a Network Load Balancer. Configure a TLS listener by specifying the use of an ECC SSL certificate that is uploaded to AWS Identity and Access Management (IAM). Turn on health checks to monitor the web hosts that connect to the end users.
- Pros:
- Network Load Balancer (NLB) can handle high-throughput traffic and supports TLS offloading.
- You can configure a TLS listener for encrypted connections.
- Health checks can be enabled for monitoring the backend servers.
- Cons:
- NLB does not support session affinity natively (sticky sessions). Since the application uses stateful connections, this is a significant drawback.
- SSL certificates stored in IAM is possible but not recommended because AWS Certificate Manager (ACM) is a more seamless and integrated solution for managing SSL/TLS certificates in AWS.
Conclusion: Rejected. While NLB supports TLS offloading and health checks, it does not support session affinity, which is crucial for stateful connections.
Option B: Provision an Application Load Balancer. Configure an HTTPS listener by specifying the use of an ECC SSL certificate that is uploaded to AWS Certificate Manager (ACM). Configure a default action to redirect to the URL for the application. Turn on health checks to monitor the web hosts that connect to the end users.
- Pros:
- Application Load Balancer (ALB) supports HTTPS listeners and ECC SSL certificates directly from AWS Certificate Manager (ACM), which makes certificate management easier and more secure.
- Health checks are available to monitor backend hosts.
- ALB also supports session affinity (sticky sessions) to maintain stateful connections between the end users and backend EC2 instances.
- Cons:
- The requirement to redirect to the URL could be unnecessary if the application doesn't require redirection, which adds a bit of complexity.
Conclusion: Sel...
Author: Alexander · Last updated May 16, 2026
A company hosts infrastructure services in multiple VPCs across multiple accounts in the us-west-2 Region. The VPC CIDR blocks do not overlap. The company wants to connect the VPCs to its data centers by using AWS Site-to-Site VPN tunnels.
The connections must be encrypted in transit. Additionally, the connection from each data center must route to the c...
The company needs to connect multiple VPCs across multiple accounts to its data centers using AWS Site-to-Site VPN tunnels while ensuring the connections are encrypted, highly available, and capable of automatic failover. Additionally, each connection must route to the closest AWS edge location. Let's evaluate each option based on the requirements:
Key Requirements:
1. Encryption in transit: The VPN connections must be secure.
2. Routing to the closest AWS edge location: This is important to ensure optimal performance and routing efficiency.
3. High availability with automatic failover: The connections need to support redundancy and automatic failover.
4. Multiple accounts and VPCs: The solution must handle multiple VPCs in different accounts.
Option A: Deploy a transit gateway. Share the transit gateway with each of the other accounts by using AWS Resource Access Manager (AWS RAM). Create VPC attachments to the transit gateway from each service account. Add routes to the on-premises subnet in each of the service VPC route tables by using the attachment as the gateway. Create Site-to-Site VPN tunnel attachments with dynamic routing to the transit gateway. Enable the acceleration feature for the Site-to-Site VPN connection. Configure the VPN tunnels on the on-premises equipment. Configure BGP peering.
- Pros:
- Transit Gateway (TGW) is designed for large-scale, multi-account, and multi-VPC architectures. It facilitates easy inter-VPC communication and simplifies routing management.
- BGP peering allows dynamic routing, which ensures that routes are automatically updated in case of changes, including failover scenarios.
- The VPN acceleration feature optimizes the VPN connections for performance.
- AWS Resource Access Manager (RAM) allows sharing the transit gateway across multiple accounts, which is essential in a multi-account environment.
- Dynamic routing allows automatic updates and failover, making the solution resilient to failures.
- Cons:
- While the solution is robust, it might be more complex and costly than simpler alternatives due to the use of a transit gateway, especially if the volume of traffic is low or the complexity of VPCs is minimal.
Conclusion: Selected. This solution is the most scalable and meets the requirements for high availability, failover, dynamic routing, and multi-account VPC connectivity.
Option B: Deploy VPN gateways to each account. Enable the acceleration feature for VPN gateways on each account. Add routes to the on-premises subnet in each of the service VPC route tables. Use the VPNs as the gateway. Configure the VPN tunnels on the on-premises equipment. Configure BGP peering.
- Pros:
- Using VPN gateways is a straightforward solution and can be simpler to set up than using a transit gateway.
- BGP peering ensures dynamic routing, which allows for automatic failover and route updates.
- The VPN acceleration feature provides improved performance for VPN connections.
- Cons:
- VPN gateways are more suitable for single VPCs or simpler architectures. They do not scale as easily when there are multiple VPCs ac...
Author: Amelia · Last updated May 16, 2026
A company has a transit gateway in AWS Account A. The company uses AWS Resource Access Manager (AWS RAM) to share the transit gateway so that users in other accounts can connect to multiple VPCs in the same AWS Region. AWS Account B contains a VPC (10.0.0.0/16) with subnet 10.0.0.0/24 in the us-west-2a Availability Zone and subnet 10.0.1.0/24 in the us-west-2b Availability Zone. Resources in these subnets can communicate with other VPCs.
A network engineer creates two new subnets: 10.0.2.0/24 in the us-west-2b Availability Zone and 10.0.3.0/24 in the us-west-2c Availability Zone. All the subnets share one route table. The default route 0.0.0.0/0 i...
To ensure that resources in subnet 10.0.3.0/24 can communicate with other VPCs, the key issue lies in routing, particularly how the new subnet is handled within the transit gateway's routing and propagation setup. Let’s analyze the options based on the provided situation:
Key Considerations:
1. Subnet Communication: Resources in subnet 10.0.2.0/24 can communicate with other VPCs, but resources in subnet 10.0.3.0/24 cannot. This suggests an issue in routing or propagation related to the new subnet.
2. Route Tables: The default route (0.0.0.0/0) points to the transit gateway, so the issue likely lies with subnet-specific routing or propagation.
3. Transit Gateway Attachment: The transit gateway needs to have proper routing to ensure that all subnets within the VPC can reach other VPCs via the shared transit gateway.
Option A: In Account B, add 10.0.2.0/24 and 10.0.3.0/24 as the destinations to the route table. Use the transit gateway as the target.
- Analysis: The route table in Account B's VPC already has the default route (0.0.0.0/0) pointing to the transit gateway. Adding specific routes for 10.0.2.0/24 and 10.0.3.0/24 would be redundant since the default route (0.0.0.0/0) should already forward traffic to the transit gateway. Moreover, subnet 10.0.2.0/24 is already working fine, suggesting the issue isn't with the destination routes but rather with the attachment or propagation.
- Conclusion: This option doesn’t address the root cause, which seems to be related to the attachment or propagation. Rejected.
Option B: In Account B, update the transit gateway attachment. Attach the new subnet ID that is associated with us-west-2c to Account B's VPC.
- Analysis: This option focuses on ensuring that the new subnet (10.0.3.0/24) in us-west-2c is included in the transit gateway attachment. Since subnets are associated with the transit gateway attachment, it’s possible that the new...
Author: IronLion88 · Last updated May 16, 2026
A company has started using AWS Cloud WAN with one edge location in the us-east-1 Region. The company has a production segment and a security segment in AWS Cloud WAN. The company also has a default core network policy.
The company has created a production VPC for the production workload. The company has created an outbound inspection VPC to inspect internet-bound traffic from the production VPC. The company has attached the production VPC to the production segment and has attached the outbound inspection VPC to the security segment. The company has also created an AWS Network Firewall firewall in the outbound inspection VPC to inspect internet-based traffic.
The company has updated a route table for the production VPC to send all internet-bound traffic to the AWS Cloud WAN core network. The company has updated a route table for the outboun...
Let's evaluate each option in detail based on the scenario provided:
1. Option A: Update the core network policy to configure segment sharing. Share the production segment with the security segment.
- Reasoning: Segment sharing typically allows multiple segments to share resources or traffic flows. However, in this scenario, the company has two separate segments: one for production and one for security. Sharing the segments may introduce complexity or unwanted behavior, as it would allow traffic from the production segment to be routed through the security segment without the proper inspection being enforced. This is not a recommended approach, as the security segment’s role is to inspect traffic, not to mix it with production traffic.
- Rejection: This could lead to a broader scope of traffic management, but it doesn't resolve the specific issue of internet-bound traffic routing and inspection.
2. Option B: Update the core network policy to create a static route for the security segment. Specify 0.0.0.0/0 as the destination CIDR block. Specify the outbound inspection VPC as an attachment.
- Reasoning: This option suggests creating a static route for the security segment directing all internet-bound traffic to the outbound inspection VPC. However, the production VPC is where the traffic originates, not the security segment. The security segment's role is to inspect the traffic and should not be the first destination for the internet-bound traffic. Therefore, the traffic must first route through the outbound inspection VPC and then to the internet, not the other way around.
- Rejection: This routing approach doesn't align with how the company wants traffic to flow (production -> inspection -> internet). Routing traffic from the security segment wouldn't solve the problem in the production VPC.
3. Option C: Update the core network policy to create a static route for the production segment. Specify 0.0.0.0/0 as the destination CIDR block. Specify the outbound inspection VPC as an attachment.
- Reasoning: This is a valid option. The production VPC must route its internet-bound traffic to the outbound inspection VPC for inspection before accessing the internet. This ensures that the outbound traffic from the production VPC goes through the outbound inspection VPC (with the AWS Network Firewall), where internet-bound traffic is filtere...
Author: ShadowWolf101 · Last updated May 16, 2026
A company has two business units (BUs). The company operates in the us-east-1 Region and the us-west-1 Region. The company plans to extend to more Regions in the future. Each BU has a VPC in each Region. Each Region has a transit gateway with the BU VPCs attached. The transit gateways in both Regions are peered.
The company will create several more BUs in the future and will need to isolate some of the BUs from the...
Let's evaluate each of the given options in terms of the company's requirements, focusing on scalability, operational efficiency, and traffic isolation.
Option A: Create a new transit gateway for each new BU in each Region. Peer the new transit gateways with the existing transit gateways. Update the route tables to control traffic between BUs.
- Reasoning: This option involves creating a new transit gateway for each BU in each Region. You would then need to peer these transit gateways across Regions, which could be complex and require extensive updates to route tables to manage traffic between BUs.
- Rejection: While this approach is possible, it can quickly become operationally complex as more BUs and Regions are added. Maintaining route tables for numerous transit gateways and managing the peering relationships between them can lead to higher administrative overhead. The solution does not provide the required traffic isolation at a scalable level for future expansion.
Option B: Create an AWS Cloud WAN core network with an edge location in both Regions. Configure a segment for each BU with VPC attachments to the new BU VPCs. Use segment actions to control traffic between segments.
- Reasoning: AWS Cloud WAN is designed for large, multi-region network management. By using Cloud WAN, you can configure segments for each BU, and use segment actions to control traffic between the BUs.
- Rejection: This approach is relatively straightforward, but the solution does not fully support traffic isolation between BUs. Segment actions alone may not provide the level of isolation required for the company's use case, especially if they need strict segmentation between BUs. More advanced isolation capabilities may be required.
Option C: Create an AWS Cloud WAN core network with an edge location in both Regions. Configure a segment for each BU with VPC attachments to ...
Author: FlamePhoenix2025 · Last updated May 16, 2026
A company has an AWS Site-to-Site VPN connection between AWS and its branch office. A network engineer is troubleshooting connectivity issues that the connection is experiencing. The VPN connection terminates at a transit gateway and is statically routed. In the transit gateway route table, there are several static route entries that target specific subnets at the branch office.
The network engineer determines that the root cause of the issues was the ...
Let's evaluate each option based on the requirements:
Option A: Determine a supernet for the branch office. In the transit gateway route table, add an aggregate route that targets the VPN attachment. Replace the specific subnet routes in the transit gateway route table with the new supernet route.
- Reasoning: In this option, the network engineer would create a supernet that encompasses the new expanded subnet range and then update the transit gateway route table to use this aggregate route. This eliminates the need to update specific subnet entries whenever there is an expansion of subnet ranges in the branch office.
- Acceptance: This is an ideal solution for future expansions. It reduces the administrative overhead significantly because you only need to update one route (the supernet) instead of managing multiple subnet-specific routes in the future. Aggregate routing minimizes the number of route entries and provides a more scalable solution to handle subnet changes.
- Key Factor: This approach is simple and reduces future administrative effort as subnets expand, as you only need to adjust the aggregate route rather than each individual subnet entry.
Option B: Create an AWS Direct Connect gateway and a transit VIF. Associate the Direct Connect gateway with the transit gateway. Create a propagation for the Direct Connect attachment to the transit gateway route table.
- Reasoning: This option introduces AWS Direct Connect, which is a private connection between your on-premises network and AWS. It is a solid choice for high-bandwidth, low-latency connections, but it is not directly related to the issue of handling the expansion of branch office subnets and the administrative overhead of managing VPN routes.
- Rejection: The problem here is specifically about the VPN connection and its route table management, which is unrelated to Direct Connect. Introducing Direct Connect adds unnecessary complexity when the VPN connection is the primary concern, especially since Direct Connect is not required to solve the problem at hand.
Option C: Create a dynamically routed VPN connection on the transit gateway. Connect the dynamically routed VPN connection to the branch office. Create a propagation for the VPN attachment to the transit gateway route table....
Author: Emma · Last updated May 16, 2026
An education agency is preparing for its annual competition between schools. In the competition, students at schools from around the country solve math problems, complete puzzles, and write essays.
The IP addressing plan of all the schools is well-known and is administered centrally. The competition is hosted in the AWS Cloud and is not publicly available. All competition traffic must be encrypted in transit. Only authorized endpoints can access the competition. All the schools have firewall policies that block ICMP traffic.
A network engineer builds a solution in which all the schools access the competition through AWS Site-to-Site VPN connections. The network engine...
Let's break down each option and determine the most effective and cost-efficient solutions.
Option A: Monitor the state of the VPN tunnels by using Amazon CloudWatch. Create a CloudWatch alarm that uses Amazon Simple Notification Service (Amazon SNS) to notify people at the affected school if the tunnels are down.
- Reasoning: AWS Site-to-Site VPN automatically publishes tunnel state changes (up/down) to CloudWatch metrics. By creating a CloudWatch alarm based on these metrics, the network engineer can easily detect when a VPN tunnel goes down and trigger an SNS notification to the affected school. This approach uses AWS-native tools and directly leverages the existing VPN infrastructure, making it cost-effective and easy to implement.
- Acceptance: This solution is efficient because it uses existing infrastructure and native AWS services for monitoring and notifications. No additional infrastructure (e.g., Lambda functions) is needed, keeping it cost-effective and scalable.
- Selected for Cost-Effectiveness: This option is a straightforward, low-cost solution that meets the requirements.
Option B: Create a scheduled AWS Lambda function that pings each school's on-premises customer gateway device. Configure the Lambda function to send an Amazon Simple Notification Service (Amazon SNS) notification to people at the affected school if the ping fails.
- Reasoning: Pinging each on-premises device via a Lambda function may not be practical or efficient because:
- The schools block ICMP traffic, so the pings would fail.
- This solution could be more expensive due to the need for Lambda invocations and external network traffic to the on-premises devices.
- Rejection: This option won't work because ICMP is blocked, and it adds unnecessary complexity and cost by relying on external traffic and custom Lambda functions.
Option C: Create a scheduled AWS Lambda function that uses the VPC Reachability Analyzer API to verify the connectivity. Configure the Lambda function to send an Amazon Simple Notification Service (Amazon SNS) notification to people at the affected school if failure occurs.
- Reasoning: VPC Reachability Analyzer is typically used for analyzing AWS network connectivity, not external connections like VPNs. It won't be directl...
Author: Ahmed97 · Last updated May 16, 2026
A company securely connects resources that are in its VPC to a software as a service (SaaS) solution from a SaaS provider. The SaaS solution is hosted in the AWS Cloud and is powered by AWS PrivateLink. The company uses a PrivateLink endpoint to access the SaaS solution behind the SaaS provider's Network Load Balancer (NLB).
The company recently added a new Availability Zone and new subnets...
Let's break down each option and analyze the situation:
Option A: The CIDR block of the new subnets conflicts with the SaaS provider's CIDR block.
- Reasoning: PrivateLink endpoints allow secure, private access to SaaS solutions hosted by AWS. If there were a CIDR block conflict between the VPC subnets and the SaaS provider's CIDR block, it could cause issues when creating a VPC endpoint. However, AWS PrivateLink generally avoids such conflicts by using a private IP address space that should not overlap with your VPC.
- Rejection: This scenario is unlikely. AWS PrivateLink manages the IP ranges for communication between the VPC and the SaaS service to avoid conflicts. CIDR conflicts are not a common reason for the failure to deploy an endpoint.
Option B: The enableDnsHostnames attribute and enableDnsSupport attribute were not configured on the new subnets in the new Availability Zone.
- Reasoning: The enableDnsHostnames and enableDnsSupport attributes must be enabled in a VPC to allow DNS resolution for resources in the VPC. If these attributes were not configured correctly, it could prevent the resolution of the DNS names associated with the PrivateLink endpoint. However, this would typically affect all DNS-related functionality and not specifically the deployment of PrivateLink endpoints.
- Rejection: While this might cause DNS resolution issues, it does not directly explain the problem with deploying the new interface endpoint in a different Availability Zone. This issue is more related to DNS resolution than to the core reason for the failure in creating the endpoint.
Option C: The SaaS provider does not offer the solution in the new Availability Zone a...
Author: NightmareDragon2025 · Last updated May 16, 2026
A company wants to use an AWS Network Firewall firewall to secure its workloads in the cloud through network traffic inspection. The company must record complete metadata information, such as source/destination IP addresses and protocol type. The company must also record all network traffic flows and any DROP or ALERT actions that the firewall takes for traffic that the firewall processes. The Network Firewall endpoints are placed in the correct subnets...
To meet the requirements outlined, the network engineer needs to ensure that all relevant metadata, including source/destination IP addresses, protocol type, and traffic flows (including any DROP or ALERT actions), are captured by AWS Network Firewall. The goal is to log network traffic flows and the actions taken by the firewall (such as drop or alert), and to ensure that all relevant information is recorded for security and monitoring purposes.
Analyzing Each Option:
Option A:
- Create a firewall policy to ensure that traffic is processed by stateless or stateful rules according to needs. Select Amazon CloudWatch Logs as the destination for the flow logs.
- This option involves setting up flow logs with CloudWatch Logs, but it doesn’t explicitly address the need to capture both flow logs and alert logs. Also, it lacks detail on logging specific firewall actions (DROP, ALERT). CloudWatch is useful for monitoring but is not sufficient alone to meet the complete logging requirements, especially when distinguishing between stateful or stateless logs.
Option B:
- Create a firewall policy to ensure that traffic is processed by stateless or stateful rules according to needs. Configure Network Firewall logging for alert logs and flow logs. Select a destination for logs separately for stateful and stateless engines.
- This option is a better choice because it explicitly mentions configuring both alert logs and flow logs for Network Firewall. It allows for separate destinations for stateful and stateless logs, which gives flexibility for precise monitoring. This is more comprehensive in fulfilling the requirements, as it directly covers both flow logs and alerts.
Option C:
- Create a firewall policy to ensure that a stateful engine processes all the traffic. Configure Network Firewall logging for alert logs and flow logs. Select a destination for alert logs and flow logs.
- This option locks the firewall policy to a stateful engine, which might be overly restrictive if the workload requires both stateful and stateless traffic processing. While it does address logging the required flow and alert logs, the requirement for flexible rule sets (stateless or stateful processing) might be better suited by Option B, which allows for more flexibility.
Option D:
- Create a firewall policy to ensure that a stateful engine processes all the traffic. Configure VPC flow...
Author: Sophia Clark · Last updated May 16, 2026
A company is building a new workload on AWS that uses an Application Load Balancer (ALB). The company has configured a new ALB target group that uses slow start mode. A team begins registering Amazon EC2 instances as targets in the new target group. During testing, the t...
To determine why the targets did not enter slow start mode, we need to review how AWS Application Load Balancer (ALB) slow start mode works and the possible causes of this issue.
Understanding Slow Start Mode:
Slow start mode in ALB is designed to allow new targets to gradually increase the amount of traffic they handle as they warm up, preventing them from being overwhelmed by requests when they are first registered. However, this feature only works under specific conditions.
Analyzing the Options:
Option A: The ALB configuration uses the round robin routing algorithm for traffic.
- The round robin algorithm is the default routing method for ALB, and it works well with slow start mode. The round robin algorithm does not prevent targets from entering slow start mode, as it simply distributes traffic across healthy targets in a cyclic manner.
- Reason for rejection: The routing algorithm is not the cause of the problem. This option is irrelevant because round robin will not prevent slow start mode.
Option B: The target group did not contain at least one healthy target configured in slow start mode.
- Slow start mode only applies to healthy targets. If no healthy targets exist in the target group or if the targets are not properly registered, slow start mode will not be triggered. Also, if a target is not in a healthy state, it cannot enter slow start mode.
- Reason for selection: This is the correct option because slow start mode requires at lea...
Author: Andrew · Last updated May 16, 2026
A network engineer is using AWS Direct Connect connections and MACsec to encrypt data from a corporate data center to the Direct Connect location. The network engineer learns that the MACsec secret key might have been compromised. The network engineer n...
In this scenario, the network engineer needs to update the MACsec secret key for the AWS Direct Connect connection because the current key might have been compromised. The solution needs to involve creating or modifying a key and updating the connection with the correct security credentials.
Analyzing the Options:
Option A: Create a new MACsec secret key that uses an AWS Key Management Service (AWS KMS) AWS managed key. Associate the new pre-shared key, Connection Key Name (CKN), and Connectivity Association Key (CAK) with the connection.
- AWS KMS AWS managed keys are automatically managed and rotated by AWS, and they are not ideal for highly specific use cases where the user needs full control over the key's lifecycle (like in this case, where the key needs to be updated manually due to a compromise).
- Reason for rejection: While AWS KMS AWS managed keys are convenient, they do not provide the level of control needed for this situation, especially because the network engineer needs to manually manage the key after compromise.
Option B: Create a new MACsec secret key that uses an AWS Key Management Service (AWS KMS) customer managed key. Associate the new pre-shared key, Connection Key Name (CKN), and Connectivity Association Key (CAK) with the connection.
- AWS KMS customer managed keys allow the network engineer to have full control over key creation, rotation, and management. This option enables the creation of a new, uncompromised key and manually managing it. This is the correct solution because the engineer can create and associate a new key while maintaining control over its lifecycle.
- Reason for selection: This is the most appropriate solution because it provides control over the key management and allows for the creation of a new key to replace the compromised one.
...
Author: MoonlitPantherX · Last updated May 16, 2026
A network engineer configures a second AWS Direct Connect connection to an existing network. The network engineer runs a test in the AWS Direct Connect Resiliency Toolkit on the connections. The test produces a failure. During the failover event, the network engineer observes a 90-...
To reduce the failover time between AWS Direct Connect connections, the network engineer needs to address how quickly the routing protocols can detect failures and switch traffic to the backup connection. Let's analyze each option and evaluate which one addresses the core issue.
Key Considerations for Fast Failover:
- BGP Hello and Hold-down Timers: BGP relies on timers for session establishment and failover detection. The Hello timer determines how often BGP peers send hello packets, while the Hold-down timer specifies how long to wait before considering a peer to be down after missing a certain number of Hello packets.
- Bidirectional Forwarding Detection (BFD): BFD is a protocol that provides fast failure detection between network devices. It allows for quicker detection of link failures and can trigger faster failover for protocols like BGP.
- VPN for Failover: Adding a VPN connection could provide an additional route for failover, but it introduces complexity and doesn't necessarily solve the BGP session failover time directly.
Analyzing Each Option:
Option A: Decrease the BGP hello timer to 5 seconds.
- Decreasing the BGP Hello timer could improve the speed of detecting BGP peer failures. However, while the Hello timer controls the frequency of hello messages, it is not the most effective method for reducing the actual failover time, since BGP relies on the Hold-down timer to determine when to declare a peer down.
- Reason for rejection: Reducing the Hello timer alone is insufficient to significantly reduce the failover time. It is the Hold-down timer that primarily governs the failover timing.
Option B: Add a VPN connection to the connectivity solution. Implement fast failover.
- Adding a VPN connection can provide an additional route, but the real bottleneck in this scenario is the BGP...
Author: Ahmed · Last updated May 16, 2026
A company is building an API-based application on AWS and is using a microservices architecture for the design. The company is using a multi-account AWS environment that includes a separate AWS account for each microservice development team. Each team hosts its microservice in its own VPC that contains Amazon EC2 instances behind a Network Load Balancer (NLB).
A network engineer needs to use Amazon API Gateway in a shared services account to create an HTTP API to expose these microservices to external applications. The network engineer must ensure that access to the microservices can occur only over a private network. Additionally, the company must ...
To determine the most secure and appropriate solution, we need to consider several factors: privacy, network isolation, control over which internal entities can connect, and scalability for future microservices integration. The goal is to ensure that external applications can securely connect to the microservices while maintaining private network access and controlling which internal entities have access.
Let's evaluate each option based on these requirements:
Key Requirements:
1. Private Network Access: The microservices should only be accessible via a private network, meaning external access should be controlled.
2. Access Control: Only specific entities from the internal network should have access to the microservices.
3. Future Scalability: The solution should allow for the easy integration of new microservices in the future.
4. Security: The solution must minimize public exposure and maintain secure communication between services.
Analyzing Each Option:
Option A: Create an Application Load Balancer (ALB) in a VPC in the shared services account. Configure the integration to the API Gateway API by using a VPC link. Associate the VPC link with the ALB. Create a VPC endpoint service in each microservice account. Create an AWS PrivateLink endpoint for those services in the shared services account. Add the elastic network interface IP addresses of the VPC endpoint as targets for the target group of the ALB.
- This option involves using an Application Load Balancer (ALB) in the shared services account to aggregate the microservices. By using VPC endpoint services (AWS PrivateLink), each microservice can be securely accessed over a private network, with fine-grained access control.
- Reason for selection: This is a very secure and scalable solution because it uses PrivateLink to establish private connections between VPCs. This solution ensures that traffic to the microservices does not traverse the public internet. The VPC link integrates the ALB with API Gateway, allowing the application to connect to the microservices securely. It also supports future expansion since new microservices can easily be added by creating new VPC endpoint services and PrivateLink endpoints.
- Future Scalability: Adding new microservices is straightforward since each microservice just needs to expose a PrivateLink endpoint.
Option B: Create an Application Load Balancer (ALB) in a VPC in the shared services account. Configure the integration to the API Gateway API by using a VPC link. Associate the VPC link with the ALB. Connect all the VPCs to each other by using a central transit gateway. Add the IP addresses of the NLB as IP-based targets in the ALB target group.
- This option connects the VPCs via a transit gateway and uses an ALB to route traffic. The NLB (Network Load Balancer) from each microservice account is used as an IP-based target for the ALB.
- Reason for rejection: The problem with this option is that connecting multiple VPCs via a central transit gateway and adding the NLBs as IP-based targets for the ALB exposes the NLBs publicly. While a transi...
Author: CrystalWolfX · Last updated May 16, 2026
A company's VPC has Amazon EC2 instances that are communicating with AWS services over the public internet. The company needs to change the connectivity so that the communication does not occur over the public internet.
The company deploys AWS PrivateLink endpoints in the VPC. After the deployment of the PrivateLink endpoints, the EC2 instances can no longer communicate...
To restore communication with the AWS services after deploying PrivateLink endpoints, we need to ensure that traffic from EC2 instances is directed correctly to the PrivateLink endpoints and DNS resolution is properly handled. Let’s go through the options and evaluate them:
1. A) In the VPC route table, add a route that has the PrivateLink endpoints as the destination.
- Reasoning: PrivateLink endpoints require routes in the VPC route table to direct traffic to the endpoint. If there is no route for traffic to go to the PrivateLink endpoint, communication will fail. This step is crucial for routing the traffic to the correct endpoint.
- Conclusion: This option is necessary for ensuring the traffic is properly routed through the PrivateLink endpoints.
2. B) Ensure that the enableDnsSupport attribute is set to True for the VPC. Ensure that each VPC endpoint has DNS support enabled.
- Reasoning: DNS resolution is critical for private communication in AWS, especially when using PrivateLink. If DNS support is not enabled for the VPC or the endpoint, the EC2 instances won’t be able to resolve the endpoint’s DNS names to the correct IP addresses. This is crucial for communication.
- Conclusion: This option ensures that the EC2 instances can resolve the DNS names for the PrivateLink endpoints, which is necessary for successful communication.
3. C) Ensure that the VPC endpoint policy allows communication.
- Reasoni...
Author: Jack · Last updated May 16, 2026
An international company wants to implement a multi-site hybrid infrastructure. The company wants to deploy its cloud computing resources on AWS in the us-east-1 Region and in the eu-west-2 Region, and in on-premises data centers in the United States (US) and in the United Kingdom (UK). The data centers are connected to each other by a private WAN connection. IP routing information is exchanged dynamically through BGP. The company wants to have two AWS Direct Connect connections, one each in the US and the UK.
The company expects to have 15 VPCs in each Region with CIDR blocks that do not overlap with each other or with CIDR blocks of the on-premises environment. The VPC CIDR blocks are planned so that the prefix aggregation can be performed both on a Regional level and across the entire AWS environment. The company will deploy a transit gateway in each Region to connect the VPCs. A network engineer plans to use a Direct Connect gateway in each Region. A transit VIF will attach the Direct Connect gateway in each Region to the transit gateway in that Region. The transit gateways will be peered with each other.
The network engineer wants to ensure that traffic follows the shortest geographical path from source to destination. Traffic between the on-premises data centers and AWS must travel across a local Direct Connect connection. T...
In this scenario, the company wants to implement a highly available and resilient hybrid infrastructure with AWS Direct Connect. The goal is to ensure traffic follows the shortest geographical path while maintaining flexibility in rerouting traffic during failures. Let’s evaluate each option carefully and see which one meets the requirements.
Option A: Advertise only the aggregate route for the company's entire AWS environment.
- Reasoning: This approach would advertise a single aggregated route for the entire AWS environment. While aggregation reduces the number of routes exchanged, it does not provide enough granularity for routing traffic to specific VPCs or regions, which is required for optimizing path selection based on geography (e.g., traffic from the US to the US Direct Connect connection). This would not fully meet the need to direct traffic to the local Direct Connect connection based on its availability.
- Conclusion: This option is not suitable because it lacks granularity in routing specific VPC traffic, making it less effective in optimizing traffic paths.
Option B: Advertise VPC-specific CIDR prefixes from only the local Region. Additionally, advertise the aggregate route for the company's entire AWS environment.
- Reasoning: This option allows each Direct Connect connection to advertise the CIDR blocks for VPCs only within the local region, along with the aggregate route for the entire environment. This offers more granularity than Option A, allowing traffic to be routed specifically to the local Direct Connect connection in case of a failure. It also ensures that if a regional Direct Connect connection fails, traffic can be routed over the private WAN connection to the other region's Direct Connect connection.
- Conclusion: This is a good approach as it allows for more granular routing based on regional availability and ensures that traffic uses the local Direct Connect connection when it is available.
Option C: Advertise all the specific VPC CIDR blocks ...
Author: Ahmed97 · Last updated May 16, 2026
A company's AWS infrastructure is spread across more than 50 accounts and across five AWS Regions. The company needs to manage its security posture with simplified administration and maintenance for all the AWS accounts. The company wants to use AWS Firewall Manager to manage the firewall rules and requirements.
The company creates an organizati...
To meet the company's requirements of managing its security posture with simplified administration and maintenance using AWS Firewall Manager across multiple accounts and regions, let's evaluate the options one by one and select the correct steps.
Option A: Configure only the Firewall Manager administrator account to join the organization.
- Reasoning: AWS Firewall Manager requires an organization with all features enabled to be able to manage security configurations across multiple accounts. However, it’s not just the administrator account that needs to be part of the organization. All accounts that will be subject to the firewall management must be part of the AWS Organization to enforce policies effectively.
- Conclusion: This option is incorrect because it limits the scope of the security management to only one account, which doesn't align with the requirement of managing multiple accounts.
Option B: Configure all the accounts to join the organization.
- Reasoning: To use AWS Firewall Manager to manage the security posture across multiple accounts, all the AWS accounts must be part of the AWS Organization. This is a fundamental requirement for centralized security management with Firewall Manager, as it requires all the accounts that will be managed to be in the same organization.
- Conclusion: This option is correct, as it ensures that all the accounts in the organization are part of the security management process.
Option C: Set an account as the Firewall Manager administrator account.
- Reasoning: AWS Firewall Manager requires an administrator account to manage firewall policies across multiple accounts. The Firewall Manager administrator account is the one responsible for defining and enforcing the security policies across the organization’s accounts. This account will also be used to configure the centralized management of AWS Firewall Manager.
- Conclusion: This option is correct because the company needs to designate one account as the administrator to control firewall configurations and policies for the entire organization.
Option D: Set an account as the Firewall Manager child account.
- Reasoning: In AWS Firewall Manager, a "child account" refers to the accounts that will have the firewall policies applied to them. These are the...
Author: David · Last updated May 16, 2026
A company is using an Amazon CloudFront distribution that is configured with an Application Load Balancer (ALB) as an origin. A network engineer needs to implement a solution that requires all inbound traffic to the ALB to come from CloudFront. The network engineer must implement the solution at the ne...
To meet the requirement of ensuring that all inbound traffic to the Application Load Balancer (ALB) comes from CloudFront, the network engineer wants to implement a solution at the network layer (as opposed to an application layer solution). Let's analyze the options based on operational efficiency, simplicity, and correctness:
Option A: Add an inbound rule to the ALB's security group to allow the AWS managed prefix list for CloudFront.
- Reasoning: The security group is associated with the ALB, and it is a network-layer control that can be used to restrict incoming traffic. AWS provides a managed prefix list for CloudFront, which is a set of IP ranges used by CloudFront edge locations. By using this prefix list in the inbound rule of the security group, the ALB will only allow traffic originating from CloudFront’s edge locations.
- Conclusion: This solution is operationally efficient because it ensures that only traffic coming from CloudFront’s IP ranges can reach the ALB, and it leverages AWS managed resources (prefix lists) that are automatically updated. This method is a clean and simple solution at the network layer, ensuring that only CloudFront traffic is allowed without modifying application logic or managing complex configurations.
Option B: Add an inbound rule to the network ACLs that are associated with the ALB's subnets. Use the AWS managed prefix list for CloudFront as the source in the rule.
- Reasoning: Network ACLs (NACLs) are a layer of security applied at the subnet level. Like security groups, NACLs can control traffic, but NACLs are stateless, meaning that both inbound and outbound rules need to be explicitly defined. While this solution could work, it’s generally less preferred than using security groups because NACLs apply to the entire subnet, which might lead to broader, less granular control.
- Conclusion: This option is also a valid solution but is not as efficient as using security groups. NACLs are more complex to manage in this context, and they might involve unnecessary complexity when you can achieve the same goal with securi...
Author: Noah · Last updated May 16, 2026
A company has AWS accounts in an organization in AWS Organizations. The company has implemented Amazon VPC IP Address Manager (IPAM) in its networking AWS account. The company is using AWS Resource Access Manager (AWS RAM) to share IPAM pools with other AWS accounts. The company has created a top-level pool with a CIDR block of 10.0.0.0/8. For each AWS account, the company has created an IPAM pool within the top-level pool.
A network engineer needs to implement a solution to ensure that users in each AWS accou...
The goal is to prevent users in each AWS account from creating new VPCs and ensure that any existing VPCs can only have CIDR blocks associated from the account-specific IPAM pool. Let's evaluate the options and explain why some are more suitable than others.
Option A: Create a new AWS Config rule to find all VPCs that are not configured to allocate their CIDR block from an IPAM pool. Invoke an AWS Lambda function to delete these VPCs.
- Reasoning: AWS Config can track the configuration of resources and evaluate them against rules. However, while AWS Config can help identify VPCs that don't follow the required CIDR allocation, this solution would require a Lambda function to delete non-compliant VPCs. Deleting VPCs automatically can be risky and could cause disruptions, especially if there are unintended consequences. This approach doesn't fully prevent the creation of VPCs in the first place, which is one of the key requirements.
- Conclusion: This is not the best solution, as it focuses on deletion rather than prevention, and automatic deletion could lead to issues.
Option B: Create a new SCP in Organizations. Add a condition that denies the CreateVpc and AssociateVpcCidrBlock Amazon EC2 actions if the Ipv4IpamPoolId context key value is not the ID of an IPAM pool.
- Reasoning: Service Control Policies (SCPs) are a powerful way to control actions across multiple accounts in AWS Organizations. By using an SCP with conditions, you can directly control the permissions to create VPCs and associate CIDR blocks. This approach would prevent users from creating VPCs or associating CIDR blocks unless they are coming from the appropriate IPAM pool. This solution is a preventive control, which is exactly what is needed here.
- Conclusion: This is the best solution because it ensures that the creation of VPCs and the association of CIDR blocks are restricted at the permission level, meeting both requirements effectively.
Option C: Create an AWS Lambda function to check for and delete all...
Author: Nia · Last updated May 16, 2026
A company has an application that runs on premises. The application needs to communicate with an application that runs in a VPC on AWS. The communication between the applications must be encrypted and must use private IP addresses. The communication cannot travel across the public internet.
The company has established a 1 Gbps AWS Direct Conne...
To solve this problem, we need to ensure secure communication between the on-premises application and the AWS-hosted application. The communication must meet several key criteria:
1. Private IP addresses: The connection must utilize private IP addresses.
2. Encryption: The communication must be encrypted.
3. No public internet: The communication must not traverse the public internet.
4. Low operational overhead: The solution must minimize manual configuration and maintenance.
Let's analyze each option:
Option A: Configure a private VIF on the Direct Connect connection. Associate the private VIF with the VPC's virtual private gateway. Set up an AWS Site-to-Site VPN private IP VPN connection to the virtual private gateway.
- Private VIF on Direct Connect: A private virtual interface (VIF) allows private communication between the on-premises data center and a VPC in AWS, using Direct Connect. This is secure and avoids public internet.
- Site-to-Site VPN: This would encrypt the traffic and provide secure communication. However, adding a Site-to-Site VPN on top of Direct Connect is redundant, as Direct Connect already provides a secure, private connection. This increases operational overhead without adding much value, since Direct Connect already ensures private communication.
Option B: Create a transit gateway. Configure a transit VIF on the Direct Connect connection. Associate the transit VIF with a Direct Connect gateway. Associate the Direct Connect gateway with a new transit gateway. Set up an AWS Site-to-Site VPN private IP VPN connection to the transit gateway.
- Transit Gateway: The transit gateway is a good solution when you need to manage multiple VPCs and on-premises connections. However, setting up a Site-to-Site VPN on top of a Direct Connect connection again introduces unnecessary complexity and operational overhead. The VPN connection is not required, as Direct Connect can directly handle private communication.
- Operational Overhead: This solution adds more steps and managemen...
Author: Charlotte · Last updated May 16, 2026
A company has established connectivity between its on-premises data center in Paris. France, and the AWS Cloud by using an AWS Direct Connect connection. The company uses a transit VIF that connects the Direct Connect connection with a transit gateway that is hosted in the Europe (Paris) Region. The company hosts workloads in private subnets in several VPCs that are attached to the transit gateway.
The company recently acquired another corporation that hosts workloads on premises in an office building in Tokyo, Japan. The company needs to migrate the workloads from the Tokyo office to AWS. These workloads must have access to the company's existing workloads in Paris. The company also must establish connectivity between the Tokyo office building and the Paris...
To meet the company's requirements of migrating workloads from the Tokyo office to AWS and ensuring connectivity between the Tokyo office, the Paris data center, and the AWS workloads, let's analyze each option in detail.
Key Requirements:
- Connectivity between Tokyo and Paris: The Tokyo office must be able to reach the Paris data center and vice versa.
- Connectivity to AWS VPCs: The new Tokyo VPC needs access to the existing Paris VPC workloads.
- Private Connectivity: No workloads should be directly accessible from the internet.
- Time Frame: The migration should be completed in 5 days, so the solution should be relatively straightforward and efficient.
Option A:
1. Create public subnets in the Tokyo VPC to migrate the workloads into.
2. Configure an internet gateway for the Tokyo office to reach the Tokyo VPC.
3. Configure security groups on the Tokyo workloads to only allow traffic from the Tokyo office and the Paris workloads.
4. Create peering connections between the Tokyo VPC and the Paris VPCs.
5. Configure a VPN connection between the Paris data center and the Tokyo office using existing routers.
- Issues:
- Public Subnets: This option involves using public subnets, which contradicts the requirement that the workloads cannot be accessible from the internet.
- Peering Connections: Peering VPCs in different regions (Tokyo and Paris) would require complex routing and management, which is not the optimal approach here.
- VPN: While VPN connections could work for Tokyo-to-Paris communication, this approach doesn’t integrate well with the AWS Direct Connect setup, which is more reliable for this purpose.
- Rejected: This option introduces unnecessary complexity and violates the private connectivity requirement by involving public subnets and an internet gateway.
Option B:
1. Configure a transit gateway in the Asia Pacific (Tokyo) Region. Associate this transit gateway with the Tokyo VPC.
2. Create peering connections between the Tokyo transit gateway and the Paris transit gateway.
3. Set up a new Direct Connect connection from the Tokyo office to the Tokyo transit gateway.
4. Configure routing on both transit gateways to allow data to flow between sites and the VPCs.
- Strengths:
- Transit Gateway: A transit gateway in Tokyo and Paris simplifies the communication and allows seamless routing between the two regions.
- Direct Connect: The new Direct Connect connection from the Tokyo office to the Tokyo transit gateway is a secure and high-bandwidth connection, which ensures reliable communication between the Tokyo office and AWS.
- Private Connectivity: Using Direct Connect ensures that traffic between Tokyo and AWS remains private and does not traverse the public internet.
- Issues:
- New Direct Connect: Setting up a new Direct Connect connection for the Tokyo office adds some complexity and may not be feasible within the 5-day migration window. This could take longer to provision and c...
Author: Isabella · Last updated May 16, 2026
Company A recently acquired Company B. Company A has a hybrid AWS and on-premises environment that uses a hosted AWS Direct Connect connection, a Direct Connect gateway, and a transit gateway. Company A has a transit VIF to access the resources in its production environment in the us-east-1 Region.
Company B has applications that run across multiple VPCs in the us-west-2 Region in a single AWS account. A transit gateway connects all Company B's application VPCs. The CIDR blocks for b...
To address the requirements for enabling Company A's on-premises environment to access Company B's applications in AWS using the existing Direct Connect connection, we need to ensure the solution facilitates secure, private connectivity without creating a new Direct Connect link for Company A. Let’s analyze the options based on this need.
Key Requirements:
1. Use the existing Direct Connect connection from Company A to access Company B’s applications.
2. No CIDR overlap between the companies, ensuring routing won't conflict.
3. The solution must be efficient and leverage existing resources to minimize changes.
Option A: Create a new Direct Connect gateway in the Company B account. Associate the Company B transit gateway with the new Direct Connect gateway. Create a transit VIF on the existing hosted connection for Company B.
- Direct Connect Gateway in Company B Account: This option suggests creating a new Direct Connect gateway in Company B’s account, which is unnecessary because the existing hosted Direct Connect gateway in Company A can already facilitate connectivity. Adding another Direct Connect gateway does not simplify the setup and would require additional configurations.
- Transit VIF: Creating a transit VIF on the existing hosted connection would potentially create a new link but is not needed since the connection from Company A’s Direct Connect to the transit gateway can be leveraged more directly.
- Rejected: This approach adds complexity by introducing a new Direct Connect gateway in Company B, which is unnecessary given the goal of using the existing Direct Connect connection.
Option B: Create an association proposal from the Company B account to associate the Company B transit gateway with the Company A Direct Connect gateway. Accept the transit gateway association proposal by logging into the Company A account.
- Association Proposal: This solution involves associating Company B's transit gateway with the Company A Direct Connect gateway, enabling routing between Company A’s on-premises environment and Company B’s VPCs via the existing Direct Connect connection. This solution leverages the existing resources and ensures that Company A can access Company B’s VPCs across regions.
- Seamless Connectivity: By accepting the association proposal between the transit gateways, this approach simplifies the so...
Author: Amelia · Last updated May 16, 2026
A company has developed a web service for language translation. The web service's application runs on a fleet of Amazon EC2 instances that are in an Auto Scaling group. The instances run behind an Application Load Balancer (ALB) and are deployed in a private subnet. The web service can process requests that contain hundreds of megabytes of data.
The company needs to give some customers the ability to access the web service. Each customer has its own AWS account. The company must make the ...
To meet the company's requirement of making the web service accessible to specific customers without exposing it to all, while minimizing operational overhead, let's analyze the options and identify the best combination of steps.
Key Requirements:
1. Web service accessibility should be granted only to approved customers (each in their own AWS account).
2. The solution must minimize operational overhead, meaning it should be easy to manage and not require extensive custom setup.
3. The web service must not be accessible to all customers, only the approved ones.
Option A: Create VPC peering connections with the approved customers only.
- VPC Peering allows direct communication between VPCs in different accounts, but it requires manual setup and management of peering connections for each approved customer. The operational overhead increases as the number of customers grows, as each customer will need a separate VPC peering connection.
- Rejected: While VPC peering can work, it does not scale well and involves more manual intervention and management as the number of approved customers increases.
Option B: Create an AWS PrivateLink endpoint service. Configure the endpoint service to require acceptance that will be granted to approved customers only.
- AWS PrivateLink enables customers to privately access your services over a VPC endpoint. With PrivateLink, the company can create an endpoint service that is only accessible to approved customers by requiring their acceptance before they can connect to the service. This solution ensures that only specific customers (those with accepted endpoint connections) can access the web service.
- Selected: This solution meets the requirement efficiently. It’s highly secure, scalable, and reduces the operational overhead of managing VPC peering connections. The approval mechanism ensures only authorized customers can access the web service.
Option C: Configure an authentication action for the endpoint service's load balancer to allow cu...
Author: Olivia · Last updated May 16, 2026
A company is migrating an application to the AWS Cloud. The company has successfully provisioned and tested connectivity between AWS Direct Connect and the company's on-premises data center. The application runs on Amazon EC2 instances across multiple Availability Zones. The instances are in an Auto Scaling group.
The application communicates through HTTPS to a third-party vendor's data service that is hosted at the company's data center. The data service implements a static ACL through explicit allow listing of client IP addresses.
A network engineer must des...
To solve the problem of ensuring that the migrated application can access the third-party vendor’s data service while minimizing changes to the vendor's static ACL (allow list), we need to consider the following requirements:
Key Requirements:
1. Minimal Ongoing Changes: The solution should minimize the amount of changes needed to the vendor’s allow list.
2. Scaling Considerations: The solution should support scaling the application seamlessly (with Auto Scaling) across multiple Availability Zones in AWS.
3. IP Address Consistency: The solution should ensure that the application can use a consistent IP address that does not change as the Auto Scaling group grows and shrinks.
Let's analyze each option to determine which solution meets these requirements.
Option A: Configure a private NAT gateway in the subnets for each Availability Zone that the application runs in. Configure the application to target the NAT gateways instead of the data service directly. Update the data service's allow list to include the IP addresses of the NAT gateways.
- NAT Gateway: A private NAT gateway can be used to allow private instances (like the EC2 instances in the Auto Scaling group) to communicate with the outside world. By configuring the application to target the NAT gateway, all outbound requests to the vendor’s data service will come from the NAT gateway’s public IP address.
- Consistency: NAT gateways provide a consistent set of IP addresses. However, AWS automatically assigns an Elastic IP (EIP) to each NAT gateway, which could require adding new IP addresses to the vendor’s allow list as more NAT gateways are provisioned across different Availability Zones.
- Scalability: As the application scales, new NAT gateways would be needed in each Availability Zone, and additional EIPs would need to be added to the vendor’s allow list.
- Rejected: Although this solution can work, it introduces ongoing maintenance to update the vendor's allow list as the application scales (i.e., adding new IP addresses for NAT gateways).
Option B: Configure an elastic network interface in the subnets for each Availability Zone that the application runs in. Associate the elastic network interfaces with the Auto Scaling group for the application. Update the data service's allow list to include the IP addresses of the elastic network interfaces.
- Elastic Network Interface (ENI): ENIs are used to provide network interfaces that are attached to instances. Associating ENIs with an Auto Scaling group means each instance can get its own private IP address. These IP addresses can be added to the vendor’s allow list.
- Scalability: Each instance can get its own ENI with a unique IP, but as the Auto Scaling group scales up and down, the number of IP addresses in the vendor's allow list would increase and change frequently.
- Rejected: This op...
Author: Aditya · Last updated May 16, 2026
A company has a highly available application that is hosted in multiple VPCs and in two on-premises data centers. All the VPCs reside in the same AWS Region. All the VPCs require access to each other and to the on-premises data centers for the transfer of files that are multiple gigabytes in size.
A network engineer is designing an AWS Direct Connect sol...
To address the requirements of the company's architecture, we need to evaluate each option based on factors such as operational overhead, scalability, inter-VPC communication, on-premises connectivity, and network performance (specifically the MTU size).
Option A:
- Virtual Private Gateway (VGW) and private VIF in each VPC.
- Direct Connect Gateway (DGW) and private VIF connecting the DGW to on-premises data centers.
- VPC peering for inter-VPC connectivity.
- Static routing for inter-VPC routing.
Pros:
- Direct Connect is used for high-throughput file transfers to and from on-premises data centers.
- Using VGWs and private VIFs connects VPCs to on-premises data centers.
Cons:
- VPC Peering is used for inter-VPC connectivity, which can lead to operational complexity as the number of VPCs increases, especially with scaling.
- Static routing increases operational overhead as each route must be managed manually.
- VPC peering does not scale well with many VPCs; if the company expands, it will require managing many peering connections, which is not ideal for high scalability.
Option B:
- Similar to Option A but with a MTU of 8500.
Pros:
- Same structure as Option A with Direct Connect used to connect the on-premises data centers.
Cons:
- The use of a smaller MTU (8500) may impact performance for large files, which is a critical requirement for the company. The MTU size of 8500 is less optimal than 9001 for high-performance file transfer.
- Same operational complexity due to the use of VPC peering and static routing.
Option C:
- Transit Gateway (TGW) attached to all VPCs.
- Direct Connect Gateway connected to the TGW.
- Transit VIF for Direct Connect to exchange BGP routes with MTU of 9001.
- Route propagation between VPCs and the TGW.
Pros:
- Transit Gateway simplifies inter-VPC communication and scales better as the number of VPCs ...
Author: Leah Davis · Last updated May 16, 2026
A company has a data center in the us-west-1 Region with a 10 Gbps AWS Direct Connect dedicated connection to a Direct Connect gateway. There are two private VIFs from the same data center location in us-west-1 that are attached to the same Direct Connect gateway.
VIF 1 advertises 172.16.0.0/16 with an AS_PATH attribute value of 65000. VIF 2 advertises 172.16.1.0/24 with an AS PATH a...
To determine how AWS will route traffic to the data center for destinations within the `172.16.1.0/24` network, we need to consider how AWS processes the BGP (Border Gateway Protocol) routes, particularly the AS_PATH attribute. The AS_PATH is used in BGP for loop prevention and path selection, with shorter AS_PATH lengths being preferred over longer ones.
Key Factors:
- AS_PATH Attribute: The AS_PATH attribute is used to prevent routing loops and to determine the best path for traffic. A shorter AS_PATH is preferred over a longer AS_PATH.
- BGP Routing Logic: AWS uses BGP for routing between the VIFs and the Direct Connect gateway. When it receives multiple routes to the same destination, it will prefer the route with the shortest AS_PATH.
- VIFs: There are two VIFs, each advertising a different subnet. VIF 1 advertises `172.16.0.0/16` with an AS_PATH of `65000`, and VIF 2 advertises `172.16.1.0/24` with an AS_PATH of `65000 65000 65000`.
Analysis:
- For the subnet `172.16.1.0/24`, the route advertised via VIF 2 has an AS_PATH of `65000 65000 65000`, meaning the traffic has to traverse through more AS hops.
- In comparison, VIF 1 advertises the broader subnet `172.16.0.0/16` with a shorter AS_PATH of `65000`, which makes it a more preferred route based on BGP's AS_PATH selection rule.
- Since the AS_PATH length for VI...
Author: Leah Davis · Last updated May 16, 2026
A company is planning to host external websites on AWS. The websites will include multiple tiers such as web servers, application logic services, and databases. The company wants to use AWS Network Firewall, AWS WAF, and VPC security groups for network security.
The company must ensure that the Network Firewall firewalls are deployed appropriately within relevant VPCs. The company needs the ability to centrally manage policies that are deployed to Network Firewall and AWS WAF rules. The company also needs to ...
Problem Breakdown and Key Requirements:
- AWS Network Firewall: Centralized firewall management for VPC traffic.
- AWS WAF: Web application firewall management for protection from common web exploits.
- VPC Security Groups: Fine-grained control over network access for EC2 instances, databases, etc.
- Centralized Management: The company needs to manage firewall and WAF policies centrally.
- Operational Efficiency: Ensure application teams can manage their own security groups without making them overly permissive.
- Monitoring: Use of Amazon GuardDuty to detect overly permissive rules.
Option A:
- Approach: Use CloudFormation to define and deploy AWS Network Firewall, AWS WAFv2 web ACLs, Network Firewall policies, and VPC security groups.
- Pros:
- CloudFormation enables infrastructure as code, making it repeatable and consistent.
- Centralized management of initial policies and rule groups via CloudFormation.
- Cons:
- While CloudFormation helps with deployment, ongoing management of AWS WAFv2 web ACLs and security group updates would require manual intervention (via console or CLI), which doesn't fully meet the operational efficiency requirement.
- GuardDuty provides security monitoring, but there is no clear automated remediation for overly permissive rules in this option.
Conclusion for Option A: Although it offers some level of automation via CloudFormation, manual updates for ongoing security management (especially security groups) and lack of automated policy enforcement make it less operationally efficient for ongoing management.
Option B:
- Approach: Define resources in code (like Option A), but use the AWS CLI/Console for ongoing management of AWS WAFv2 web ACLs, Network Firewall policies, and security groups. Utilize Amazon GuardDuty with AWS Lambda to evaluate rules and remove overly permissive ones.
- Pros:
- Lambda can help automate responses to overly permissive security group rules by invoking GuardDuty findings.
- Some automation is provided via Lambda.
- Cons:
- Manual management via the CLI/Console for ongoing updates is not the most efficient method.
- While GuardDuty can detect issues, automatic remediation requires careful Lambda configuration, which adds complexity.
- Manual intervention still required for security group management...
Author: Aria · Last updated May 16, 2026
A company has deployed an application in which the front end of the application communicates with the backend instances through a Network Load Balancer (NLB) in the same VPC. The application is highly available across two Availability Zones. The company wants to limit the amount of traffic that travels across the Availability Zones. Traffic from the front end of the application must stay in the same Availability Zone unless there is no healthy target in th...
To meet the company's requirement of limiting traffic across Availability Zones (AZs) unless there are no healthy targets in the local AZ, we need to evaluate the options based on AWS features related to traffic distribution, cross-zone load balancing, and DNS routing.
Requirements:
- Traffic staying within the same Availability Zone: The front end should communicate with the backend in the same AZ unless the backend in that AZ is unhealthy.
- Failover to the other Availability Zone only when there are no healthy targets in the same AZ: If there are no healthy targets in the local AZ, traffic should be routed to the other AZ.
Option A:
- Create a private hosted zone with weighted routing for each AZ. The primary record points to the NLB DNS for the local AZ, and the secondary record points to the Regional NLB DNS.
- Configure the front end to perform DNS lookups on the local private hosted zone records.
Pros:
- Weighted routing allows for control over the traffic distribution and can help route traffic to a particular AZ by default.
- Secondary routing could be used to failover to the other AZ when there are no healthy targets in the primary AZ.
Cons:
- DNS routing may introduce latency in the failover process because DNS caching can delay the change from the primary to secondary record.
- DNS is not real-time, so failover may not be instantaneous, leading to potential traffic disruptions or delays.
Conclusion for Option A: This option is somewhat suitable but introduces potential delays due to DNS caching and isn't as immediate as other methods in handling failover.
Option B:
- Turn off cross-zone load balancing on the NLB.
- Configure the front end to perform DNS lookups on the local Availability Zone NLB DNS record.
Pros:
- Turning off cross-zone load balancing means traffic will stay within the local AZ unless there are no healthy targets in that AZ.
- Traffic will only be directed to the other AZ if there are no healthy targets in the primary AZ, which meets the requirement.
Cons:
- The NLB itself doesn’t have the capability to check for healthy targets across AZs when cross-zone load balancing is disabled. It will not automatically failover to another AZ unless there is a change in the health status of targets, so there may be instances where the application needs to handle retries or other logic for failover.
Conclusion for Option B:...
Author: Liam · Last updated May 16, 2026
A company needs to protect against potential botnet command and control traffic from any Amazon EC2 instances that is in in the company's AWS...
To protect against potential botnet command and control traffic from EC2 instances in the company's AWS environment, the solution should focus on blocking or mitigating traffic associated with botnet activity in a scalable, automated, and efficient manner.
Key Requirements:
- Protect EC2 instances from botnet traffic: The solution needs to detect and block command and control (C&C) traffic from EC2 instances.
- Automated and scalable: The solution should scale with the environment and be automated to handle the increasing complexity of botnet activities.
- Minimal operational overhead: The solution should require minimal manual intervention and configuration.
Option A: Use AWS Shield Advanced
- Approach: AWS Shield Advanced provides protection against DDoS attacks, but it is specifically designed to mitigate large-scale DDoS attacks, not botnet C&C traffic specifically. It does not provide a direct mechanism to detect or block botnet traffic at the level required for this scenario.
- Pros: Protection against DDoS attacks.
- Cons: Does not specifically address botnet C&C traffic detection or mitigation for EC2 instances. Shield Advanced is focused on mitigating volumetric and network-layer DDoS attacks rather than application-layer botnet traffic.
Conclusion: Option A is not suitable for blocking botnet C&C traffic as it does not focus on botnet detection or control.
Option B: Use Amazon Route 53 Resolver DNS Firewall
- Approach: Amazon Route 53 Resolver DNS Firewall allows for the creation of DNS firewall rules. By using the `AWSManagedDomainsBotnetCommandandControl` managed domain list, it can block DNS queries to known botnet C&C domains.
- Pros: Provides DNS-level protection by blocking requests to known botnet C&C domains. This solution can work across AWS accounts and VPCs.
- Cons: This solution works at the DNS layer and cannot block botnet traffic directly on the EC2 instances or at the application level. It only blocks DNS queries to domains associated with botnets and won't necessarily stop botnet traffic if the botnet does not rely on DNS or uses non-standard domains.
Conclusion: While it can help mitigate some botnet C&C traffic at the DNS level, it doesn't provide a...
Author: Henry · Last updated May 16, 2026
A company has two on-premises data centers. The first data center is in the us-east-1 Region. The Second data canter is in the us-east-2 Region. Each data center connects to the closest AWS Direct Connect facility. The company uses Direct Connect connections, transit VIFs, and a single Direct Connect gateway to establish connectivity to VPCs in us-east-1 and us-east-2 from the company's data centers. The company also has private connectivity from a telecommunications provider that connects the first data center to the second data center.
Recently, there have...
To improve the reliability of the connection between the two data centers, the company needs to ensure that there is a reliable, redundant connection between the data centers and the AWS environment. Let’s analyze each option:
Option A: Create a new Direct Connect gateway. Enable the Direct Connect SiteLink feature on the transit VIF. Share the CIDR blocks from the first data center and the second data center with each other.
- Analysis: This solution involves creating a new Direct Connect gateway and enabling the SiteLink feature on a new transit VIF. While the Direct Connect SiteLink feature improves the ability to route traffic between VPCs in different regions, creating a new gateway is unnecessary if there is already an existing one. The company already uses a Direct Connect gateway, and creating a new one would not directly resolve the existing connectivity issues between the data centers themselves. Sharing CIDR blocks between the two data centers is a valid step, but this doesn't specifically address the current disruptions.
- Why Rejected: Creating a new Direct Connect gateway is redundant and not optimal. This option doesn't directly solve the issue of private connectivity disruptions between the data centers.
Option B: Create a new public VIF to both Regions. Enable the Direct Connect SiteLink feature on the new public VIF.
- Analysis: A new public VIF is typically used for accessing AWS public services (like S3, EC2 public endpoints, etc.) but it wouldn’t be used to improve connectivity between VPCs or between on-premises data centers. A SiteLink feature on a public VIF would not impact the private connectivity between the data centers, as the SiteLink feature is generally used for inter-region traffic over private connectivity via Direct Connect.
- Why Rejected: This option would not address the primary requirement of improving reliability between the two data centers. Public VIFs are not suitable for private connectivity between data centers.
Option C: Enable the Direct Connect SiteLink feature on the existing Direct Connect connections.
- Analysis: This option involves enabling the SiteLink feature on the existing Direct Connect connections. The SiteLink feature allows the use of Direct Connect to route traffic betwee...
Author: Isabella · Last updated May 16, 2026
A network engineer is working on a large migration effort from an on-premises data center to an AWS Control Tower based multi-account environment. The environment has a transit gateway that is deployed to a central network services account. The central network services account has been shared with an organization in AWS Organizations through AWS Resource Access Manager (AWS RAM).
A shared services account also exists in the environment. The shared services account hosts workloads that need to be shared with the entire organization.
The network engineer needs to create a solution to automate the deployment of common network components across the environment. The soluti...
To meet the requirements of automating the deployment of common network components across multiple accounts in an AWS Control Tower-based environment, the solution must provision VPCs in new and existing member accounts and connect them to the central transit gateway with minimal operational overhead. Let’s analyze each option:
Option A: Deploy an AWS Lambda function to the shared services account. Program the Lambda function to assume a role in the new and existing member accounts to provision the necessary network infrastructure.
- Analysis: Deploying an AWS Lambda function in the shared services account to assume roles in member accounts and provision infrastructure is a feasible solution. However, this approach requires significant custom code and IAM role configuration across each member account. While functional, it introduces operational complexity and the need for ongoing maintenance of the Lambda function and IAM roles.
- Why Rejected: While this could meet the requirement, the solution is custom and would require ongoing maintenance of roles and Lambda function logic, leading to higher operational overhead compared to more native AWS solutions.
Option B: Update the existing accounts with an Account Factory Customization (AFC). Select the same AFC when provisioning new accounts.
- Analysis: The Account Factory within AWS Control Tower is used for automating the creation of new accounts, including the configuration of networking components. By using Account Factory Customization (AFC), the solution can automatically deploy network resources such as VPCs and connect them to the transit gateway during account creation. This can be applied to new and existing accounts, as AFC can be re-applied during the lifecycle of an account.
- Why Selected: This approach leverages AWS Control Tower's native capabilities, automating the provisioning of VPCs in new and existing accounts, minimizing manual effort, and ensuring consistency. It reduces operational overhead because it integrates with the overall Control Tower environment and doesn't require custom coding or external resources.
Option C: Create an AWS CloudFormation template that describes the infrastructure that needs to be created in each account. Upload the template as an AWS Service Catalog product to the shared services account.
- Analysis: Creating a CloudFormation template and uploading it as a product to AWS Service Catalog is a solid solution for defining infrastructure as code. AWS Service Catalog can be used to manage and provision resources across accounts. However, to provision infrastructure across multiple accounts, you'd need to ensure each account has the necessary permissions to invoke the Service Catalog and execute the CloudFormation stack. This would add some operational overhead as you'd have to manage the lifecycle of the templates and permissions manually.
- Why Rejected: Wh...
Author: Madison · Last updated May 16, 2026
An online retail company is running a web application in the us-wast-2 Region and serves consumers in the United States. The company plans to expand across several countries in Europe and wants to provide low latency for all its users.
The application needs to identify the users' IP addresses and provide localized content based on the users' geographic location. The application uses HTTP GET and POST methods for its functionality. The company also needs to deve...
To meet the requirements for low latency, IP-based geographic localization, and fast failover for GET and POST requests, let's analyze each solution option:
Option A: Configure a Network Load Balancer (NLB) for the application in each environment in the new AWS Regions. Create an AWS Global Accelerator accelerator that has endpoint groups that point to the NLBs in each Region.
- Analysis: AWS Global Accelerator can distribute traffic across multiple regions with low latency, and NLBs are ideal for handling large amounts of traffic with high throughput. Global Accelerator ensures traffic is routed to healthy endpoints based on health checks, providing automatic failover. However, NLBs do not provide functionality like HTTP request inspection, geographic localization, or content customization based on IP addresses. This option addresses failover and latency but does not provide easy access to geolocation-based content.
- Why Rejected: While this solution offers low latency and failover capabilities, it lacks the ability to customize content based on geographic location and does not handle HTTP-level routing for GET and POST methods. A solution like Global Accelerator with NLBs is not as efficient for content localization.
Option B: Configure an Application Load Balancer (ALB) for the application in each environment in the new AWS Regions. Create an AWS Global Accelerator accelerator that has endpoint groups that point to the ALBs in each Region.
- Analysis: ALBs are designed for HTTP/HTTPS traffic, making them perfect for routing GET and POST methods. They can inspect HTTP headers and enable content-based routing, such as serving localized content based on the user's geographic location (by using the IP address). Pairing this with AWS Global Accelerator improves global application performance by routing traffic based on the health of the endpoints and providing low-latency routing to the nearest region. This solution also enables automatic failover with minimal downtime.
- Why Selected: This solution offers low latency, geographic localization, and automatic failover, all while supporting HTTP GET and POST methods. It provides the best combination of traffic management, content customization, and fast failover. Global Accelerator ensures failover happens within a minute, and the ALB can perform content routing based on user IP a...
Author: Elijah · Last updated May 16, 2026
A company has VPCs across 50 AWS accounts and is using AWS Organizations. The company wants to implement web filtering. The requirements for how the traffic must be filtered are the same for all the VPCs. A network engineer plans to use AWS Network Firewall. The network engineer needs to implement a solution that minimizes the number of fire...
To meet the company's requirements for web filtering across 50 AWS accounts using AWS Network Firewall, the network engineer needs a solution that minimizes the number of firewall policies and rule groups. The best approach would centralize and streamline the management of firewall policies and minimize the administrative overhead. Let’s break down the options and determine the most efficient solution:
Option A: Create a firewall policy or rule group in each account.
- Analysis: Creating separate firewall policies and rule groups for each account would lead to a high level of administrative overhead. Managing 50 different policies or rule groups across 50 accounts would be cumbersome and difficult to scale. This option is inefficient because it requires repetitive tasks and lacks centralization.
- Why Rejected: This option goes against the goal of minimizing the number of policies and rule groups, as it would create many separate resources that need to be managed individually.
Option B: Use SCPs to share the firewall policy or rule group.
- Analysis: Service Control Policies (SCPs) are used to control permissions at the organization level and do not provide a mechanism for sharing AWS resources like firewall policies or rule groups. SCPs are more about restricting or allowing actions and do not directly help with resource sharing or centralizing firewall management.
- Why Rejected: SCPs cannot be used to share resources like AWS Network Firewall policies or rule groups. This option doesn't meet the requirement of efficiently managing firewall policies across multiple accounts.
Option C: Create a firewall policy or rule group in the management account.
- Analysis: Creating a firewall policy or rule group in the management account is a good starting point. However, AWS does not automatically share resources like firewall policies across accounts. While this step is part of the solution, it must be paired with a mechanism to share the policy or rule group with other accounts.
- Why Rejected: While creating a policy or rule group in the management account is a good step, it alone does not ensure sharing across the 50 accounts. Additional steps are required to share the policy or rule group.
Option D: Use AWS Resource Access Manag...
Author: William · Last updated May 16, 2026
A company has an internal web-based application that employees use. The company hosts the application over a VPN in the company's on-premises network. The application runs on a fleet of Amazon EC2 instances in a private subnet behind a Network Load Balancer (NLB) in the same subnet. The instances are in an Amazon EC2 Auto Scaling group.
During a recent security incident, SQL injection occurred on the appl...
To prevent SQL injection attacks in the future for the web-based application, the network engineer must use security controls that specifically address such attacks while ensuring minimal disruption to the current infrastructure. Let’s analyze each option:
Option A: Create an AWS WAF web ACL that includes rules to block SQL injection attacks.
- Analysis: AWS WAF (Web Application Firewall) can be configured to detect and block SQL injection attacks. AWS provides pre-configured rules in AWS WAF, including the SQL Injection rule set, which can be added to a web ACL (Access Control List). The web ACL can inspect HTTP requests and prevent malicious SQL injection patterns.
- Why Selected: This is the key part of the solution. Creating an AWS WAF web ACL with rules to block SQL injection attacks directly addresses the requirement to prevent such attacks in the future.
Option B: Create an Amazon CloudFront distribution. Specify the EC2 instances as the origin.
- Analysis: Amazon CloudFront is a content delivery network (CDN) service that can provide low-latency access to your application. While CloudFront can be integrated with AWS WAF, simply adding CloudFront would not by itself prevent SQL injection attacks unless you configure AWS WAF and associate it with CloudFront.
- Why Rejected: While CloudFront can help with content delivery, it does not inherently provide protection against SQL injection. Therefore, it is not enough by itself to fulfill the security requirement.
Option C: Replace the NLB with an Application Load Balancer.
- Analysis: An Application Load Balancer (ALB) operates at the HTTP/HTTPS layer, unlike a Network Load Balancer (NLB), which operates at the TCP layer. ALBs support deeper inspection of HTTP requests, which can allow for better integration with AWS WAF to filter out malicious requests like SQL injection. NLBs, on the other hand, are better suited for high-performance TCP-level traffic but lack the ability to inspect HTTP headers or URLs.
- Why Selected: Replacing the NLB with an Application Load Balancer allows the use of AWS WAF for HTTP/HTTPS traffic filtering. ALBs work seamlessly with AWS WAF, which can block SQL injection attacks, making this a crucial step in enhancing security.
Option D: Associa...
Author: Sophia · Last updated May 16, 2026
A company has two data centers that are interconnected with multiple redundant links from different suppliers. The company Uses IP addresses that are within the 172.16,0.0/16 CIDR block. The company is running iBGP between the two data centers by using a private Autonomous System Number (ASN) and IGP.
The company is moving toward a hybrid setup in which the company will initially use one VPC in the AWS Cloud. An AWS Direct Connect connection runs from the first data center to a Direct Connect gateway by using a private VIF. On the connection, the company advertises a summarized route for the 172.16.0.0/16 network. The company is planning to set up a second summarized route from the second data c...
The company's goal is to route traffic to AWS through the first Direct Connect connection under normal conditions, and use the second Direct Connect connection for failover purposes only. The solution should allow for both connections to exist without causing routing conflicts, ensuring that the second connection is only used when the first connection fails.
Let's break down each option:
Option A: Prepend the private ASN on the BGP announcements to AWS from the second data center. Add a second VIF in the first Direct Connect connection. Advertise the same network without any prepends from the first data center. Implement the same setup for the BGP announcement from AWS to the two data centers.
- Analysis: ASN prepending is typically used to influence BGP routing decisions by artificially increasing the AS path length. This would make the route from the second data center less preferred, which aligns with the requirement for the second Direct Connect link to be used only in failover. However, adding a second VIF on the first Direct Connect connection is redundant and not necessarily helpful, as it does not provide any specific preference for one connection over the other.
- Why Rejected: The solution of adding a second VIF doesn't directly solve the problem of making the second connection only a failover route. Additionally, prepending ASN can create complexity without offering clear control over the primary routing decision.
Option B: Tag the BGP announcements with the local preference BGP community tags. Set the tag to high preference for the first data center. Set the tag to low preference for the second data center. Configure the second data center’s router to have a lower local preference for the direct AWS BGP advertisements than for the advertisement from the first data center.
- Analysis: BGP local preference is a well-established method for influencing inbound routing decisions. By setting a higher local preference for the first data center, the company can ensure that traffic from AWS prefers the first Direct Connect link. The second data center can be configured with a lower local preference, ensuring that the second Direct Connect link is only used when the first one fails. This method provides fine-grained control over routing preferences and meets the requirement for using the second link as a failover only.
- Why Selected: This solution effectively prioritizes the first Direct Connect link for routing ...
Author: Samuel · Last updated May 16, 2026
A company is replatforming a legacy data processing solution to AWS. The company deploys the solution on Amazon EC2 Instances in private subnets that are in one VPC.
The solution uses Amazon S3 for abject storage. Both the data that the solution processes and the data the solution produces are stored in Amazon S3. The solution uses Amazon DynamoDB to save its own state. The company collects flow logs for the VPC. The solution uses one NAT gateway to register its license through the internet. A software vendor provides a specific hostname so the solution can register its license.
The company notices that the AWS bill exceeds the projected budget f...
The issue in question stems from the high costs associated with the use of the NAT gateway (specifically the USE2-NatGateway-Bytes($) usage type), which suggests that the data traffic flowing through the NAT gateway is generating unexpected costs. The goal is to identify and address the unnecessary or excessive use of the NAT gateway.
Let’s analyze the options in detail:
Option A: Set up Amazon VPC Traffic Mirroring. Analyze the traffic to identify the traffic that the NAT gateway processes.
- Analysis: Amazon VPC Traffic Mirroring allows capturing and analyzing traffic within a VPC, providing deep insights into network traffic patterns. However, while VPC Traffic Mirroring can give you detailed insights into network traffic, it is not directly useful for identifying excessive usage of the NAT gateway in this context. The issue is more related to how traffic flows through the NAT gateway, which can be better identified through VPC flow logs rather than traffic mirroring.
- Why Rejected: VPC Traffic Mirroring is not necessary for diagnosing NAT gateway usage. It adds complexity and is generally used for deeper network analysis (e.g., troubleshooting security issues), but it doesn't directly resolve the cost issue related to the NAT gateway.
Option B: Examine the VPC flow logs to identify the traffic that traverses the NAT gateway.
- Analysis: VPC flow logs capture network traffic information, including the source and destination of the traffic that flows through the NAT gateway. By analyzing the flow logs, you can identify what traffic is using the NAT gateway and look for patterns that might explain high data usage. For example, unnecessary or excessive outbound traffic (such as large data uploads or repeated requests to external services) could be contributing to the high cost.
- Why Selected: Examining VPC flow logs is a critical step in identifying excessive traffic through the NAT gateway. By understanding the flow of traffic, you can pinpoint areas where costs can be reduced (e.g., unnecessary traffic to external resources or inefficient data processing patterns).
Option C: Set up an AWS Cost and Usage Report in the AWS Billing and Cost Management console. Examine the report to find more details about the NAT gateway charges.
- Analysis: AWS Cost and Usage Reports provide detailed billing information, including a breakdown of costs per service and resource. This can help track NAT gateway costs, but it won’t help directly resolve the high usage issue. While it’s useful for identifying where ...
Author: Olivia · Last updated May 16, 2026
A company ran out of IP address space in one of the Availability Zones in an AWS Region that the company uses. The Availability Zone that is out of space is assigned the 10.10.1.0/24 CIDR block. The company manages its networking configurations in an AWS CloudFormation stack. The company' VPC is assigned the 10 10.0.0/16 CIDR block and has available capac...
The company has already allocated a 10.10.0.0/16 CIDR block for its VPC and has available space in the 10.10.1.0/22 CIDR block. The issue at hand is that the 10.10.1.0/24 subnet in one Availability Zone is out of IP address space, and the company needs to add more IP address space to the existing VPC with the least operational overhead.
Let’s evaluate each option:
Option A: Update the AWS::EC2::Subnet resource for the Availability Zone in the CloudFormation stack. Change the CidrBlock property to 10.10.1.0/22.
- Analysis: The `AWS::EC2::Subnet` resource in CloudFormation allows you to define subnets within a VPC. However, you cannot modify the CIDR block of an existing subnet. Once a subnet is created, its CIDR block is fixed and cannot be resized or expanded. Attempting to modify the CIDR block of an existing subnet would lead to an error.
- Why Rejected: This option is not valid because subnets cannot have their CIDR blocks modified after they are created. You would need to create a new subnet with the desired CIDR block.
Option B: Update the AWS::EC2::VPC resource in the CloudFormation stack. Change the CidrBlock property to 10.10.1.0/22.
- Analysis: The CIDR block of a VPC can only be modified during the creation of the VPC, not after it has been created. Since the company already has a VPC with the `10.10.0.0/16` CIDR block, this option would not be feasible.
- Why Rejected: You cannot change the CIDR block of an existing VPC once it’s created. This option would result in an error.
Option C: Copy the CloudFormation stack. Set the AWS::EC2::VPC resource CidrBlock property to 10.10.0.0/16. Set the AWS::EC2::Subnet resource CidrBlock property to 1...
Author: ThunderBear · Last updated May 16, 2026
A company's network engineer must implement a cloud-based networking environment for a network operations team to centrally manage. Other Teams will use the environment. Each team must be able to deploy infrastructure to the environment and must be able to manage its own resources. The environment must feature IPv4 and IPv6 support and must provide internet connectivity in a dual-stack configuration.
The company has an organization in AWS Organizations that contains a workload...
To meet the requirements of providing IPv4 and IPv6 support, internet connectivity, and the ability for teams to deploy and manage their own resources in a dual-stack configuration, let's evaluate the given options:
Option A: Create a new VPC. Associate an IPv4 CIDR block of 10.0.0.0/16 and specify an IPv6 block of 2001:db8:c5a:6000::/56. Provision subnets by assigning /24 IPv4 CIDR blocks and /64 IPv6 CIDR blocks.
- Analysis: This option is a valid approach for setting up a VPC with both IPv4 and IPv6 addresses. It specifies a custom IPv6 CIDR block (`2001:db8:c5a:6000::/56`) and assigns IPv4 subnets and IPv6 subnets accordingly. This is a good approach to ensure dual-stack configuration and gives flexibility to define subnets in both IP versions.
- Why Selected: This option works as it sets up a VPC with both IPv4 and IPv6 support, including proper subnet allocation. This configuration meets the dual-stack requirement.
Option B: Create a new VPC. Associate an IPv4 CIDR block of 10.0.0.0/16 and use an Amazon-provided IPV6 CIDR block. Provision subnets by assigning /24 IPv4 CIDR blocks and /64 IPV6 CIDR blocks.
- Analysis: This option uses an Amazon-provided IPv6 CIDR block, which is a simpler approach than specifying a custom IPv6 block. Amazon-provided CIDR blocks automatically provide an IPv6 range for the VPC. The subnetting strategy is the same as in Option A and follows the same principles of allocating /24 IPv4 and /64 IPv6 subnets.
- Why Selected: This option is simpler than Option A, as AWS automatically provides the IPv6 block. The subnetting strategy and dual-stack configuration are valid and meet the requirements.
Option C: Enable sharing of resources within the organization by using AWS Resource Access Manager (AWS RAM). Create a resource share in the networking account, select the provisioned subnets, and share the provisioned subnets with the target workload account. Use the workload account to accept the resource share through AWS RAM.
- Analysis: This option focuses on sharing subnets between accounts using AWS RAM, which is useful for allowing multiple teams or accounts to access shared resources. However, while sharing subnets can be part of a multi-account strategy, this does not directly address the need for configuring the VPC with IPv4 and IPv6 or setting up internet connectivity.
- Why Rejected: While this is a valid approach for sharing resources, it does not directly meet the need for configuring the VPC and internet connectivity. It's more about resource sharing than VPC setup.
Option D: Enable sharing of resources within the organization by using AWS Resource...
Author: Kai · Last updated May 16, 2026
A company is using third-party firewall appliances to monitor and inspect traffic on premises. The company wants to use the same model on AWS. The Company has a single VPC with an internet gateway. The VPC has a fleet of web servers that run on Amazon EC2 instances that are managed by an Auto Scaling group.
The company's network team needs to work with the security team to establish inline inspection of all packets that are sent to and from t...
To implement the solution of inline inspection of all packets sent to and from the web servers, while scaling alongside the fleet of firewall appliances, the network team needs to consider several key factors:
1. Gateway Load Balancer (GLB) Setup: The Gateway Load Balancer is crucial because it allows the network team to deploy and manage third-party appliances (like firewall appliances) in a way that can scale automatically based on traffic. It acts as a traffic manager and routes the network traffic to the firewall appliances.
2. VPC Routing: Proper route management is critical for directing traffic to and from the firewall appliances for inspection, especially for traffic going to/from the internet and the web servers.
3. Security Groups and Health Checks: Security groups for the firewall appliances ensure that only the right traffic flows to the firewall, and health checks ensure that the firewall appliances are functioning correctly.
Explanation of each option:
Option A: Create a new VPC, and deploy a fleet of firewall appliances. Create a Gateway Load Balancer. Add the firewall appliances as targets.
- This option suggests creating a completely new VPC, which is unnecessary. The company already has a VPC set up. Recreating a new VPC would add complexity and cost.
- Rejected: The goal is to deploy within the existing VPC.
Option B: Create a security group for use with the firewall appliances, and allow port 443. Allow a port for the Gateway Load Balancer to perform health checks.
- Port 443 is typically used for HTTPS traffic, but the firewall appliances will likely need to inspect all traffic, not just HTTPS. More appropriate ports (like 6081) should be considered for the health check and other necessary communication between the firewall appliances and the GLB.
- Rejected: Port 443 is not the best choice for firewall appliances and their health checks.
Option C: Create a security group for use with the firewall appliances, and allow port 6081. Allow a port for the Gateway Load Balancer to perform health checks.
- Port 6081 is typically used for the communication between the Gateway Load Balancer and the firewall appliances. This is an appropriate step, as it will enable the firewall appliances to respond to the health checks from the GLB.
- Accepted: This ensures the firewall appliances are reachable by the Gateway Load Balancer for health checks a...
Author: StarlightBear · Last updated May 16, 2026
A financial company offers investment forecasts and recommendations to authorized users through the internet. All the services are hosted in the AWS Cloud. A new compliance requirement states that all the internet service traffic from any host must be logged and retained for 2 years. In its development AWS accounts, the company has designed, tested, and verified a solution that uses Amazon VPC Traffic Mirroring with a Network Load Balancer (NLB) as the traffic mirror target. While the solution runs in one AWS account, the solution mirrors the traffic to another AWS account.
A network engineer notice...
To troubleshoot the issue where not all traffic is mirrored in the production environment, we need to consider key factors, such as network performance, configuration of services, and potential misconfigurations in the solution.
Explanation of each option:
Option A: The security groups are misconfigured on the production AWS account that hosts the company’s services.
- Security groups can control inbound and outbound traffic. If the security groups on the production environment are misconfigured, it could block traffic that should be mirrored or cause incomplete traffic mirroring.
- However, security group misconfigurations typically block traffic altogether, rather than causing random issues with some traffic being mirrored. This would likely lead to consistent, rather than intermittent, failures.
- Rejected: This is less likely to be the issue, as security groups would more likely prevent traffic entirely, not cause random drops.
Option B: The Amazon EC2 instance that is being monitored cannot handle the extra traffic that Traffic Mirroring has introduced.
- Traffic Mirroring introduces additional network traffic for monitoring, and if the EC2 instance cannot handle the extra load, it could cause issues with the mirroring.
- If the instance's network capacity is exceeded, the mirrored traffic could be dropped or fail to be sent to the target (NLB). This could explain why the issue appears random, as the instance might be able to handle the traffic at some times but not others.
- Accepted: This is a plausible explanation, as the traffic mirroring can introduce significant overhead that might exceed the capacity of the EC2 instance.
Option C: The IAM policy that allows the creation of traffic mirror sessions is misconfigured.
- The IAM policy governs who can create or modify traffic mirror sessions. If the IAM policy is misconfigured, it could cause issues with creating or maintaining the sessions needed to mirror the traffic.
- However, this is not directly related to intermittent issues with traffic mirroring i...
Author: ThunderBear · Last updated May 16, 2026
A company has a VPC in the AWS Cloud. The company recently acquired a competitor that also has a VPC the AWS Cloud. A network engineer discovers an IP address overlap between the two VPCs. Both VPCs require access to an AWS Marketplace partner service.
Whi...
To address the IP address overlap between the two VPCs and ensure interoperability with the AWS Marketplace partner service, the solution must provide a way for both VPCs to communicate with each other while also connecting securely to the partner service. The solution should also handle the potential IP address conflicts between the VPCs, which will need to be managed carefully.
Explanation of each option:
Option A: Configure VPC peering with static routing between the VPCs. Configure an AWS Site-to-Site VPN connection with static routing to the partner service.
- VPC Peering allows traffic to flow between two VPCs, but it has limitations when IP address ranges overlap. Since the two VPCs have overlapping IP addresses, this would create routing issues, making VPC peering unsuitable.
- AWS Site-to-Site VPN to connect to the partner service is fine, but VPC peering cannot be used effectively with overlapping IPs, and this solution would not solve the problem of address conflicts.
- Rejected: VPC peering is not feasible due to the IP address overlap, and this would result in routing problems.
Option B: Configure a NAT gateway in the VPCs. Configure default routes in each VPC to point to the local NAT gateway. Attach each NAT gateway to a transit gateway. Configure an AWS Site-to-Site VPN connection with static routing to the partner service.
- NAT Gateway allows instances in private subnets to access the internet, but it does not resolve IP address overlap between VPCs.
- Transit Gateway can facilitate routing between VPCs, but the main issue here is the IP address overlap, which would still cause routing issues between the VPCs.
- Rejected: While Transit Gateway can help route traffic between VPCs, the solution does not address the key issue of overlapping IP addresses, which would lead to routing conflicts.
Option C: Configure AWS PrivateLink to facilitate connectivity between the VPCs and the partner service. Use the DNS name that is created with the associated interface endpoints to route traffic between the VPCs and the pa...
Author: Sophia · Last updated May 16, 2026
A company uses the us-east-1 Region and the ap-south-1 Region for its business units (BUs). The BUS are named BU-1 and BU-Z. For each BU, there are two VPCs in us-east-1 and one VPC in ap-south-1.
Because of workload isolation requirements, resources can communicate within the same BU but cannot communicate with resources in the other BU. The co...
Key Considerations:
The company has two main requirements:
1. Workload Isolation: Resources within the same Business Unit (BU) should be able to communicate, but resources from different BUs should not be able to communicate.
2. Expansion and Operational Efficiency: The solution should be scalable as the company adds more BUs and expands into additional AWS regions.
Analysis of Each Option:
Option A: Configure an AWS Cloud WAN network that operates in the required Regions. Attach all BU VPCs to the AWS Cloud WAN core network. Update the AWS Cloud WAN segment actions to configure new routes to deny traffic between the different BU segments.
- AWS Cloud WAN is designed to connect multiple VPCs across regions and enforce global network policies. This option suggests attaching all BU VPCs to a central AWS Cloud WAN core network and using segment actions to deny traffic between BU segments.
- This solution is feasible but relies on manually configuring routes and denying traffic at the core network level, which might become cumbersome as the number of BUs grows, and it introduces complexity in managing route updates.
- Rejected: While technically possible, it lacks the simplicity and operational efficiency of other options, especially when expanding.
Option B: Configure a transit gateway in each Region. Configure peering between the transit gateways. Attach the BU VPCs to the transit gateway in the corresponding Region. Configure the transit gateway and VPC route tables to isolate traffic between BU VPCs.
- Transit Gateways (TGWs) are often used for connecting multiple VPCs within a region and between regions. This option suggests setting up a Transit Gateway per region and peering them across regions. Then, VPCs are attached to their corresponding TGWs, with route tables configured for isolation.
- While this approach can work, managing multiple TGWs and peering them across regions can be complex, especially when the company expands to more regions and adds more BUs. Configuring and maintaining VPC route tables and TGW route tables could add operational overhead.
- Rejected: This solution is functional but involves more manual configuration and scaling challenges, making it le...
