Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company is planning to deploy many software-defined WAN (SD-WAN) sites. The company is using AWS Transit Gateway and has deployed a transit gateway in the required AWS Region. A network engineer needs to deploy the SD-WAN hub virtual appliance into a VPC that is connected to the transit gateway. The solution must support at least 5 Gbps of t...

Analysis: The company needs a solution that supports at least 5 Gbps of throughput from the SD-WAN hub virtual appliance to other VPCs connected to the AWS Transit Gateway. Given this high throughput requirement, the solution must be capable of handling substantial traffic efficiently. Let’s review each option: --- Option A: Create a new VPC for the SD-WAN hub virtual appliance. Create two IPsec VPN connections between the SD-WAN hub virtual appliance and the transit gateway. Configure BGP over the IPsec VPN connections. - Analysis: - IPsec VPN Connections: Using IPsec VPNs over the Transit Gateway to connect the SD-WAN hub virtual appliance is not ideal for handling the required throughput (5 Gbps). IPsec VPNs typically have performance limitations, especially when dealing with high throughput. - BGP over VPN: While BGP can be used to manage the routing over the VPN connections, IPsec VPNs are not optimized for very high throughput, making this option unsuitable for meeting the 5 Gbps requirement. - Pros: Relatively simple setup, widely used in smaller-scale deployments. - Cons: IPsec VPNs introduce performance bottlenecks for high-throughput scenarios. - Use Case: Best for smaller throughput requirements or simpler setups. --- Option B: Assign a new CIDR block to the transit gateway. Create a new VPC for the SD-WAN hub virtual appliance. Attach the new VPC to the transit gateway with a VPC attachment. Add a transit gateway Connect attachment. Create a Connect peer and specify the GRE and BGP parameters. Create a route in the appropriate VPC for the SD-WAN hub virtual appliance to route to the transit gateway. - Analysis: - Transit Gateway Connect Attachment: The use of the Transit Gateway Connect attachment is a scalable and efficient solution for connecting SD-WAN appliances to the Transit Gateway. It supports high throughput and is optimized for SD-WAN traffic. - GRE and BGP: GRE (Generic Routing Encapsulation) and BGP are suitable for handling dynamic routing with high throughput, and this setup supports the required bandwidth and performance. - Pros: The Transit Gateway Connect attachment is specifically designed for high-throughput SD-WAN solutions, making this option well-suited for the 5 Gbps requirement. - Cons: The setup involves multiple components, such as CIDR block assignments and route configuration, but it is still efficient and scalable. - Use Cas...

Author: Kunal · Last updated Jul 24, 2026

A company is deploying a new application on AWS. The application uses dynamic multicasting. The company has five VPCs that are all attached to a transit gateway Amazon EC2 instances in each VPC need to be able to register dynamically to receive a mu...

Analysis: The company is deploying an application that uses dynamic multicasting, where EC2 instances across multiple VPCs must be able to register dynamically to receive multicast transmissions. AWS Transit Gateway supports multicast, but the configuration must consider the protocols and traffic types involved, as well as proper routing and multicast group management. Let’s break down the options: --- Option A: Create a static source multicast domain within the transit gateway. Associate the VPCs and applicable subnets with the multicast domain. Register the multicast senders' network interface with the multicast domain. Adjust the network ACLs to allow UDP traffic from the source to all receivers and to allow UDP traffic that is sent to the multicast group address. - Analysis: - Static Source Multicast Domain: A static multicast domain is typically used for scenarios where multicast sources and receivers are pre-configured and not subject to dynamic changes. However, dynamic multicast registration is required in this case. - UDP Traffic: Multicast typically uses UDP for transmission of data, as it's a connectionless protocol well-suited for multicast traffic. This configuration is correct in allowing UDP traffic for multicast. - Network ACLs: Allowing UDP traffic for multicast group addresses is correct for multicast to function properly. - Pros: Configures multicast in a static way, which would be suitable for certain use cases but not for dynamic registration. - Cons: This option is not dynamic enough to support the dynamic registration of EC2 instances as required. - Use Case: This might work for environments with static multicast sources and receivers, but dynamic registration is a key requirement that this option does not address. --- Option B: Create a static source multicast domain within the transit gateway. Associate the VPCs and applicable subnets with the multicast domain. Register the multicast senders' network interface with the multicast domain. Adjust the network ACLs to allow TCP traffic from the source to all receivers and to allow TCP traffic that is sent to the multicast group address. - Analysis: - TCP Traffic: Multicast traffic is typically transmitted using UDP, not TCP. Multicast over TCP is not a standard approach, as TCP is connection-oriented, which contradicts the nature of multicast communications. - Static Multicast Domain: As mentioned earlier, a static multicast domain does not support the dynamic registration that is required for the EC2 instances to register automatically. - Network ACLs: The inclusion of TCP traffic in the network ACLs is incorrect for multi...

Author: Ishaan · Last updated Jul 24, 2026

A company is creating new features for its ecommerce website. These features will use several microservices that are accessed through different paths. The microservices will run on Amazon Elastic Container Service (Amazon ECS). The company requires the use of HTTPS for all of its public websites. The application requires the customer's source IP addresses. A network engineer must im...

In this scenario, the company needs to implement a load balancing strategy that supports HTTPS for all public websites, and also allows retrieval of the customer's source IP addresses. Let's break down the options based on the requirements: 1. HTTPS support: The company requires all public-facing websites to use HTTPS, which implies the need for TLS/SSL termination at the load balancer level. 2. Retrieving customer source IP addresses: The microservices need to access the customer's original IP address, which means we need to ensure that the load balancer forwards the correct source IP address to the microservices. Option Analysis: A) Use a Network Load Balancer (NLB) - Explanation: A Network Load Balancer (NLB) operates at the Layer 4 (Transport) level, handling TCP/UDP traffic. It doesn't provide built-in support for terminating HTTPS requests or reading headers like `X-Forwarded-For`. It forwards requests to backend services without inspecting HTTP headers. This option doesn't support HTTPS termination or provide the ability to retrieve client IP addresses via HTTP headers. - Rejection: While it can forward traffic based on IP, it doesn't meet the requirement for HTTPS termination and passing the client IP as needed. B) Retrieve client IP addresses by using the X-Forwarded-For header - Explanation: The `X-Forwarded-For` header is commonly used by HTTP/HTTPS load balancers to pass the original client IP address. This header is typically used in conjunction with an Application Load Balancer (ALB) or a Reverse Proxy. The header allows microservices to access the client's real IP address, which is crucial for logging, geolocation, and other purposes. - Selection Reason: This option is suitable as it directly addresses the requirement to retrieve the customer’s original IP address. C) Use ...

Author: James · Last updated Jul 24, 2026

A company is migrating its containerized application to AWS. For the architecture the company will have an ingress VPC with a Network Load Balancer (NLB) to distribute the traffic to front-end pods in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The front end of the application will determine which user is requesting access and will send traffic to 1 of 10 services VPCs. Each services VPC will include an NLB that distributes traffic to the services pods in an EKS cluster. The company is concerned about overall cost. User traffic will be responsib...

Let's analyze each solution option in terms of cost, scalability, and meeting the requirements for high-volume traffic transfer: Key Requirements: 1. Cost-Effective Solution: The company is concerned about costs, especially with over 10 TB of data transfer monthly. Any solution that minimizes inter-VPC traffic costs will be ideal. 2. Traffic Distribution: Traffic from the ingress VPC to the 10 service VPCs needs to be managed in a way that minimizes data transfer costs. 3. AWS Architecture: We need to ensure communication is secure, scalable, and efficient between the VPCs, without unnecessarily increasing costs. Option Analysis: A) Create a transit gateway. Peer each VPC to the transit gateway. Use zonal DNS names for the NLB in the services VPCs to minimize cross-AZ traffic from the ingress VPC to the services VPCs. - Explanation: A Transit Gateway is a highly scalable solution for inter-VPC communication. By using zonal DNS names, the NLB in the services VPCs can ensure that traffic is routed within the same Availability Zone (AZ), minimizing cross-AZ traffic and associated costs. - Cost Considerations: Transit Gateway pricing depends on the data transfer between VPCs. While it's scalable, the transit gateway charges for data transfer between VPCs, and the additional VPC peering costs can make this option more expensive for large-scale traffic like 10 TB/month. - Rejection Reason: Even though a Transit Gateway allows for easy inter-VPC communication, its data transfer costs and the fact that each VPC will be directly connected to the gateway (with charges based on transfer volume) make this a potentially higher-cost solution. B) Create an AWS PrivateLink endpoint in every Availability Zone in the ingress VPC. Each PrivateLink endpoint will point to the zonal DNS entry of the NLB in the services VPCs. - Explanation: AWS PrivateLink enables private connectivity between VPCs via endpoints. It ensures secure and private communication, but also incurs PrivateLink data processing and hourly charges for each endpoint. Each VPC would require multiple endpoints in each AZ. - Cost Considerations: While PrivateLink provides secure connectivity, its pricing model for data processing and the creation of multiple endpoints in each AZ could lead to high costs, particularly for the significant amount of traffic (10 TB/month) expected in this architecture. - Rejection Reason: While PrivateLink offers security and private communication, the data transfer costs associated with high-volume traffic across many endpoints would make this a more expensive option, especially for a setup that requires 10 TB of data transfer monthly. C) Create a VPC peering connection between the ingress VPC and each of the 10 services V...

