Amazon Exam Practice Questions - Page 93

Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company has deployed a web application on AWS. The web application uses an Application Load Balancer (ALB) across multiple Availability Zones. The targets of the ALB are AWS Lambda functions. The web application also uses Amazon CloudWatch metrics for monitoring. Users report that parts of the web application are not loading properly. A network engineer needs to troublesho...

Key Factors for Consideration: - Troubleshooting the ALB Errors: The goal is to determine which errors the ALB is receiving. Access logs can help identify issues like 4xx or 5xx responses from targets, which will provide insights into what is going wrong. - Log Storage and Querying: Efficient ways to store and query ALB logs are crucial for troubleshooting. The solution should allow the network engineer to easily view and analyze the logs for error patterns. - Operational Simplicity: The solution should be easy to set up and query without introducing unnecessary complexity, particularly as the company is troubleshooting an issue in production. Evaluation of Options: A) Send the logs to Amazon CloudWatch Logs. Review the ALB logs in CloudWatch Insights to determine which error messages the ALB is receiving. - Pros: - CloudWatch Logs and CloudWatch Logs Insights offer a powerful way to store and query logs in real-time. CloudWatch Insights allows for interactive querying, which can help the network engineer analyze logs and identify errors quickly. - This solution provides a streamlined approach for troubleshooting within AWS and doesn’t require additional tools. - Cons: - While CloudWatch Logs Insights is powerful, querying large log volumes can become expensive if not managed properly. However, this is less of a concern for typical troubleshooting tasks. - Scenario: This is the most efficient and integrated solution within AWS, leveraging CloudWatch's querying capabilities directly. B) Configure the Amazon S3 bucket destination. Use Amazon Athena to determine which error messages the ALB is receiving. - Pros: - Storing ALB logs in Amazon S3 and querying with Amazon Athena can provide fast and scalable querying of large datasets. - Athena is designed to query large volumes of data quickly, making it ideal for large-scale log analysis. - Cons: - This approach introduces more complexity because the network engineer would need to set up the S3 bucket as a destination for the ALB logs, and Athena would need to be configured to query those logs. - The added setup could lead to more overhead compared to using CloudWatch Logs Insights. - Scenario: This option is useful for handling very larg...

Author: Isabella · Last updated May 16, 2026

A company is planning to use Amazon S3 to archive financial data. The data is currently stored in an on-premises data center. The company uses AWS Direct Connect with a Direct Connect gateway and a transit gateway to connect to the on-premises data center. The data cannot b...

Key Factors for Consideration: - Encryption in Transit: The solution must ensure that data is encrypted during transfer from the on-premises data center to Amazon S3, as it cannot be transported over the public internet. - Direct Connect and Transit Gateway: The company is using AWS Direct Connect with a Direct Connect gateway and a transit gateway, which indicates that a private, low-latency, and high-throughput connection is required. - Data Access Restrictions: The data cannot be sent over the public internet, so any solution using internet-based connections (such as a public VIF or internet VPN) would not meet the requirements. - S3 Access: The solution must involve Amazon S3 access, which should be done securely and efficiently, without relying on public internet access. Evaluation of Options: A) Create a Direct Connect public VIF. Set up an IPsec VPN connection over the public VIF to access Amazon S3. Use HTTPS for communication. - Pros: - IPsec VPN would encrypt the data in transit. - HTTPS can be used for secure communication to Amazon S3. - Cons: - The Direct Connect public VIF is designed for accessing AWS public services over the public internet. It does not provide private access to Amazon S3, which is necessary in this case. Public VIFs are generally used for accessing services like AWS public APIs, not private resources like S3 over a private connection. - This approach violates the requirement of not using the public internet for data transfer, even though the VPN provides encryption. - Rejection Reason: The use of a public VIF does not align with the need for private data transfer, especially when dealing with sensitive data. B) Create an IPsec VPN connection over the transit VIF. Create a VPC and attach the VPC to the transit gateway. In the VPC, provision an interface VPC endpoint for Amazon S3. Use HTTPS for communication. - Pros: - An IPsec VPN connection would encrypt the traffic, and using a VPC endpoint ensures that traffic to S3 stays within the AWS private network, avoiding the public internet. - HTTPS ensures secure communication. - Cons: - The use of a transit VIF is not necessary when you already have a Direct Connect connection that can be used with a private VIF to achieve the same goal. The ...

Author: Leah · Last updated May 16, 2026

A company is using Amazon Route 53 Resolver DNS Firewall in a VPC to block all domains except domains that are on an approved list. The company is concerned that if DNS Firewall is unresponsive, resources in the VPC might be affected if the network cannot resolve any DNS queries. To maintain application service level agreements, the company needs DNS queries to continue ...

In this scenario, the company wants to ensure that DNS queries continue to resolve even if the Route 53 Resolver DNS Firewall is unresponsive. The key issue here is how to handle situations when the DNS Firewall fails to respond, without affecting the overall DNS resolution process within the VPC. Evaluating the options: A) Update the DNS Firewall VPC configuration to disable fail open for the VPC. - Fail open means that if the DNS Firewall is unavailable, queries are allowed to proceed without blocking. Disabling fail open would mean that if the DNS Firewall is unresponsive, DNS queries could be blocked, causing DNS resolution issues. This is the opposite of what the company wants because it would affect application service levels during DNS Firewall failure. - Rejected because it would not provide DNS resolution continuity if the DNS Firewall fails. B) Update the DNS Firewall VPC configuration to enable fail open for the VPC. - Enabling fail open ensures that if the DNS Firewall is unresponsive, DNS queries will still resolve without interruption. The DNS Firewall will not block queries, allowing the system to continue functioning normally. This ensures that application service level agreements (SLAs) are maintained, even in the case of DNS Firewall unavailability. - Selected option becau...

Author: Amira · Last updated May 16, 2026

A company is migrating an existing application to a new AWS account. The company will deploy the application in a single AWS Region by using one VPC and multiple Availability Zones. The application will run on Amazon EC2 instances. Each Availability Zone will have several EC2 instances. The EC2 instances will be deployed in private subnets. The company's clients will connect to the application by using a web browser with the HTTPS protocol. Inbound connections must be distributed across the Availability Zones and EC2 instances. All connections from the same client s...

Let's analyze the requirements and the available options. Requirements: 1. Web browser HTTPS protocol: Clients will connect to the application using HTTPS. 2. Inbound connection distribution: The traffic must be distributed across multiple Availability Zones and EC2 instances. 3. Session persistence: All connections from the same client session must connect to the same EC2 instance (sticky sessions). 4. End-to-end encryption: The SSL certificate for the application must be used to ensure encryption from the client to the application. 5. Private subnets: The EC2 instances are in private subnets, so the solution must be able to route traffic to the EC2 instances in the private subnet while maintaining security and compliance. Evaluating the Options: A) Create a Network Load Balancer. Create a target group. Set the protocol to TCP and the port to 443 for the target group. Turn on session affinity (sticky sessions). Register the EC2 instances as targets. Create a listener. Set the protocol to TCP and the port to 443 for the listener. Deploy SSL certificates to the EC2 instances. - Issue: A Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP), which doesn’t support the ability to terminate SSL/TLS at the load balancer itself. In this case, SSL termination must occur at the EC2 instances (i.e., each EC2 instance would need its own SSL certificate). - Rejected: While it does distribute traffic across Availability Zones and supports sticky sessions, it doesn’t allow for SSL termination at the load balancer. The company requires end-to-end encryption, and the SSL certificate should be managed centrally, not on individual EC2 instances. B) Create an Application Load Balancer. Create a target group. Set the protocol to HTTP and the port to 80 for the target group. Turn on session affinity (sticky sessions) with an application-based cookie policy. Register the EC2 instances as targets. Create an HTTPS listener. Set the default action to forward to the target group. Use AWS Certificate Manager (ACM) to create a certificate for the listener. - Issue: The target group is set to HTTP and port 80, which would mean that the connection between the load balancer and the EC2 instances is not encrypted. The client traffic is encrypted over HTTPS, but the communication from the load balancer to the EC2 instances would be unencrypted (HTTP), which does not meet the requirement for end-to-end encryption. - Re...

Author: FrozenWolf2022 · Last updated May 16, 2026

A company is developing an application in which IoT devices will report measurements to the AWS Cloud. The application will have millions of end users. The company observes that the IoT devices cannot support DNS resolution. The company needs to implement an Amazon EC2 Auto Scaling solution so that the IoT de...

Let's analyze the requirements and the available options carefully. Key Requirements: 1. No DNS resolution: IoT devices cannot resolve DNS names, so they need to connect directly to IP addresses. 2. EC2 Auto Scaling: The application should use EC2 Auto Scaling to handle fluctuating workloads. 3. Cost-effectiveness: The solution should be as cost-effective as possible while meeting the other requirements. 4. IoT devices: The devices need to connect directly to an IP address. Evaluating the Options: A) Use an Application Load Balancer (ALB)-type target group for a Network Load Balancer (NLB). Create an EC2 Auto Scaling group. Attach the Auto Scaling group to the ALB. Set up the IoT devices to connect to the IP addresses of the NLB. - Issue: This solution is a bit complex because it involves using an ALB as the target for an NLB. The ALB operates at Layer 7 (HTTP/HTTPS), while the NLB operates at Layer 4 (TCP/UDP). ALB is designed for HTTP(S) traffic, which isn't necessary for IoT devices in this case. Additionally, the IoT devices need to connect directly to an IP address, so this configuration wouldn't be the most optimal or cost-effective. - Rejected: This solution is unnecessarily complex and may incur additional costs due to the use of an ALB in combination with an NLB. B) Use an AWS Global Accelerator accelerator with an Application Load Balancer (ALB) endpoint. Create an EC2 Auto Scaling group. Attach the Auto Scaling group to the ALB. Set up the IoT devices to connect to the IP addresses of the accelerator. - Issue: While Global Accelerator provides static IP addresses and improves global traffic routing, using it with an ALB introduces unnecessary complexity. ALB is suited for HTTP/HTTPS traffic, which is not required for IoT devices in this case. IoT devices don’t need the global routing features provided by Global Accel...

Author: NebulaEagle11 · Last updated May 16, 2026

A company has deployed a new web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are in an Amazon EC2 Auto Scaling group. Enterprise customers from around the world will use the application. Employees of these enterprise customers will connect to the application over HTTPS from office locations. The company must configure firewalls to allow outbound traffic to only approved IP addresses. The employees o...

Let's break down the requirements and evaluate each option carefully: Key Requirements: 1. Enterprise customers from around the world: The application needs to be accessible globally, and access should be optimized for low latency. 2. Employees of these enterprise customers must access the application via HTTPS: Secure connections over HTTPS are a requirement. 3. Outbound traffic must be restricted to approved IP addresses: This implies the need for controlled outbound access, likely using firewalls and security groups. 4. Minimize latency: The solution must optimize access times for employees connecting from various geographical locations. Evaluating the Options: A) Create a new Network Load Balancer (NLB). Add the ALB as a target of the NLB. - Issue: This option introduces a Network Load Balancer (NLB) in front of the existing Application Load Balancer (ALB). While NLB is optimized for high-throughput and low-latency TCP traffic (Layer 4), adding NLB here wouldn't reduce latency significantly for HTTPS traffic (Layer 7). In fact, this setup could add unnecessary complexity without providing any tangible performance benefits. The ALB itself is already capable of handling HTTPS traffic, and routing it through an NLB would likely create an extra hop and increase complexity without a clear benefit. - Rejected: This is an unnecessary architecture that doesn't meet the goal of minimizing latency for HTTPS traffic. B) Create a new Amazon CloudFront distribution. Set the ALB as the distribution's origin. - Correct choice: Amazon CloudFront is a content delivery network (CDN) that caches content at edge locations around the world. This reduces latency for users by serving requests from the nearest edge location. When CloudFront is used in front of an ALB, it can improve the performance of the web application for global users. CloudFront will cache static content and route dynamic content through the ALB, ensuring secure HTTPS access. Additionally, CloudFront allows fine-grained control over outbound traffic and can enforce specific security policies. It optimizes latency and improves user experience for glo...

Author: StarryEagle42 · Last updated May 16, 2026

A company has hundreds of VPCs on AWS. All the VPCs access the public endpoints of Amazon S3 and AWS Systems Manager through NAT gateways. All the traffic from the VPCs to Amazon S3 and Systems Manager travels through the NAT gateways. The company's network engineer must centralize access to these services an...