Author: David · Last updated Jul 24, 2026

A company has stateful security appliances that are deployed to multiple Availability Zones in a centralized shared services VPC. The AWS environment includes a transit gateway that is attached to application VPCs and the shared services VPC. The application VPCs have workloads that are deployed in private subnets across multiple Availability Zones. The stateful appliances in the shared services VPC inspect all east west (VPC-to-VPC) traffic. Users report that inter-VPC traffic to different Availability Zones is dropping. A network engineer verified this claim by issuing Internet Control Message Protocol (I...

Let's analyze the given scenario and the options one by one to understand the cause of the dropped traffic. Scenario Breakdown: - Stateful security appliances: These appliances inspect all east-west (VPC-to-VPC) traffic between application VPCs. - Transit Gateway: It connects the application VPCs to the shared services VPC where the stateful appliances are deployed. - Traffic dropping: The inter-VPC traffic between different Availability Zones in the application VPCs is dropping. ICMP pings from workloads across Availability Zones are failing. The network engineer has ruled out security groups, stateful device configurations, and network ACLs as the cause of the issue. This leaves us with the potential cause being something related to the transit gateway or how it interacts with the stateful appliances in the shared services VPC. Option Analysis: A) The stateful appliances and the transit gateway attachments are deployed in a separate subnet in the shared services VPC. - Explanation: Deploying the stateful appliances and the transit gateway attachments in separate subnets within the shared services VPC might create communication issues if the routing between these subnets is not set up correctly. However, this would not cause the dropping of traffic as described unless there's a routing or security issue between the subnets. - Rejection Reason: While this setup could cause communication issues between subnets, it doesn't directly explain why traffic between different Availability Zones is dropping. B) Appliance mode is not enabled on the transit gateway attachment to the shared services VPC. - Explanation: Appliance mode on a transit gateway attachment allows traffic to be routed through stateful appliances such as firewalls, intrusion detection systems, etc. If appliance mode is not enabled on the attachment to the shared services VPC, the traffic would bypass the appliances and not be inspected. This would cause issues with east-west traffic inspection, and traffic might not be properly handled by the appliances, resulting in drops or lack of inspection. - Selection Reason...

Author: GlowingTiger · Last updated Jul 24, 2026

A company has hundreds of Amazon EC2 instances that are running in two production VPCs across all Availability Zones in the us-east-1 Region. The production VPCs are named VPC A and VPC B. A new security regulation requires all traffic between production VPCs to be inspected before the traffic is routed to its final destination. The company deploys a new shared VPC that contains a stateful firewall appliance and a transit gateway with a VPC attachment across all VPCs to route traffic between VPC A and VPC B through the firewall appliance for ins...

To address the issue of traffic being dropped when traversing between different Availability Zones (AZs) through the transit gateway, we need to focus on the root cause of the problem. The main issue is that traffic between different AZs is not correctly being routed through the firewall appliance in the shared VPC for inspection. Let's break down the options: A) In the shared VPC, replace the VPC attachment with a VPN attachment. Create a VPN tunnel between the transit gateway and the firewall appliance. Configure BGP. - Explanation: This option introduces VPN tunnels and BGP, which adds complexity and overhead. VPNs between the transit gateway and firewall appliance would not address the core requirement of inspecting inter-VPC traffic efficiently. The use of VPN connections would introduce unnecessary complexity and operational overhead, particularly for routing large volumes of traffic between VPCs. - Rejection Reason: This solution adds significant management overhead and is not the most effective or efficient way to route traffic between VPCs through a firewall appliance. It's not aligned with the goal of minimizing management overhead. B) Enable transit gateway appliance mode on the VPC attachment in VPC A and VPC B. - Explanation: Transit Gateway appliance mode ensures that the traffic between VPCs is directed to a stateful appliance for inspection. Enabling appliance mode on the VPC attachment to VPC A and VPC B would ensure that the traffic from both VPCs is routed through the firewall appliance in the shared VPC for inspection. - Selection Reason: This option would ensure that all traffic between VPC A and VPC B is correctly routed through the firewall appliance for inspection. However, this approach does not address the issue if the firewall appliance is in the shared VPC, which may require appliance mode to be enabled on the VPC attachment in the shared VPC to properly route traffic through it. - Rejection Reason: While enabling appliance mode on VPC A and VPC B is ...

Author: Liam · Last updated Jul 24, 2026

A company has deployed a critical application on a fleet of Amazon EC2 instances behind an Application Load Balancer. The application must always be reachable on port 443 from the public internet. The application recently had an outage that resulted from an incorrect change to the EC2 security group. A network engineer needs to automate a way to verify the network connectivity between the public internet and the EC2 instances ...

Let's analyze each option based on the requirement to automate the verification of network connectivity between the public internet and EC2 instances whenever a change is made to the security group and notify the network engineer if the change impacts connectivity. Requirements: - The application must always be reachable on port 443 from the public internet. - The solution must automate the verification of connectivity whenever a change is made to the EC2 security group. - The solution must notify the network engineer if the change affects connectivity. Option Analysis: A) Enable VPC Flow Logs on the elastic network interface of each EC2 instance to capture REJECT traffic on port 443. Publish the flow log records to a log group in Amazon CloudWatch Logs. Create a CloudWatch Logs metric filter for the log group for rejected traffic. Create an alarm to notify the network engineer. - Explanation: VPC Flow Logs capture network traffic metadata, including whether traffic is allowed or rejected. Enabling flow logs to capture rejected traffic specifically for port 443 allows the engineer to detect when traffic is being blocked. However, this solution only provides reactive monitoring and is not triggered automatically by changes to security groups. It also may result in high data volumes, and you would need to manually configure and monitor the rejected traffic metrics. - Rejection Reason: Although VPC Flow Logs could provide valuable information, this solution doesn't meet the requirement for automatic notification based on security group changes. It also doesn't proactively test connectivity in real-time. B) Enable VPC Flow Logs on the elastic network interface of each EC2 instance to capture all traffic on port 443. Publish the flow log records to a log group in Amazon CloudWatch Logs. Create a CloudWatch Logs metric filter for the log group for all traffic. Create an alarm to notify the network engineer. - Explanation: This option captures all traffic on port 443, which could generate a lot of flow log data, especially if the application experiences high traffic. It then uses CloudWatch Logs metric filters to monitor for any changes in traffic. While this can provide some level of monitoring, it doesn't automate the verification of the actual connectivity whenever a change is made to the security group. It would also result in monitoring all traffic, not specifically targeting issues arising from security group changes. - Rejection Reason: While it can capture traffic patterns, this approach lacks automation in verifying connectivity based on security group changes. It is more passive and doesn't fully meet the requirement. C) Create a VPC Reachability Analyzer path on port 443. Specify the security group as the source. Specify the EC2 instances as the destination. Create an Amazon Simple Notification Service (Amazon SNS) top...

Author: Ava · Last updated Jul 24, 2026

A security team is performing an audit of a company's AWS deployment. The security team is concerned that two applications might be accessing resources that should be blocked by network ACLs and security groups. The applications are deployed across two Amazon Elastic Kubernetes Service (Amazon EKS) clusters that use the Amazon VPC Container Network Interface (CNI) plugin for Kubernetes. The clusters are in separate subnets within the same VPC and have a Cluster Autoscaler configured. The security team needs to determine which POD IP addresses are communicating...

Key Factors in Reasoning: 1. VPC Flow Logs Format: - The flow logs can be configured in either the default format or custom format. The default format provides basic information, whereas the custom format allows for specific field selections, like source and destination IP addresses of the packets (`pkt-srcaddr`, `pkt-dstaddr`), which would be critical for the security team in identifying application-level traffic. 2. Traffic Source and Destination: - The security team is interested in monitoring traffic from the two applications deployed in EKS clusters. To minimize the number of flow logs and focus on relevant traffic, it is crucial to narrow the logs to the application-specific resources. 3. Resource Selection: - EKS nodes (or EC2 instances running EKS) could be monitored using VPC flow logs, but in a Kubernetes environment, it’s more relevant to focus on application-specific subnets or Pod IPs to pinpoint the traffic between specific applications. 4. Operational Overhead: - Limiting the flow logs to only the relevant application traffic and using a custom format reduces unnecessary log data, reducing operational overhead and storage costs. Analyzing the Options: - Option A: - VPC flow logs in the default format can capture basic information but does not provide the specific packet-level data (like `pkt-srcaddr` and `pkt-dstaddr`) that is crucial for identifying application-specific communication. Also, this option limits the scope to EKS nodes, which may not capture traffic between pods directly. - Rejected: Not sufficient for monitoring traffic between specific ...

Author: Sophia Clark · Last updated Jul 24, 2026

A data analytics company has a 100-node high performance computing (HPC) cluster. The HPC cluster is for parallel data processing and is hosted in a VPC in the AWS Cloud. As part of the data processing workflow, the HPC cluster needs to perform several DNS queries to resolve and connect to Amazon RDS databases, Amazon S3 buckets, and on-premises data stores that are accessible through AWS Direct Connect. The HPC cluster can increase in size by five to seven times during the company's peak event at the end of the year. The company is using two Amazon EC2 instances as primary DNS servers for the VPC. The EC2 instances are configured to forward queries to the default VPC resolver for Amazon Route 53 hosted domains and to the on-premises DNS ...

Key Factors in Reasoning: 1. Scalability: - The HPC cluster is expected to scale from 100 nodes to 500-700 nodes during peak events. Any DNS solution must be able to handle this growth efficiently without introducing bottlenecks or failure points. 2. DNS Query Resolution for AWS Services: - The HPC cluster needs to resolve DNS names for AWS services like Amazon RDS and S3, as well as on-premises services through AWS Direct Connect. The solution must support resolution of AWS resources as well as external on-premises resources reliably. 3. Reliability: - DNS failures in an HPC environment can lead to job failures, making it critical to have a highly available and fault-tolerant DNS service. 4. Operational Simplicity: - The solution should simplify DNS management, reduce overhead, and avoid complexity in scaling out DNS services manually as the cluster grows. Analyzing the Options: - Option A: - Scaling out the DNS service by adding two additional EC2 instances: This option suggests manually adding more EC2 instances as DNS servers, then reconfiguring the HPC nodes to use these new servers. The HPC cluster will still be dependent on EC2-based DNS servers, which requires manual scaling and configuration. This approach introduces operational overhead as the cluster grows, and does not scale automatically. - Rejected: While it provides a solution for scaling, it requires manual intervention for scaling and management, which increases complexity and operational overhead as the cluster grows. - Option B: - Scaling up the existing EC2 instances by changing their instance size: This option suggests resizing the existing EC2 DNS servers to the largest possible instance size. While this may improve performance for the current load, it will not solve the scalability problem in the long term, especially when the cluster increases in size by 5 to 7 times during peak events. This ...

Author: Mia · Last updated Jul 24, 2026

A company's network engineer is designing an active-passive connection to AWS from two on-premises data centers. The company has set up AWS Direct Connect connections between the on-premises data centers and AWS. From each location, the company is using a transit VIF that connects to a Direct Connect gateway that is associated with a transit gateway. The network engineer must ensure that traffic from AWS to the data cen...

Key Factors in Reasoning: 1. BGP Routing and Traffic Flow: - The company needs to control the routing of traffic from AWS to its on-premises data centers. This requires influencing BGP route preference to ensure that traffic is routed primarily to the primary data center and only fails over to the failover data center in the event of an outage. 2. BGP Community Tags: - BGP community tags are a mechanism used to influence routing decisions in a network. By assigning different community tags to routes from the primary and failover data centers, the network engineer can set preferred routes. 3. Active-Passive Failover: - In an active-passive setup, the primary connection (from the primary data center) should be preferred under normal conditions, and only if it becomes unavailable, should the traffic failover to the secondary connection (failover data center). This is usually achieved by setting lower-preference community tags for the primary data center and higher-preference tags for the failover data center. Analyzing the Options: - Option A: - Primary data center: BGP community tag `7224:7100`. - Failover data center: BGP community tag `7224:7300`. - Typically, lower values for the BGP community tag are preferred in routing. Since the primary data center has the tag `7224:7100` (which is lower than `7224:7300`), traffic will be routed primarily to the primary data center. If there’s an issue with the primary data center, the failover data center, tagged with a higher community value (`7224:7300`), will be used. - Selected: This option works because it assigns a lower community tag to the primary data center, ensuring traffic is routed to it first, and the failover data center is used only when the primary is unavailable. - Option B: - Primary data cent...

Author: Mia · Last updated Jul 24, 2026

A real estate company is building an internal application so that real estate agents can upload photos and videos of various properties. The application will store these photos and videos in an Amazon S3 bucket as objects and will use Amazon DynamoDB to store corresponding metadata. The S3 bucket will be configured to publish all PUT events for new object uploads to an Amazon Simple Queue Service (Amazon SQS) queue. A compute cluster of Amazon EC2 instances will poll the SQS queue to find out about newly uploaded objects. The cluster will retrieve new objects, perform proprietary image and video recognition and classifica...

Key Factors in Reasoning: 1. No Public IP Addresses on EC2 Instances: - The company does not want public IP addresses on the EC2 instances, which means the instances must be in a private subnet. 2. Internet Access for EC2 Instances: - The EC2 instances need to access services like Amazon SQS, Amazon S3, and Amazon DynamoDB. The method of accessing these services should not involve using public IP addresses or require NAT gateways unless absolutely necessary. 3. Cost Efficiency: - As the application usage increases, it's important to choose a solution that scales cost-effectively. This includes minimizing the need for NAT gateways or public IP addresses, as both can add significant costs. 4. AWS Service Endpoints: - Using VPC endpoints for Amazon SQS, S3, and DynamoDB allows the EC2 instances to access these services directly through private IP addresses, ensuring security and reducing the need for internet-bound traffic. Analyzing the Options: - Option A: - Public subnet with disabled public IP address: While this approach would allow EC2 instances to access the internet via an internet gateway, it contradicts the requirement to avoid using public IP addresses. Disabling the public IP assignment on the EC2 instances doesn’t solve the need for a secure and cost-effective method to access services like SQS, S3, and DynamoDB. - Rejected: This setup involves unnecessary complexity with public access and doesn't meet the cost-efficient, private networking requirements. - Option B: - Private subnet with NAT gateway: This solution involves placing the EC2 instances in a private subnet and using a NAT gateway to provide internet access. However, NAT gateways are costly, especially as traffic scales. Also, the NAT gateway doesn’t...

Author: Jack · Last updated Jul 24, 2026

A company has an AWS Direct Connect connection between its on-premises data center in the United States (US) and workloads in the us-east-1 Region. The connection uses a transit VIF to connect the data center to a transit gateway in us-east-1. The company is opening a new office in Europe with a new on-premises data center in England. A Direct Connect connection will connect the new data center with some workloads that are running in a single VPC in the eu-west-2 Region. The company needs to connect the US data center and us-east-1 with the Europe da...

Key Factors in Reasoning: 1. Connectivity Between Data Centers and Regions: - The company needs to establish connectivity between the on-premises data centers in the US and Europe, and between workloads in the us-east-1 and eu-west-2 Regions. This requires a design that supports inter-region and inter-data center communication with low latency. 2. AWS Direct Connect Gateways and Transit Gateways: - The Direct Connect gateway allows for cross-region connectivity, and a transit gateway can provide centralized routing for multiple VPCs and on-premises connections. - SiteLink enables direct communication between VPCs and on-premises networks connected via Direct Connect without going through the internet. 3. Latency Considerations: - Minimizing latency is crucial, so the design should avoid unnecessary hops and leverage the lowest-latency path for inter-region traffic. 4. Solution Flexibility and Scalability: - The solution must be flexible and scalable to support future growth and potentially more regions or data centers. Analyzing the Options: - Option A: - Connect the VPC in eu-west-2 to the Europe data center via a Direct Connect gateway and a private VIF. Then, associate the transit gateway in us-east-1 with the same Direct Connect gateway and enable SiteLink for both the transit VIF and private VIF. - This solution uses the Direct Connect gateway to bridge the Europe data center and the VPC in eu-west-2, and it connects the US transit gateway to this Direct Connect gateway. However, it doesn't fully address the requirement of direct, low-latency communication between the US and Europe regions because the two regions (us-east-1 and eu-west-2) may need separate, dedicated connections. - Rejected: While it achieves inter-region connectivity, the method might not be as efficient for high-performance, low-latency traffic between the two regions. - Option B: - Connect the VPC in eu-west-2 to a new transit gateway and the Europe data center to the new transit gateway using a Direct Connect gateway and a new transit VIF. Peer this new transit gateway with the us-east-1 transit gateway, and enable SiteLink for both transit VIFs. - This ...