Key Requirements: 1. Centralize access: The goal is to centralize access to Amazon S3 and AWS Systems Manager for all VPCs, which currently rely on NAT gateways. 2. Eliminate public endpoints: The need to eliminate the use of public endpoints for S3 and Systems Manager and route traffic privately. 3. Minimize operational overhead: The solution should minimize the need for manual intervention, complexity, or extensive configuration after the initial setup. Evaluating the Options: A) Create a central egress VPC that has private NAT gateways. Connect all the VPCs to the central egress VPC by using AWS Transit Gateway. Use the private NAT gateways to connect to Amazon S3 and Systems Manager by using private IP addresses. - Issue: This option would centralize the egress traffic through a central egress VPC with NAT gateways. However, the requirement specifies eliminating the use of public endpoints, and the use of private NAT gateways still requires public traffic routing, which may not fully satisfy the requirement of avoiding public endpoints. - Rejected: This solution still relies on NAT gateways, which means public traffic would still be used for S3 and Systems Manager access, which doesn't fully meet the goal of removing public endpoint usage. B) Create a central shared services VPC. In the central shared services VPC, create interface VPC endpoints for Amazon S3 and Systems Manager to access. Ensure that private DNS is turned off. Connect all the VPCs to the central shared services VPC by using AWS Transit Gateway. Create an Amazon Route 53 forwarding rule for each interface VPC endpoint. Associate the forwarding rules with all the VPCs. Forward DNS queries to the interface VPC endpoints in the shared services VPC. - Issue: This option requires using Route 53 forwarding rules, which adds complexity in managing DNS across all VPCs. The operational overhead of maintaining forwarding rules and ensuring correct DNS resolution can be burdensome. - Rejected: The need for managing Route 53 forwarding rules across multiple VPCs introduces unnecessary operational complexity, which could lead to additional overhead. C) Create a central shared services VPC. In the central shared services VPC, create interface VPC endpoints for Amazon S3 and Systems Manager to access. Ensure that private DNS i...

Author: Daniel · Last updated May 16, 2026

A company manages resources across VPCs in multiple AWS Regions. The company needs to connect to the resources by using its internal domain name. A network engineer needs to apply the aws.example.com DNS...

To meet the company's requirement of connecting to resources using the internal domain name (aws.example.com) across multiple AWS Regions, the network engineer must ensure that DNS resolution for the domain is correctly configured for each Region and its associated VPCs. Let’s go through each option and analyze which one best satisfies the requirement. Option A: Create an Amazon Route 53 private hosted zone for aws.example.com in each Region that has resources. Associate the private hosted zone with that Region's VPC. In the appropriate private hosted zone, create DNS records for the resources in each Region. - Explanation: This option suggests creating a separate private hosted zone for aws.example.com in each Region. This means that the DNS records for resources in each Region will be isolated to that specific Region’s VPC. This approach ensures that the DNS suffix (aws.example.com) can be applied consistently across multiple Regions, but each Region’s VPC will have its own set of DNS records. This is a solid choice for managing DNS records per Region. - Why selected: This option allows for fine-grained DNS management and works well when managing resources in multiple Regions, with the ability to have region-specific records. Each VPC will resolve internal resources based on the hosted zone associated with it. - Scenario: Ideal when the company wants to manage Region-specific DNS records independently and avoid any potential conflicts between regions. Option B: Create one Amazon Route 53 private hosted zone for aws.example.com. Configure the private hosted zone to allow zone transfers with every VPC. - Explanation: This option suggests creating a single hosted zone for aws.example.com and using zone transfers to share the DNS records across multiple VPCs. While zone transfers are used to synchronize DNS records, Route 53 doesn't support zone transfers across VPCs natively. Instead, each VPC can have its own set of DNS records for proper name resolution. This option lacks an appropriate method for cross-VPC DNS resolution, as Route 53 doesn’t support zone transfers in this context. - Why rejected: AWS Route 53 does not allow zone transfers between VPCs in the way this option assumes. This solution would not work as expected. - Scenario: This could be a valid approach in on-premises DNS configurations, but it's not suitable for AWS VPCs where Route 53 handles DNS management independently in each VPC. ...

Author: MysticJaguar44 · Last updated May 16, 2026

An insurance company is planning the migration of workloads from its on-premises data center to the AWS Cloud. The company requires end-to-end domain name resolution. Bi-directional DNS resolution between AWS and the existing on-premises environments must be established. The workloads will be migrated into multiple VPCs. The workload...

To establish bi-directional DNS resolution between AWS and the on-premises environment, the solution needs to handle DNS resolution both ways: from AWS to on-premises and from on-premises to AWS. Additionally, it must cater to workloads being migrated at different times and support multiple VPCs. Let's break down each option: Option A: Configure a private hosted zone for each application VPC, and create the requisite records. Create a set of Amazon Route 53 Resolver inbound and outbound endpoints in an egress VPC. Define Route 53 Resolver rules to forward requests for the on-premises domains to the on-premises DNS resolver. Associate the application VPC private hosted zones with the egress VPC, and share the Route 53 Resolver rules with the application accounts by using AWS Resource Access Manager. Configure the on-premises DNS servers to forward the cloud domains to the Route 53 inbound endpoints. - Explanation: This option uses private hosted zones for each VPC, which is appropriate for internal AWS DNS resolution. It also sets up inbound and outbound Route 53 Resolver endpoints, ensuring bidirectional DNS resolution. The rules are configured to forward DNS requests between AWS and on-premises. The configuration includes sharing the Route 53 Resolver rules using AWS Resource Access Manager (RAM), which helps manage permissions across multiple AWS accounts. - Why selected: This option is ideal because it effectively manages DNS resolution between AWS and on-premises, especially as workloads are migrated incrementally. The use of private hosted zones ensures that DNS queries for internal AWS resources are resolved correctly, and the resolver endpoints facilitate bi-directional DNS resolution. - Scenario: Perfect for a phased migration where workloads are being migrated across multiple VPCs and need both intra-cloud and cross-cloud resolution. Option B: Configure a public hosted zone for each application VPC, and create the requisite records. Create a set of Amazon Route 53 Resolver inbound and outbound endpoints in an egress VPC. Define Route 53 Resolver rules to forward requests for the on-premises domains to the on-premises DNS resolver. Associate the application VPC private hosted zones with the egress VPC. and share the Route 53 Resolver rules with the application accounts by using AWS Resource Access Manager. Configure the on-premises DNS servers to forward the cloud domains to the Route 53 inbound endpoints. - Explanation: This option involves configuring public hosted zones for the application VPCs. Public hosted zones are typically used for DNS records that are accessible over the internet, not for internal AWS resources. This is not suitable for the requirement of end-to-end internal domain resolution between AWS and on-premises. - Why rejected: Public hosted zones are not designed for internal, private DNS resolution between VPCs and on-premises environments. Using public hosted zones would expose internal DNS records to the internet, which contradicts the requirement for secure, internal DNS resolution. - Scenario: Public hosted zones can be used for external-facing services but not for private ...

Author: Amira · Last updated May 16, 2026

A global company runs business applications in the us-east-1 Region inside a VPC. One of the company's regional offices in London uses a virtual private gateway for an AWS Site-to-Site VPN connection tom the VPC. The company has configured a transit gateway and has set up peering between the VPC and other VPCs that various departments in the company use. Employees a...

To address the latency issue that employees in the London office are experiencing when connecting to the business applications in the US East (us-east-1) Region, we need to evaluate how to improve network performance, specifically in terms of reducing latency. Let's analyze the different options: Option A: Create a new Site-to-Site VPN connection. Set the transit gateway as the target gateway. Enable acceleration on the new Site-to-Site VPN connection. Update the VPN device in the London office with the new connection details. - Explanation: This option suggests creating a new Site-to-Site VPN connection with the transit gateway as the target and enabling VPN acceleration. This approach can improve latency by leveraging AWS VPN acceleration, which reduces overhead and optimizes data transmission. However, it requires the setup of a new connection, which might introduce additional configuration work and complexity, particularly if the existing VPN connection is already functional. - Why rejected: While VPN acceleration could help with reducing latency, creating an entirely new VPN connection is unnecessary if the existing connection can be optimized or modified. Creating a new connection would involve extra administrative effort and may cause temporary disruption during the switch. Option B: Modify the existing Site-to-Site VPN connection by setting the transit gateway as the target gateway. Enable acceleration on the existing Site-to-Site VPN connection. - Explanation: This option modifies the existing Site-to-Site VPN connection by directing it through the transit gateway and enabling VPN acceleration. The transit gateway can be a more efficient way to route traffic between VPCs and other networks, and VPN acceleration would help optimize the connection. This solution directly addresses the latency problem and is much simpler than creating a new connection. - Why selected: This is the most efficient solution because it leverages the existing VPN connection, applies acceleration, and routes traffic more efficiently via the transit gateway. It avoids the need to create a new connection, thus minimizing configuration overhead. This approach optimizes the current setup without adding unnecessary complexity. - Scenario: Id...

Author: Stella · Last updated May 16, 2026

A company has a hybrid cloud environment. The company's data center is connected to the AWS Cloud by an AWS Direct Connect connection. The AWS environment includes VPCs that are connected together in a hub-and-spoke model by a transit gateway. The AWS environment has a transit VIF with a Direct Connect gateway for on-premises connectivity. The company has a hybrid DNS model. The company has configured Amazon Route 53 Resolver endpoints in the hub VPC to allow bidirectional DNS traffic flow. The company is running a backend application in one of the VPCs. The company uses a message-oriented architecture and employs Amazon Simple Queue Service (Amazon SQS) to receive messages from other applications over a private network. A network engineer wants to use an interface VPC endpoint...

In this scenario, the company wants to ensure that client applications can resolve the DNS for the Amazon Simple Queue Service (SQS) interface endpoint across multiple VPCs and from on-premises. The company has a hybrid DNS model and uses a transit gateway for VPC interconnectivity. The network engineer is tasked with setting up DNS resolution for the SQS interface endpoint. Let's go over the steps needed and why some options are selected while others are rejected. Key Requirements: - The SQS interface endpoint should be accessible from multiple VPCs and on-premises. - DNS resolution should be consistent across all environments (AWS and on-premises). - The interface endpoint should be accessed using a private DNS name, not a public one, for internal resolution. Option A: Create the interface endpoint for Amazon SQS with the option for private DNS names turned on. - Explanation: This option ensures that the private DNS name for the interface endpoint is automatically created. The private DNS name will resolve to the correct IP addresses of the endpoint for all the VPCs that are associated with the endpoint’s private hosted zone. - Why selected: Turning on the private DNS option allows the interface endpoint to be accessed via a private DNS name, which is essential for ensuring internal communication within VPCs. This eliminates the need for manual DNS configuration and leverages the automatic creation of DNS records. - Scenario: Ideal in most cases when the goal is seamless, private access to SQS through a private DNS name in AWS environments. Option B: Create the interface endpoint for Amazon SQS with the option for private DNS names turned off. - Explanation: Turning off the private DNS name means that the interface endpoint will not automatically create DNS records for the service. Instead, the DNS records need to be manually configured. - Why rejected: This option is unnecessary because the goal is to use a private DNS for internal resolution across multiple VPCs and on-premises. Manually configuring DNS records would add complexity and extra steps for this setup. - Scenario: Could be used for specific cases where private DNS records are not required, but it complicates the architecture without offering any advantages in this case. Option C: Manually create a private hosted zone for sqs.us-east-1.amazonaws.com. Add necessary records that point to the interface endpoint. Associate the private hosted zones with other VPCs. - Explanation: This option involves manually creating a private hosted zone for `sqs.us-east-1.amazonaws.com` and associating it with each VPC. The engineer would then need to manually add the DNS records pointing to the interface endpoint. - Why rejected: While it could work, manually creating and managing private hosted zones and DNS records adds unnecessary complexity. The automatic creation of DNS records when private DNS is enabled is a simpler and more manageable solution. - Scenario: Useful in specific cases where custom DNS configurations are needed, but ...

Author: Oliver · Last updated May 16, 2026

A company's network engineer builds and tests network designs for VPCs in a development account. The company needs to monitor the changes that are made to network resources and must ensure strict compliance with network security policies. The company also nee...

The company needs to monitor changes made to network resources, ensure compliance with network security policies, and have access to historical configurations. Let's evaluate each option based on these requirements: Option A: Create an Amazon EventBridge (Amazon CloudWatch Events) rule with a custom pattern to monitor the account for changes. Configure the rule to invoke an AWS Lambda function to identify noncompliant resources. Update an Amazon DynamoDB table with the changes that are identified. - Explanation: This option involves using EventBridge (CloudWatch Events) to detect changes, invoking a Lambda function to check for noncompliant resources, and storing the results in DynamoDB. While this approach can monitor real-time changes, it doesn't directly provide historical configuration data or automate compliance enforcement. The Lambda function would need to be programmed to detect and handle noncompliant configurations, and this process requires significant custom code to ensure the monitoring and compliance checks are robust and comprehensive. - Why rejected: This solution requires a lot of custom setup and coding. It doesn't inherently provide historical configurations or offer built-in compliance management, which is crucial for ensuring strict network security policies. Option B: Create custom metrics from Amazon CloudWatch logs. Use the metrics to invoke an AWS Lambda function to identify noncompliant resources. Update an Amazon DynamoDB table with the changes that are identified. - Explanation: Similar to Option A, this option proposes using CloudWatch logs to create custom metrics, which then trigger a Lambda function to identify noncompliant resources. The results are then recorded in DynamoDB. - Why rejected: While this solution focuses on monitoring, it still requires significant custom development to identify noncompliant resources and lacks an easy way to store historical configurations. Custom metrics may not be the most efficient method for managing and tracking configuration compliance compared to native AWS services. Option C: Record the current state of network resources by using AWS Config. Create rules that reflect the desired configuration settings. Set remediation for non...

Author: RadiantPhoenixX · Last updated May 16, 2026