Author: Sara · Last updated Jul 24, 2026

A network engineer has deployed an Amazon EC2 instance in a private subnet in a VPC. The VPC has no public subnet. The EC2 instance hosts application code that sends messages to an Amazon Simple Queue Service (Amazon SQS) queue. The subnet has the default network ACL with no modification applied. The EC2 instance has the default security grou...

To diagnose why the EC2 instance is not able to send messages to Amazon SQS, let’s consider the key components that could impact connectivity and functionality: Option A: The EC2 instance is not attached to an IAM role that allows write operations to Amazon SQS. - Reasoning: This is a valid cause. An IAM role is needed for the EC2 instance to interact with AWS services like SQS. If the EC2 instance does not have the correct IAM permissions to write to SQS, it won't be able to send messages, even if the network configuration is correct. - Scenario: This is a common scenario where an IAM role might not be properly configured or attached to the EC2 instance. This would prevent the EC2 instance from interacting with SQS. - Conclusion: This is a possible cause. Option B: The security group is blocking traffic to the IP address range used by Amazon SQS. - Reasoning: This is not a likely cause. By default, EC2 instances in a default security group can send traffic to any destination, as outbound traffic is allowed. Unless the security group is specifically modified to restrict outbound traffic (which is not mentioned here), the security group would not block SQS communication. - Scenario: This would apply only if outbound traffic rules on the security group were explicitly restrictive, but that’s not stated in the problem. - Conclusion: This is not a likely cause. Option C: There is no interface VPC endpoint configured for Amazon SQS. - Reasoning: This could be a valid cause if the EC2 instance is in a private subnet without access to the internet. Without a VPC endpoint for SQS, the EC2 instance would not be able to send messages to SQS since there is no direct route to the SQS service. - Scenario:...

Author: Amira99 · Last updated Jul 24, 2026

A network engineer needs to standardize a company's approach to centralizing and managing interface VPC endpoints for private communication with AWS services. The company uses AWS Transit Gateway for inter-VPC connectivity between AWS accounts through a hub-and-spoke model. The company's network services team must manage all Amazon Route 53 zones and interface endpoints within a shared services AWS account. The company wants to use this centralized m...

To address the requirement of centralizing and managing interface VPC endpoints for private communication with AWS services (such as AWS Key Management Service or AWS KMS) in a hub-and-spoke architecture using AWS Transit Gateway, let's analyze each option carefully. Key Factors to Consider: - Centralized Management: The company wants to centralize the management of interface VPC endpoints in the shared services AWS account. - AWS Transit Gateway: Since the company uses AWS Transit Gateway in a hub-and-spoke model, VPCs must be able to communicate via the Transit Gateway without traffic going over the public internet. - Private DNS: The private DNS for AWS services like KMS must remain functional so that AWS resources can access KMS through the interface endpoint. Option A: In the shared services account, create an interface endpoint for AWS KMS. Modify the interface endpoint by disabling the private DNS name. Create a private hosted zone in the shared services account with an alias record that points to the interface endpoint. Associate the private hosted zone with the spoke VPCs in each AWS account. - Explanation: This option creates a centralized interface endpoint for KMS in the shared services account. It then disables the private DNS name and creates a private hosted zone in the shared services account, which is associated with the spoke VPCs. This approach ensures that the shared services account manages the interface endpoint and the DNS records, and it also centralizes the management of the KMS access. - Reasoning: By centralizing the DNS management in the shared services account and associating the private hosted zone with the spoke VPCs, the approach fits the company's goal of centralization. - Conclusion: This is a valid option. Option B: In the shared services account, create an interface endpoint for AWS KMS. Modify the interface endpoint by disabling the private DNS name. Create a private hosted zone in each spoke AWS account with an alias record that points to the interface endpoint. Associate each private hosted zone with the shared services AWS account. - Explanation: This option proposes creating a private hosted zone in each spoke account and associating it with the shared services account. However, this is not ideal for centralizing DNS management, as it requires managing separate hosted zones in each spoke account. - Reasoning: The company’s requirement is to centralize t...

Author: Leah · Last updated Jul 24, 2026

A development team is building a new web application in the AWS Cloud. The main company domain, example.com, is currently hosted in an Amazon Route 53 public hosted zone in one of the company's production AWS accounts. The developers want to test the web application in the company's staging AWS account by using publicly resolvable subdomains under the example.com domain with the ability to create and delete DNS records as needed. Developers have full access to Route 53 hosted zones within the staging account, but the...

In this scenario, the goal is to allow the development team in the staging AWS account to create and manage DNS records under the `example.com` domain while maintaining the production account's control over the domain. The developers are prohibited from accessing the production account, and they only have full access to Route 53 hosted zones within the staging account. Key Points to Consider: - The developers need to create and manage records under the `example.com` domain. - They do not have access to the production AWS account where the `example.com` public hosted zone resides. - The `staging.example.com` subdomain should be handled in the staging AWS account, and developers should be able to add and remove records. - Any changes in the staging account should not interfere with production resources or DNS management. Option A: Create a public hosted zone for example.com in the staging account. - Reasoning: This is not a valid solution. A public hosted zone for `example.com` should only exist in the production account where the actual `example.com` domain is managed. If the staging account had its own public hosted zone for `example.com`, it would conflict with the existing production domain, potentially causing DNS resolution issues. - Conclusion: Not selected. Option B: Create a staging.example.com NS record in the example.com domain. Populate the value with the name servers from the staging.example.com domain. Set the routing policy type to simple routing. - Reasoning: This is a valid option. By adding an `NS` record for `staging.example.com` in the `example.com` public hosted zone (managed in the production account), the `staging.example.com` subdomain can be delegated to a new hosted zone in the staging account. This allows the developers to create and manage records under `staging.example.com` without affecting the `example.com` domain. The `NS` record in `example.com` will point to the name servers of the hosted zone created for `staging.example.com` in the staging account. - Conclusion: Selected option. ...

Author: FlamePhoenix2025 · Last updated Jul 24, 2026

A company plans to deploy a two-tier web application to a new VPC in a single AWS Region. The company has configured the VPC with an internet gateway and four subnets. Two of the subnets are public and have default routes that point to the internet gateway. Two of the subnets are private and share a route table that does not have a default route. The application will run on a set of Amazon EC2 instances that will be deployed behind an external Application Load Balancer. The EC2 instances must not be directly accessible from the internet. The application will use an Amazon S3 bucket in the ...

To determine the most cost-effective and efficient solution, let's analyze the given requirements and options: Key Requirements: - The EC2 instances must not be directly accessible from the internet. - The EC2 instances should be able to perform S3 GET and PUT operations. - Minimize data transfer costs. Data Transfer Considerations: - Data transfer from EC2 instances to S3 within the same AWS region is free if done via a VPC endpoint. - Data transfer over the internet (via the public internet or through a NAT gateway) can incur additional costs, so we need to avoid routing S3 traffic over the public internet. Option A: Deploy the EC2 instances in the public subnets. Create an S3 interface endpoint in the VPC. Modify the application configuration to use the S3 endpoint-specific DNS hostname. - Reasoning: This option would place the EC2 instances in the public subnets, which is contrary to the requirement that the instances should not be directly accessible from the internet. Although the S3 interface endpoint would route S3 traffic directly to S3, the EC2 instances would still be publicly accessible, which is not desired. - Conclusion: This option is not suitable because it violates the requirement of keeping the EC2 instances private. Option B: Deploy the EC2 instances in the private subnets. Create a NAT gateway in the VPC. Create default routes in the private subnets to the NAT gateway. Connect to Amazon S3 by using the NAT gateway. - Reasoning: This option suggests using a NAT gateway, which would allow EC2 instances in the private subnets to access the internet, including Amazon S3. However, this would incur data transfer costs because the traffic from the private subnets to S3 would go through the NAT gateway, resulting in additional data transfer costs for outgoing traffic. - Conclusion: This option is not ideal because it increases costs due to the NAT gateway, which we want to minimize. Option C: Deploy the EC2 instances in the private subnets. Create an S3 gateway endpoint in the VPC. Specify the route table of the private...

Author: Sofia · Last updated Jul 24, 2026

A company has two AWS accounts one for Production and one for Connectivity. A network engineer needs to connect the Production account VPC to a transit gateway in the Connectivity account. The feature to auto accept shared attachments is not enabled on the transi...

To meet the requirements of connecting a VPC in the Production account to a transit gateway in the Connectivity account, while the feature to auto-accept shared attachments is not enabled, the network engineer needs to manually share the necessary resources and create attachments. Key Requirements: 1. The Production account's VPC should be connected to the transit gateway in the Connectivity account. 2. The auto-accept shared attachments feature is not enabled, so manual acceptance of resource shares and attachments is required. Key Components: - AWS Resource Access Manager (RAM): Used to share resources (such as a transit gateway or VPC subnets) across AWS accounts. - Attachment to Transit Gateway: This is required to connect the VPC to the transit gateway. Option A: 1. In the Production account: Create a resource share in AWS Resource Access Manager for the transit gateway. Provide the Connectivity account ID. Enable the feature to allow external accounts. 2. In the Connectivity account: Accept the resource. 3. In the Connectivity account: Create an attachment to the VPC subnets. 4. In the Production account: Accept the attachment. Associate a route table with the attachment. - Explanation: This approach first creates a resource share for the transit gateway in the Production account, which is not correct because the transit gateway belongs to the Connectivity account. In the next steps, the Connectivity account would accept the resource and create an attachment, which is also not the ideal flow. - Conclusion: This is incorrect because the resource share and attachment creation must start in the Connectivity account, not the Production account. Option B: 1. In the Production account: Create a resource share in AWS Resource Access Manager for the VPC subnets. Provide the Connectivity account ID. Enable the feature to allow external accounts. 2. In the Connectivity account: Accept the resource. 3. In the Production account: Create an attachment on the transit gateway to the VPC subnets. 4. In the Connectivity account: Accept the attachment. Associate a route table with the attachment. - Explanation: This option starts by sharing the VPC subnets in the Production account, but the resource share should be for the transit gateway (in the Connectivity account), not the VPC subnets. Creating an attachment in the Production account also doesn’t align with how resources are typically shared and attached to a...

Author: Leah · Last updated Jul 24, 2026

A company is running multiple workloads on Amazon EC2 instances in public subnets. In a recent incident, an attacker exploited an application vulnerability on one of the EC2 instances to gain access to the instance. The company fixed the application and launched a replacement EC2 instance that contains the updated application. The attacker used the compromised application to spread malware over the internet. The company became aware of the compromise through a notification f...

To determine the most effective solution with the least operational effort for identifying when an application deployed on an EC2 instance is spreading malware, let’s analyze each option in detail: A) Use Amazon GuardDuty to analyze traffic patterns by inspecting DNS requests and VPC flow logs. - Explanation: Amazon GuardDuty is a threat detection service that continuously monitors for malicious or unauthorized behavior by analyzing AWS CloudTrail event logs, VPC Flow Logs, and DNS logs. By inspecting traffic patterns such as DNS requests and VPC flow logs, GuardDuty can identify suspicious activities like botnet communication or unusual traffic patterns indicative of malware spreading. - Why Selected: This option provides an automated, low-maintenance solution. GuardDuty is a fully managed service, which minimizes operational overhead. It can help identify malware spreading across instances by analyzing network traffic and DNS activity. It also provides timely alerts and requires little configuration. - Why Other Options Are Rejected: - Option B (AWS managed decoy systems): Using decoy systems is effective for detecting unauthorized access but involves more operational effort, such as managing decoys, updating signatures, and handling alerts. - Option C (IDS appliance): While intrusion detection systems (IDS) are powerful for detecting suspicious activity, setting up and maintaining an IDS appliance involves operational overhead in terms of configuration, monitoring, and performance management. - Option D (Amazon Inspector): Amazon Inspector primarily focuses on security assessments (e.g., vulnerabilities, compliance) rather than inspecting network traffic. I...

Author: Liam · Last updated Jul 24, 2026

A company deploys a new web application on Amazon EC2 instances. The application runs in private subnets in three Availability Zones behind an Application Load Balancer (ALB). Security auditors require encryption of all connections. The company uses Amazon Route 53 for DNS and uses AWS Certificate Manager (ACM) to automate SSL/TLS certificate provisioning. SSL/TLS connections are terminated on the ALB. The company tests the application with a single EC2 instance and does not observe any problems. How...

To resolve the issue where users can log in but cannot use the application (with each new request restarting the login process), the problem is likely related to session stickiness. Stickiness ensures that requests from the same user are routed to the same EC2 instance, which is critical for maintaining session state during the login process. Without stickiness, each request may be routed to a different EC2 instance, resulting in the loss of session data and causing the login process to restart. Let’s analyze each option to determine the best solution: A) Modify the ALB listener configuration. Edit the rule that forwards traffic to the target group. Change the rule to enable group-level stickiness. Set the duration to the maximum application session length. - Explanation: This option suggests enabling group-level stickiness on the Application Load Balancer (ALB). However, ALB stickiness operates based on a cookie, and configuring group-level stickiness is not a standard term in ALB. It seems the intent is to modify the listener rules to support session persistence, but the proper configuration would involve target group stickiness (not group-level). This could work but the terminology and approach are slightly misdirected. - Why Rejected: Although the idea of enabling session persistence is correct, the way this is phrased is not the best practice for ensuring session continuity. B) Replace the ALB with a Network Load Balancer. Create a TLS listener. Create a new target group with the protocol type set to TLS. Register the EC2 instances. Modify the target group configuration by enabling the stickiness attribute. - Explanation: A Network Load Balancer (NLB) is designed for high performance and operates at the transport layer (Layer 4). It is not ideal for managing HTTP/HTTPS traffic with session stickiness because NLB does not offer built-in support for application-level cookies required for session stickiness. NLB is bet...

Author: Lucas Carter · Last updated Jul 24, 2026

A company recently migrated its Amazon EC2 instances to VPC private subnets to satisfy a security compliance requirement. The EC2 instances now use a NAT gateway for internet access. After the migration, some long-running database queries from private EC2 instances to a publicly accessible third-party database no longer receive responses. The database query logs reveal that the queries successfully c...

The issue described involves long-running database queries from private EC2 instances, where the queries eventually complete, but the responses are never received by the client EC2 instances. This suggests that the connection between the client EC2 instance and the third-party database is timing out before the response is received. Let's analyze each option and determine the best solution: A) Configure the NAT gateway timeout to allow connections for up to 600 seconds. - Explanation: The NAT gateway is responsible for forwarding traffic from the private subnet EC2 instances to the internet. However, NAT gateways do not have direct control over TCP connection timeouts, and they typically use connection tracking with timeouts that might be set to a lower value, resulting in dropped connections. Configuring the timeout on the NAT gateway is not a typical solution because the NAT gateway timeout configuration is not directly adjustable in terms of TCP session duration. - Why Rejected: NAT gateways typically manage traffic efficiently, but they don’t directly handle or allow modification of TCP session timeouts for the duration of connections in the way needed here. So, changing the NAT gateway timeout would likely not resolve the issue. B) Enable enhanced networking on the client EC2 instances. - Explanation: Enhanced networking uses the Elastic Network Adapter (ENA) or the Intel 82599 Virtual Function (VF) interface to improve the performance of EC2 instances, especially for high throughput and low latency. While this is beneficial for overall network performance, it does not directly address the issue of TCP connection timeouts for long-running queries. - Why Rejected: While enhanced networking improves general performance, it doesn't solve the is...

Author: Maya2022 · Last updated Jul 24, 2026

A company uses AWS Direct Connect to connect its corporate network to multiple VPCs in the same AWS account and the same AWS Region. Each VPC uses its own private VIF and its own virtual LAN on the Direct Connect connection. The company has grown and will soon surpass the limit...