A company is migrating an application from on premises to AWS. The company will host the application on Amazon EC2 instances that are deployed in a single VPC. During the migration period, DNS queries from the EC2 instances must be able to resolve names of on-premises servers. The migration is expected to take 3 months After the 3-month migration period, the resol...

To meet the requirement of enabling DNS resolution for on-premises servers from Amazon EC2 instances in AWS during a migration period of 3 months, the solution needs to be cost-effective, simple, and support seamless DNS resolution. Let's evaluate each option and its feasibility: Option A: Set up an AWS Site-to-Site VPN connection between on-premises and AWS. Deploy an Amazon Route 53 Resolver outbound endpoint in the Region that is hosting the VPC. - Why it works: A Site-to-Site VPN connection provides secure communication between on-premises and AWS, allowing traffic (including DNS queries) to traverse this connection. The Route 53 Resolver outbound endpoint in AWS can forward DNS queries from the EC2 instances to the on-premises DNS servers. - Key Factor: This solution fits well because it leverages an existing VPN connection to resolve DNS queries from AWS EC2 instances to on-premises DNS servers. It is also simple to implement and decommission after the 3-month migration period. - Why it’s preferred: The VPN connection is cost-effective for temporary use, and setting up the outbound resolver is straightforward. Option B: Set up an AWS Direct Connect connection with a private VIF. Deploy an Amazon Route 53 Resolver inbound endpoint and a Route 53 Resolver outbound endpoint in the Region that is hosting the VPC. - Why it works: Direct Connect is a dedicated network connection that can offer high performance and low latency. The Route 53 Resolver inbound and outbound endpoints would allow DNS resolution both ways (on-premises to AWS and AWS to on-premises). - Why it’s rejected: Direct Connect is usually more expensive and complex to set up compared to a VPN, and it’s typically used for long-term or high-perform...

Author: Lina Zhang · Last updated May 16, 2026

A company is hosting an application on Amazon EC2 instances behind an Application Load Balancer. The instances are in an Amazon EC2 Auto Scaling group. Because of a recent change to a security group, external users cannot access the application. A network engineer needs to prevent this downtime from happening again. The netwo...

The goal is to prevent downtime caused by noncompliant changes to security groups and ensure automatic remediation when such changes occur. Let's evaluate each option in terms of its effectiveness and suitability: Option A: Configure Amazon GuardDuty to detect inconsistencies between the desired security group configuration and the current security group configuration. Create an AWS Systems Manager Automation runbook to remediate noncompliant security groups. - Why it’s rejected: Amazon GuardDuty primarily focuses on detecting security threats such as compromised instances, unusual API activity, and other suspicious behavior. However, GuardDuty is not designed to specifically detect configuration changes (such as inconsistencies in security group settings). It would not be an appropriate tool to monitor and correct noncompliant changes to security groups. Option B: Configure an AWS Config rule to detect inconsistencies between the desired security group configuration and the current security group configuration. Configure AWS OpsWorks for Chef to remediate noncompliant security groups. - Why it’s rejected: AWS Config is indeed the correct tool to monitor security group configurations. However, AWS OpsWorks for Chef is an infrastructure automation tool primarily designed for managing configuration of applications and servers, not specifically for managing or remediating security group configurations. It would introduce unnecessary complexity when simpler and more direct options like AWS Systems Manager can handle the remediation. Option C: Configure Amazon GuardDuty to detect inconsistencies between the desired security group configuration and the current...

Author: Zain · Last updated May 16, 2026

A company is deploying third-party firewall appliances for traffic inspection and NAT capabilities in its VPC. The VPC is configured with private subnets and public subnets. The company needs to deploy the firewall appliances ...

The goal is to deploy third-party firewall appliances in a cost-effective manner while ensuring traffic inspection and NAT capabilities. Let's evaluate each option to determine the best fit based on cost, simplicity, and the specific requirements of using firewall appliances behind a load balancer. Option A: Deploy a Gateway Load Balancer with the firewall appliances as targets. Configure the firewall appliances with a single network interface in a private subnet. Use a NAT gateway to send the traffic to the internet after inspection. - Why it works: The Gateway Load Balancer (GWLB) is specifically designed for use with virtual appliances such as firewalls. By configuring the firewall appliances with a single network interface in a private subnet, the architecture allows the GWLB to direct traffic to the firewall appliances for inspection. After inspection, a NAT gateway can be used to send the traffic to the internet. - Cost Efficiency: Using a single network interface in the private subnet reduces complexity and cost, as there is no need for additional resources such as a second network interface for each firewall appliance. The GWLB allows for scalable and cost-effective traffic inspection. - Why it’s preferred: This option is the most cost-effective because it uses a single network interface and relies on the NAT gateway for internet traffic. The GWLB integrates well with third-party appliances and simplifies routing without overcomplicating the architecture. Option B: Deploy a Gateway Load Balancer with the firewall appliances as targets. Configure the firewall appliances with two network interfaces: one network interface in a private subnet and another network interface in a public subnet. Use the NAT functionality on the firewall appliances to send the traffic to the internet after inspection. - Why it’s rejected: This option introduces unnecessary complexity by requiring two network interfaces per firewall appliance. One network interface in a public subnet is not needed since the private subnet is sufficient for traffic inspection and routing via the GWLB. Moreover, using NAT functionality on the firewall appliances adds overhead that c...

Author: CrimsonViperX · Last updated May 16, 2026

A company's AWS architecture consists of several VPCs. The VPCs include a shared services VPC and several application VPCs. The company has established network connectivity from all VPCs to the on-premises DNS servers. Applications that are deployed in the application VPCs must be able to resolve DNS for internally hosted domains on premises. The applications also must be able to...

To meet the requirements of allowing applications in multiple VPCs to resolve DNS for on-premises domains, as well as local VPC domain names and domains hosted in Amazon Route 53 private hosted zones, the solution must be able to handle both DNS forwarding and resolution across VPCs. Let's evaluate each option and why it may or may not meet the requirements: Option A: Create a new Route 53 Resolver inbound endpoint in the shared services VPC. Create forwarding rules for the on-premises hosted domains. Associate the rules with the new Resolver endpoint and each application VPC. Update each application VPC's DHCP configuration to point DNS resolution to the new Resolver endpoint. - Why it works: A Route 53 Resolver inbound endpoint allows DNS queries to be received from an external network (in this case, on-premises DNS servers). By creating forwarding rules, the DNS queries for on-premises hosted domains can be forwarded to the on-premises DNS servers. Associating the resolver with each application VPC ensures that DNS queries from these VPCs are properly handled. Updating the DHCP configuration of the application VPCs ensures that all instances use the Route 53 Resolver as their DNS resolver. - Why it's preferred: This option is a good fit because it leverages the inbound endpoint for DNS queries from on-premises servers and ensures that each application VPC is correctly pointed to this resolver for DNS resolution. This solution supports both on-premises domains and Route 53 private hosted zones. Option B: Create a new Route 53 Resolver outbound endpoint in the shared services VPC. Create forwarding rules for the on-premises hosted domains. Associate the rules with the new Resolver endpoint and each application VPC. - Why it’s rejected: An outbound endpoint is used to forward DNS queries from AWS to an external DNS resolver, such as on-premises DNS servers. However, this solution does not directly allow for the resolution of on-premises domains from the VPC. The outbound endpoint is more useful for queries going from AWS to o...

Author: ShadowWolf101 · Last updated May 16, 2026

A company has been using an outdated application layer protocol for communication among applications. The company decides not to use this protocol anymore and must migrate all applications to support a new protocol. The old protocol and the new protocol are TCP-based, but the protocols use different port numbers. After several months of work, the company has migrated dozens of applications that run on Amazon EC2 instances and in containers. The company believes that all the applications have been m...

To verify that no application is still using the old protocol without causing any downtime, the solution must be efficient, non-intrusive, and allow real-time verification of active connections. Let's evaluate each option based on these requirements: Option A: Use Amazon Inspector and its Network Reachability rules package. Wait until the analysis has finished running to find out which EC2 instances are still listening to the old port. - Why it’s rejected: Amazon Inspector primarily focuses on security assessments and vulnerabilities rather than verifying active network protocols or port usage. The Network Reachability rules package is useful for security auditing but does not specifically track or identify the actual running applications or protocols on active EC2 instances. Also, waiting for analysis could delay real-time verification, and it is not ideal for continuous monitoring of port usage. - Key Limitation: It may not provide the level of insight needed to verify active connections or usage of the old protocol in real-time. Option B: Enable Amazon GuardDuty. Use the graphical visualizations to filter for traffic that uses the port of the old protocol. Exclude all internet traffic to filter out occasions when the same port is used as an ephemeral port. - Why it’s rejected: Amazon GuardDuty focuses on threat detection and monitoring for suspicious activity such as potential security breaches, rather than monitoring routine network traffic or port usage by specific applications. Additionally, GuardDuty's visualizations are not designed for detailed traffic analysis based on specific port usage by applications. The tool is more geared toward security issues and would not directly answer whether an application is still using the old protocol. - Key Limitation: GuardDuty may not be suitable for verifying the specific port usage of the old protocol since it focuses more on detecting threats rather than analyzing normal application traffic. Option C: Configure VPC flow logs to be delivered into an Amazon S3 bucket. Use Amazon Athena to query the data and to filter for the port number that is used by the old protocol. - Wh...

Author: Sofia · Last updated May 16, 2026

A company has deployed its AWS environment in a single AWS Region. The environment consists of a few hundred application VPCs, a shared services VPC, and a VPN connection to the company's on-premises environment. A network engineer needs to implement a transit gateway with the following requirements: * Application VPCs must be isolated from each other. * Bidirectional communication must be allowed between the application VPCs and the on-premises network. * Bidirectional communication must be allowed between the application VPCs and the shared services VPC. The network engineer creates the transit gateway with options disabled for default route table association and default route table propagation. The network engineer also creates the VPN attachment for the on-premises network and create...

To meet the given requirements, the network engineer must ensure that: 1. Application VPCs are isolated from each other: This means no direct communication between the application VPCs. Each application VPC should not propagate its routes to other application VPCs. 2. Bidirectional communication between application VPCs and the on-premises network: This requires a configuration where the VPN attachment to the on-premises network is accessible from the application VPCs. 3. Bidirectional communication between application VPCs and the shared services VPC: The shared services VPC must be reachable by all application VPCs, and vice versa. Let's analyze the options based on these requirements: Option A: Configure a separate transit gateway route table for on-premises. Associate the VPN attachment with this transit gateway route table. Propagate all application VPC attachments to this transit gateway route table. - Analysis: This option isolates the on-premises network in its own route table. It allows the VPN connection to propagate routes for the application VPCs, which is good for bidirectional communication between on-premises and the application VPCs. However, it does not account for isolating the application VPCs from each other, as propagating all application VPC attachments to this route table would break the isolation requirement. - Rejected because: It fails to meet the isolation requirement for the application VPCs. Option B: Configure a separate transit gateway route table for each application VPC. Associate each application VPC attachment with its respective transit gateway route table. Propagate the shared services VPC attachment and the VPN attachment to this transit gateway route table. - Analysis: This option isolates the application VPCs from each other by having a separate route table for each. It allows for propagation from the shared services VPC and the VPN connection, which meets the bidirectional communication requirement. However, this setup creates a lot of route tables (one per application VPC), which could be inefficient and complex to manage. - Rejected because: While it meets all requirements, it creates unnecessary complexity with a large number of route tables, which isn't the least number of route tables needed. Option C: Configure a separate transit gateway route table for all application VPCs. Associate all application VPCs with this transit gateway route table...

Author: Aria · Last updated May 16, 2026

A company has an AWS Site-to-Site VPN connection between its existing VPC and on-premises network. The default DHCP options set is associated with the VPC. The company has an application that is running on an Amazon Linux 2 Amazon EC2 instance in the VPC. The application must retrieve an Amazon RDS database secret that is stored in AWS Secrets Manager through a private VPC endpoint. An on-premises application provides internal RESTful API service that can be reached by URL (https://api.example.internal). Two on-premises Windows DNS servers provide internal DNS resolution. The application on the EC2 instance needs to call the internal API service that is deployed in the on-premises environment. When the application on the EC2 instance attempts to call the internal API service by referr...

The Situation: - The Amazon EC2 instance in the VPC needs to access an on-premises internal API service (https://api.example.internal). - The DNS resolution for this service fails when using the hostname (api.example.internal), but works when using the IP address. - The company’s on-premises DNS servers are responsible for resolving internal domain names like `api.example.internal`. Requirements: - The EC2 instance needs to resolve the internal API service hostname (`api.example.internal`) correctly. - The solution must work for all resources in the VPC to prevent the issue from affecting others. Let's evaluate the options: Option A: Create a new DHCP options set that specifies the on-premises Windows DNS servers. Associate the new DHCP options set with the existing VPC. Reboot the Amazon Linux 2 EC2 instance. - Analysis: The DHCP options set defines the DNS servers that instances in the VPC should use. By updating the DHCP options set to specify the on-premises DNS servers, all instances in the VPC (including the EC2 instance) will use the on-premises DNS servers for DNS resolution. - Pros: - This solution ensures that all instances in the VPC can use the on-premises DNS servers. - It is scalable and applies to other resources in the VPC, addressing the underlying issue. - Once the new DHCP options set is applied, no further configuration is needed on individual instances. - Cons: - The EC2 instance will need to be rebooted to pick up the new DHCP options set. - Selected because it directly addresses the root cause by using the correct DNS servers for the EC2 instance and ensures that this applies to other resources in the VPC. Option B: Create an Amazon Route 53 Resolver rule. Associate the rule with the VPC. Configure the rule to forward DNS queries to the on-premises Windows DNS servers if the domain name matches `example.internal`. - Analysis: This option involves setting up a Route 53 Resolver rule to forward DNS queries for `example.internal` to the on-premises DNS servers. It would resolve the hostname correctly and ensure DNS resolution for the EC2 instance. - Pros: - It allows DNS queries to be forwarded to the on-premises DNS servers based on the domain name. - It does not require rebooting the EC2 instance. - Cons: - This solution adds co...

Author: Grace · Last updated May 16, 2026

A company has several production applications across different accounts in the AWS Cloud. The company operates from the us-east-1 Region only. Only certain partner companies can access the applications. The applications are running on Amazon EC2 instances that are in an Auto Scaling group behind an Application Load Balancer (ALB). The EC2 instances are in private subnets and allow traffic only from the ALB. The ALB is in a public subnet and allows inbound traffic only from partner network IP address ranges over port 80. When the company adds a new partner, the company must allow the IP address range of the partner net...

To meet the company's requirements of centrally managing partner network IP address ranges for access to the applications, we need to look for a solution that: 1. Centralizes management of IP address ranges. 2. Automatically updates security groups across different accounts when a new partner is added. 3. Minimizes operational overhead and is scalable to handle multiple accounts. Let's evaluate each option: Option A: Create an Amazon DynamoDB table to maintain all IP address ranges and security groups that need to be updated. Update the DynamoDB table with the new IP address range when the company adds a new partner. Invoke an AWS Lambda function to read new IP address ranges and security groups from the DynamoDB table to update the security groups. Deploy this solution in all accounts. - Analysis: This option centralizes the IP address ranges in DynamoDB, and Lambda functions are used to update the security groups. However, this approach is more complex compared to the other options because it requires managing DynamoDB tables and invoking Lambda functions across multiple accounts. It also lacks native integration with AWS security features like prefix lists. - Rejected because it involves unnecessary complexity and operational overhead in maintaining DynamoDB tables and Lambda invocations. Option B: Create a new prefix list. Add all allowed IP address ranges to the prefix list. Use Amazon EventBridge (Amazon CloudWatch Events) rules to invoke an AWS Lambda function to update security groups whenever a new IP address range is added to the prefix list. Deploy this solution in all accounts. - Analysis: This option involves using prefix lists, which are a managed and efficient way to handle IP address ranges. EventBridge is used to trigger Lambda functions to update security groups when a new IP address range is added. However, this approach requires managing EventBridge rules and Lambda functions to update the security groups, which adds a layer of complexity. - Rejected because it requires setting up EventBridge rules and Lambda functions to respond to updates to the prefix list. While this is a good option, it's more complex than the next one. Option C: Create a new prefix list. Add all allowed IP address ranges to the prefix list. Share the prefix list ac...

Author: GlowingTiger · Last updated May 16, 2026

A company uses a 1 Gbps AWS Direct Connect connection to connect its AWS environment to its on-premises data center. The connection provides employees with access to an application VPC that is hosted on AWS. Many remote employees use a company-provided VPN to connect to the data center. These employees are reporting slowness when they access the application during business hours. On-premises users have started to report similar slowness while they are in the office. The company plans to build an additional application on AWS. On-site and remote employees will use the additional application. After the deployment of this additional application, the company will need 20% more bandwidth than the compa...

To solve the problem, we need to consider the following key requirements and constraints: 1. Current Issue: Remote employees and on-premises users are experiencing slowness when accessing the application hosted on AWS. This is likely due to congestion on the 1 Gbps Direct Connect connection. 2. Future Growth: The company expects a 20% increase in bandwidth usage, and they want to add resiliency to the AWS connectivity. 3. Budget Constraints: The company has a limited budget, so the solution needs to be cost-effective. Now let's evaluate each option: Option A: Set up a new 1 Gbps Direct Connect dedicated connection to accommodate the additional traffic load from remote employees and the additional application. Create a link aggregation group (LAG). - Analysis: This option involves adding another 1 Gbps Direct Connect connection and aggregating the two connections into a Link Aggregation Group (LAG). This would increase bandwidth capacity by 1 Gbps, giving a total of 2 Gbps. LAG would also provide some level of redundancy and increased reliability. This is a scalable solution that addresses the bandwidth issue. - Pros: - It increases the available bandwidth by 1 Gbps, which helps with the increased usage. - LAG provides resiliency (failover capability) between the two connections, ensuring higher reliability. - This is a cost-effective solution, as it only requires the addition of a 1 Gbps connection. - Cons: - The company would still be limited to 2 Gbps total bandwidth, which might not be enough after the 20% increase, especially with increased usage over time. However, this option is the most balanced in terms of cost and benefit. Option B: Deploy an AWS Site-to-Site VPN connection to the application VPC. Configure the on-premises routing for the remote employees to connect to the Site-to-Site VPN connection. - Analysis: This option introduces a VPN connection as an additional way for remote employees to access the application VPC. However, VPN connections are typically less efficient and slower than Direct Connect, especially when dealing with high traffic volumes. Adding a VPN connection could help offload some traffic, but it would introduce additional latency and potential bandwidth limits, which would not fully resolve the slowne...

Author: RadiantJaguar56 · Last updated May 16, 2026

A company has a global network and is using transit gateways to connect AWS Regions together. The company finds that two Amazon EC2 instances in different Regions are unable to communicate with each other. A network engineer needs to t...

To troubleshoot the connectivity issue between Amazon EC2 instances in different AWS Regions connected via transit gateways, the network engineer needs to: 1. Analyze routing in both the transit gateways and VPC route tables to ensure proper connectivity. 2. Analyze network traffic to ensure that security groups and network ACLs are not blocking the communication. 3. Use the right AWS tools to diagnose both routing and security issues effectively. Let's evaluate each option: Option A: Use AWS Network Manager Route Analyzer to analyze routes in the transit gateway route tables and in the VPC route tables. Use VPC flow logs to analyze the IP traffic that security group rules and network ACL rules accept or reject in the VPC. - Analysis: This option uses AWS Network Manager Route Analyzer, which is designed to help troubleshoot routing issues in global networks using transit gateways. It also uses VPC flow logs to inspect traffic based on security group rules and network ACLs. - Pros: - The Route Analyzer is appropriate for analyzing routing between regions via transit gateways. - VPC flow logs provide insights into whether traffic is allowed or denied by security groups and network ACLs. - Cons: - This option is a comprehensive and practical solution, but it doesn't mention a tool specifically designed to verify VPC-level connectivity, which would be helpful in this case. Option B: Use AWS Network Manager Route Analyzer to analyze routes in the transit gateway route tables. Verify that the VPC route tables are correct. Use AWS Firewall Manager to analyze the IP traffic that security group rules and network ACL rules accept or reject in the VPC. - Analysis: This option uses AWS Network Manager Route Analyzer to analyze transit gateway routes, but it uses AWS Firewall Manager, which is primarily a tool for managing security policies across accounts. Firewall Manager isn't designed to analyze specific traffic flows or inspect security groups or ACLs in the same detailed way as VPC flow logs. - Rejected because AWS Firewall Manager is not the right tool for analyzing...

Author: Sofia · Last updated May 16, 2026

A company needs to transfer data between its VPC and its on-premises data center. The data must travel through a connection that has dedicated bandwidth. The data also must be encrypted in transit. The company has been working with an AWS Partner Network (APN) ...

Let's break down the requirements and look at each option to determine which ones meet the company's needs: Requirements: 1. Dedicated bandwidth: The data must travel through a connection that has dedicated bandwidth. 2. Encryption in transit: The data must be encrypted while traveling. 3. Working with an APN Partner: The company is working with an AWS Partner Network (APN) Partner to establish the connection. Analysis of Each Option: 1. A) Request a hosted connection from the APN Partner: - Explanation: A hosted connection from an APN Partner typically provides dedicated bandwidth. It involves a partner managing the network connection, such as through Direct Connect, to AWS. Since this is usually a private connection, encryption can be handled via an additional layer, but the main characteristic is the dedicated bandwidth. - Why it's Selected: Meets the dedicated bandwidth requirement, and encryption can be added (typically with IPsec over the dedicated connection). 2. B) Request a hosted public VIF from the APN Partner: - Explanation: A hosted public Virtual Interface (VIF) is typically used for accessing public AWS services (like S3, DynamoDB) over Direct Connect. However, this type of VIF is not intended for private connectivity to the VPC. - Why it's Rejected: The requirement specifies a connection to the VPC, so a public VIF is inappropriate. It also does not provide encryption by default. 3. C) Create an AWS Site-to-Site VPN connection: - Explanation: AWS Site-to-Site VPN allows for encrypted connections over the public internet. This provides encryption, but it does not ensure dedicated bandwidth, as the connection is still subject to internet routing and is not a private, dedicated link. - Why it's Rejected: Although it provides encryption, it does not meet th...

Author: Lina Zhang · Last updated May 16, 2026

A company's security guidelines state that all outbound traffic from a VPC to the company's on-premises data center must pass through a security appliance. The security appliance runs on an Amazon EC2 instance. A network engineer needs to improve the network performance between the on-premises dat...

Requirements: 1. Outbound traffic must pass through a security appliance: The appliance runs on an EC2 instance, and all outbound traffic must go through it. 2. Improve network performance: The network engineer needs to enhance the performance of the connection between the on-premises data center and the security appliance, which is running on EC2. Analysis of Each Option: 1. A) Use an EC2 instance that supports enhanced networking: - Explanation: EC2 instances that support enhanced networking (using Elastic Network Adapter or ENA) provide higher throughput and lower latency than standard EC2 instances. This is essential for improving the performance of the network traffic that passes through the security appliance. - Why it's Selected: Enhanced networking improves the EC2 instance's network performance, which directly benefits the traffic flowing through the security appliance, meeting the performance improvement requirement. 2. B) Send outbound traffic through a transit gateway: - Explanation: A transit gateway can centralize routing and simplify network architecture by connecting VPCs, VPNs, and on-premises networks. However, it does not directly improve the performance of traffic passing through the EC2 security appliance; it is primarily for routing and centralizing network management. - Why it's Rejected: Although a transit gateway might be useful for routing, it doesn’t specifically enhance network performance between the on-premises data center and the EC2 instance hosting the security appliance. 3. C) Increase the EC2 instance size: - Explanation: Increasing the EC2 instance size might provide more CPU, RAM, and network throughput, which can improve performance. However, the main focus here is on network performance. Simply increasing the EC2 instance size may not necessarily maximize network throughput compared to enabling enhanced networking. - Why it's Rejected: While increasing the EC2 inst...

Author: Ahmed97 · Last updated May 16, 2026

A company's application team is unable to launch new resources into its VPC. A network engineer discovers that the VPC has run out of usable IP addresses. The VPC CIDR block is 172.16.0....

Requirements: The VPC has run out of usable IP addresses, and the network engineer needs to add an additional CIDR block to the VPC to resolve the issue. Analysis of Each Option: 1. A) 172.17.0.0/29: - Explanation: A `/29` subnet provides only 8 IP addresses (6 usable IP addresses for hosts, 1 network address, and 1 broadcast address). This would provide a very small number of IP addresses, which likely wouldn't address the VPC’s scalability needs, as a larger CIDR block is needed. - Why it's Rejected: The `/29` block only provides a few IP addresses, which would not significantly help resolve the problem of running out of IP addresses in a `/16` block. 2. B) 10.0.0.0/16: - Explanation: The `10.0.0.0/16` CIDR block is a private IP address range that is completely distinct from the `172.16.0.0/16` block. It is entirely valid to add this as an additional CIDR block to the VPC. This block provides 65,536 IP addresses, which can significantly expand the available IPs for resources in the VPC. - Why it's Selected: This is a valid option because it's a new, non-overlapping CIDR block that is not part of the original `172.16.0.0/16` block and provides a large number of IP addresses for future use. 3. C) 172.17.0.0/16: - Explanation: The `172.17.0.0/16` CIDR block is part o...

Author: Akash · Last updated May 16, 2026

A financial trading company is using Amazon EC2 instances to run its trading platform. Part of the company's trading platform includes a third-party pricing service that the EC2 instances communicate with over UDP on port 50000. Recently, the company has had problems with the pricing service. Some of the responses from the pricing service appear to be incorrectly formatted and are not being processed successfully. The third-party vendor requests access to the data that the pricing service is returning. The third-party vendor wants to capture request and response data for debugging by logging in to an EC2 instance that ...