In this scenario, the company is running into the AWS service limit for VPCs and private virtual interfaces (VIFs) on Direct Connect and needs a scalable solution to connect multiple VPCs to their corporate network over Direct Connect. Let’s analyze each option in detail to determine the most appropriate solution: A) Provision a new Direct Connect connection to handle the additional VPCs. Use the new connection to connect additional VPCs. - Explanation: Adding a new Direct Connect connection can increase the number of VPCs that can be connected to the corporate network, but this approach doesn't solve the core issue. AWS imposes limits on the number of private VIFs per Direct Connect connection, so adding additional connections doesn’t scale efficiently as the number of VPCs grows. Each new Direct Connect connection will require manual setup and maintenance, leading to operational overhead. - Why Rejected: This approach does not scale well because each new Direct Connect connection requires additional setup, and you would still hit service limits. It introduces unnecessary complexity as the number of VPCs increases. B) Create virtual private gateways for each VPC that is over the service quota. Use AWS Site-to-Site VPN to connect the virtual private gateways to the corporate network. - Explanation: This option involves using AWS Site-to-Site VPN in conjunction with virtual private gateways for each VPC that exceeds the limit. While VPN connections can provide a solution, they are typically less reliable and have higher latency and bandwidth limits compared to Direct Connect. This might not be the most efficient or scalable solution, especially for a growing number of VPCs. - Why Rejected: VPN connections are generally less scalable and have higher overhead, and would not be the most efficient or high-performance solution when the company is expanding its infrastructure. C) Create a Direct Connect gateway, and add virtual private gateway associations to the VPCs. Configu...

Author: Noah · Last updated Jul 24, 2026

A network engineer is designing a hybrid architecture that uses a 1 Gbps AWS Direct Connect connection between the company's data center and two AWS Regions: us-east-1 and eu-west-1. The VPCs in us-east-1 are connected by a transit gateway and need to access several on-premises databases. According to company policy, only one VPC in eu-west-1 can be connected to one on-premises server. The on-pr...

In this scenario, the network engineer needs to design a hybrid architecture using AWS Direct Connect to connect a data center with two AWS Regions (us-east-1 and eu-west-1). The design must accommodate specific requirements, including using a transit gateway in us-east-1 and private VIF for the VPC in eu-west-1, and ensure proper routing from Direct Connect to the AWS Regions while maintaining the separation of traffic. Let’s break down each option and determine the best fit. A) Create one hosted connection. Use a transit VIF to connect to the transit gateway in us-east-1. Use a private VIF to connect to the VPC in eu-west-1. Use one Direct Connect gateway for both VIFs to route from the Direct Connect locations to the corresponding AWS Region along the path that has the lowest latency. - Explanation: In this option, a single hosted connection is used, which may not be ideal for the scalability and redundancy requirements. A single Direct Connect gateway is used for routing traffic to both us-east-1 and eu-west-1, which could work under normal conditions but might not provide the necessary flexibility and reliability for handling distinct routing between different regions. - Why Rejected: A single Direct Connect gateway for both VIFs may not fully meet the requirement of isolating traffic between regions or properly segmenting traffic between the VPCs and on-premises databases. Also, a hosted connection might not provide the required performance and flexibility for the design. B) Create one hosted connection. Use a transit VIF to connect to the transit gateway in us-east-1. Use a private VIF to connect to the VPC in eu-west-1. Use two Direct Connect gateways, one for each VIF, to route from the Direct Connect locations to the corresponding AWS Region along the path that has the lowest latency. - Explanation: This option uses two Direct Connect gateways, one for each VIF. It isolates the traffic to ensure that the two AWS regions (us-east-1 and eu-west-1) use separate paths, which increases flexibility and scalability. However, using two Direct Connect gateways for a single hosted connection could complicate the routing and introduce unnecessary complexity. - Why Rejected: Using two Direct Connect gateways with a hosted conne...

Author: VenomousSerpent42 · Last updated Jul 24, 2026

A company has deployed an application in a VPC that uses a NAT gateway for outbound traffic to the internet. A network engineer notices a large quantity of suspicious network traffic that is traveling from the VPC over the internet to IP addresses that are included on a deny list. The network engineer must implement a solution to determine which AWS re...

To solve the problem of identifying the AWS resources generating suspicious traffic, we need a solution that minimizes cost and administrative overhead while providing the necessary visibility. Let's evaluate each option. Option A: Launch an EC2 instance with Traffic Mirroring - How it works: Traffic Mirroring can be set up to capture network traffic at the VPC level. The EC2 instance is the destination for the mirrored traffic, and the captured traffic is analyzed using open-source tools. - Advantages: - Provides detailed visibility into network traffic. - Allows deep packet inspection. - Disadvantages: - Requires launching and managing an EC2 instance for capturing traffic. - Can be costly due to traffic mirroring at the VPC level and the need for additional compute resources. - Involves administrative overhead of setting up and maintaining tools on the EC2 instance. - Not the most cost-effective for large-scale or long-term monitoring. Why it’s not selected: Traffic mirroring is a more granular approach but can be resource-intensive and costly, especially for continuous monitoring. It also requires manual analysis and management. Option B: Use VPC flow logs with a SIEM solution - How it works: VPC flow logs capture metadata about network traffic, and these logs can be ingested by a Security Information and Event Management (SIEM) solution to run queries to identify suspicious traffic. - Advantages: - SIEM solutions are designed for security analysis and can correlate events across various sources. - VPC flow logs provide visibility into traffic flow and can easily be linked to security threats. - Disadvantages: - SIEM solutions can be expensive, especially if running on an enterprise scale. - Requires integration with the SIEM solution, which can add complexity and administrative overhead. - It may not be the most cost-effective option for a smaller environment or for minimizing operational complexity. Why it’s not selected: While powerful, SIEM solutions can be costly and require significant administrative effort to maintain and configure. This solution might be overkill for simply identifying sources of suspicious traffic. Option C: Use VPC flow logs with CloudWatch Logs Insights - How it works: VPC flow logs capture metadata about network traffic, and the logs are published...

Author: Ryan · Last updated Jul 24, 2026

A company has its production VPC (VPC-A) in the eu-west-1 Region in Account 1. VPC-A is attached to a transit gateway (TGW-A) that is connected to an on-premises data center in Dublin, Ireland, by an AWS Direct Connect transit VIF that is configured for an AWS Direct Connect gateway. The company also has a staging VPC (VPC-B) that is attached to another transit gateway (TGW-B) in the eu-west-2 Region in A...

In this scenario, the company needs to establish connectivity between a staging VPC (VPC-B) in the eu-west-2 Region and an on-premises data center in Dublin, Ireland, leveraging a Direct Connect connection already established in the eu-west-1 Region (VPC-A). Let's evaluate each option: --- Option A: Configure inter-Region VPC peering between VPC-A and VPC-B. Add the required VPC peering routes. Add the VPC-B CIDR block in the allowed prefixes on the Direct Connect gateway association. - How it works: Inter-region VPC peering connects VPC-A (in eu-west-1) to VPC-B (in eu-west-2), allowing traffic between the two VPCs. The VPC-B CIDR would need to be included in the allowed prefixes list on the Direct Connect gateway. - Advantages: - Allows communication between VPC-A and VPC-B. - Relatively simple to configure if both VPCs are in different regions. - Disadvantages: - This approach only connects VPC-A and VPC-B. It doesn’t directly allow traffic from VPC-B to the on-premises data center. The Direct Connect gateway for VPC-A is configured for connectivity from VPC-A to the data center, not VPC-B. Why it’s not selected: While inter-region VPC peering would connect VPC-A and VPC-B, it does not solve the primary issue of routing traffic from VPC-B to the on-premises data center in Dublin, Ireland. It lacks a direct connection between VPC-B and the data center. --- Option B: Associate TGW-B with the Direct Connect gateway. Advertise the VPC-B CIDR block under the allowed prefixes. - How it works: This option configures TGW-B to advertise VPC-B's CIDR block over Direct Connect. By associating TGW-B with the Direct Connect gateway, the on-premises data center can reach VPC-B. - Advantages: - Directly connects VPC-B to the on-premises data center using the existing Direct Connect connection, making the solution straightforward. - Disadvantages: - While this would work in some cases, VPC-B is in a different region, and Direct Connect gateway associations are region-specific. You cannot directly associate a VPC's transit gateway (TGW-B) in one region with a Direct Connect gateway in another region. Why it’s not selected: This solution won’t work because Direct Connect gateway associations are regional. TGW-B in eu-west-2 cannot be associated directly with a Direct Connect gateway in eu-west-1. --- Option C: Configure another transit VIF on the Direct Connect connection and associate TGW-B. Advertise the VPC-B CIDR block under the allowed prefixes. - How it works: This solution creates an additional transit virtual interface (VIF) on the Direct Connect connection, which is associated with TGW-B (in the eu-west-2 region). The VPC-B CIDR block is advertised to the on-premises data center. - Advantages: - This allows VPC-B to be directly accessible from the on-premises data center via Direct Connect. - It avoids the need for complex configurations such as inter-region peering. - Disadvantages: - It requires an additional transit VIF, which incurs ex...