Requirements: 1. Capture the traffic between the EC2 instance and the third-party pricing service, particularly the UDP traffic on port 50000. 2. Log analysis should be performed in a dedicated monitoring account, not directly on the production EC2 instances. 3. Prohibit direct access to production systems, and provide the captured data to the third-party vendor for debugging. Analysis of Each Option: --- A) 1. Configure VPC flow logs to capture the data that flows in the VPC. 2. Send the data to an Amazon S3 bucket. 3. In the monitoring account, extract the data that flows to the EC2 instance's IP address and filter the traffic for the UDP data. 4. Provide the data to the third-party vendor. - Explanation: VPC flow logs can capture metadata about traffic (source/destination IPs, ports, protocols, etc.), but VPC flow logs do not capture the actual content of the UDP traffic—they only provide metadata. VPC flow logs are good for basic traffic analysis, but they don't give full visibility into the UDP packets, which is necessary for debugging the format of the pricing service responses. - Why it's Rejected: This option will not capture the actual content of the UDP traffic, which is essential for identifying issues in the responses from the pricing service. It only gives metadata, not the actual payload, which doesn't meet the requirements. --- B) 1. Configure a traffic mirror filter to capture the UDP data. 2. Configure Traffic Mirroring to capture the traffic for the EC2 instance's elastic network interface. 3. Configure a packet inspection package on a new EC2 instance in the production environment. Use the elastic network interface of the new EC2 instance as the target for the traffic mirror. 4. Extract the data by using the packet inspection package. 5. Provide the data to the third-party vendor. - Explanation: Traffic Mirroring captures the actual packet-level data for inspection. This is appropriate for capturing UDP traffic and analyzing the packet content, which is exactly what the third-party vendor needs for debugging. However, performing the packet inspection on an EC2 instance in the production environment contradicts the company's policy of prohibiting direct access to production systems. - Why it's Rejected: While it captures the correct data, performing the packet inspection within the production environment violates the company's security policy of prohibiting direct access to production systems. --- C) 1. Configure a traffic mirror filter to capture the UDP data. 2...

Author: Noah · Last updated May 16, 2026

A company's network engineer is configuring an AWS Site-to-Site VPN connection between a transit gateway and the company's on-premises network. The Site-to-Site VPN connection is configured to use BGP over two tunnels in active/active mode with equal-cost multi-path (ECMP) routing activated on the transit gateway. When the network engineer attempts to send traffic from the on-premises network to an Amazon EC2 instance, traffic is sent over the first tunnel. However, return traffic ...

Problem Overview: The network engineer has set up an AWS Site-to-Site VPN connection using BGP with two active tunnels in active/active mode and ECMP routing. Traffic from the on-premises network is flowing over the first tunnel, but return traffic is coming over the second tunnel and being dropped at the customer gateway, likely because of asymmetric routing. The goal is to resolve the issue without reducing the overall VPN bandwidth. Key Factors to Consider: 1. Asymmetric Routing: Asymmetric routing occurs when outbound and inbound traffic take different paths, which can lead to dropped packets, especially if the return path (in this case, the second tunnel) isn’t expected or properly configured at the customer gateway. 2. Active/Active Mode with ECMP: Equal-cost multi-path (ECMP) allows traffic to flow over multiple paths with equal cost. However, if the return traffic is routed back on a different tunnel, the customer gateway must be capable of handling that scenario. Analysis of Each Option: --- A) Configure the customer gateway to use AS PATH prepending and local preference to prefer one tunnel over the other. - Explanation: AS path prepending and local preference are BGP techniques to influence routing decisions. By modifying these parameters, the customer gateway can prefer one tunnel for inbound and outbound traffic. While this could solve the asymmetric routing issue by controlling the return path, it may reduce the overall available bandwidth by making one tunnel more preferred, which is against the requirement of maintaining overall VPN bandwidth. - Why it's Rejected: This option introduces preference to one tunnel, potentially reducing the redundancy and load balancing advantages of the active/active setup. It goes against the requirement to preserve the overall bandwidth utilization by using both tunnels effectively. --- B) Configure the Site-to-Site VPN options to set the first tunnel as the primary tunnel to eliminate asymmetric routing. - Explanation: This would force all traffic to flow over the first tunnel, which would eliminate asymmetric routing issues. However, it eff...

Author: Kai · Last updated May 16, 2026

A company runs an application on Amazon EC2 instances. A network engineer implements a NAT gateway in the application's VPC to replace self-managed NAT instances. After the network engineer shifts traffic from the self-managed NAT instances to the NAT gateway, users begin to report issues. During troubleshooting, the network engineer discovers that...

In this scenario, the users are experiencing connection drops after about 6 minutes of inactivity. This issue is likely related to how the NAT gateway and the application EC2 instances are handling network traffic and idle connections. Let's analyze each option in detail: Option A: Check for increases in the IdleTimeoutCount Amazon CloudWatch metric for the NAT gateway. Configure TCP keepalive on the application EC2 instances. - Why selected? The NAT gateway has an idle timeout value for connections. When a connection remains idle for a specific period, it might be closed. By checking the IdleTimeoutCount metric in CloudWatch, you can confirm if this is causing the disconnection. Configuring TCP keepalive on the EC2 instances ensures that periodic "pings" are sent to keep the connection active, preventing idle timeouts. - Why other options are rejected? - Option B suggests configuring an HTTP timeout, but this is not directly related to TCP connections or idle timeouts managed by the NAT gateway. Also, HTTP timeouts typically apply to web servers rather than ...

Author: Sofia2021 · Last updated May 16, 2026

A software-as-a-service (SaaS) company is migrating its private SaaS application to AWS. The company has hundreds of customers that connect to multiple data centers by using VPN tunnels. As the number of customers has grown, the company has experienced more difficulty in its effort to manage routing and segmentation of customers with complex NAT rules. After the migration to AWS is complete, the company's AWS customers must be able to access the SaaS...

In this scenario, the SaaS company is migrating its private application to AWS and needs to facilitate direct access from AWS customer VPCs and maintain connectivity for on-premises customers through IPsec VPN tunnels. The solution needs to address both customer routing and segmentation efficiently. Let's analyze each option: Option A: Connect the AWS customer VPCs to a shared transit gateway. Use AWS Site-to-Site VPN connections to the transit gateway for the on-premises customers. - Why selected? A transit gateway is a highly scalable and flexible solution for managing multiple VPCs, allowing AWS customer VPCs to connect to it directly. With this setup, AWS customers can easily access the SaaS application VPC. Additionally, the Site-to-Site VPN connections from the transit gateway provide secure connectivity for on-premises customers. This solution allows for efficient routing and segmentation between AWS customers and on-premises customers while minimizing the need for complex NAT rules or individual VPC peering. - Why other options are rejected? - Option B: AWS PrivateLin...

Author: Andrew · Last updated May 16, 2026

A company's existing AWS environment contains public application servers that run on Amazon EC2 instances. The application servers run in a VPC subnet. Each server is associated with an Elastic IP address. The company has a new requirement for firewall inspection of all traffic from the internet before the traffic reaches any EC2 instances. A security engineer has deployed and configured a Gateway Load Balancer (GLB...

In this scenario, the company needs to route all incoming traffic from the internet through a fleet of third-party firewalls deployed via a Gateway Load Balancer (GLB). The goal is to ensure that the traffic is inspected before reaching the EC2 instances. Let’s break down the options and determine the most suitable solution. Option A: Deploy a transit gateway. Attach a GLB endpoint to the transit gateway. Attach the application VPC to the transit gateway. Update the application subnet route table's default route destination to be the GLB endpoint. Ensure that the EC2 instances' security group allows traffic from the GLB endpoint. - Why rejected? - A transit gateway would allow connectivity between multiple VPCs, but this setup would require more complexity, as you’d need to manage additional routing between VPCs (application VPC and standalone VPC for firewalls). - The transit gateway is best suited for scenarios involving multiple VPCs, but here, since the requirement is only to route internet traffic to firewalls in a standalone VPC, this solution adds unnecessary complexity. Option B: Update the application subnet route table to have a default route to the GLB. On the standalone VPC that contains the firewall fleet, add a route in the route table for the application VPC's CIDR block with the GLB endpoint as the destination. Update the EC2 instances' security group to allow traffic from the GLB. - Why rejected? - This option suggests modifying the application subnet route table, but it lacks the necessary steps for directing traffic from the internet to the GLB for firewall inspection. It also doesn't address routing traffic between the GLB endpoint and the firewall fleet. It would require further adjustments to ensure traffic flows correctly through the firewall fleet before reaching the application servers. Option C: Provision a GLB endpoint in the application VPC in a new subnet. Create a gateway route table with a route that specifies the application subnet CIDR block as the destination and the GLB endpoint as the target. Associate the gateway route table with the internet gateway in the application VPC. Update the application...

Author: Kai · Last updated May 16, 2026

A company has an AWS Site-to-Site VPN connection between its office and its VPC. Users report occasional failure of the connection to the application that is hosted inside the VPC. A network engineer discovers in the customer gateway logs that the Internet Key Exchange (IKE) session ends when the con...

When a Site-to-Site VPN connection fails and the Internet Key Exchange (IKE) session goes down, it's essential to bring the session back up as soon as possible to restore connectivity. The Dead Peer Detection (DPD) feature helps detect when the peer (the other end of the VPN connection) is no longer responsive and can trigger an action to either clear, restart, or cancel the session. Let’s analyze the options in detail: Option A: Set the dead peer detection (DPD) timeout action to Clear. Initiate traffic from the VPC to on-premises. - Why rejected? - DPD action: Clear will immediately clear the VPN connection when the peer is unresponsive. While this can detect an issue and remove the current session, it doesn’t attempt to restart the session. This might result in the connection being terminated without automatically bringing it back up, which doesn’t help with the goal of restoring the IKE session immediately. - Initiating traffic from the VPC to on-premises does not address the root cause of the issue. If the IKE session has already gone down, the connection would still fail even if traffic is initiated from the VPC. Option B: Set the dead peer detection (DPD) timeout action to Restart. Initiate traffic from on-premises to the VPC. - Why selected? - DPD action: Restart is the correct approach to automatically attempt to bring the IKE session back up if it goes down. When the IKE session is lost, this action triggers an automatic reconnection, which helps to re-establish the VPN connection without manual intervention. - Initiating traffic from on-premises to the VPC is a good ...

Author: Ahmed97 · Last updated May 16, 2026

A network engineer is designing a hybrid networking environment that will connect a company's corporate network to the company's AWS environment. The AWS environment consists of 30 VPCs in 3 AWS Regions. The network engineer needs to implement a solution to centrally filter traffic by using a firewall that the company's security team has approved. The solution must give all the VPCs the ability to ...

The company needs a solution that ensures the ability to centrally filter traffic with a firewall, connects all VPCs across multiple regions, and meets the bandwidth requirement of at least 2 Gbps for connectivity between the corporate network and the AWS environment. Let's break down the options and evaluate which one best meets these requirements. Option A: Deploy an IPsec VPN connection between the corporate network and a new transit gateway. Connect all VPCs to the transit gateway. Associate the approved firewall with the transit gateway. - Why rejected? - While an IPsec VPN connection is a valid solution for connectivity, it has limitations in terms of scalability and bandwidth. The required 2 Gbps bandwidth might not be achievable with a VPN, especially when connecting multiple VPCs across different regions. - VPN connections are also less reliable and may introduce latency and packet loss compared to other direct connection options, especially at higher throughput levels. - The transit gateway would allow central routing, but the VPN tunnel would limit the overall bandwidth and performance. Option B: Deploy a single 10 Gbps AWS Direct Connect connection between the corporate network and virtual private gateway of each VPC. Connect the virtual private gateways to a Direct Connect gateway. Build an IPsec tunnel to a new transit VPC. Deploy the approved firewall to the transit VPC. - Why rejected? - A single 10 Gbps Direct Connect connection between the corporate network and the virtual private gateway of each VPC is not ideal because Direct Connect should provide a reliable, high-throughput connection. However, this option involves creating IPsec tunnels to a new transit VPC, which complicates the design unnecessarily. - The IPsec tunnel may limit the throughput and introduce extra overhead compared to using direct connections for routing traffic to the firewall. - The design also requires traffic to be routed via the transit VPC, which may introduce additional points of failure or performance bottlenecks. Option C: Deploy two 1 Gbps AWS Direct Connect connections in different Direct Connect locations to connect to the corporate network. Build a transit VIF on each connection to a Direct Connect gateway. Associate the Direct Connect gateway with a new transit gateway for each Region. Configure the VIFs to use equal-cost multipath (ECMP) routing. Connect all the VPCs in the three Regions to the transit gateway. Configure the transit ga...

Author: Zara · Last updated May 16, 2026

A company uses an AWS Direct Connect private VIF with a link aggregation group (LAG) that consists of two 10 Gbps connections. The company's security team has implemented a new requirement for external network connections to provide layer 2 encryption. The company's network team plans to use MACsec support for Direct Conne...

To meet the requirement of enabling MACsec support for Direct Connect using a Link Aggregation Group (LAG), the network team needs to take specific steps. Let's break down the options and reasoning behind them: Option Analysis: - A) Create a new Direct Connect LAG with new circuits and ports that support MACsec. - Reasoning: This is a valid option if the existing LAG does not support MACsec, or if the Direct Connect connections do not have ports or circuits capable of supporting MACsec encryption. This ensures that the Direct Connect connections are built with MACsec support from the start. However, if the existing LAG already supports MACsec, creating a new LAG might not be necessary. - Rejection: If the current Direct Connect setup already supports MACsec and no hardware or configuration changes are needed for MACsec, this step could be redundant. - B) Associate the MACsec Connectivity Association Key (CAK) and the Connection Key Name (CKN) with the new LAG. - Reasoning: MACsec requires the use of a CAK (Connectivity Association Key) for encryption and a CKN (Connection Key Name) to define the key identity. This association is necessary to configure MACsec on the Direct Connect connections. It is required for both new and existing LAGs that use MACsec, but typically, this would apply when creating or modifying an existing LAG to support MACsec. - Rejection: This option is necessary but only in combination with the correct setup. Without creating or configuring the MACsec encryption mode, just associating CAK and CKN isn't sufficient. - C) Associate the Internet Key Exchange (IKE) with the existing LAG. - Reasoning: IKE is typically used for IPsec VPNs, not for MACsec. MACsec doesn't use IKE for key exchange. MACsec uses the CAK for encryption. Therefore, this option is irrelevant for the task of enabling MACsec on Direct Connect. - Rejection: IKE is unrelated to MACsec and does not apply here. - D) Configure the MACsec encryption mode on the existing LAG. - Reasoning: This is a valid step if the existing LAG supports MACsec encryption. Enabling MACsec encryption on the existing LAG e...

Author: Noah · Last updated May 16, 2026

A company recently implemented a security policy that prohibits developers from launching VPC network infrastructure. The policy states that any time a NAT gateway is launched in a VPC, the company's network security team must immediately receive an alert to terminate the NAT gateway. The network security team needs to implement a solution that can be deployed across AWS accounts with the least possible ...

Let's analyze the provided options based on the given requirements: Key Requirements: 1. Alert Network Security Team: An immediate alert should be sent whenever a NAT gateway is launched. 2. Terminate NAT Gateway: The solution must have the capability to terminate the NAT gateway. 3. Minimal Administrative Overhead: The solution should minimize complexity in deployment and management across multiple AWS accounts. 4. View Compliance History: A simple way to track and review the history of compliance actions (such as termination of NAT gateways) is needed. Option Breakdown: - A) Develop a script that programmatically checks for NAT gateways in an AWS account, sends an email alert, and terminates the NAT gateway if a NAT gateway is detected. Deploy the script on an Amazon EC2 instance in each account. Use a cron job to run the script every 5 minutes. Log the results of the checks to an Amazon RDS for MySQL database. - Reasoning: This option requires manually deploying and maintaining an EC2 instance in every AWS account, along with scheduling a cron job to check for NAT gateways. While it technically meets the requirement, this approach introduces significant administrative overhead because of the need to manage EC2 instances, cron jobs, and a separate MySQL database to log results. Additionally, the logs are not as easily accessible or centralized, which increases complexity for compliance tracking. - Rejection: High administrative overhead, especially for managing EC2 instances in multiple accounts. - B) Create an AWS Lambda function that programmatically checks for NAT gateways in an AWS account, sends an email alert, and terminates the NAT gateway if a NAT gateway is detected. Deploy the Lambda function to each account by using AWS Serverless Application Model (AWS SAM) templates. Store the results of the checks on an Amazon OpenSearch Service cluster in each account. - Reasoning: This solution is more serverless, reducing the need to manage EC2 instances. It also uses AWS Lambda, which can scale automatically and be managed centrally. However, deploying the Lambda function in every account using AWS SAM templates still requires a bit of setup. Storing the logs in OpenSearch Service is a feasible option, but OpenSearch might be overkill for simple compliance tracking and alerting. - Rejection: The complexity of using OpenSearch for logging might be unnecessary, and deploying Lambda functions in each account using SAM templates still requires additional overhead. ...

Author: Leah Davis · Last updated May 16, 2026

A company is running an online game on AWS. The game is played globally and is gaining popularity. Users are reporting problems with the game's responsiveness. Replay rates are dropping, and the company is losing subscribers. Game servers are located in the us-west-2 Region and use an Elastic Load Balancer to distribute client traffic. The company has decided to deploy game servers to 11 additional AWS Regions to reduce the round-trip times of network traffic to game clients. A network en...

To address the company's need to optimize user traffic and reduce network latency for their game servers deployed across multiple AWS Regions, the network engineer needs to design a DNS solution that ensures users are routed to the game servers with the optimal response time. Let's evaluate the options: Option Analysis: - A) Create Route 53 records for the Elastic Load Balancers in each Region. Specify a weighted routing policy. Calculate the weight by using the number of clients in each Region. - Reasoning: A weighted routing policy allows routing traffic based on predefined weights. While this approach can distribute traffic based on the number of clients, it does not directly account for latency or network responsiveness. Therefore, the round-trip times to each Region may still be suboptimal for some users, and the solution would not ensure that users are routed to the closest or most responsive servers. - Rejection: This option does not optimize for low latency, as it relies on client count rather than actual response times or network performance. - B) Create Route 53 records for the Elastic Load Balancers in each Region. Specify a latency routing policy. Set the Region to the Region where the Elastic Load Balancer is deployed. - Reasoning: A latency routing policy ensures that traffic is directed to the server with the lowest network latency for the user. Route 53 automatically measures the latency to each Region and routes traffic to the game server with the best performance. This is the best option to meet the requirement of reducing round-trip times and ensuring optimal response times for users, as it dynamically routes traffic based on current network conditions. - Selection: This option optimizes for the required outcome, directing traffic based on actual latency. - C) Create Route 53 records for the Elastic Load Balancers in eac...

Author: Liam123 · Last updated May 16, 2026

A network engineer needs to build an encrypted connection between an on-premises data center and a VPC. The network engineer attaches the VPC to a virtual private gateway and sets up an AWS Site-to-Site VPN connection. The VPN tunnel is UP after configuration and is working. However, during rekey for phase 2 of the VPN negotiation, the customer gateway device is receiving different parameters than the parameters that the device is configured to support. The network engineer checks the IPsec configuration of the VPN tunnel. The network engine...

Understanding the Situation: The issue involves a mismatch in VPN parameters during the phase 2 rekey negotiation, where the customer gateway device is receiving different parameters than what it supports. This can be due to the configuration differences between the on-premises customer gateway device and the AWS Virtual Private Gateway. The customer gateway device is configured with the most secure encryption algorithms offered in the AWS Site-to-Site VPN configuration file. Key Considerations: - Phase 2 Rekeying: This refers to the process where the encryption keys for the IPsec VPN tunnel are periodically renegotiated. - Customer Gateway Configuration: The customer gateway device may be set to use more secure algorithms than what is required or supported by the virtual private gateway. - Troubleshooting: The issue appears to be caused by a mismatch between the parameters supported by the customer gateway device and the virtual private gateway. This needs to be resolved by ensuring that both sides agree on the encryption algorithms and other parameters used during the tunnel negotiation. Option Breakdown: - A) Check the native virtual private gateway logs. Restrict the VPN tunnel options to the specific VPN parameters that the virtual private gateway requires. - Reasoning: The virtual private gateway is controlled by AWS, and the logs might provide insights into why the negotiation fails. However, it’s more likely that the issue lies with the customer gateway device being configured to use algorithms that are too strong or mismatched with what the virtual private gateway is offering. Restricting the parameters on the AWS side might not be the best option unless it's clear that the virtual private gateway is enforcing restrictions that conflict with the customer gateway settings. - Rejection: This option focuses on AWS side configurations, but the issue seems to be on the customer gateway side due to parameter mismatches. - B) Check the native customer gateway logs. Restrict the VPN tunnel options to the specific VPN parameters that the customer gateway requires. - Reasoning: The customer gateway device is where the mismatch is occurring, and reviewing its logs will give us insight into what parameters it supports and how it is handling the phase 2 rekeying process. If the customer gateway is set to use stronger encrypti...

Author: Mia · Last updated May 16, 2026

A company is growing rapidly. Data transfers between the company's on-premises systems and Amazon EC2 instances that run in VPCs are limited by the throughput of a single AWS Site-to-Site VPN connection between the company's on-premises data center firewall and an AWS Transit Gateway. A network engineer must resolve the throttling by designing a solution that is highly available and secure....

Problem Breakdown: The company’s current AWS Site-to-Site VPN connection is being throttled due to throughput limitations. The network engineer needs to resolve this issue by scaling the VPN throughput, ensuring high availability, security, and supporting increasing traffic between the on-premises data center and VPC resources. Key Requirements: - High Availability: The solution must ensure that there are no single points of failure, ensuring constant connectivity even in case of network issues. - Secure: The solution should maintain the security of the data transferred between the on-premises network and the VPC. - Scalable: The solution should allow for increased throughput as traffic grows. Let’s evaluate the proposed options: Option Analysis: - A) Configure multiple dynamic BGP-based Site-to-Site VPN connections to the transit gateway. Configure equal-cost multi-path routing (ECMP). - Reasoning: This solution involves configuring multiple VPN connections with dynamic BGP (Border Gateway Protocol) for routing and enabling ECMP for load balancing. This provides high availability and scales the throughput by distributing traffic across multiple connections. BGP ensures that the routing between the on-premises data center and AWS is adaptive and efficient. ECMP allows for better utilization of available VPN links, enhancing throughput. - Selection: This option meets all the key requirements—high availability (multiple connections), security (VPN is inherently secure), and scalability (multiple paths with ECMP for increased throughput). - B) Configure multiple static routing-based Site-to-Site VPN connections to the transit gateway. Configure equal-cost multi-path routing (ECMP). - Reasoning: While static routing with ECMP can also scale throughput and provide high availability, it is less flexible than dynamic BGP-based routing. Static routes need to be manually adjusted if network changes occur, and this approach does not dynamically adapt to changes in the network, unlike BGP. BGP is more efficient in handling routing changes, especially in dynamic ...

Author: Scarlett · Last updated May 16, 2026

A company uses Amazon Route 53 to host a public hosted zone for example.com. A network engineer recently reduced the TTL on several records to 60 seconds. The network engineer wants to assess whether the change has increased the number of queries to Route 53 beyond the expected levels that the company identified before the change. The network e...

To determine which solution provides the necessary information about the number of DNS queries made to the example.com public hosted zone, let's review each option: A) Create a new trail in AWS CloudTrail to include Route 53 data events. Send logs to Amazon CloudWatch Logs. Set up a CloudWatch metric filter to count the number of queries and create graphs. - CloudTrail logs events related to API activity, but it does not log every individual DNS query. While CloudTrail can be used to track API requests (e.g., record changes to Route 53 records), it does not log DNS queries themselves. Therefore, this option will not provide accurate data regarding the number of DNS queries made to the hosted zone. Rejected for DNS query tracking. B) Use Amazon CloudWatch to access the AWS/Route 53 namespace and to check the DNSQueries metric for the public hosted zone. - CloudWatch provides a DNSQueries metric for Route 53 in the AWS/Route 53 namespace. This metric tracks the total number of queries made to a public hosted zone, which is exactly what the network engineer needs to assess the impact of the TTL reduction. This is a direct, relevant metric for monitoring the number of queries for the hosted zone. Selected for DNS query tracking. C) Use Amazon CloudWatch to access the AWS/Route 53 Resolver namespace and to check the InboundQuery...

Author: StarlightBear · Last updated May 16, 2026

A company is establishing connectivity between its on-premises site and an existing VPC on AWS to meet a new security requirement. According to the new requirement, all public DNS queries must use an on-premises DNS security solution. The company's security team has allowed an exception for the AWS service endpoints because the company is using VPC endpoints to...

To meet the security requirement where all public DNS queries should use an on-premises DNS security solution, while allowing exceptions for AWS service endpoints, the network engineer needs to configure a solution that forwards DNS queries from the VPC to the on-premises DNS solution, while ensuring that AWS service endpoints are excluded. Let’s break down the options: A) Create a system rule for the domain name “.” (dot) with a target IP address of the on-premises DNS security solution. - A system rule with a domain name of `"."` (the root domain) can be used to forward all DNS queries to the on-premises DNS security solution. This is a broad rule that ensures all queries (for both public and private domains) are directed to the on-premises DNS, except for any exceptions (like service endpoints). - Selected because this ensures that all DNS queries are routed to the on-premises DNS solution, except where exceptions are configured. B) Create a new DHCP options set that provides the IP address of the on-premises DNS security solution. Update the VPC to use this new DHCP options set. - The DHCP options set in a VPC can be used to define custom DNS settings for instances in the VPC. By specifying the IP address of the on-premises DNS security solution in this options set, the instances in the VPC will use the on-premises DNS solution for all DNS queries. - Selected because this will ensure that the VPC instances are using the on-premises DNS solution for resolving DNS queries, fulfilling the security requirement. C) Create an Amazon Route 53 Resolver inbound endpoint. Associate this endpoint with the VPC. - An inbound endpoint in Amazon Route 53 Resolver is used to allow DNS queries to be forwarded from on-premises systems to AWS. However, this is not directly relevant to the requirement of using the on-premises DNS solution for VPC queries. Inbound endpoints are used to resolve DNS queries from on-premises networks into the VPC, which is the opposite direction of what is required in this case. - Rejected because inbound endpoints are not needed for forwarding DNS queries from the VPC to the on-premises ...

Author: BlazingPhoenix22 · Last updated May 16, 2026