Author: Daniel · Last updated Jul 24, 2026

A company's network engineer is designing a hybrid DNS solution for an AWS Cloud workload. Individual teams want to manage their own DNS hostnames for their applications in their development environment. The solution must integrate the application-specific hostnames with the centrally managed DNS hostnames from the on-premises network and must provide bidirectional name resolu...

To meet the requirements of a hybrid DNS solution with bidirectional name resolution, integrating application-specific hostnames from the AWS environment with on-premises DNS, while minimizing management overhead, the network engineer must implement the following steps. Let's break down each option: --- Option A: Use an Amazon Route 53 Resolver inbound endpoint - How it works: An inbound endpoint allows DNS queries from the on-premises network to be routed to AWS-hosted DNS services, such as Route 53 private hosted zones. - Advantages: - Enables on-premises DNS servers to resolve AWS resources and applications in private hosted zones. - Supports bidirectional resolution by allowing DNS queries from on-premises to AWS. - Disadvantages: - The setup is straightforward and is required if you want the on-premises network to resolve AWS-hosted DNS names. Why it’s selected: The inbound endpoint is necessary to allow on-premises DNS servers to resolve AWS-hosted DNS records, enabling bidirectional resolution between the on-premises network and the AWS Cloud environment. --- Option B: Modify the DHCP options set by setting a custom DNS server value - How it works: Modifying the DHCP options set to point to specific DNS servers ensures that instances in the VPC use the correct DNS resolver (e.g., the Route 53 Resolver for integration with the on-premises DNS). - Advantages: - Ensures that VPC resources use the proper DNS servers, like those configured for hybrid resolution. - Disadvantages: - It only addresses DNS resolution on the AWS side, not the integration of DNS from on-premises to AWS. Why it’s rejected: While modifying the DHCP options is useful for controlling DNS resolution within the AWS VPC, it does not directly address the hybrid name resolution with the on-premises network. This option alone won't provide bidirectional resolution, which is crucial in the scenario. --- Option C: Use an Amazon Route 53 Resolver outbound endpoint - How it works: An outbound endpoint allows DNS queries from AWS to be forwarded to on-premises DNS servers. This supports bidirectional name resolution, enabling AWS-hosted resources to resolve names from on-premises DNS servers. - Advantages: - Facilitates name resolution from AWS to on-premises DNS resources, completing the bidirectional DNS integration. - Works in conjunction with the inbound endpoint for full hybrid DNS resolution. - Disadvantages: - Requires setup of the outbound endpoint along with an inbound endpoint to achieve bidirectional resolution. Why it’s selected: The outbound endpoint is required to ensure that AWS can resolve on-premises DNS records. This works together with the inbound endpoint to provide full bidirectional resolution between on-premises and AWS-hosted applications. --- Option D: Create DNS proxy servers - How i...

Author: Sofia · Last updated Jul 24, 2026

A company hosts a web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The ALB is the origin in an Amazon CloudFront distribution. The company wants to implement a custom authentication system that will provide a token for its authenticated customers. The web application must ensure that the GET/POST requests come from authenticated customers before it delivers the content. A network enginee...

To solve the problem of providing authenticated access to a web application hosted on EC2 instances behind an Application Load Balancer (ALB), we need a solution that ensures GET/POST requests come from authenticated customers. The goal is to implement the custom authentication system in an operationally efficient manner, ensuring the web application can identify authorized customers. Let’s evaluate each option: --- Option A: Use the ALB to inspect the authorized token inside the GET/POST request payload. Use an AWS Lambda function to insert a customized header to inform the web application of an authenticated customer request. - How it works: This approach involves using the ALB to inspect the token in the request, then triggering a Lambda function to add a custom header that informs the web application of the authentication status. - Advantages: - Lambda is flexible and can perform token validation and header insertion. - ALB and Lambda work well together and can be integrated with minimal overhead. - Disadvantages: - The ALB itself cannot natively inspect the request payload or body (it can inspect only headers and some metadata). This requires more complex integration and might involve additional steps (e.g., custom Lambda functions) to parse and validate the token inside the request body. Why it’s rejected: The primary limitation here is that the ALB cannot directly inspect the request payload or body. While Lambda can be used, additional complexity is added by the need to handle the token inspection outside the ALB itself. This makes the solution less efficient. --- Option B: Integrate AWS WAF with the ALB to inspect the authorized token inside the GET/POST request payload. Configure the ALB listener to insert a customized header to inform the web application of an authenticated customer request. - How it works: AWS WAF can be used to inspect the request for a valid token, and if valid, the ALB can insert a custom header to indicate the authentication status. - Advantages: - AWS WAF can inspect both headers and payloads for custom rules, making it a powerful tool for security purposes. - The ALB can be configured to pass headers to the web application. - Disadvantages: - AWS WAF has some limitations in processing payloads, especially for complex or large bodies, and might not be as efficient as a Lambda-based solution for more complex validation scenarios. Why it’s rejected: AWS WAF is powerful, but it may not be as flexible for detailed or complex validation tasks, especially when inspecting GET/POST request payloads with custom authentication tokens. It would be a good solution for simple token validation but is less suitable for the fine-grained control and customization needed in this case. --- Option C: Use an AWS Lambda@Edge funct...

Author: Aria · Last updated Jul 24, 2026

A company has created three VPCs: a production VPC, a nonproduction VPC, and a shared services VPC. The production VPC and the nonproduction VPC must each have communication with the shared services VPC. There must be no communication between the production VPC and the nonproduction VPC. A transit gateway is de...

To meet the requirements where: - The production VPC and the nonproduction VPC must have communication with the shared services VPC. - There must be no communication between the production VPC and the nonproduction VPC. A transit gateway is used to facilitate communication between the VPCs, but we must carefully configure the route tables on the transit gateway to prevent unintended communication while allowing the required communication. Key considerations: - Propagation of routes: Propagating routes means that the VPC will be aware of the networks in other VPCs attached to the transit gateway. We need to carefully control which VPCs are allowed to communicate with each other. - No communication between production and nonproduction VPCs: This is a critical constraint. The production VPC and nonproduction VPC should not see each other’s routes in the route table. - Communication with shared services VPC: Both the production and nonproduction VPCs must be able to communicate with the shared services VPC. Let's evaluate each option: --- Option A: Configure a route table with the production and nonproduction VPC attachments associated with propagated routes for only the shared services VPC. Create an additional route table with only the shared services VPC attachment associated with propagated routes from the production and nonproduction VPCs. - How it works: - One route table is configured for production and nonproduction VPCs, with routes only propagated for the shared services VPC. - A second route table is configured for the shared services VPC, propagating routes for production and nonproduction VPCs. - Advantages: - This ensures that the production and nonproduction VPCs can only reach the shared services VPC and cannot communicate with each other. - Disadvantages: - This configuration creates two route tables, but there is a possibility that it could inadvertently allow routing that doesn't strictly enforce separation between the production and nonproduction VPCs. Why it’s rejected: The second route table could potentially propagate routes for both the production and nonproduction VPCs into the shared services VPC, making it possible for both VPCs to see each other. While the separation is attempted, it's not completely clear how this setup would fully enforce isolation. --- Option B: Configure a route table with the production and nonproduction VPC attachments associated with propagated routes for each VPC. Create an additional route table with only the shared services VPC attachment associated with propagated routes from each VPC. - How it works: - A route table is created for both production and nonproduction VPCs, with propagated routes for each VPC, allowing communication. - A second route table is created for the shared services VPC, propagating routes from both the production and nonproduction VPCs. - Advantages: - Allows VPCs to route traffic to the shared services VPC, but it would inadvertently allow the production VPC and nonproduction VPC to see each other’s routes, which violates the...

Author: Deepak · Last updated Jul 24, 2026

A company is using an AWS Site-to-Site VPN connection from the company's on-premises data center to a virtual private gateway in the AWS Cloud Because of congestion, the company is experiencing availability and performance issues as traffic travels across the internet before the traffic reaches AWS. A network engineer must re...