A network engineer is designing the DNS architecture for a new AWS environment. The environment must be able to resolve DNS names of endpoints on premises, and the on-premises systems must be able to resolve the names of AWS endpoints. The DNS architecture must give individual accounts the ability to manage subdomains. The network engineer needs to create a single set of rules that will work across multiple accounts to control this behavi...

To design the DNS architecture to meet the requirements of resolving DNS names between AWS and on-premises systems, while allowing individual accounts to manage subdomains, the network engineer must configure a combination of Amazon Route 53, AWS Directory Service, and Route 53 Resolver rules. Here’s an analysis of each option: A) Create an Amazon Route 53 private hosted zone for the overall cloud domain. Plan to create subdomains that align to other AWS accounts that are associated with the central Route 53 private hosted zone. - This option aligns with the requirement of enabling individual accounts to manage subdomains. A central private hosted zone can be created in one AWS account, and subdomains can be delegated to other AWS accounts. This configuration ensures that each account can manage its portion of the DNS namespace while maintaining a central point of control. - Selected because this architecture supports the delegation of subdomains to individual accounts, which aligns with the requirement for multiple accounts to manage their subdomains. B) Create AWS Directory Service for Microsoft Active Directory server endpoints in the central AWS account that hosts the private hosted zone for the overall cloud domain. Create a conditional forwarding rule in Microsoft Active Directory DNS to forward traffic to a DNS resolver endpoint on premises. Create another rule to forward traffic between subdomains to the VPC resolver. - Using AWS Directory Service to manage DNS for Microsoft Active Directory (AD) is helpful in certain enterprise environments, but it's not necessary for the DNS architecture described here. The solution should focus on Amazon Route 53 Resolver for DNS resolution across AWS and on-premises, not necessarily for AD-specific DNS forwarding. Also, the conditional forwarding rule within AD DNS does not provide the flexibility of managing subdomains for individual accounts in AWS. - Rejected because it introduces unnecessary complexity with AWS Directory Service and is not directly aligned with the requirements. C) Create Amazon Route 53 Resolver inbound and outbound endpoints in the central AWS account that hosts the private hosted zone for the overall cloud domain. Create a forwarding rule to forward traffic to a DNS resolver endpoint on premises. Create another rule to forward traffic between subdomains to the Resolver inbound endpoint. - This solution involves Route 53 Resolver inbound and outbound endpoints, which are key for enabling DNS resolution between AWS and on-premises systems. The outbound endpoint forwards DNS queries from the VPC to the on-premises DNS system, while the inbound endpoint allows on-premises systems to resolve AWS-hosted domains. Addition...

Author: Layla · Last updated May 16, 2026

A company wants to migrate its DNS registrar and DNS hosting to Amazon Route 53. The company website receives tens of thousands of visits each day, and the company's current DNS provider cannot keep up. The company wants to migrate as ...

To meet the requirement of migrating DNS hosting to Amazon Route 53 without any downtime, it's crucial to carefully plan the transfer process. Let's analyze each option: A) Transfer the domain name to Route 53. Create a Route 53 private hosted zone, and copy all the existing DNS records. Update the name servers on the domain to use the name servers that are specified in the newly created private hosted zone. - Private Hosted Zone is not appropriate for a public-facing domain. A private hosted zone is used for DNS resolution within a VPC and is not accessible from the public internet. Since the company’s website needs to be publicly accessible, a public hosted zone should be used instead. - Rejected because a private hosted zone would not work for public DNS resolution. B) Copy all DNS records from the existing DNS servers to a Route 53 private hosted zone. Update the name servers with the existing registrar to use the private hosted zone name servers. Transfer the domain name to Route 53. Ensure that all the changes have propagated. - Similar to option A, this solution uses a private hosted zone, which is not suitable for a public website. Additionally, even if the domain is transferred later, using a private hosted zone for a public domain would result in DNS resolution issues. - Rejected because private hosted zones cannot be used for public DNS queries. C) Transfer the domain name to Route 53. Create a Route 53 public hosted zone, and copy all the existing DNS records. Set the TTL value on each record to 1 second. Update the name servers on the domain to use the name servers that are specified in the newly created public hosted zone. - Public Hosted Zone is appropriate for the company's domain since it’s a public website. However, this approach may cause DNS propagation delays, as transferring the domain to Route 53 and updating...

Author: Ethan · Last updated May 16, 2026

A company has an AWS account with four VPCs in the us-east-1 Region. The VPCs consist of a development VPC and three production VPCs that host various workloads. The company has extended its on-premises data center to AWS with AWS Direct Connect by using a Direct Connect gateway. The company now wants to establish connectivity to its production VPCs and development VPC from on premises. The production VPCs are allowed to route data to each other. However, the development VPC must be isolated from the production VPCs. No data can flow between the development VPC and the production VPCs. In preparation to implement this solution, a network engineer creates a transit gateway with a single transit gateway route table. Default route table association and default route table propagation are turned off. The net...

To meet the requirement of establishing connectivity between the on-premises data center and the VPCs while isolating the development VPC from the production VPCs, the network engineer needs to carefully configure the transit gateway and route tables. Let's break down each option and determine the best course of action: A) Associate the production VPC attachments with the existing transit gateway route table. Propagate the routes from these attachments. - Production VPC attachments should be associated with the existing transit gateway route table to allow routing between the production VPCs and the on-premises network. Propagating the routes from these attachments ensures that the production VPCs can route traffic to each other and to the on-premises network via the transit gateway. - Selected because this step ensures that the production VPCs are correctly routed and able to communicate with on-premises through the transit gateway. B) Associate all the attachments with the existing transit gateway route table. Propagate the routes from these attachments. - Associating all attachments with the existing route table and propagating the routes might seem logical, but this would violate the isolation requirement between the development and production VPCs. The development VPC should not be able to route traffic to production VPCs, so including all attachments in the same route table would allow undesired communication between the development and production VPCs. - Rejected because this would break the isolation between the development and production VPCs. C) Associate the Direct Connect gateway attachment with the existing transit gateway route table. Propagate the Direct Connect gateway attachment to this route table. - Associating the Direct Connect gateway with the transit gateway allows on-premises traffic to flow into AWS via Direct Connect. Propagating this attachment ensures that on-premises traffic can reach the VPCs via the transit gateway. This is a necessary step to enable connectivity between on-premises and AWS. - Selected because this is required for on-premises connectivity. D) Change the security group inbound rules on the existing transit gateway network interfaces in the development VPC to allow connections to and from the on-premises CIDR range only. - Security group changes...

Author: Emma · Last updated May 16, 2026

A network engineer needs to provide dual-stack connectivity between a company's office location and an AWS account. The company's on-premises router supports dual-stack connectivity, and the VPC has been configured with dual-stack support. The company has set up two AWS Direct Connect connections to the office location. This connecti...

To meet the dual-stack connectivity requirements between a company's office location and AWS with high availability and low latency, let's break down the solutions provided and evaluate them based on the key factors such as dual-stack support, high availability, and performance. Key Factors: 1. Dual-Stack Support: The solution must support both IPv4 and IPv6 to meet the dual-stack requirement. This means both IPv4 and IPv6 must be properly peered and advertised over AWS Direct Connect. 2. High Availability: The solution must ensure high availability through redundancy. The use of two AWS Direct Connect connections implies the need for routing failover between these connections, which can be achieved using Border Gateway Protocol (BGP) and potentially Bidirectional Forwarding Detection (BFD). 3. Low Latency: The solution must minimize any latency due to configuration or network failover. Option Breakdown: - A) Configure a single private VIF on each Direct Connect connection. Add both IPv4 and IPv6 peering to each private VIF. Configure the on-premises equipment with the AWS provided BGP neighbors to advertise IPv4 routes on the IPv4 peering and IPv6 routes on the IPv6 peering. Enable Bidirectional Forwarding Detection (BFD) on all peering sessions. - Explanation: This solution uses a single private VIF per Direct Connect connection for both IPv4 and IPv6. While this approach allows dual-stack support, it does not provide redundancy for both IPv4 and IPv6 peering separately, which could lead to a potential single point of failure if one of the VIFs fails. It does meet the requirement of high availability via BFD, but redundancy is compromised because there is only one VIF per connection. - Rejected: This solution doesn't provide the desired redundancy and separation of the IPv4 and IPv6 address families across different VIFs, which is important for a highly available, low-latency solution. - B) Configure two private VIFs on each Direct Connect connection: one private VIF with the IPv4 address family and one private VIF with the IPv6 address family. Configure the on-premises equipment with the AWS provided BGP neighbors to advertise IPv4 routes on the IPv4 peering and IPv6 routes on the IPv6 peering. Enable Bidirectional Forwarding Detection (BFD) on all peering sessions. - Explanation: This option provides separate VIFs for IPv4 and IPv6, which enhances redundancy and ensures that each address family has a dedicated path. It also supports the use of BFD for fast detection of failures and high availability. This configuration also provides better performance, as failure or issues with one address family (IPv4 or IPv6) won’t affect the other. - Selected: This is a good option as it meets the requirements of dual-stack connectivity, high availability (via BFD), and redundancy (separate VIFs for each address family). - C) Configure a single private VIF and IPv4 peering on each Direct Connect connection. Configure the on-premises equipment with this peering to advertise the IPv6 routes in the same BGP neighbor configuration. Enable Bidirectional Forwarding Detection (BFD) on all peering sessions. - Explanation: This option only provides IPv4 peering on the VIF a...

Author: IceDragon2023 · Last updated May 16, 2026

A company recently started using AWS Client VPN to give its remote users the ability to access resources in multiple peered VPCs and resources in the company's on-premises data center. The Client VPN endpoint route table has a single entry of 0.0.0.0/0. The Client VPN endpoint is using a new security group that has no inbound rules and a single outbound rule that allows all traffic to 0.0.0.0/0. Multiple remote users report that web search results are showing i...

The issue here involves remote users experiencing incorrect geographic location information when performing web searches while connected via AWS Client VPN. This is likely caused by traffic routing through the VPN and using the AWS region's public IP address, which results in location discrepancies. We need to resolve this issue with minimal disruption. Key Factors: 1. Geographic Location Information Issue: This suggests that the users’ traffic is being routed through the AWS region, not their actual geographic location. 2. Service Interruption: The solution should minimize service disruption for remote users, as the goal is to avoid downtime or major changes. 3. Network Traffic Routing: Since the Client VPN is configured with a `0.0.0.0/0` route, it implies that all traffic from the remote users is being routed through the VPN tunnel, causing all traffic to appear to come from the AWS region. Option Breakdown: - A) Switch users to AWS Site-to-Site VPNs. - Explanation: AWS Site-to-Site VPN is designed for site-to-site connectivity, not for remote users. Switching to this would require significant changes to the infrastructure, and it would cause service disruption. It does not directly address the issue of geographic location. - Rejected: Not the best option, as it changes the setup to something that is not suited for individual remote users and introduces unnecessary complexity. - B) Enable the split-tunnel option on the Client VPN endpoint. - Explanation: Enabling split tunneling allows remote users' traffic to be routed to the internet directly (bypassing the VPN) while only the traffic destined for the VPC or on-premises data center goes through the VPN. This would allow users to access the internet from their actual geographic location, fixing the geographic issue in web searches. - Selected: This option addresses the geographic location issue and reduces traffic through the VPN for internet-bound traffic, providing a simple solution with minimal disruption. - C) Add routes for the peered VPCs and for the on-premises data center to the Client VPN route table. - Explanation: Adding the necessary routes for the peered VPCs and on-premises data center will allow proper routing to those networks. However, this does not address the geographic issue directly and will only affect the internal routing within AWS or between AWS and on-premises networks. It doesn’t resolve the root cause of incorrect geographic ...

Author: Isabella1 · Last updated May 16, 2026

A company has set up hybrid connectivity between its VPCs and its on-premises data center. The company has the on-premises.example.com subdomain configured at its DNS server in the on-premises data center. The company is using the aws.example.com subdomain for workloads that run on AWS across different VPCs and accounts. Resources in both environments can access each other by using IP addresses. The company wants workloads in...

The company wants to allow workloads in its VPCs to access on-premises resources using the `on-premises.example.com` DNS names, with minimal management of resources. Let's analyze the options based on key factors such as ease of setup, scalability, and management overhead. Key Factors: 1. DNS Resolution: The solution must ensure that DNS queries from the VPC can resolve `on-premises.example.com` to the correct on-premises resources. 2. Minimal Management: The company aims to minimize management overhead. This suggests a solution that integrates seamlessly with existing AWS infrastructure and avoids the need to manage custom EC2 instances or manual configurations. 3. Hybrid Connectivity: The solution should leverage the existing hybrid connectivity (e.g., VPN, Direct Connect) between the VPC and on-premises data center. Option Breakdown: - A) Create an Amazon Route 53 Resolver outbound endpoint. Configure a Resolver rule that conditionally forwards DNS queries for on-premises.example.com to the on-premises DNS server. Associate the rule with the VPCs. - Explanation: This option creates an outbound endpoint for Amazon Route 53 Resolver, which allows DNS queries from AWS VPCs to be forwarded to the on-premises DNS server. By configuring a conditional forwarding rule, queries for `on-premises.example.com` will be forwarded to the on-premises DNS server. This is a highly scalable and managed solution, as AWS handles the DNS forwarding and resolution without requiring custom instances. - Selected: This option is the most efficient because it minimizes the need for manual management (no need to launch and manage EC2 instances). It integrates well with AWS DNS services and requires minimal setup, while being scalable for multiple VPCs and environments. - B) Create an Amazon Route 53 Resolver inbound endpoint and a Resolver outbound endpoint. Configure a Resolver rule that conditionally forwards DNS queries for on-premises.example.com to the on-premises DNS server. Associate the rule with the VPCs. - Explanation: This solution involves both an inbound and outbound Route 53 Resolver endpoint. The inbound endpoint is typically used for resolving DNS queries from on-premises to AWS, while the outbound endpoint is used for sending DNS queries from AWS to on-premises. While it allows bidirectiona...

Author: Samuel · Last updated May 16, 2026

A company is in the early stage of AWS Cloud adoption. The company has an application that is running in an on-premises data center in Asia. The company needs to deploy new applications in the us-east-1 Region. The applications in the cloud need connectivity to the on-premises data center. The company needs to set up a communication channel between AWS and the data center. The solution must improve latency, minimize the possibi...

The company needs a communication channel between its AWS infrastructure (in the us-east-1 region) and its on-premises data center in Asia. The primary goals are to improve latency, minimize performance impact due to transcontinental routing over the public internet, and encrypt data in transit. Additionally, the solution must be set up in the least amount of time. Key Factors for Decision: 1. Latency: Since the data center is in Asia, the solution should avoid relying on the public internet for transcontinental routing as much as possible. This reduces latency and minimizes performance degradation. 2. Encryption: The solution must ensure secure communication between AWS and the on-premises data center. 3. Time to Deploy: The solution should be fast to implement, ideally using fully managed services. 4. Scalability: The solution should allow for easy expansion as the company scales its applications. Option Breakdown: - A) Create an AWS Site-to-Site VPN connection with acceleration turned on. Create a virtual private gateway. Attach the Site-to-Site VPN connection to the virtual private gateway. Attach the virtual private gateway to the VPC where the applications will be deployed. - Explanation: This option involves creating a Site-to-Site VPN with acceleration turned on, which uses AWS's VPN acceleration feature to optimize the connection performance. It uses a virtual private gateway to attach the VPN to the VPC. This option would be fast to deploy, as AWS VPN connections are simple to configure and do not require a physical infrastructure setup. However, it still relies on the public internet, so it might not completely minimize latency or prevent potential performance issues over transcontinental routing, despite the use of VPN acceleration. - Rejected: While VPN with acceleration is a good solution for secure connections, it still relies on the public internet, which could be susceptible to latency and performance degradation. - B) Create an AWS Site-to-Site VPN connection with acceleration turned on. Create a transit gateway. Attach the Site-to-Site VPN connection to the transit gateway. Create a transit gateway attachment to the VPC where the applications will be deployed. - Explanation: This option introduces a transit gateway, which simplifies network management, especially when dealing with multiple VPCs or complex networking configurations. However, using VPN acceleration over a transit gateway does not address the concern of minimizing latency from transcontinental routing. The transit gateway adds complexity without solving the main issue of reducing latency between regions. ...

Author: Noah · Last updated May 16, 2026

A company is moving its record-keeping application to the AWS Cloud. All traffic between the company's on-premises data center and AWS must be encrypted at all times and at every transit device during the migration. The application will reside across multiple Availability Zones in a single AWS Region. The application will use existing 10 Gbps AWS Direct Connect dedicated connections with a MACsec capable port. A network engineer must ensure that the Direct Connect connection is secured accordingly at every transit device. The net...

The company is moving its record-keeping application to AWS and needs to ensure that all traffic between its on-premises data center and AWS is encrypted using MACsec (Media Access Control Security) for encryption at every transit device during the migration. The company already has 10 Gbps AWS Direct Connect dedicated connections with MACsec capable ports and has created the Connection Key Name (CKN) and Connectivity Association Key (CAK) pair for the MACsec secret key. The engineer needs to configure the Direct Connect connection with the appropriate encryption settings to ensure security at every transit device. Key Factors: 1. MACsec Encryption: To ensure encryption, MACsec must be enabled on the Direct Connect connection. 2. CKN/CAK Pair: This pair must be associated with the connection to enable MACsec encryption. 3. Encryption Mode: The MACsec encryption mode defines how encryption is applied. There are different levels of enforcement: - must_encrypt: Traffic must be encrypted. - should_encrypt: Encryption is recommended, but not strictly required. Option Breakdown: - A) Configure the on-premises router with the MACsec secret key. - Explanation: While configuring the on-premises router with the MACsec secret key is essential to establish MACsec encryption, this step alone does not directly involve AWS Direct Connect. The network engineer is tasked with configuring AWS settings, not the on-premises router. - Rejected: Although configuring the router with the MACsec secret key is necessary for the encryption to work, it is not part of the specific steps required for setting up the connection within AWS. - B) Update the connection's MACsec encryption mode to must_encrypt. Then associate the CKN/CAK pair with the connection. - Explanation: Setting the encryption mode to must_encrypt enforces that all traffic between the AWS environment and the on-premises data center is encrypted using MACsec. Associating the CKN/CAK pair ensures that the proper secret key is used for encryption. This ensures the highest level of security. - Selected: Thi...

Author: Maya2022 · Last updated May 16, 2026

A network engineer is designing hybrid connectivity with AWS Direct Connect and AWS Transit Gateway. A transit gateway is attached to a Direct Connect gateway and 19 VPCs across different AWS accounts. Two new VPCs are being attached to the transit gateway. The IP address administrator has assigned 10.0.32.0/21 to the first VPC and 10.0.40.0/21 to the second VPC. The prefix list has one CIDR block remaining before th...

In this scenario, the network engineer is managing the integration of AWS Direct Connect with AWS Transit Gateway and has encountered a situation where there is a constraint on the maximum number of CIDR blocks in a prefix list. Specifically, the engineer must find a way to advertise routes to on-premises while adhering to this constraint. Let's evaluate the options: A) Add 10.0.32.0/21 and 10.0.40.0/21 to both AWS managed prefix lists. - Problem: AWS managed prefix lists have a limit on the number of CIDR blocks they can contain. By adding two additional /21 blocks (10.0.32.0/21 and 10.0.40.0/21) to the AWS-managed prefix list, the network engineer would quickly hit the quota for the number of entries in the prefix list. Since only one CIDR block is available before the prefix list reaches its limit, this option would not be feasible. - Rejection Reason: This option is rejected because it will exceed the quota for entries in the AWS managed prefix list. B) Add 10.0.32.0/21 and 10.0.40.0/21 to the allowed prefix list. - Problem: The allowed prefix list is used to control the prefixes that can be advertised to AWS resources. However, the problem lies in the fact that the prefix list can only hold a limited number of entries, and with the remaining quota being one CIDR block, adding two separate /21 blocks would exceed this limit. - Rejection Reason: This option is rejected because adding both /21 CIDR blocks would exceed the remaining capacity of the prefix list. C) Add 10.0.32.0/20 to bo...

Author: James · Last updated May 16, 2026

Two companies are merging. The companies have a large AWS presence with multiple VPCs and are designing connectivity between their AWS networks. Both companies are using AWS Direct Connect with a Direct Connect gateway. Each company also has a transit gateway and multiple AWS Site-to-Site VPN connections from its transit gateway to on-premise...

In this scenario, the two companies are merging, and the goal is to optimize network visibility, throughput, logging, and monitoring. The companies already have AWS Direct Connect with transit gateways and Site-to-Site VPN connections. To meet these objectives, we need to consider how to best integrate the two networks and enhance visibility and monitoring. Let’s evaluate each option carefully: A) Configure a Site-to-Site VPN connection between each company's transit gateway to establish reachability between the respective networks. Configure VPC Flow Logs for all VPCs. Publish the flow logs to Amazon CloudWatch. Use VPC Reachability Analyzer to monitor connectivity. - Explanation: This option establishes Site-to-Site VPN connections between each company’s transit gateway, which can provide connectivity. It also configures VPC Flow Logs to track network traffic and publishes them to CloudWatch for monitoring. VPC Reachability Analyzer is useful for testing connectivity between VPCs or resources. However, while the VPC Reachability Analyzer helps with testing specific routes, it doesn’t provide ongoing, real-time monitoring or centralized visibility of all transit gateways, connections, or peering links. - Rejection Reason: This option lacks a comprehensive monitoring solution for the entire transit gateway setup, especially across multiple VPCs and AWS environments. It is not optimized for monitoring at a larger scale (e.g., peering links, overall network visibility). B) Configure a Site-to-Site VPN connection between each company's transit gateway to establish reachability between the respective networks. Configure VPC Flow Logs for all VPCs. Publish the flow logs to Amazon CloudWatch. Use AWS Transit Gateway Network Manager to monitor the transit gateways and their respective connections. - Explanation: This option uses Site-to-Site VPN connections for reachability and VPC Flow Logs to monitor traffic. AWS Transit Gateway Network Manager is a centralized tool for monitoring and managing AWS Transit Gateways. It provides visibility into the network, monitoring connections, and understanding the health and status of each transit gateway and its links. While it’s a better solution than option A for monitoring, it still relies on VPNs for interconnectivity, which may not be the most optimized solution for throughput and performance. - Rejection Reason: While this option improves monitoring and visibility, using VPNs for in...

Author: Ava · Last updated May 16, 2026

A company has a single VPC in the us-east-1 Region. The company is planning to set up a new VPC in the us-east-2 Region. The existing VPC has an AWS Site-to-Site VPN connection to the company's on-premises environment and uses a virtual private gateway. A network engineer needs to implement a solution to establish connectivity between the existing VPC and the new VPC. The solution also must implement support ...

To meet the requirements of connecting the existing VPC in the us-east-1 region with the new VPC in the us-east-2 region, while also ensuring IPv6 support and facilitating on-premises access, let’s evaluate the options: A) Create a new virtual private gateway in us-east-1. Attach the new virtual private gateway to the new VPC. Create two new Site-to-Site VPN connections to the new virtual private gateway with IPv4 and IPv6 support. Configure routing between the VPCs by using VPC peering. - Explanation: This option suggests creating a new virtual private gateway in us-east-1 and connecting it to the new VPC in us-east-2. It uses Site-to-Site VPN connections with both IPv4 and IPv6 support. While VPC peering could be used for routing between the two VPCs, VPC peering does not support IPv6 routing across regions, and VPC peering is not ideal for cross-region connectivity if VPN connections are involved. Additionally, it introduces complexity by requiring the management of two separate VPN connections and the virtual private gateway, which would not be scalable. - Rejection Reason: VPC peering across regions does not support IPv6, and this approach would require managing two different Site-to-Site VPN connections for the IPv4 and IPv6 traffic separately, which is inefficient. B) Create a transit gateway in us-east-1 and in us-east-2. Attach the existing VPC and the new VPC to each transit gateway. Create a new Site-to-Site VPN connection to each transit gateway with IPv4 and IPv6 support. Configure transit gateway peering. Configure routing between the VPCs and the on-premises environment. - Explanation: This option involves creating a transit gateway in both regions, attaching the respective VPCs to each, and establishing Site-to-Site VPN connections with IPv4 and IPv6 support. Transit gateway peering would be used to allow the two transit gateways to communicate with each other. While this solution allows for multi-region connectivity, it introduces the complexity of managing two separate transit gateways and associated VPN connections. This is a feasible solution but may be an overcomplicated approach when simpler options are available. - Rejection Reason: While this solution can work, using two transit gateways increases complexity and cost, especially when only a single transit gateway per region can suffice. C) Create a new virtual private gateway in us-east-2. Attach the new...

Author: Ravi Patel · Last updated May 16, 2026

What Our Friends Say

What Our Friends Say

Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company is planning to use Amazon S3 to archive financial data. The data is currently stored in an on-premises data center. The company uses AWS Direct Connect with a Direct Connect gateway and a transit gateway to connect to the on-premises data center. The data cannot b...

A company manages resources across VPCs in multiple AWS Regions. The company needs to connect to the resources by using its internal domain name. A network engineer needs to apply the aws.example.com DNS...

A company's network engineer builds and tests network designs for VPCs in a development account. The company needs to monitor the changes that are made to network resources and must ensure strict compliance with network security policies. The company also nee...

A company is deploying third-party firewall appliances for traffic inspection and NAT capabilities in its VPC. The VPC is configured with private subnets and public subnets. The company needs to deploy the firewall appliances ...

A company has a global network and is using transit gateways to connect AWS Regions together. The company finds that two Amazon EC2 instances in different Regions are unable to communicate with each other. A network engineer needs to t...

A company needs to transfer data between its VPC and its on-premises data center. The data must travel through a connection that has dedicated bandwidth. The data also must be encrypted in transit. The company has been working with an AWS Partner Network (APN) ...

A company's application team is unable to launch new resources into its VPC. A network engineer discovers that the VPC has run out of usable IP addresses. The VPC CIDR block is 172.16.0....

A company wants to migrate its DNS registrar and DNS hosting to Amazon Route 53. The company website receives tens of thousands of visits each day, and the company's current DNS provider cannot keep up. The company wants to migrate as ...