Key Factors for Consideration: - Availability and Performance Issues: The main challenge is congestion on the internet affecting the VPN's availability and performance. - Minimum Administration Effort: The solution must minimize complexity and avoid a lot of manual intervention. - VPN vs. Direct Connection: The solution must be appropriate for reducing congestion in an existing VPN connection without requiring major infrastructure changes unless absolutely necessary. Evaluation of Options: A) Edit the existing Site-to-Site VPN connection by enabling acceleration. Stop and start the VPN service on the customer gateway for the new setting to take effect. - Pros: This solution is relatively simple. It involves minimal configuration changes by enabling acceleration, which is designed to improve performance. - Cons: It does not solve the issue of congestion on the internet backbone that the VPN traffic is experiencing. Acceleration may help, but it may not be enough to overcome the inherent internet congestion causing the problem. - Scenario: This option works well when the issue is related to latency or minor congestion but does not directly address significant performance degradation due to internet congestion. - Rejection Reason: While acceleration can help optimize traffic, it doesn’t resolve the underlying problem of internet congestion which is significantly affecting performance. B) Configure a transit gateway in the same AWS Region as the existing virtual private gateway. Create a new accelerated Site-to-Site VPN connection. Connect the new connection to the transit gateway by using a VPN attachment. Update the customer gateway device to use the new Site-to-Site VPN connection. Delete the existing Site-to-Site VPN connection. - Pros: Using a transit gateway could optimize network traffic routing within AWS, and creating a new accelerated VPN connection could potentially enhance performance. - Cons: This approach is complex and requires additional configuration, including transit gateway setup, VPN connection attachment, and deletion of the existing VPN connection. This introduces a higher level of administration effort than necessary for solving a congestion issue. - Scenario: This solution might be useful in scenarios where there is a complex network topology and multiple VPCs need to be interconnected. However, for the case at hand, where the issue is related to congestion, this approach seems over-engineered. - Rejection Reason: The complexity of adding a transit gateway may not be justified for simply improving VPN performance. This option involves more administrative overhead than necessary for resolving internet congestion issues. C) Create a new...

Author: Ava · Last updated Jul 24, 2026

An Australian ecommerce company hosts all of its services in the AWS Cloud and wants to expand its customer base to the United States (US). The company is targeting the western US for the expansion. The company's existing AWS architecture consists of four AWS accounts with multiple VPCs deployed in the ap-southeast-2 Region. All VPCs are attached to a transit gateway in ap-southeast-2. There are dedicated VPCs for each application service. The company also has VPCs for centralized security features such as proxies, firewalls, and logging. The company plans to duplicate the infrastructure from ap-southeas...

Key Factors for Consideration: - Maximize Bandwidth: The solution must ensure high bandwidth to meet performance needs between regions. - Minimize Latency: Reducing latency is critical to providing a seamless experience for customers in the US. - Minimize Operational Overhead: The solution should be easy to manage and require minimal manual intervention or configuration changes. - Scale and Flexibility: Since the company plans to duplicate its infrastructure and possibly expand further in the future, the solution should scale well. - Security: As the company has centralized security features in the architecture, maintaining a secure and isolated connection between regions is important. Evaluation of Options: A) Create VPN attachments between the two transit gateways. Configure the VPN attachments to use BGP routing between the two transit gateways. - Pros: VPN connections between transit gateways can provide secure connectivity across regions. - Cons: VPN connections tend to have higher latency and lower bandwidth compared to other solutions like AWS Direct Connect or transit gateway peering. The VPN connection would also require managing BGP routing, adding complexity and operational overhead. - Scenario: This solution might be useful for a low-cost, temporary setup but isn’t ideal for high bandwidth or low-latency connections between regions. - Rejection Reason: While this option provides secure connectivity, it introduces potential performance limitations and more complexity for routing configuration, which doesn’t meet the requirement to minimize latency and operational overhead. B) Peer the transit gateways in each Region. Configure routing between the two transit gateways for each Region's IP addresses. - Pros: Transit gateway peering between regions offers high bandwidth and low-latency connectivity between VPCs in different regions. It is a fully managed solution with reduced operational overhead compared to VPN-based solutions. - Cons: Peering may require careful routing setup, especially in complex environments with multiple VPCs. However, this is a standard practice for establishing inter-region connectivity in AWS. - Scenario: This solution works well for high-performance inter-region communication, especially when multiple VPCs in each region need to communicate efficiently. - Rejection Reason: There are no significant drawbacks to this option. ...

Author: Leah · Last updated Jul 24, 2026

An IoT company sells hardware sensor modules that periodically send out temperature, humidity, pressure, and location data through the MQTT messaging protocol. The hardware sensor modules send this data to the company's on-premises MQTT brokers that run on Linux servers behind a load balancer. The hardware sensor modules have been hardcoded with public IP addresses to reach the brokers. The company is growing and is acquiring customers across the world. The existing solution can no longer scale and is introducing additional latency because of the company's global presence. As a result, the company decides to migrate its entire infrastructure from on premises to the AWS Cloud. ...

Key Factors for Consideration: - Global Presence and Latency: The company needs to minimize latency as they have a global customer base. The existing infrastructure introduces latency, so the new solution should ensure low-latency access for global customers. - No Change to Hardware Sensor Modules: The hardware sensor modules are hardcoded with public IP addresses to connect to the brokers. This means the solution should not require changes to the existing modules. - Scalability: The solution should be scalable to accommodate future growth as the company expands globally. - Operational Overhead: The solution should minimize the need for reconfiguring or managing additional components that could increase operational complexity. Evaluation of Options: A) Place the EC2 instances behind a Network Load Balancer (NLB). Configure TCP listeners. Use Bring Your Own IP (BYOIP) from the on-premises network with the NLB. - Pros: - Using an NLB with TCP listeners is appropriate for MQTT, as it supports the protocol natively and can handle high-throughput, low-latency connections. - Bring Your Own IP (BYOIP) allows you to keep the same public IP addresses, which is ideal since the hardware sensor modules are hardcoded with those IPs. - Cons: - This solution doesn’t address the global latency issue. Since NLB only distributes traffic to a single region, customers far from that region will experience higher latency. - It does not provide global routing or acceleration. - Scenario: This solution is good for migrating existing services, but it does not optimize global performance or minimize latency across regions. B) Place the EC2 instances behind a Network Load Balancer (NLB). Configure TCP listeners. Create an AWS Global Accelerator accelerator in front of the NLB. Use Bring Your Own IP (BYOIP) from the on-premises network with Global Accelerator. - Pros: - The NLB with TCP listeners is well-suited for MQTT traffic. - Global Accelerator improves global access by routing traffic to the optimal AWS region based on latency and health, which reduces the latency and improves performance for global customers. - BYOIP allows the hardware sensor modules to continue using the existing public IP addresses. - Cons: - There m...

Author: Zara · Last updated Jul 24, 2026

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

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

Author: Liam · Last updated Jul 24, 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: Benjamin · Last updated Jul 24, 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: John · Last updated Jul 24, 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: Noah Williams · Last updated Jul 24, 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: Nia · Last updated Jul 24, 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: Liam123 · Last updated Jul 24, 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: Henry · Last updated Jul 24, 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: Emma · Last updated Jul 24, 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: Isabella · Last updated Jul 24, 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: Michael · Last updated Jul 24, 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: Deepak · Last updated Jul 24, 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: Ahmed · Last updated Jul 24, 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: Deepak · Last updated Jul 24, 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: Emily · Last updated Jul 24, 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: Andrew · Last updated Jul 24, 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: CrystalWolfX · Last updated Jul 24, 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: Benjamin · Last updated Jul 24, 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: Stella · Last updated Jul 24, 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: Emma Brown · Last updated Jul 24, 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: Ming88 · Last updated Jul 24, 2026

What Our Friends Say

What Our Friends Say

Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company is deploying a new application on AWS. The application uses dynamic multicasting. The company has five VPCs that are all attached to a transit gateway Amazon EC2 instances in each VPC need to be able to register dynamically to receive a mu...

A company has two AWS accounts one for Production and one for Connectivity. A network engineer needs to connect the Production account VPC to a transit gateway in the Connectivity account. The feature to auto accept shared attachments is not enabled on the transi...

A company uses AWS Direct Connect to connect its corporate network to multiple VPCs in the same AWS account and the same AWS Region. Each VPC uses its own private VIF and its own virtual LAN on the Direct Connect connection. The company has grown and will soon surpass the limit...

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 ...