Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has an AWS environment that includes multiple VPCs that are connected by a transit gateway. The company has decided to use AWS Site-to-Site VPN to establish connectivity between its on-premises network and its AWS environment.
The company does not have a static public IP address for its on-premises network. A network engineer must implement a solution to initiate the VPN connection on the AWS side of the connection for traffic from the AWS enviro...
To establish a VPN connection between an AWS transit gateway and the on-premises network without a static public IP address for the on-premises network, the network engineer must take the following key steps:
Key Considerations:
1. Dynamic IP Address: Since the on-premises network does not have a static IP address, the solution should allow the VPN to work even with dynamic IPs.
2. Initiate Connection from AWS: The VPN connection should be initiated from the AWS side, as per the requirement.
3. Protocol Support: The correct VPN protocols and configuration must be set to establish and maintain a secure connection.
4. VPN Tunnel Configuration: The options should facilitate a connection that works even when the on-premises network does not have a static public IP.
Option Analysis:
A) Configure the Site-to-Site VPN tunnel options to use Internet Key Exchange version 1 (IKEv1).
- IKEv1 is an older version of the protocol used in IPsec VPNs. It has some security vulnerabilities and limitations compared to IKEv2. AWS prefers IKEv2 for its improved security and reliability.
- Rejection Reason: IKEv1 is not recommended for new configurations due to its limitations and potential security risks.
B) Configure the Site-to-Site VPN tunnel options to use Internet Key Exchange version 2 (IKEv2).
- IKEv2 is the preferred and more secure option compared to IKEv1. It supports modern encryption and provides better security, faster reconnection after link failures, and improved reliability.
- Selection Reason: IKEv2 is the best choice because it meets modern security requirements and works more efficiently with AWS services.
C) Use a private certificate authority (CA) from AWS Private Certificate Authority to create a certificate.
- A private certificate authority (CA) is used when you want to manage your own certificates for internal purposes or private communications within your organization.
- However, the VPN connection between AWS and an on-premises network usually doesn't require private certificates in this context. AWS typically uses pre-shared keys (PSK) for Site-to-Site VPNs.
- Rejection Reason: Private CA is unnecessary for establishing a Site-to-Site VPN in this case.
D) Use a public certificate authority (CA) from AWS Private Certificate Authority to create a certificate.
- Similar to the...
Author: SilverBear · Last updated Jun 30, 2026
A company's AWS environment has two VPCs. VPC A has a CIDR block of 192.168.0.0/16. VPC B has a CIDR block of 10.0.0.0/16. Each VPC is deployed in a separate AWS Region. The company has remote users who work outside the company's offices. These users need to connect to an application that is running in the VPCs.
Traffic to and from the VPCs over the internet must be encrypted. A network engineer must set up connectivi...
To meet the requirement of securely connecting remote users to the application running in the two VPCs (VPC A and VPC B), the solution must ensure that traffic between the remote users and the VPCs is encrypted over the internet and has minimal management overhead. Here's the breakdown of the options:
Key Requirements:
1. Remote Access: Remote users need to connect to the application running in the two VPCs.
2. Encryption: The traffic between the remote users and the VPCs must be encrypted.
3. Minimal Management Overhead: The solution must minimize ongoing management tasks.
4. Separate Regions: The VPCs are deployed in separate AWS Regions.
Option Analysis:
A) Establish an AWS Site-to-Site VPN connection between VPC A and VPC B.
- A Site-to-Site VPN connects on-premises networks or remote AWS networks. While this would provide encrypted communication between the two VPCs, it does not directly address remote users connecting to the application.
- Rejection Reason: This solution only connects the VPCs, not the remote users. It also requires managing the VPN infrastructure, which does not minimize overhead in this case.
B) Establish a VPC peering connection between VPC A and VPC B.
- VPC Peering allows direct traffic between VPCs. However, it requires managing routing between VPCs. It doesn't inherently provide remote access to users outside of the VPCs, and it does not directly address encrypted connections over the internet.
- Rejection Reason: VPC Peering only facilitates communication between VPCs but doesn't cater to remote user access. The solution requires a separate remote access mechanism.
C) Create an AWS Client VPN endpoint in VPC A and VPC B. Add an authorization rule to grant access to VPC A and VPC B.
- AWS Client VPN provides encrypted access for remote users. By setting up a Client VPN endpoint in both VPCs, remote users can securely access resources in both VPCs. The authorization rules allow remote users to access resources in both VPCs.
- Selection Reason: This approach provides secure, encrypted access to both VPCs for remote users ...
Author: Vivaan · Last updated Jun 30, 2026
A company uses Amazon Route 53 to register a public domain, example.com, in an AWS account. A central services group manages the account. The company wants to create a subdomain, test.example.com, in another AWS account to offer name services for Amazon EC2 instances that are hosted in the account. The company does not want to migrate the parent domain to the subdomain account.
A network engineer...
The task is to create a subdomain, test.example.com, in a separate AWS account while keeping example.com in the original AWS account. The network engineer has created a Route 53 hosted zone for the subdomain in the second account, and now needs to ensure the DNS resolution between the parent domain and subdomain works seamlessly.
Option Analysis:
1. Option A: Add records for the hosts of the new subdomain to the new Route 53 hosted zone.
- Explanation: This step is necessary for defining specific resource records (such as A records, CNAME records, etc.) within the new Route 53 hosted zone for the subdomain. This allows the subdomain to resolve to the correct resources (e.g., EC2 instances) within the second AWS account.
- Reason for selection: It is a required step to ensure that DNS queries for resources under test.example.com will return the correct results.
2. Option B: Update the DNS service for the parent domain by adding name server (NS) records for the subdomain.
- Explanation: To delegate authority for the subdomain test.example.com to another AWS account, you must add NS records in the parent domain's hosted zone (in the first account) pointing to the name servers of the new hosted zone for the subdomain.
- Reason for selection: This delegation step is essential so that DNS queries for test.example.com are resolved by the hosted zone in the second AWS account.
3. Option C: Update the DNS service for the subdomain by adding name server (NS) records for the parent domain.
- Explanation: This step is unnecessary because test.example.com is the subdomain, and there’s no need to point it to the name servers of the parent domain example.com. The parent domain's name ...
Author: Maya · Last updated Jun 30, 2026
An IoT company collects data from thousands of sensors that are deployed in the Unites States and South Asia. The sensors use a proprietary communication protocol that is built on UDP to send the data to a fleet of Amazon EC2 instances. The instances are in an Auto Scaling group and run behind a Network Load Balancer (NLB). The instances, Auto Scaling group, and NLB are deployed in the us-west-2 Region.
Occasion...
Problem Analysis:
The IoT company is experiencing packet loss when data is sent from sensors located in South Asia to EC2 instances deployed in the us-west-2 Region. The data travels over the internet using UDP, and this loss could be due to network congestion, latency issues, or unreliable network paths.
Solution Options:
1. Option A: Use AWS Global Accelerator with the existing NLB.
- Explanation: AWS Global Accelerator improves the availability and performance of applications by directing user traffic to the optimal endpoint based on health, geography, and routing policies. By using Global Accelerator in conjunction with the existing Network Load Balancer (NLB), the company can ensure that traffic from sensors in South Asia is routed through the AWS Global Accelerator, which leverages the AWS global network to reduce latency and improve packet delivery success.
- Reason for selection: This solution enhances the availability and reliability of the UDP traffic from South Asia by routing it over a more reliable network, reducing packet loss.
2. Option B: Create an Amazon CloudFront distribution. Specify the existing NLB as the origin.
- Explanation: CloudFront is primarily used for HTTP/HTTPS traffic and can’t be used for UDP traffic. Since the sensors use a proprietary communication protocol based on UDP, CloudFront is not an appropriate solution.
- Reason for rejection: CloudFront is not designed to work with UDP traffic, and therefore, cannot be used to resolve the issue of lost data from sensors.
3. Option C: Create a second deployment of the EC2 instances and the NLB in the ap-south-1 Region. Use an Amazon Route 53 latency routing policy to resolve to the Region that provides the least latency.
- Explanation: Deploying EC2 instances and NLBs in the ap-south-1 (Mumbai) Region would provide a closer endpoint for sensors in South Asia, reducing network latency and possibly preventing packet loss. The Route 53 latency routing policy will direct traffic to the region with the lowest late...
Author: FrostFalcon88 · Last updated Jun 30, 2026
A company has an application that runs on a fleet of Amazon EC2 instances. A new company regulation mandates that all network traffic to and from the EC2 instances must be sent to a centralized third-par...
To meet the new company regulation requiring that all network traffic to and from the EC2 instances be sent to a centralized third-party EC2 appliance for content inspection, the solution needs to provide a way to mirror traffic from the EC2 instances to a dedicated appliance. Let's evaluate each option.
Option Analysis:
1. Option A: Configure VPC flow logs on each EC2 network interface. Publish the flow logs to an Amazon S3 bucket. Create a third-party EC2 appliance to acquire flow logs from the S3 bucket. Log in to the appliance to monitor network content.
- Explanation: VPC flow logs capture metadata about network traffic, such as IP addresses, ports, and protocols, but do not capture the actual content of the traffic. This option will not meet the requirement for content inspection, as it does not provide the actual traffic payloads, just metadata.
- Reason for rejection: This solution doesn't provide the actual data content necessary for inspection, making it unsuitable for content inspection.
2. Option B: Create a third-party EC2 appliance in an Auto Scaling group fronted by a Network Load Balancer (NLB). Configure a mirror session. Specify the NLB as the mirror target. Specify a mirror filter to capture inbound and outbound traffic. For the source of the mirror session, specify the EC2 elastic network interfaces for all the instances that host the application.
- Explanation: This solution uses traffic mirroring to capture the actual packet-level network traffic from the EC2 instances and sends it to the third-party appliance. By placing the appliance behind an NLB, traffic can be directed for inspection. Traffic mirroring allows the appliance to analyze the traffic in real time.
- Reason for selection: This solution is ideal because it mirrors the actual traffic for content inspection and can handle both inbound and outbound traffic, fulfilling the regulation requirement.
3. Option C: Configure a mirror session. Specify an Amazon Kinesis Data F...
Author: Chloe · Last updated Jun 30, 2026
A company has two AWS Direct Connect links. One Direct Connect link terminates in the us-east-1 Region, and the other Direct Connect link terminates in the af-south-1 Region. The company is using BGP to exchange routes with AWS.
How...
To configure AWS Direct Connect links to prioritize one link over the other while maintaining the secondary link, we need to take into account BGP attributes like local preference and community tags. Here's how to assess the provided options:
Key Factors:
1. Local Preference: This BGP attribute is used to influence the outbound traffic routing. The higher the value, the more preferred the route. If we want to make us-east-1 the primary link, we need to set a higher local preference for that link.
2. Community Tags: Community tags can be used to control routing behavior. Tags like `7224:7100` and `7224:7300` can be configured on the BGP peers to mark routes and influence routing decisions.
3. Redundancy: We want to ensure that the af-south-1 link serves as a secondary path (backup link). Therefore, the local preference for af-south-1 should be lower than for us-east-1, making af-south-1 less preferred by default.
Analysis of Options:
- Option A:
- Community tags:
- us-east-1 → `7224:7100` (typically for primary path)
- af-south-1 → `7224:7300` (typically for secondary path)
- Local preference:
- us-east-1 → 200 (higher, making it more preferred)
- af-south-1 → 50 (lower, making it less preferred)
This is a valid configuration, where us-east-1 is preferred due to the higher local preference, and af-south-1 serves as the secondary link.
- Option B:
- Community tags:
- us-east-1 → `7224:7300` (typically for secondary path)
- af-south-1 → `7224:7100` (typically for primary path)
- Local preference:
- us-east-1 → 200 (h...
Author: Sofia2021 · Last updated Jun 30, 2026
A team of infrastructure engineers wants to automate the deployment of Application Load Balancer (ALB) components by using the AWS Cloud Development Kit (AWS CDK). The CDK application must deploy an infrastructure stack that is reusable and consistent across multiple environments, AWS Regions, and AWS accounts.
The lead network architect on the project has already bootstrapped the target accounts. The lead network architect also has deployed core network components such as VPCs and Amazon Route 53 private hosted zones across the multiple environments and Regions. The infras...
Problem Context:
The infrastructure engineers want to automate the deployment of Application Load Balancer (ALB) components using AWS CDK across multiple environments, regions, and accounts. The goal is to leverage existing network components (VPCs, Route 53 private hosted zones) and ensure reusability and consistency with the least manual effort.
Solution Approach:
The most suitable approach involves leveraging AWS CDK’s features for environment and region-specific configurations. Let’s evaluate the provided options:
---
Option A: Design the CDK application to read AWS CloudFormation parameters for the values that vary across environments and Regions. Reference these variables in the CDK stack for resources that require the variables.
- Explanation: Using CloudFormation parameters allows the CDK application to be flexible and reusable across different environments and regions. The parameters can be defined for values like VPC IDs, subnet IDs, Route 53 private hosted zones, etc., which will vary depending on the environment. This approach makes it possible to configure the infrastructure dynamically during deployment, without the need for hardcoding values.
- Reason for selection: This approach allows for parameterization of values, ensuring that the stack can be reused and customized easily across different environments and regions. It minimizes manual work and hardcoding, which is ideal for scaling the infrastructure across accounts and regions.
- Reason for rejection: The option is rejected for not being the most straightforward solution, as AWS CDK provides more flexible mechanisms to handle environment-specific configurations (like using context values or environment variables directly).
---
Option B: Design the CDK application to read environment variables that contain account and Region details at runtime. Use these variables as properties of the CDK stack. Use context methods in the CDK stack to retrieve variable values.
- Explanation: Environment variables can be used to inject account and region-specific details at runtime. These can be passed to the CDK stack during execution. Using context methods like `cdk.context.get()` can help retrieve environment-specific configuration values, making the stack adaptable and reusable. This method allows dynamically pulling environment settings for each deployment without modifying the CDK code for each environment.
- Reason for selection: This is a highly dynamic approach, as it provides flexibility by allowing the CDK stack to be context-aware, and the values can be passed in at runtime. This reduces manual steps and ensures consistency in deployments.
- Reason for rejection: Although it offers flexibility, the reliance on environment variables requires a good infrastructure setup to manage these variables across different environments, which might be more complicated than using CloudFormation parameters.
---
Option C: Create a dedicated account for shared application services in the multi-a...
Author: Emma · Last updated Jun 30, 2026
A company has critical VPC workloads that connect to an on-premises data center through two redundant active-passive AWS Direct Connect connections. However, a recent outage on one Direct Connect connection revealed that it takes more than a minute for traffic to fail over to the secondary Direct Connect connection. The comp...
To solve the problem of reducing the BGP failover time from minutes to seconds, let's evaluate each of the proposed solutions and their respective benefits.
Option A: Reduce the BGP hold-down timer that is configured on the BGP sessions on the Direct Connect connection VIFs.
- BGP Hold-down Timer: The BGP hold-down timer defines how long BGP waits to declare a route as invalid after a failure. By reducing this timer, you can potentially speed up the detection of failures, but BGP still needs to wait for a certain period before it can advertise a new route.
- Drawback: While reducing the hold-down timer might reduce failover time to some extent, BGP isn't inherently fast in responding to network failures (due to its reliance on timers). BGP is a more complex protocol meant to handle larger network topologies, and it doesn't optimize for sub-second failover. Therefore, this approach will not provide a significant reduction in failover time.
Option B: Configure an Amazon CloudWatch alarm for the Direct Connect connection state to invoke an AWS Lambda function to fail over the traffic.
- CloudWatch Alarm with Lambda: This method triggers a failover based on the state of the Direct Connect connection. However, it requires detection of the connection failure by CloudWatch, followed by the invocation of a Lambda function to reconfigure routing.
- Drawback: While this might be useful for monitoring, it does not address the fundamental issue of BGP failover time. CloudWatch detection itself may not be instantaneous, and invoking Lambda could add additional delay. It’s also not directly related to reducing the time BGP takes to detect and propagate changes in routing, which is the core of the failover process.
Option C: Configure Bidirectional Forwarding Detection (BFD) on the Direct Connect...
Author: ShadowWolf101 · Last updated Jun 30, 2026
A European car manufacturer wants to migrate its customer-facing services and its analytics platform from two on-premises data centers to the AWS Cloud. The company has a 50-mile (80.4 km) separation between its on-premises data centers and must maintain that separation between its two locations in the cloud. The company also needs failover capabilities between the two locations in the cloud.
The company's infrastructure team creates several accounts to separate workloads and responsibilities. The company provisions resources in the eu-west-3 Region and in the eu-central-1 Region. The company selects an AWS Direct Connect Partner in each Region and requests two resilient 1 Gbps fiber connections fro...
To meet the requirements of the European car manufacturer's solution—maintaining separation between its two cloud locations, failover capabilities, and connectivity between all VPCs and on-premises networks—let’s carefully evaluate the given options.
Key Requirements:
1. Separation between locations: The solution needs to maintain separation between the two locations in the cloud (eu-west-3 and eu-central-1).
2. Failover capabilities: The company needs to ensure that network issues will not disrupt access to services in either Region, so failover between Regions is essential.
3. VPC Connectivity: All VPCs in both Regions must be able to communicate with each other and with the on-premises network.
4. Multiple connections for resilience: The company has requested two resilient 1 Gbps fiber connections from each AWS Direct Connect partner.
Now let’s evaluate each option:
Option A:
Create a Direct Connect gateway. Create a private VIF on each of the Direct Connect connections. Attach the private VIFs to the Direct Connect gateway. Use equal-cost multi-path (ECMP) routing to aggregate the four connections across the two Regions. Attach the Direct Connect gateway directly to each VPC's virtual private gateway.
- Analysis: This solution involves using a Direct Connect gateway, attaching VIFs (Virtual Interfaces) to it, and using ECMP routing to aggregate the connections. It suggests directly connecting the Direct Connect gateway to each VPC’s virtual private gateway (VGW).
- Issue: This solution doesn't fully leverage the required regional failover capabilities and cross-region connectivity. Attaching the Direct Connect gateway directly to each VGW limits the flexibility of routing between VPCs across regions. Additionally, ECMP helps distribute traffic across multiple paths, but it doesn’t provide robust failover if one of the regions or connections goes down, nor does it address VPC-to-VPC connectivity across regions directly.
Rejected because it doesn't offer the necessary cross-region failover and VPC-to-VPC routing for separation and resiliency.
Option B:
Create a Direct Connect gateway. Create a transit gateway. Attach the transit gateway to the Direct Connect gateway. Create a transit VIF on each of the Direct Connect connections. Attach the transit VIFs to the Direct Connect gateway. Use a link aggregation group (LAG) to aggregate the four connections across the two Regions. Attach the transit gateway directly to each VPC.
- Analysis: This solution uses a Direct Connect gateway and a transit gateway for both cross-region connectivity and failover. The LAG enables aggregation of the four 1 Gbps connections, improving resilience and redundancy.
- Issue: While this solution aggregates connections for better resilience, it doesn't provide direct pe...
Author: Ming · Last updated Jun 30, 2026
A company wants to analyze TCP traffic to the internet. The traffic originates from Amazon EC2 instances in the company's VPC. The EC2 instances initiate connections through a NAT gateway. The required information includes source and destination IP addresses, ports, and the first 8 bytes of payload of TCP seg...
To meet the company's requirement of analyzing TCP traffic and collecting detailed information such as source and destination IP addresses, ports, and the first 8 bytes of payload from TCP segments, we need to evaluate the available options based on the following criteria:
1. Capture the required traffic details (source/destination IP, ports, and payload).
2. Collect and store the traffic data for analysis.
3. Analyze the data effectively to gain insights into the traffic patterns and behaviors.
Option A: Set up the EC2 instances as VPC traffic mirror sources. Deploy software on the traffic mirror target to forward the data to Amazon CloudWatch Logs. Analyze the data by using CloudWatch Logs Insights.
- VPC Traffic Mirroring: This solution captures and mirrors traffic at the network interface level, including the detailed information needed such as TCP/IP headers and the first 8 bytes of the payload (if configured). By setting the EC2 instances as the mirror sources, you can capture the traffic initiated by these instances.
- CloudWatch Logs: The mirrored traffic is forwarded to CloudWatch Logs, where you can analyze it using CloudWatch Logs Insights. This option allows for deep analysis and querying of the captured data, but CloudWatch Logs Insights is typically used for log data and might not be optimal for network traffic data at a deep packet inspection level.
Reason for selection: VPC traffic mirroring is a direct solution for capturing the detailed TCP traffic data required. It can forward the relevant data to CloudWatch Logs for analysis. However, the CloudWatch Logs Insights might not be the most efficient or detailed tool for the traffic analysis, especially when needing to handle raw network traffic.
Option B: Set up the NAT gateway as a VPC traffic mirror source. Deploy software on the traffic mirror target to forward the data to an Amazon OpenSearch Service cluster. Analyze the data by using OpenSearch Dashboards.
- NAT Gateway as Mirror Source: NAT gateways are designed to handle and forward traffic between private instances in the VPC and the internet, but they don't directly support traffic mirroring. You cannot mirror traffic from the NAT gateway in the same way you can from EC2 instances or ENIs (Elastic Network Interfaces).
- OpenSearch for Analysis: OpenSearch Service could be useful for analyzing network data and providing dashboards for visualization. However, capturing the required TCP traffic dat...
Author: Jack · Last updated Jun 30, 2026
A company has three VPCs in a single AWS Region. Each VPC contains 15 Amazon EC2 instances, and no connectivity exists between the VPCs.
The company is deploying a new application across all three VPCs. The application requires high bandwidth between the nodes. A network engineer...
To meet the requirement for high-bandwidth connectivity between three VPCs in a single AWS region, let's evaluate each of the proposed options in terms of scalability, throughput, and ease of implementation.
Option A: Configure a transit gateway. Attach each VPC to the transit gateway. Configure static routing in each VPC to route traffic to the transit gateway.
- Transit Gateway: The AWS Transit Gateway is designed to simplify and scale network architectures by enabling communication between multiple VPCs, on-premises networks, and remote networks. The transit gateway provides high-throughput and low-latency communication between VPCs by acting as a central hub.
- High Throughput: A transit gateway supports high throughput and can handle high-bandwidth traffic between VPCs. It also allows for simpler routing and scaling compared to VPC peering.
- Scalability: The transit gateway supports up to 50 Gbps of throughput per connection and can easily scale with the addition of more VPCs.
- Routing: The solution uses dynamic or static routing (with static routing specified here), making it flexible and easy to manage.
- Advantage: This solution meets the need for high-bandwidth connectivity between VPCs and can scale as the number of VPCs or the required bandwidth increases.
Selected option: This is the best option as it provides the highest throughput with easy management and scalability.
Option B: Configure VPC peering between the three VPCs. Configure static routing to route traffic between the three VPCs.
- VPC Peering: In this solution, VPC peering is set up between each pair of VPCs. While this can work for smaller environments, it quickly becomes complex and inefficient as the number of VPCs grows.
- Throughput: VPC peering can provide good throughput but has limitations in terms of managing traffic at scale. The bandwidth depends on the type of instance and the network performance of each VPC's connection.
- Scalability: When using VPC peering, each additional VPC requires setting up new peering connections. This can create a large and hard-to-manage mesh of peerings that becomes more difficult to maintain over time, particularly with 3 VPCs.
- Routing: Static routing in each VPC would require manual management and updates as the network grows.
- Drawback: Although VPC peering can work for smaller, simpler networks, it’s not ideal for scalability and maintaining high-throughput connectivity, especially in larger setups like the one described.
Rejected: This option is less scalable, and maintaining multiple ...
Author: Ethan · Last updated Jun 30, 2026
A network engineer needs to deploy an AWS Network Firewall firewall into an existing AWS environment. The environment consists of the following:
* A transit gateway with all VPCs attached to it
* Several hundred application VPCs
* A centralized egress internet VPC with a NAT gateway and an internet gateway
* A centralized ingress internet VPC that hosts public Application Load Balancers
* On-premises connectivity through an AWS Direct Connect gateway attachment
The application VPCs have workloads deployed across multiple Availability Zones in private subnets with the VPC route table s default route (0.0.0.0/0) pointing to the transit gateway. The Network Firewall firewall needs to inspect east-west (VPC-to-VPC) traffic and north-south (internet-bound and on...
To deploy AWS Network Firewall into the existing AWS environment with minimal architectural changes and ensure that both east-west (VPC-to-VPC) and north-south (internet-bound and on-premises network) traffic are inspected, we need to choose the most efficient configuration. Let's evaluate the requirements and each option.
Key Requirements:
1. Inspect East-West and North-South Traffic: The firewall must inspect both VPC-to-VPC (east-west) traffic and traffic going to/from the internet or on-premises (north-south).
2. Suricata-Compatible Rules: The firewall must support Suricata-compatible rule sets for traffic inspection.
3. Minimal Architectural Changes: The deployment should require the least disruption to the current network setup, which already involves VPCs connected through a transit gateway.
Option A: Deploy Network Firewall in all Availability Zones in each application VPC.
- Analysis: Deploying the firewall in every Availability Zone (AZ) of each application VPC would be very complex and would require significant changes to the VPCs’ architecture. Each application VPC would need a firewall endpoint in each AZ, and the traffic inspection would need to be configured within each individual VPC.
- Drawback: This approach would involve many changes and isn’t the most efficient way to integrate the firewall, especially since the goal is minimal disruption and it complicates network management across many VPCs.
Rejected: This approach introduces significant complexity and architectural changes, which goes against the goal of minimal disruption.
Option B: Deploy Network Firewall in all Availability Zones in a centralized inspection VPC.
- Analysis: This approach involves deploying the Network Firewall in a centralized inspection VPC that spans across all Availability Zones. By doing this, traffic from all application VPCs can be routed through this inspection VPC, allowing for centralized inspection of both east-west and north-south traffic.
- Minimal Changes: This option only requires changes to the routing and firewall inspection in the transit gateway and the centralized inspection VPC, which minimizes architectural disruption.
- Scalability: A centralized inspection VPC is easier to scale and manage compared to deploying firewalls in each AZ of every application VPC.
Selected: This is the best choice because it allows for centralized management and inspection without the need to deploy firewalls in each AZ of every VPC. This is highly scalable and less disruptive.
Option C: Update the HOME_NET rule group variable to include all CIDR ranges of the VPCs and on-premises networks.
- Analysis: The `HOME_NET` variable in Suricata rule sets defines the internal network addresses (for instance, VPC CIDR ranges) that should be considered as the "home" network for traffic inspection. Updating this variable ensures that the firewall inspects traffic originating from the application VPCs and on-premises networks.
- Requirement: This step is necessary to ensure that the firewall correctly identifies and i...
Author: Ethan · Last updated Jun 30, 2026
A company is using a shared services VPC with two domain controllers. The domain controllers are deployed in the company's private subnets. The company is deploying a new application into a new VPC in the account. The application will be deployed onto an Amazon EC2 for Windows Server instance in the new VPC. The instance must join the existing Windows domain that is supported by the domain controllers in the shared services VPC.
A transit gateway is attached to both the shared services VPC and the new VPC. The company has updated the route tables for the transit gateway, the shared services VPC, and the new VPC. The security groups for the domain controllers and the instance are...
To troubleshoot the issue of the EC2 instance being unable to join the domain, we need to identify the problem with minimal operational overhead. Let's analyze the options:
Option A: Use AWS Network Manager to perform a route analysis for the transit gateway network. Specify the existing EC2 instance as the source. Specify the first domain controller as the destination. Repeat the route analysis for the second domain controller.
- Reasoning: This option checks if the routing between the EC2 instance and the domain controllers is functioning correctly. By analyzing the route path, you can confirm that the traffic between the EC2 instance and the domain controllers is correctly routed via the transit gateway.
- Pros: It is a good way to verify whether the network routing is set up correctly without having to dive into detailed logs or packet captures. This can help identify if the traffic is being blocked or misrouted.
- Cons: This only provides a routing analysis and may not give you detailed information on network-level connectivity issues such as port blocking or application-level failures.
- Conclusion: This option is useful for ensuring the EC2 instance and domain controllers can communicate, but it does not provide detailed packet-level insights.
Option B: Use port mirroring with the existing EC2 instance as the source and another EC2 instance as the target to obtain packet captures of the connection attempts.
- Reasoning: Port mirroring would allow you to capture all the network traffic between the EC2 instance and the domain controllers. This would be valuable for troubleshooting domain join issues because it can show whether domain-related traffic (e.g., LDAP, Kerberos) is even reaching the domain controllers.
- Pros: This option provides the most granular visibility into network traffic, making it easier to diagnose specific issues with domain join operations.
- Cons: This option introduces operational overhead, as it involves setting up packet capture instances and analyzing large amounts of traffic. It's effective but not the least operational overhead.
- Conclusion: While highly effective, it might be more complicated and time-consuming than necessary for a first-level investigation.
Option C: Review the VPC flow logs on the shared services VPC and the new VPC.
- Reasoning: VPC flow logs can show whether traffic is being allowed or denied between the EC2 instance and the domain controllers. By examining flow logs, you can see if the necessary traffic (like DNS, Kerberos, or LDAP) is being blocked, which would explain why the EC2 instance cannot join the domain.
- Pros: This p...
Author: SolarFalcon11 · Last updated Jun 30, 2026
A company has an order processing system that needs to keep credit card numbers encrypted. The company's customer-facing application runs as an Amazon Elastic Container Service (Amazon ECS) service behind an Application Load Balancer (ALB) in the us-west-2 Region. An Amazon CloudFront distribution is configured with the ALB as the origin. The company uses a third-party trusted certificate authority to provision its certificates.
The company is using HTTPS for encryption in transit. The company needs additional ...
To meet the requirements of keeping credit card numbers encrypted during processing, field-level encryption must be enabled for specific data that needs additional protection. Here's the reasoning behind the selected options and the rejection of others:
Option A: Import the third-party certificate for the ALB. Associate the certificate with the ALB. Upload the certificate for the CloudFront distribution into AWS Certificate Manager (ACM) in us-west-2.
- Reasoning: This option addresses the secure transmission of data between the client and the CloudFront distribution. However, this option does not address field-level encryption, which is a requirement for encrypting the sensitive data at the field level during processing.
- Conclusion: While necessary for encryption in transit, it doesn't solve the issue of field-level encryption for sensitive data like credit card numbers. Hence, this option does not meet the requirement.
Option B: Import the third-party certificate for the ALB into AWS Certificate Manager (ACM) in us-west-2. Associate the certificate with the ALB. Upload the certificate for the CloudFront distribution into ACM in the us-east-1 Region.
- Reasoning: This option ensures that SSL/TLS certificates are managed properly for both the ALB and CloudFront. It addresses encryption in transit but does not fulfill the field-level encryption requirement, which is the focus of the question. Field-level encryption needs specific configuration within CloudFront for data processing, which this option does not mention.
- Conclusion: This is necessary for securing communication but does not address field-level encryption, so this option does not meet the requirement.
Option C: Upload the private key that handles the encryption of the sensitive data to the CloudFront distribution. Create a field-level encryption profile and specify the fields that contain sensitive information. Create a field-level encryption configuration, and choose the newly created profile. Link the configuration to the appropriate cache behavior that is associated with sensitive POST requests.
- Reasoning: This option suggests uploading the private key to the CloudFront distribution. This is incorrect because AWS field-level encryption uses public key encryption. The private key must remain secure and should not be uploaded to CloudFront. The other actions related to creating a field-level encryption profile and linking it to the appropriate cache behavior are correct, but the private key shou...
Author: Amira · Last updated Jun 30, 2026
A company has deployed a multi-VPC environment in the AWS Cloud. The company uses a transit gateway to connect all the VPCs together. In the past, the company has experienced a loss of connectivity between applications after changes to security groups, network ACLs, and route tables in a VPC. When these ...
Let's evaluate each option based on the company's needs to automatically verify connectivity after changes are made to security groups, network ACLs, and route tables in a VPC:
Option A: Create a list of paths between different resources to check in VPC Reachability Analyzer. Create an Amazon EventBridge rule to monitor when a change is made and logged in Amazon CloudWatch. Configure the rule to invoke an AWS Lambda function to test the different paths in Reachability Analyzer.
- Reasoning: VPC Reachability Analyzer is specifically designed to check network connectivity between resources within a VPC. Using it to verify paths between resources is suitable because it directly tests connectivity within a VPC, including potential issues related to security groups, network ACLs, and route tables. Amazon CloudWatch can be used to monitor logs and metrics related to changes, but this option is less ideal because changes to security groups or route tables might not always generate log entries in CloudWatch directly (they are often logged in AWS CloudTrail instead). While this option is possible, CloudWatch monitoring is not as specific for tracking changes that could affect VPC resources.
- Conclusion: This approach can be used but may not be the most effective given that CloudWatch doesn't always capture the precise changes to VPC configuration that impact connectivity.
Option B: Create a list of paths between different resources to check in VPC Reachability Analyzer. Create an Amazon EventBridge rule to monitor when a change is made and logged in AWS CloudTrail. Configure the rule to invoke an AWS Lambda function to test the different paths in Reachability Analyzer.
- Reasoning: CloudTrail records detailed logs about all API calls made within an AWS account, including changes to VPC configuration, security groups, network ACLs, and route tables. Monitoring CloudTrail logs with Amazon EventBridge will allow you to trigger an action (such as invoking a Lambda function) when changes occur. VPC Reachability Analyzer will then test the paths between resources, verifying whether connectivity is intact. This is an effective way to automate testing for connectivity after configuration changes.
- Conclusion: This option is ideal because it directly monitors changes to VPC configuration using CloudTrail and leverages VPC Reachability Analyzer for testing connectivity.
Option C: Create a list of paths to check i...
Author: StarlightBear · Last updated Jun 30, 2026
A company hosts a web application that runs on a fleet of Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. The company uses an Amazon CloudFront distribution with the ALB as an origin.
The application recently experienced an attack. In response, the company associated an AWS WAF web ACL with the Cloud...
Let's evaluate each option based on the requirement to analyze application attacks detected by AWS WAF using Amazon Athena.
Option A: Configure the ALB and the EC2 instance subnets to produce VPC flow logs. Configure the VPC flow logs to deliver logs to an Amazon S3 bucket for log analysis.
- Reasoning: VPC flow logs capture network traffic data between resources, such as EC2 instances and the ALB. While this can help you analyze traffic patterns, VPC flow logs do not capture AWS WAF-specific data such as blocked requests or attacks detected by WAF. VPC flow logs focus on network traffic, not on the specific events that are relevant for analyzing WAF detections.
- Conclusion: VPC flow logs are not tailored to capture AWS WAF detection data and are not suitable for analyzing application attacks that AWS WAF detects. This option is not the best choice.
Option B: Create a trail in AWS CloudTrail to capture data events. Configure the trail to deliver logs to an Amazon S3 bucket for log analysis.
- Reasoning: AWS CloudTrail captures API calls made in your AWS environment, which includes actions performed by AWS services. CloudTrail logs do not capture AWS WAF web ACL logs or the details of specific attack requests detected by WAF. CloudTrail is useful for tracking changes to AWS resources and actions, but it is not designed to log WAF-specific events.
- Conclusion: CloudTrail logs are not focused on capturing the application-specific data needed to analyze AWS WAF attack detections. This option does not meet the requirement.
Option C: Configure the AWS WAF web ACL to deliver logs to an Amazon Kinesis Data Firehose delivery stream. Configure the stream to deliver the data to an Amazon S3 bucket for log analysis....
Author: Carlos Garcia · Last updated Jun 30, 2026
A real estate company is using Amazon Workspaces to provide corporate managed desktop service to its real estate agents around the world. These Workspaces are deployed in seven VPCs. Each VPC is in a different AWS Region.
According to a new requirement, the company's cloud-hosted security information and events management (SIEM) system needs to analyze DNS queries generated by the Workspaces to identify the target domains that are connected to t...
Let's evaluate each option based on the requirements and the most cost-effective solution:
Option A: Create VPC flow logs in each VPC that is connected to the Workspaces instances. Publish the log data to a central Amazon S3 bucket. Configure the SIEM system to poll the S3 bucket periodically.
- Reasoning: VPC flow logs capture network traffic metadata, including DNS queries. While this solution collects relevant data, VPC flow logs do not provide detailed DNS query information (e.g., domain names, request types), as they capture only high-level networking data such as IP addresses and traffic flow details. Additionally, publishing flow logs to an S3 bucket and having the SIEM system poll the bucket periodically could introduce latency and be more expensive in terms of storage and data transfer costs.
- Conclusion: This option is not ideal because VPC flow logs do not capture detailed DNS queries, and the polling approach for log collection may not be as efficient or cost-effective.
Option B: Configure an Amazon CloudWatch agent to log all DNS requests in Amazon CloudWatch Logs. Configure a subscription filter in CloudWatch Logs. Push the logs to the SIEM system by using Amazon Kinesis Data Firehose.
- Reasoning: This solution would allow you to capture DNS queries at the instance level by using the CloudWatch agent, which is a more targeted approach for logging DNS queries compared to VPC flow logs. By setting up a subscription filter in CloudWatch Logs and pushing the logs to the SIEM system using Amazon Kinesis Data Firehose, you can achieve near-real-time log delivery. However, deploying the CloudWatch agent on each Workspace could be operationally complex and costly, especially across seven VPCs and numerous Workspaces.
- Conclusion: While this option provides more detailed DNS data, the operational complexity of managing CloudWatch agents on each Workspace may not be the most cost-effective solution.
Option C: Configure VPC Traffic Mirroring to copy network traffic from each Workspace and to send the traffic to the SIEM system probes for analysis.
- Reasoning...
Author: Daniel · Last updated Jun 30, 2026
A network engineer needs to design the architecture for a high performance computing (HPC) workload. Amazon EC2 instances will require 10 Gbps flows and an aggregate throughput of up to 100 Gbps across many instance...
To optimize the architecture for a high-performance computing (HPC) workload with 10 Gbps flows and an aggregate throughput of up to 100 Gbps across many instances, the focus is on achieving low-latency communication, high throughput, and proper configuration for the EC2 instances.
Let's analyze each option:
Option A:
Place nodes in a single subnet of a VPC. Configure a cluster placement group. Ensure that the latest Elastic Fabric Adapter (EFA) drivers are installed on the EC2 instances with a supported operating system.
- Why Selected: The cluster placement group allows instances to be placed physically close together to reduce latency, and when combined with the Elastic Fabric Adapter (EFA), it optimizes high-throughput, low-latency communication between instances. EFA enables scalable, low-latency networking, which is essential for HPC workloads.
- Why Rejected: This option restricts the EC2 instances to a single subnet within a VPC. For very large workloads with potentially high instance counts (up to 100 Gbps), this could limit scalability. However, in smaller, more contained scenarios where the total network requirements are within the limits of a single subnet, this option can still be viable.
Option B:
Place nodes in multiple subnets in a single VPC. Configure a spread placement group. Ensure that the EC2 instances support Elastic Network Adapters (ENAs) and that the drivers are updated on each instance operating system.
- Why Rejected: A spread placement group distributes instances across different underlying hardware to ensure high availability, but it is not optimized for low-latency, high-throughput communication. While ENAs provide high performance for networking, they do not guarantee the same low-latency characteristics as EFA, which is critical for HPC workloads.
Option C:
Place nodes in multiple VPCs. Use AWS Transit Gateway to route traffic between the VPCs. Ensure that the latest Elastic Fabric Adapter (EFA) drivers are installed on the EC2 instances with a supported operating system.
- Why Rejected: This option introduces an unnecessary level of complexity by using multiple VPCs and an A...
Author: Ming · Last updated Jun 30, 2026
A company uses multiple AWS accounts and VPCs in a single AWS Region. The company must log all network traffic for Amazon EC2 instances and Amazon RDS databases. The company will use the log information to monitor and identify traffic flows in the event of a security incident. The information must be retained for 12 months but will be accessed infrequently after the first 90 days. T...
To address the company's requirements of logging network traffic for Amazon EC2 instances and RDS databases, and storing metadata such as `vpc-id`, `subnet-id`, and `tcp-flags` for 12 months, we need to select a solution that provides low-cost retention, meets the metadata requirements, and supports infrequent access after the first 90 days.
Let's break down the options:
Option A:
Configure VPC flow logs with the default fields. Store the logs in Amazon CloudWatch Logs.
- Why Rejected: While this option will capture default flow log data (like source/destination IP addresses, traffic volume, etc.), it doesn't meet the requirement to capture specific custom fields (`vpc-id`, `subnet-id`, `tcp-flags`). Additionally, storing large quantities of logs in CloudWatch Logs can be costly, especially when the data must be retained for long periods, such as 12 months. CloudWatch is more suited for real-time monitoring, and accessing logs infrequently can become expensive for long-term retention.
Option B:
Configure Traffic Mirroring on all AWS resources to point to a Network Load Balancer that will send the mirrored traffic to monitoring instances.
- Why Rejected: Traffic Mirroring is a more comprehensive tool for capturing detailed packet-level traffic, but it is more suitable for deep inspection and security analysis. It's complex to implement and manage, and it incurs additional costs due to the processing and data transfer involved in mirroring traffic. Traffic Mirroring is typically used for advanced monitoring, debugging, or security use cases, but it's overkill for simple network traffic logging in the scenario where we are only concerned with flow logs. The costs and complexity would far exceed the requirements for this use case.
Option C:
Configure VPC flow logs with additional custom format fields. Store the logs in Amazon S3.
- Why Selected: This option satisfies the metadata requirement, including the ability to add custom fields like `vpc-id`, `subnet-id`, and `tcp-flags` through the custom format feature of VPC flow logs. Storing logs in Amazon S3 is cost-effective for long-term retention (12 months in this case) and infrequen...
Author: ThunderBear · Last updated Jun 30, 2026
A network engineer is evaluating a network setup for a global retail company. The company has an AWS Direct Connect connection between its on-premises data center and the AWS Cloud. The company has AWS resources in the eu-west-2 Region. These resources consist of multiple VPCs that are attached to a transit gateway.
The company recently provisioned a few AWS resources in the eu-central-1. Region in a single VPC close to its users in this area. The network engineer must connect the resources i...
Let's evaluate the options in the context of the network setup and requirements outlined:
Scenario Summary:
- The company has an AWS Direct Connect connection between its on-premises data center and AWS (in the eu-west-2 Region).
- There are multiple VPCs in eu-west-2 connected via a transit gateway.
- The company has resources in eu-central-1 in a single VPC and wants to connect it to the existing Direct Connect connection, as well as the resources in eu-west-2.
- The solution must minimize changes to the Direct Connect connection.
Option A:
Create a new virtual private gateway. Attach the new virtual private gateway to the VPC in eu-central-1. Use a transit VIF to connect the VPC and the Direct Connect router.
- Why Rejected: This option would require creating a new virtual private gateway and a new Direct Connect virtual interface (VIF) to establish a connection from the VPC in eu-central-1 to the on-premises data center via Direct Connect. However, since the company already has an existing Direct Connect connection in eu-west-2, introducing a separate virtual private gateway and new VIF for eu-central-1 would require unnecessary changes to the existing infrastructure, which is against the goal of minimizing changes to the existing Direct Connect setup.
- Additional Complexity: This approach would also create a separate Direct Connect path for eu-central-1, which is less efficient compared to using the existing transit gateway network.
Option B:
Create a new transit gateway in eu-central-1. Create a peering attachment request to the transit gateway in eu-west-2. Add a static route in the transit gateway route table in eu-central-1 to point to the transit gateway peering attachment. Accept the peering request. Add a static route in the transit gateway route table in eu-west-2 to point to the new transit gateway peering attachment.
- Why Selected: This option takes advantage of the existing transit gateway architecture in eu-west-2 and establishes a transit gateway peering between the eu-central-1 and eu-west-2 regions.
- Key Benefits:
- Minimal changes to Direct Connect: The Direct Connect connection remains unchanged because the on-premises data center is connected to eu-west-2, and traffic can be routed from eu-central-1 to eu-west-2 via the peered transit gateways.
- Efficient routing: This solution allows eu-central-1 to benefit from the existing network setup in eu-west-2 without modifying the Direct Connect connection or creating new infrastructure elements like additional VIFs.
- Scalability: Transit gateway peering allows easy routing and integration across multiple regions, making this solution scalable as the company's network grows.
- How It Works:
- eu-central-1 will route traffic to eu-west-2 via the transit gateway peering attachment.
- The Direct Connect connection to the on-premises data cente...
Author: Maya2022 · Last updated Jun 30, 2026
A company has a 2 Gbps AWS Direct Connect hosted connection from the company's office to a VPC in the ap-southeast-2 Region. A network engineer adds a 5 Gbps Direct Connect hosted connection from a different Direct Connect location in the same Region. The hosted connections are connected to different routers from the office with an iBGP session running in between the routers.
The network engineer wants to ensure that the VPC uses the 5 Gbps ...
To ensure that the VPC uses the 5 Gbps hosted connection to route traffic to the office and fails over to the 2 Gbps hosted connection if the 5 Gbps connection goes down, the solution should rely on manipulating BGP (Border Gateway Protocol) path selection. Let's evaluate each option to determine the most suitable solution:
Option A:
Configure an outbound BGP policy from the router that is connected to the 2 Gbps connection. Advertise routes with a longer AS_PATH attribute to AWS.
- Why Rejected: The AS_PATH attribute in BGP is primarily used for preventing routing loops and influencing the selection of inbound routes. By advertising routes with a longer AS_PATH on the 2 Gbps connection, you are telling AWS to prefer the 5 Gbps hosted connection (which has the shorter AS_PATH). However, this would not provide failover functionality because the primary path would be set to the 5 Gbps connection, and the 2 Gbps connection would only be used as a secondary path if the 5 Gbps connection fails.
- Failover Issue: This method would not effectively trigger failover in the event of a failure of the 5 Gbps link, as it focuses on influencing AWS's path selection, not the failover logic.
Option B:
Advertise a longer prefix route from the router that is connected to the 2 Gbps connection.
- Why Rejected: The length of the prefix in BGP routing is an important factor in determining the best path for routing traffic. By advertising a longer prefix from the 2 Gbps connection, the traffic will prefer the 5 Gbps connection (with the shorter prefix). However, the issue is that advertising a longer prefix does not directly contribute to failover in the event of the 5 Gbps connection failure.
- Failover Issue: This approach won't effectively handle failover since it will prioritize the 5 Gbps connection and doesn't introduce a mechanism to switch to the 2 Gbps link if the primary 5 Gbps connection goes down.
Option C:
Advertise a less specific route from the router that is connected to the 5 Gbps connection.
- Why Selected: BGP prefers the more specific route, meaning that when advertising a less specific route (such as a larger subnet or aggregate), the 5 Gbps connection will be preferred over the 2 Gbps one. If the 5 Gbps connection fails, the less specific route will be replaced by the more specific one from the 2 Gbps connection, causing traffic to fail over to the 2 Gbps connection.
- How It Works:
- By advertising a less s...
Author: Daniel · Last updated Jun 30, 2026
An ecommerce company needs to implement additional security controls on all its domain names that are hosted in Amazon Route 53. The company's new policy requires data authentication and data integrity verification for all queries to the company's domain names. The current Route 53 architecture has four public hosted zones.
A network engineer needs to implement DNS Security Extensions (DNSS...
To implement DNSSEC signing and validation for domain names in Amazon Route 53 with data authentication, integrity verification, and alert capabilities, let's evaluate each of the options to determine which combination of steps will meet the requirements.
Option A:
Enable DNSSEC signing for Route 53 Request that Route 53 create a key-signing key (KSK) based on a customer managed key in AWS Key Management Service (AWS KMS).
- Why Rejected: When enabling DNSSEC in Route 53, Route 53 automatically creates the key-signing key (KSK) and the zone-signing key (ZSK). There is no need for the user to manually request Route 53 to create the KSK based on a customer-managed key in KMS. This option implies unnecessary manual steps, which are handled automatically by Route 53 when DNSSEC is enabled.
Option B:
Enable DNSSEC signing for Route 53 Request that Route 53 create a zone-signing key (ZSK) based on a customer managed key in AWS Key Management Service (AWS KMS).
- Why Rejected: Similar to Option A, Route 53 automatically creates the zone-signing key (ZSK) when DNSSEC is enabled. The ZSK is used to sign records in the hosted zone. There is no need to create a customer-managed key in AWS KMS for this purpose, as Route 53 will handle the creation and management of both the KSK and ZSK automatically when DNSSEC signing is enabled.
Option C:
Create a chain of trust for the hosted zones by adding a Delegation Signer (DS) record for each subdomain.
- Why Rejected: DNSSEC works by creating a "chain of trust," but the Delegation Signer (DS) record must be added to the parent zone, not each subdomain. The DS record contains a hash of the KSK from the child zone (your hosted zone in Route 53) and is used to establish trust with the parent domain. Adding DS records to subdomains doesn't create a valid chain of trust. This step would be incorrect for establishing the chain of trust.
Option D:
Create a chain of trust for the hosted zones by adding a Delegation Signer (DS) record to the parent zone.
- Why Selected: This is the correct approach to create a chain of trust for DNSSEC. After enabling DNSSEC for the hosted zones in Route 53, you must add a DS record to the parent zone (the zone where your domain is registered). The DS record contains the hash of the KSK and is used to establish DNSSEC validation between the child zone (the hosted zone in Route 53) and the pare...
Author: Leo · Last updated Jun 30, 2026
A financial company that is located in the us-east-1 Region needs to establish secure connectivity to AWS. The company has two on-premises data centers, each located within the same Region. The company's network team needs to establish hybrid connectivity to its AWS environment with reliable and consistent connectivity.
The connection must provide access to the company's private resources inside its AWS environment. The resources are located in the us-east-1 and us-west-2 Regions. The connection must allow resources from the corporate networks to send large amounts of data to Amazon S3 over the same connection. To meet complia...
To meet the company's requirements for secure, high availability, and consistent connectivity to AWS, with encryption for all packets and the ability to send large amounts of data to Amazon S3, we need to evaluate the options carefully based on the specific requirements outlined.
Key Requirements:
- Hybrid Connectivity: The solution must connect the on-premises data centers with AWS.
- Highly Available: The solution should ensure reliable and redundant connectivity.
- Encryption: Data must be encrypted in transit.
- Large Data Transfer to Amazon S3: The connection must support the transfer of large amounts of data to S3.
- Access to Private Resources: The connection should allow access to private AWS resources across multiple regions.
Let's break down the options:
---
A) Set up a private VIF to send data to Amazon S3. Use an AWS Site-to-Site VPN connection over the private VIF to encrypt data in transit to the VPCs in us-east-1 and us-west-2.
- Analysis: A private VIF (Virtual Interface) provides dedicated, private connectivity over AWS Direct Connect, which is a highly reliable and low-latency connection. However, using AWS Site-to-Site VPN over the private VIF introduces unnecessary complexity, as the VPN will encrypt the data, but Direct Connect itself provides private connectivity that already ensures security and encryption through its physical link. The solution is not optimal, as Direct Connect typically eliminates the need for a Site-to-Site VPN when using private VIFs.
- Rejection Reason: Using a VPN over Direct Connect adds redundancy in encryption but increases complexity without providing a significant benefit in this case.
---
B) Set up an AWS Direct Connect connection to each of the company's data centers.
- Analysis: This option suggests a Direct Connect connection to each data center, which is ideal for providing private, low-latency, and high-bandwidth connectivity between on-premises and AWS. With a Direct Connect connection, data can flow securely, and encryption can be handled by the connection or through a Site-to-Site VPN if additional security is needed.
- Strengths: This solution supports high availability (as each data center would have its own Direct Connect connection) and is highly suitable for sending large data volumes to S3 while ensuring encryption and consistent performance. This also ensures access to AWS private resources and meets compliance requirements for secure connectivity.
- Selection: This is a strong candidate for meeting the company's needs.
---
C) Set up an AWS Direct Connect connection from one of the company's data centers to us-east-1 and us-west-2.
- Analysis: A Direct Connect connection from one data center to both us-east-1 and us-west-2 is not ideal. While it wo...
Author: Ethan Smith · Last updated Jun 30, 2026
A global company is designing a hybrid architecture to privately access AWS resources in the us-west-2 Region. The company's existing architecture includes a VPC that uses RFC 1918 IP address space. The VPC is connected to an on-premises data center over AWS Direct Connect Amazon Route 53 provides name resolution within the VPC. Locally managed DNS servers in the data center provide DNS services to the on-premises hosts.
The company has applica...
To enable the company's on-premises applications to access Amazon S3 in the us-west-2 Region privately, without using public IP address space, we need to focus on solutions that ensure private connectivity to S3 while maintaining the existing DNS resolution setup for the on-premises network. Let's break down the options:
Key Requirements:
- Private Access to S3 (without using public IP addresses).
- Seamless DNS Resolution for applications on-premises, leveraging existing DNS configurations.
- The solution must work with AWS Direct Connect for the hybrid architecture.
- RFC 1918 IP address space is used for the VPC.
Analysis of Options:
---
A) Create an S3 interface endpoint in the VPC. Update the on-premises application configuration to use the Regional VPC endpoint DNS hostname that is mapped to the S3 interface endpoint.
- Analysis: An S3 Interface Endpoint uses PrivateLink, which provides private connectivity to S3 over the VPC's internal IP space, avoiding the need to route through the public internet. However, in this scenario, the on-premises data center DNS servers need to resolve the DNS hostname of the VPC endpoint for S3.
- Rejection Reason: The main issue here is that Route 53 Resolver in the VPC (used for on-premises DNS resolution) isn’t part of the solution. The solution doesn’t mention how DNS queries would be handled for the on-premises network, which is necessary for name resolution of the VPC endpoint.
---
B) Create an S3 interface endpoint in the VPC. Configure a Route 53 Resolver inbound endpoint in the VPC. Set up the data center DNS servers to forward DNS queries for the S3 domain from on-premises to the inbound endpoint.
- Analysis: This solution involves creating an S3 interface endpoint in the VPC (ensuring private access to S3 via PrivateLink) and using a Route 53 Resolver inbound endpoint. The data center DNS servers are then configured to forward DNS queries for S3 (specifically the S3 domain) to the inbound endpoint in the VPC, allowing on-premises applications to resolve the S3 endpoint privately.
- Selection Reason: This is the best solution because it ensures private access to S3 (via the interface endpoint), and the DNS queries for S3 are resolved correctly by forwarding to the inbound resolver, which makes sure the on-premises appli...
Author: Maya2022 · Last updated Jun 30, 2026
A company is migrating critical applications to AWS. The company has multiple accounts and VPCs that are connected by a transit gateway.
A network engineer must design a solution that performs deep packet inspection for any traffic that leaves a VPC network boundary. All inspected traffic and the actions that are taken on...
Key Considerations for Selecting a Solution:
1. Deep Packet Inspection (DPI): The solution must support DPI for traffic leaving a VPC network boundary. DPI typically requires specialized security appliances or services like next-generation firewalls (NGFW) or intrusion detection systems (IDS).
2. Centralized Logging: All actions taken on the traffic must be logged centrally in an Amazon S3 bucket or similar. This means the solution must support logging to a central account.
3. Least Administrative Overhead: The solution should be easy to manage and should minimize the operational burden of configuration, maintenance, and scaling.
4. Integration with AWS Transit Gateway: The solution should integrate with the transit gateway, which connects multiple VPCs, to ensure that traffic between VPCs is inspected and logged.
---
Option Analysis:
Option A:
- Architecture: Create a central network VPC with an attachment to the transit gateway. Deploy an AWS Gateway Load Balancer (GLB) backed by third-party next-generation firewall appliances.
- Deep Packet Inspection: The firewall appliances can perform DPI using custom policies.
- Logging: The firewall appliances can capture and log network traffic to an Amazon S3 bucket in a central log account.
- Administrative Overhead: This approach centralizes traffic inspection with minimal configuration. The AWS Gateway Load Balancer simplifies the integration of third-party appliances into the AWS environment. Configuring the firewall appliances to log to an S3 bucket ensures centralized logging. The solution is scalable, and the administrative overhead is low since AWS GLB simplifies routing and load balancing.
Option A meets the requirements well because it leverages AWS's managed services (AWS Gateway Load Balancer) and integrates with third-party appliances for DPI. It also allows centralized logging in an S3 bucket with minimal complexity.
Option B:
- Architecture: Similar to Option A, it uses a central network VPC with an attachment to the transit gateway and third-party firewall appliances, but instead of AWS Gateway Load Balancer, it uses an Application Load Balancer (ALB).
- Deep Packet Inspection: The firewall appliances can still perform DPI, but the ALB is not designed for DPI or traffic inspection; it’s more suited for HTTP/HTTPS traffic.
- Logging: Logs are sent to a syslog server in the central log account.
- Administrative Overhead: Using an ALB in this context is inappropriate because it’s not designed for DPI tasks, l...
Author: Aria · Last updated Jun 30, 2026
A company has an on-premises data center in the United States. The data center is connected to AWS by an AWS Direct Connect connection. The data center has a private VIF that is connected to a Direct Connect gateway.
Recently, the company opened a new data center in Europe and established a new Direct Connect connection between the Europe data center and AWS. A new private VIF connects to the existing Direct Connect gateway.
The company wants to use Direct Connect...
Key Considerations:
1. Direct Connect SiteLink: Direct Connect SiteLink allows private connectivity between Direct Connect-connected sites, enabling them to communicate over a private network. It works between private VIFs (Virtual Interfaces) and enables traffic routing between locations in different regions. SiteLink works with Direct Connect connections but only for private VIFs, not public or transit VIFs.
2. Operational Efficiency: The goal is to minimize operational complexity. This includes leveraging existing infrastructure and avoiding unnecessary additional resources.
3. Existing Setup: The company already has a Direct Connect gateway with private VIFs connecting two data centers (U.S. and Europe). Therefore, the focus is on adding SiteLink with minimal disruption.
---
Option Analysis:
Option A:
- Public VIFs: Create new public VIFs for each data center.
- Enable SiteLink: Enable SiteLink on these new public VIFs.
Issue: SiteLink does not work with public VIFs; it only works with private VIFs that are part of Direct Connect gateways. Public VIFs are used for accessing AWS public services (like S3, EC2, etc.), not for connecting between private networks (such as the data centers).
Conclusion: This option is rejected because public VIFs cannot be used with SiteLink.
Option B:
- Transit VIFs: Create transit VIFs from each data center.
- Enable SiteLink: Enable SiteLink on the new transit VIFs.
Issue: Transit VIFs are used to connect Direct Connect to AWS Transit Gateway or AWS Regions, and they are designed to handle large-scale inter-region connectivity. SiteLink, however, works with private VIFs, not transit VIFs. Therefore, enabling SiteLink on transit VIFs is not a valid solution.
Conclusion: This option is rej...
Author: Sofia · Last updated Jun 30, 2026
A company has a new AWS Direct Connect connection between its on-premises data center and the AWS Cloud. The company has created a new private VIF on this connection. However, the VIF status is DOWN.
A network engineer verifies that the physical connection status is UP and RUNNING based on information from the AWS Management Console. The network engineer checks the customer Direc...
Question 1: Setting up Direct Connect SiteLink for private network between the US and European data centers
To establish a private network between the two data centers in the United States and Europe using AWS Direct Connect SiteLink, we need a solution that leverages AWS Direct Connect and meets operational efficiency.
Key Requirements:
- Private network between the US and Europe data centers.
- Operational efficiency: Minimize the complexity of network configurations and management.
Let's evaluate the options:
---
A) Create a new public VIF from each data center. Enable SiteLink on the new public VIFs.
- Analysis: A public VIF (Virtual Interface) connects to public AWS services like S3, and it is used to route traffic over AWS's global network to public endpoints. SiteLink is intended for private traffic between two private locations over AWS Direct Connect, so using public VIFs is not the correct approach here.
- Rejection Reason: SiteLink requires private VIFs, not public VIFs, to facilitate private network connectivity between the two data centers.
---
B) Create a new transit VIF from each data center. Enable SiteLink on the new transit VIFs.
- Analysis: A transit VIF connects to a Direct Connect Gateway and allows the connection of multiple VPCs across different AWS Regions. Transit VIFs are designed to handle traffic between VPCs and on-premises resources. However, SiteLink is specifically designed to work between private VIFs and not transit VIFs, which is meant for routing traffic across VPCs and regions.
- Rejection Reason: SiteLink cannot be enabled on transit VIFs. This approach does not meet the requirements of establishing a private network between the data centers.
---
C) Use the existing VIF from each data center. Enable SiteLink on the existing private VIFs.
- Analysis: The private VIFs are the correct interface for establishing private, direct connections between AWS and on-premises data centers. SiteLink is a feature that can be enabled on private VIFs to create a private, high-bandwidth, low-latency network between different AWS locations, in this case, the data centers in the US and Europe.
- Strengths: This solution leverages existing infrastructure and is operationally efficient. SiteLink is designed for exactly this purpose, enabling private connectivity across data centers and AWS regions using private VIFs.
- Selection Reason: This option satisfies all the requirements for private networking, is simple to implement, and ensures operational efficiency.
---
D) Create a new AWS Site-to-Site VPN connection between the data centers. Configure the new connection to use SiteLink.
- Analysis: Site-to-Site VPN is typically used for connecting on-premises networks to AWS over an encrypted tunnel. While this can work for private connectivity, it adds more complexity than necessary. AWS Direct Connect with SiteLink is the preferred solution for private network connectivity as it provides more reliable, higher bandwidth connections compared to VPNs.
- Rejection Reason: This approach introduces additional overhead by using a VPN and does not leverage the more efficient Direct Connect SiteLink solution.
---
Conclusion for Question 1:
Selected option: C
This solution uses pri...
Author: Noah · Last updated Jun 30, 2026
AnyCompany has acquired Example Corp. AnyCompany's infrastructure is all on premises, and Example Corp's infrastructure is completely in the AWS Cloud. The companies are using AWS Direct Connect with AWS Transit Gateway to establish connectivity between each other.
Example Corp has deployed a new application across two Availability Zones in a VPC with no internet gateway. The CIDR range for the VPC is 10.0.0.0/16. Example Corp needs to access an application that is deployed on premises by AnyCompany. Because of compliance requirements, Example Corp must access the application through a limited contiguous block of approved IP ...
To meet the requirements of enabling Example Corp to access an application deployed on-premises by AnyCompany through a limited contiguous block of approved IP addresses (10.1.0.0/24), while ensuring high availability, the following key factors must be considered:
1. High Availability: The solution must ensure that if one Availability Zone (AZ) becomes unavailable, the application can still be accessed from another AZ.
2. Private Access: Since Example Corp's infrastructure has no internet gateway and access must be routed to the on-premises application, the solution must route traffic in a secure, private manner.
3. Use of Approved IP Range: Traffic from Example Corp needs to originate from the IP block 10.1.0.0/24 to meet compliance requirements.
Option Analysis
- Option A:
- Creates public NAT gateways in each AZ.
- Public NAT gateways are typically used when you need to route traffic to the internet, which isn’t necessary in this case because Example Corp’s application is on-premises and the goal is private communication. This makes it less appropriate.
- The use of public NAT gateways also exposes the traffic to the public internet, which doesn’t align with the security requirement.
- Option B:
- Creates private NAT gateways in each A...
Author: Joseph · Last updated Jun 30, 2026
A company recently experienced an IP address exhaustion event in its VPCs. The event affected service capacity. The VPCs hold two or more subnets in different Availability Zones.
A network engineer needs to develop a solution that monitors IP address usage across resources in the VPCs. The company needs to receive notification about possibl...
To meet the requirements of monitoring IP address usage in VPCs and receiving notifications when the availability limit is reached, the company wants a solution with the least operational overhead while preventing IP address exhaustion issues. Let’s go through the options and determine which one meets the goal effectively:
Option Analysis
- Option A:
- Amazon VPC IP Address Manager (IPAM) is a managed service designed specifically to help with managing and monitoring IP address usage within AWS VPCs. It provides a centralized view of IP address usage across VPCs and subnets.
- The auto-import feature automatically tracks IP address usage in VPCs and subnets, reducing manual configuration.
- By using CloudWatch alarms triggered when the availability limit threshold is reached, the company will be alerted before issues occur.
- Pros:
- Fully managed service that reduces operational overhead.
- Seamless integration with AWS services like Amazon SNS for notifications.
- Provides native support for IP address monitoring without needing custom Lambda functions or metric creation.
- Cons:
- Some setup complexity, but minimal compared to custom solutions.
- Best Fit: Ideal for this scenario as it is designed for VPC IP address management, provides automatic tracking, and integrates directly with AWS notifications with minimal manual intervention.
- Option B:
- Sets up a log group in Amazon CloudWatch Logs for each subnet, and uses an AWS Lambda function to read and publish metrics.
- This requires custom Lambda code to track IP address usage, which adds operational overhead.
- While this approach could work, it requires more setup and ongoing maintenance compared to a native service like IPAM.
- Cons:
- More complex and requires continuous maintenance of Lambda f...
Author: Oliver · Last updated Jun 30, 2026
A company has a hybrid IT setup that includes services that run in an on-premises data center and in the AWS Cloud. The company is using AWS Direct Connect to connect its data center to AWS. The company is using one AWS Site-to-Site VPN connection as backup and requires a backup connectivity option to always be present. The company is transitioning to IPv6 by implem...
To transition the data center's connectivity to AWS in the least amount of time while adopting dual-stack architectures and maintaining backup connectivity, let's evaluate each option:
Key Factors:
1. Dual-Stack Transition: The company is moving to IPv6, meaning they need support for both IPv4 and IPv6 simultaneously.
2. Backup Connectivity: The company requires continuous backup connectivity using AWS Direct Connect and a Site-to-Site VPN connection.
3. Minimal Transition Time: The goal is to implement the solution quickly, ensuring minimal disruption to existing services.
Option Analysis:
- Option A: Create a new Site-to-Site VPN tunnel for the IPv6 traffic.
- This option creates a new tunnel specifically for IPv6 traffic, which makes sense for transitioning to IPv6 but doesn’t address the need for dual-stack support in the most time-efficient manner.
- Pros: Directly supports IPv6, providing a backup solution for IPv6 traffic.
- Cons: This step focuses only on the VPN and requires managing a new tunnel. While it is an option, it doesn't address integrating IPv6 into the overall Direct Connect setup quickly.
- Best Fit: Useful for specific scenarios where IPv6-only traffic needs to be handled separately, but not optimal in terms of simplifying the dual-stack transition.
- Option B: Create a new dual-stack Site-to-Site VPN connection between the data center and AWS. Provision routing. Delete the original Site-to-Site VPN connection.
- This option proposes creating a completely new dual-stack Site-to-Site VPN connection. While it will enable IPv6 traffic to flow, it requires deleting the existing connection and replacing it entirely with a new one.
- Pros: Ensures a dual-stack VPN setup for both IPv4 and IPv6.
- Cons: The need to delete the original connection creates downtime and increases transition time. This may not be optimal for ensuring continuous backup connectivity while migrating.
- Best Fit: This option might be useful for transitioning entirely to dual-stack but is less efficient in terms of speed and operational continuity during migration.
- Option C: Associate a new dual-stack public VIF with the Direct Connect connection. Migrate the Direct Connect traffic to the new VIF.
- This option involves associating a new dual-stack Virtual Interface (VIF) for Direct Connect, supporting both IPv4 and IPv6 traff...
Author: Noah · Last updated Jun 30, 2026
A company is developing a new application that is deployed in multiple VPCs across multiple AWS Regions. The VPCs are connected through AWS Transit Gateway. The VPCs contain private subnets and public subnets.
All outbound internet traffic in the private subnets must be audited and logged. The company's network engineer plans to use AWS Network Firewall and must ensure that all traffic t...
To meet the requirements of auditing and logging all outbound internet traffic in the private subnets and ensuring that the Network Firewall logs all traffic for auditing and alerting, let's evaluate each option:
Key Requirements:
1. Audit and log outbound internet traffic: This involves capturing logs of all outbound traffic from private subnets.
2. Use of AWS Network Firewall: The logs should come from AWS Network Firewall, which should capture both alerts and traffic flow.
3. Logging for alerting and auditing: The logs must be integrated into a system that allows for efficient alerting, analysis, and auditing.
Option Analysis:
- Option A: Configure Network Firewall logging in Amazon CloudWatch to capture all alerts. Send the logs to a log group in Amazon CloudWatch Logs.
- Pros:
- This option enables logging alerts to CloudWatch, which is useful for generating metrics and creating CloudWatch alarms for alerting.
- Cons:
- This configuration will only capture alerts, not the full traffic flow data. Alerts are useful for detecting malicious or anomalous behavior, but they don't provide the granular information needed for full traffic auditing.
- Missing the actual traffic flow logs, which are needed for complete auditing of outbound traffic.
- Option B: Configure Network Firewall logging in Network Firewall to capture all alerts and flow logs.
- Pros:
- This option enables logging both alerts and traffic flow logs. Flow logs provide detailed data on network traffic, including source and destination IP addresses, ports, protocols, etc.
- Capturing both types of logs meets the requirement of auditing all traffic, as flow logs record all traffic passing through the Network Firewall.
- Cons:
- None significant; this is the most comprehensive solution.
- Best Fit: This option is the most suitable as it captures both alerts and traffic flow logs, providing a complete and ...
Author: Zain · Last updated Jun 30, 2026
A company has set up a NAT gateway in a single Availability Zone (AZ1) in a VPC (VPC1) to access the internet from Amazon EC2 workloads in the VPC. The EC2 workloads are running in private subnets in three Availability Zones (AZ1, AZ2, AZ3). The route table for each subnet is configured to use the NAT gateway to access the internet.
Recently during an outage, internet access stopped working for the EC2 workloads because of the NAT gateway's unavai...
Key Factors:
1. Redundancy: The current architecture has a single NAT gateway, which creates a single point of failure (SPOF). We need a solution that removes this SPOF and ensures internet access even if one NAT gateway becomes unavailable.
2. High Availability: The solution should provide built-in redundancy across multiple Availability Zones (AZs) to ensure that the EC2 workloads in all AZs have internet access.
3. Simple Configuration: The solution should be simple to configure, not requiring significant changes or complex routing setups.
Option Analysis:
- Option A:
- Set up two NAT gateways in different AZs (AZ2 and AZ3).
- Configure a single route table to route traffic to the virtual IP addresses of the two NAT gateways.
- Pros:
- This provides two NAT gateways in different AZs, which is good for redundancy.
- The virtual IP approach is useful for handling failover between the two NAT gateways.
- Cons:
- AWS does not allow routing to multiple NAT gateways through a single route table without more complex setup such as route precedence and failover logic.
- This would require a custom solution to handle failover, complicating the configuration.
- Option B:
- Set up two NAT gateways in AZ2 and AZ3, with each NAT gateway serving traffic for a specific set of private subnets.
- Configure separate route tables for each AZ’s private subnets, pointing to the NAT gateway in the same AZ.
- Pros:
- This provides redundancy across two AZs and ensures that private subnets in each AZ will use a NAT gateway in their respective AZs.
- Simple configuration of route tables per AZ, making the solution easy to manage.
- Cons:
- There is no failover between AZs. If the NAT gateway in AZ2 go...
Author: Ella · Last updated Jun 30, 2026
A company has a total of 30 VPCs. Three AWS Regions each contain 10 VPCs. The company has attached the VPCs in each Region to a transit gateway in that Region. The company also has set up inter-Region peering connections between the transit gateways.
The company wants to use AWS Direct Connect to provide access from its on-premises location for only four VPCs across the three Regions. The company has...
To meet the requirements of providing access from on-premises to only four VPCs across three AWS Regions with the most cost-effective solution, let's evaluate each option:
Key Considerations:
1. On-premises access: The company wants to use AWS Direct Connect to provide access to only four VPCs.
2. Cost-effectiveness: We want to minimize the number of resources and connections to save on costs.
3. Inter-Region setup: There are inter-Region peering connections set up for the transit gateways, so some resources will already be in place to facilitate communication across Regions.
4. Direct Connect connections: The company has provisioned four Direct Connect connections at two locations, so we need to optimize the use of these connections.
Option Evaluation:
A) Create four virtual private gateways. Attach the virtual private gateways to the four VPCs.
- Rejection: Virtual Private Gateways (VGWs) are used to connect a VPC to an external network (like Direct Connect or VPN). Since the company is using a transit gateway architecture (already attached to VPCs in each Region), this would be redundant and less efficient. Creating separate VGWs for each VPC would increase cost and complexity, making it an undesirable option.
B) Create a Direct Connect gateway. Associate the four virtual private gateways with the Direct Connect gateway.
- Rejection: This option is not appropriate because the company is using transit gateways, not individual VGWs. A Direct Connect gateway is typically used when connecting multiple VGWs or a VPN, but in this case, the transit gateway is the key to interconnecting the VPCs. Associating it with VGWs would not be optimal.
C) Create four transit VIFs on each Direct Connect connection. Associate the transit VIFs with the Direct Connect gateway.
- Acceptance: A transit VIF (Virtual Interface) is the correct approach when connecting a Direct Connect connection to a Direct Connect gateway. Each Direct Connect connection can have m...
Author: Noah Williams · Last updated Jun 30, 2026
A company needs to manage Amazon EC2 instances through command line interfaces for Linux hosts and Windows hosts. The EC2 instances are deployed in an environment in which there is no route to the internet. The company must implement role-based access control for management of the instances. The comp...
Let's break down the options to find the best solution that meets the requirements with the least maintenance overhead.
Key Requirements:
1. No route to the internet: The EC2 instances cannot be directly accessed over the public internet.
2. Role-based access control (RBAC): The solution should allow for fine-grained access control for management of EC2 instances.
3. Command line management: The solution should allow for command-line access to both Linux and Windows EC2 instances.
4. Standalone on-premises environment: The company has an existing on-premises environment that should integrate with the solution.
Option Evaluation:
A) Set up an AWS Direct Connect connection between the on-premises environment and the VPC where the instances are deployed. Configure routing, security groups, and ACLs. Connect to the instances by using the Direct Connect connection.
- Rejection: While Direct Connect would provide a dedicated network connection between the on-premises environment and AWS, it does not inherently provide role-based access control (RBAC) or an easy way to manage EC2 instances without additional configuration. It would also require managing routing, security groups, and ACLs, which could result in higher complexity and maintenance overhead compared to other solutions. It also doesn't meet the requirement for an internet-independent solution as Direct Connect could be cumbersome to set up in an environment where AWS management should be simpler.
B) Deploy and configure AWS Systems Manager Agent (SSM Agent) on each instance. Deploy VPC endpoints for Systems Manager Session Manager. Connect to the instances by using Session Manager.
- Acceptance: This is the most efficient and least maintenance-intensive option. AWS Systems Manager (SSM) enables management of EC2 instances without requiring internet access. By using Session Manager, the company can securely connect to both Linux and Windows EC2 instances for command-line management without the need for SSH or RDP acces...
Author: William · Last updated Jun 30, 2026
A network engineer needs to improve the network security of an existing AWS environment by adding an AWS Network Firewall firewall to control internet-bound traffic. The AWS environment consists of five VPCs. Each VPC has an internet gateway, NAT gateways, public Application Load Balancers (ALBs), and Amazon EC2 instances. The EC2 instances are deployed in private subnets. The architecture is deployed across two Availability Zones.
The network engineer must be able to configure rules for the public IP addresses in the environment, regardless of the direction of traffic. The network engineer must ...
To improve the network security of the AWS environment by adding AWS Network Firewall and controlling internet-bound traffic, we need to carefully assess how to deploy the firewall in a way that ensures high availability, minimizes changes to the existing infrastructure, and allows for inspection and filtering of traffic in a scalable manner.
Key Requirements:
1. Control internet-bound traffic: We need to manage traffic going to/from the internet for the EC2 instances in private subnets and public-facing resources like ALBs.
2. High availability: The firewall solution should be resilient across multiple Availability Zones.
3. Minimal changes: The solution must not require significant changes to the existing production environment.
4. Inspect traffic based on public IPs: Rules should be configurable based on traffic direction, with a focus on internet-bound traffic.
Option Evaluation:
A) Create a centralized inspection VPC with subnets in two Availability Zones. Deploy Network Firewall in this inspection VPC with an endpoint in each Availability Zone.
- Acceptance: This is a commonly used approach when implementing AWS Network Firewall to centralize traffic inspection. A centralized inspection VPC in two Availability Zones ensures high availability by placing firewall endpoints in multiple AZs. This solution minimizes changes to the existing VPCs because the firewall is implemented in a dedicated VPC, and only routing changes are needed to redirect traffic through the firewall. This approach ensures that all internet-bound traffic can be inspected and controlled in a single location, providing centralized management and minimal disruption to the production environment.
- Why accepted: Meets high availability, minimal changes, and centralized traffic inspection requirements. This approach is best suited for handling traffic control from multiple VPCs without disrupting the existing architecture.
B) Configure new subnets in two Availability Zones in each VPC. Deploy Network Firewall in each VPC with an endpoint in each Availability Zone.
- Rejection: While this approach also ensures high availability by deploying firewall endpoints in each VPC and AZ, it introduces more complexity. Creating new subnets in every VPC and placing the firewall within each VPC would require more configuration and changes to the existing envir...
Author: Sofia · Last updated Jun 30, 2026
A company is planning to migrate an internal application to the AWS Cloud. The application will run on Amazon EC2 instances in one VPC. Users will access the application from the company's on-premises data center through AWS VPN or AWS Direct Connect. Users will use private domain names for the application endpoint from a domain name that is reserved explicitly for use in the AWS Cloud.
Each EC2 instance must have automatic failover to another EC2 in...
To meet the requirements of the scenario, let’s evaluate the solution based on the following needs:
Key Requirements:
1. Private DNS for the application: The application should use private domain names, and the DNS should not expose the application to the public internet.
2. Automatic failover: Each EC2 instance must have automatic failover to another EC2 instance in case of failure.
3. On-premises access: Users will access the application from the company's on-premises data center via AWS VPN or Direct Connect.
4. Same VPC and AWS account: The EC2 instances will be deployed in the same VPC and AWS account.
Option Analysis:
A) Assign public IP addresses to the EC2 instances. Create an Amazon Route 53 private hosted zone for the AWS reserved domain name. Associate the private hosted zone with the VPC. Create a Route 53 Resolver outbound endpoint. Configure conditional forwarding in the on-premises DNS resolvers to forward all DNS queries for the AWS domain to the outbound endpoint IP address for Route 53 Resolver. In the private hosted zone, configure primary and failover records that point to the public IP addresses of the EC2 instances. Create an Amazon CloudWatch metric and alarm to monitor the application's health. Set up a health check on the alarm for the primary application endpoint.
- Rejection: This approach requires assigning public IP addresses to the EC2 instances, which contradicts the requirement to not expose the application to the internet. Additionally, using a Route 53 Resolver outbound endpoint is more suitable when forwarding DNS queries to external DNS resolvers, which is not necessary for this scenario, where the DNS queries are being forwarded from the on-premises environment to AWS. Hence, this solution is not ideal.
B) Place the EC2 instances in private subnets. Create an Amazon Route 53 public hosted zone for the AWS reserved domain name. Associate the public hosted zone with the VPC. Create a Route 53 Resolver inbound endpoint. Configure conditional forwarding in the on-premises DNS resolvers to forward all DNS queries for the AWS domain to the inbound endpoint IP address for Route 53 Resolver. In the public hosted zone, configure primary and failover records that point to the IP addresses of the EC2 instances. Create an Amazon CloudWatch metric and alarm to monitor the application's health. Set up a health check on the alarm for the primary application endpoint.
- Rejection: This option suggests using a public hosted zone, which means the domain name would be publicly resolvable, which contradicts the ...
Author: Henry · Last updated Jun 30, 2026
A company uses Amazon Route 53 for its DNS needs. The company's security team wants to update the DNS infrastructure to provide the most recent security posture.
The security team has configured DNS Security Extensions (DNSSEC) for the domain. The security team wants a network engineer to explain who ...
Key Concepts for DNSSEC and Key Management:
- DNSSEC (DNS Security Extensions): DNSSEC is used to protect against certain types of attacks, such as cache poisoning, by ensuring that DNS responses are authentic and haven't been tampered with. It does so by using cryptographic signatures, which rely on two types of keys:
- Zone-Signing Key (ZSK): This key is used to sign DNS records in the zone (domain). The ZSK is rotated more frequently because it is used for signing individual records.
- Key-Signing Key (KSK): This key is used to sign the ZSK itself. The KSK is rotated less frequently but is crucial for the overall integrity of the DNSSEC process.
- Key Management: Key rotation is a necessary process to ensure security, and it is the responsibility of the zone owner (the company in this case) to manage this process. The KSK and ZSK must be rotated according to best practices to ensure that keys are not compromised.
Option Evaluation:
A) AWS rotates the zone-signing key (ZSK). The company rotates the key-signing key (KSK).
- Rejection: AWS does not automatically manage key rotation for DNSSEC keys in Route 53. The responsibility for rotating both the ZSK and the KSK falls to the customer (the company). This option is incorrect because it incorrectly assigns the responsibility of rotating t...
Author: Henry · Last updated Jun 30, 2026
A company has agreed to collaborate with a partner for a research project. The company has multiple VPCs in the us-east-1 Region that use CIDR blocks within 10.10.0.0/16. The VPCs are connected by a transit gateway that is named TGW-C in us-east-1. TGW-C has an Autonomous System Number (ASN) configuration value of 64520.
The partner has multiple VPCs in us-east-1 that use CIDR blocks within 172.16.0.0/16. The VPCs are connected by a transit gateway that is named TGW-P in us-east-1. TGW-P has an ASN configuration va...
To solve this problem efficiently, we need to establish network connectivity between the company's VPCs (using CIDR blocks within 10.10.0.0/16) and the partner's VPCs (using CIDR blocks within 172.16.0.0/16) within the us-east-1 region using the transit gateway (TGW) configurations described. Let's break down the options to determine the one with the least complexity and changes while achieving the desired connectivity.
Option Analysis:
Option A: Create a new VPC in a new account. Deploy a router from AWS Marketplace. Share TGW-C and TGW-P with the new account by using AWS Resource Access Manager (AWS RAM). Associate TGW-C and TGW-P with the new VPC. Configure the router in the new VPC to route between TGW-C and TGW-P.
- Pros:
- This solution introduces an isolated VPC in a new account, creating a controlled environment.
- Cons:
- The need for a new VPC and external router introduces unnecessary complexity and costs.
- Deploying and managing the router from the AWS Marketplace can lead to operational overhead.
- This is a more complicated solution than required, as it involves additional AWS resources, routing configurations, and possible management of an external router.
Conclusion: Rejected. This option is unnecessarily complex for the given requirements.
Option B: Create an IPsec VPN connection between TGW-C and TGW-P. Configure the routing between the transit gateways to use the IPsec VPN connection.
- Pros:
- IPsec VPNs can provide secure connectivity.
- Cons:
- IPsec VPN connections are typically used for securing traffic between on-premises networks or hybrid-cloud scenarios. Setting this up between two AWS Transit Gateways could introduce unnecessary overhead, potentially making the routing between the transit gateways more complex.
- IPsec VPNs may introduce latency and performance considerations that are not ideal in this case.
Conclusion: Rejected. The need for an IPsec VPN connection between two transit gateways introduces unnecessary complexity and performance concerns. This is not the best solution for VPC-to-VPC connectivity.
Option C: Configure a cross-account transit gateway peering attachment between TGW-C and TGW-P. Configure the routing between the transit gateways to use the peering attachment.
- ...
Author: GlowingTiger · Last updated Jun 30, 2026
A company has a public application. The application uses an Application Load Balancer (ALB) that has a target group of Amazon EC2 instances.
The company wants to protect the application from security issues in web requests. The traff...
The company has an application that requires end-to-end encryption and protection from web security issues. The solution needs to ensure that traffic is encrypted from the client to the load balancer and from the load balancer to the backend EC2 instances. Additionally, the company wants to implement security features like AWS WAF for web request protection.
Let's analyze each option to determine which one meets these criteria:
Option A: Configure a Network Load Balancer (NLB) that has a target group of the existing EC2 instances. Configure TLS connections to terminate on the EC2 instances that use a public certificate. Configure an AWS WAF web ACL. Associate the web ACL with the NLB.
- Pros:
- The Network Load Balancer (NLB) can handle high traffic and provide end-to-end encryption if TLS is terminated at the EC2 instances.
- AWS WAF can be associated with the NLB to protect against security issues like SQL injection, cross-site scripting (XSS), etc.
- Cons:
- The NLB does not support TLS termination natively. The TLS must be terminated at the EC2 instances, which could lead to performance issues, and managing certificates on EC2 instances manually could increase operational complexity.
- End-to-end encryption is achieved, but terminating TLS on EC2 instances is not the most efficient or scalable solution.
Conclusion: Rejected. While this option achieves end-to-end encryption, it involves manual TLS certificate management on EC2 instances and does not use the NLB's full capabilities.
Option B: Configure TLS connections to terminate at the ALB that uses a public certificate. Configure AWS Certificate Manager (ACM) certificates for the communication between the ALB and the EC2 instances. Configure an AWS WAF web ACL. Associate the web ACL with the ALB.
- Pros:
- Application Load Balancer (ALB) supports TLS termination directly, which means it can manage the SSL/TLS handshake and handle the encryption/decryption of traffic efficiently.
- The communication between the ALB and the backend EC2 instances can be encrypted using AWS ACM certificates, which simplifies certificate management.
- AWS WAF can be associated with the ALB to provide protection against common web attacks.
- This solution offers end-to-end encryption if TLS is terminated at the ALB and communication to EC2 instances is secured.
- Cons:
- This option requires the ALB to terminate the TLS connection, and the connection from the ALB to the EC2 instances would be encrypted with an ACM certificate, which is easy to manage.
Conclusion: Selected. This option provides a secure, scalable, and efficient appro...
Author: Olivia · Last updated Jun 30, 2026
A company has an application that hosts personally identifiable information (PII) of users. All connections to the application must be secured by HTTPS with TLS certificates that implement Elliptic Curve Cryptography (ECC).
The application uses stateful connections between the web tier and the end users. Multiple instances host the application. A ne...
To meet the requirements of securing connections with HTTPS, Elliptic Curve Cryptography (ECC) certificates, and offloading TLS connections to a load balancer, we need to carefully evaluate each option. The key requirements are:
1. Use of ECC certificates for encryption.
2. Offloading TLS connections to a load balancer, which means the load balancer should handle the encryption and decryption.
3. The application uses stateful connections, so session affinity (sticky sessions) is needed to maintain the state between the client and the server.
4. Health checks to monitor the health of the backend web hosts.
Option Analysis:
Option A: Provision a Network Load Balancer. Configure a TLS listener by specifying the use of an ECC SSL certificate that is uploaded to AWS Identity and Access Management (IAM). Turn on health checks to monitor the web hosts that connect to the end users.
- Pros:
- Network Load Balancer (NLB) can handle high-throughput traffic and supports TLS offloading.
- You can configure a TLS listener for encrypted connections.
- Health checks can be enabled for monitoring the backend servers.
- Cons:
- NLB does not support session affinity natively (sticky sessions). Since the application uses stateful connections, this is a significant drawback.
- SSL certificates stored in IAM is possible but not recommended because AWS Certificate Manager (ACM) is a more seamless and integrated solution for managing SSL/TLS certificates in AWS.
Conclusion: Rejected. While NLB supports TLS offloading and health checks, it does not support session affinity, which is crucial for stateful connections.
Option B: Provision an Application Load Balancer. Configure an HTTPS listener by specifying the use of an ECC SSL certificate that is uploaded to AWS Certificate Manager (ACM). Configure a default action to redirect to the URL for the application. Turn on health checks to monitor the web hosts that connect to the end users.
- Pros:
- Application Load Balancer (ALB) supports HTTPS listeners and ECC SSL certificates directly from AWS Certificate Manager (ACM), which makes certificate management easier and more secure.
- Health checks are available to monitor backend hosts.
- ALB also supports session affinity (sticky sessions) to maintain stateful connections between the end users and backend EC2 instances.
- Cons:
- The requirement to redirect to the URL could be unnecessary if the application doesn't require redirection, which adds a bit of complexity.
Conclusion: Sel...
Author: Victoria · Last updated Jun 30, 2026
A company hosts infrastructure services in multiple VPCs across multiple accounts in the us-west-2 Region. The VPC CIDR blocks do not overlap. The company wants to connect the VPCs to its data centers by using AWS Site-to-Site VPN tunnels.
The connections must be encrypted in transit. Additionally, the connection from each data center must route to the c...
The company needs to connect multiple VPCs across multiple accounts to its data centers using AWS Site-to-Site VPN tunnels while ensuring the connections are encrypted, highly available, and capable of automatic failover. Additionally, each connection must route to the closest AWS edge location. Let's evaluate each option based on the requirements:
Key Requirements:
1. Encryption in transit: The VPN connections must be secure.
2. Routing to the closest AWS edge location: This is important to ensure optimal performance and routing efficiency.
3. High availability with automatic failover: The connections need to support redundancy and automatic failover.
4. Multiple accounts and VPCs: The solution must handle multiple VPCs in different accounts.
Option A: Deploy a transit gateway. Share the transit gateway with each of the other accounts by using AWS Resource Access Manager (AWS RAM). Create VPC attachments to the transit gateway from each service account. Add routes to the on-premises subnet in each of the service VPC route tables by using the attachment as the gateway. Create Site-to-Site VPN tunnel attachments with dynamic routing to the transit gateway. Enable the acceleration feature for the Site-to-Site VPN connection. Configure the VPN tunnels on the on-premises equipment. Configure BGP peering.
- Pros:
- Transit Gateway (TGW) is designed for large-scale, multi-account, and multi-VPC architectures. It facilitates easy inter-VPC communication and simplifies routing management.
- BGP peering allows dynamic routing, which ensures that routes are automatically updated in case of changes, including failover scenarios.
- The VPN acceleration feature optimizes the VPN connections for performance.
- AWS Resource Access Manager (RAM) allows sharing the transit gateway across multiple accounts, which is essential in a multi-account environment.
- Dynamic routing allows automatic updates and failover, making the solution resilient to failures.
- Cons:
- While the solution is robust, it might be more complex and costly than simpler alternatives due to the use of a transit gateway, especially if the volume of traffic is low or the complexity of VPCs is minimal.
Conclusion: Selected. This solution is the most scalable and meets the requirements for high availability, failover, dynamic routing, and multi-account VPC connectivity.
Option B: Deploy VPN gateways to each account. Enable the acceleration feature for VPN gateways on each account. Add routes to the on-premises subnet in each of the service VPC route tables. Use the VPNs as the gateway. Configure the VPN tunnels on the on-premises equipment. Configure BGP peering.
- Pros:
- Using VPN gateways is a straightforward solution and can be simpler to set up than using a transit gateway.
- BGP peering ensures dynamic routing, which allows for automatic failover and route updates.
- The VPN acceleration feature provides improved performance for VPN connections.
- Cons:
- VPN gateways are more suitable for single VPCs or simpler architectures. They do not scale as easily when there are multiple VPCs ac...
Author: Oscar · Last updated Jun 30, 2026
A company has a transit gateway in AWS Account A. The company uses AWS Resource Access Manager (AWS RAM) to share the transit gateway so that users in other accounts can connect to multiple VPCs in the same AWS Region. AWS Account B contains a VPC (10.0.0.0/16) with subnet 10.0.0.0/24 in the us-west-2a Availability Zone and subnet 10.0.1.0/24 in the us-west-2b Availability Zone. Resources in these subnets can communicate with other VPCs.
A network engineer creates two new subnets: 10.0.2.0/24 in the us-west-2b Availability Zone and 10.0.3.0/24 in the us-west-2c Availability Zone. All the subnets share one route table. The default route 0.0.0.0/0 i...
To ensure that resources in subnet 10.0.3.0/24 can communicate with other VPCs, the key issue lies in routing, particularly how the new subnet is handled within the transit gateway's routing and propagation setup. Let’s analyze the options based on the provided situation:
Key Considerations:
1. Subnet Communication: Resources in subnet 10.0.2.0/24 can communicate with other VPCs, but resources in subnet 10.0.3.0/24 cannot. This suggests an issue in routing or propagation related to the new subnet.
2. Route Tables: The default route (0.0.0.0/0) points to the transit gateway, so the issue likely lies with subnet-specific routing or propagation.
3. Transit Gateway Attachment: The transit gateway needs to have proper routing to ensure that all subnets within the VPC can reach other VPCs via the shared transit gateway.
Option A: In Account B, add 10.0.2.0/24 and 10.0.3.0/24 as the destinations to the route table. Use the transit gateway as the target.
- Analysis: The route table in Account B's VPC already has the default route (0.0.0.0/0) pointing to the transit gateway. Adding specific routes for 10.0.2.0/24 and 10.0.3.0/24 would be redundant since the default route (0.0.0.0/0) should already forward traffic to the transit gateway. Moreover, subnet 10.0.2.0/24 is already working fine, suggesting the issue isn't with the destination routes but rather with the attachment or propagation.
- Conclusion: This option doesn’t address the root cause, which seems to be related to the attachment or propagation. Rejected.
Option B: In Account B, update the transit gateway attachment. Attach the new subnet ID that is associated with us-west-2c to Account B's VPC.
- Analysis: This option focuses on ensuring that the new subnet (10.0.3.0/24) in us-west-2c is included in the transit gateway attachment. Since subnets are associated with the transit gateway attachment, it’s possible that the new...
Author: Ishaan · Last updated Jun 30, 2026
A company has started using AWS Cloud WAN with one edge location in the us-east-1 Region. The company has a production segment and a security segment in AWS Cloud WAN. The company also has a default core network policy.
The company has created a production VPC for the production workload. The company has created an outbound inspection VPC to inspect internet-bound traffic from the production VPC. The company has attached the production VPC to the production segment and has attached the outbound inspection VPC to the security segment. The company has also created an AWS Network Firewall firewall in the outbound inspection VPC to inspect internet-based traffic.
The company has updated a route table for the production VPC to send all internet-bound traffic to the AWS Cloud WAN core network. The company has updated a route table for the outboun...
Let's evaluate each option in detail based on the scenario provided:
1. Option A: Update the core network policy to configure segment sharing. Share the production segment with the security segment.
- Reasoning: Segment sharing typically allows multiple segments to share resources or traffic flows. However, in this scenario, the company has two separate segments: one for production and one for security. Sharing the segments may introduce complexity or unwanted behavior, as it would allow traffic from the production segment to be routed through the security segment without the proper inspection being enforced. This is not a recommended approach, as the security segment’s role is to inspect traffic, not to mix it with production traffic.
- Rejection: This could lead to a broader scope of traffic management, but it doesn't resolve the specific issue of internet-bound traffic routing and inspection.
2. Option B: Update the core network policy to create a static route for the security segment. Specify 0.0.0.0/0 as the destination CIDR block. Specify the outbound inspection VPC as an attachment.
- Reasoning: This option suggests creating a static route for the security segment directing all internet-bound traffic to the outbound inspection VPC. However, the production VPC is where the traffic originates, not the security segment. The security segment's role is to inspect the traffic and should not be the first destination for the internet-bound traffic. Therefore, the traffic must first route through the outbound inspection VPC and then to the internet, not the other way around.
- Rejection: This routing approach doesn't align with how the company wants traffic to flow (production -> inspection -> internet). Routing traffic from the security segment wouldn't solve the problem in the production VPC.
3. Option C: Update the core network policy to create a static route for the production segment. Specify 0.0.0.0/0 as the destination CIDR block. Specify the outbound inspection VPC as an attachment.
- Reasoning: This is a valid option. The production VPC must route its internet-bound traffic to the outbound inspection VPC for inspection before accessing the internet. This ensures that the outbound traffic from the production VPC goes through the outbound inspection VPC (with the AWS Network Firewall), where internet-bound traffic is filtere...
Author: Elizabeth · Last updated Jun 30, 2026
A company has two business units (BUs). The company operates in the us-east-1 Region and the us-west-1 Region. The company plans to extend to more Regions in the future. Each BU has a VPC in each Region. Each Region has a transit gateway with the BU VPCs attached. The transit gateways in both Regions are peered.
The company will create several more BUs in the future and will need to isolate some of the BUs from the...
Let's evaluate each of the given options in terms of the company's requirements, focusing on scalability, operational efficiency, and traffic isolation.
Option A: Create a new transit gateway for each new BU in each Region. Peer the new transit gateways with the existing transit gateways. Update the route tables to control traffic between BUs.
- Reasoning: This option involves creating a new transit gateway for each BU in each Region. You would then need to peer these transit gateways across Regions, which could be complex and require extensive updates to route tables to manage traffic between BUs.
- Rejection: While this approach is possible, it can quickly become operationally complex as more BUs and Regions are added. Maintaining route tables for numerous transit gateways and managing the peering relationships between them can lead to higher administrative overhead. The solution does not provide the required traffic isolation at a scalable level for future expansion.
Option B: Create an AWS Cloud WAN core network with an edge location in both Regions. Configure a segment for each BU with VPC attachments to the new BU VPCs. Use segment actions to control traffic between segments.
- Reasoning: AWS Cloud WAN is designed for large, multi-region network management. By using Cloud WAN, you can configure segments for each BU, and use segment actions to control traffic between the BUs.
- Rejection: This approach is relatively straightforward, but the solution does not fully support traffic isolation between BUs. Segment actions alone may not provide the level of isolation required for the company's use case, especially if they need strict segmentation between BUs. More advanced isolation capabilities may be required.
Option C: Create an AWS Cloud WAN core network with an edge location in both Regions. Configure a segment for each BU with VPC attachments to ...
Author: Matthew · Last updated Jun 30, 2026
A company has an AWS Site-to-Site VPN connection between AWS and its branch office. A network engineer is troubleshooting connectivity issues that the connection is experiencing. The VPN connection terminates at a transit gateway and is statically routed. In the transit gateway route table, there are several static route entries that target specific subnets at the branch office.
The network engineer determines that the root cause of the issues was the ...
Let's evaluate each option based on the requirements:
Option A: Determine a supernet for the branch office. In the transit gateway route table, add an aggregate route that targets the VPN attachment. Replace the specific subnet routes in the transit gateway route table with the new supernet route.
- Reasoning: In this option, the network engineer would create a supernet that encompasses the new expanded subnet range and then update the transit gateway route table to use this aggregate route. This eliminates the need to update specific subnet entries whenever there is an expansion of subnet ranges in the branch office.
- Acceptance: This is an ideal solution for future expansions. It reduces the administrative overhead significantly because you only need to update one route (the supernet) instead of managing multiple subnet-specific routes in the future. Aggregate routing minimizes the number of route entries and provides a more scalable solution to handle subnet changes.
- Key Factor: This approach is simple and reduces future administrative effort as subnets expand, as you only need to adjust the aggregate route rather than each individual subnet entry.
Option B: Create an AWS Direct Connect gateway and a transit VIF. Associate the Direct Connect gateway with the transit gateway. Create a propagation for the Direct Connect attachment to the transit gateway route table.
- Reasoning: This option introduces AWS Direct Connect, which is a private connection between your on-premises network and AWS. It is a solid choice for high-bandwidth, low-latency connections, but it is not directly related to the issue of handling the expansion of branch office subnets and the administrative overhead of managing VPN routes.
- Rejection: The problem here is specifically about the VPN connection and its route table management, which is unrelated to Direct Connect. Introducing Direct Connect adds unnecessary complexity when the VPN connection is the primary concern, especially since Direct Connect is not required to solve the problem at hand.
Option C: Create a dynamically routed VPN connection on the transit gateway. Connect the dynamically routed VPN connection to the branch office. Create a propagation for the VPN attachment to the transit gateway route table....
Author: Isabella1 · Last updated Jun 30, 2026
An education agency is preparing for its annual competition between schools. In the competition, students at schools from around the country solve math problems, complete puzzles, and write essays.
The IP addressing plan of all the schools is well-known and is administered centrally. The competition is hosted in the AWS Cloud and is not publicly available. All competition traffic must be encrypted in transit. Only authorized endpoints can access the competition. All the schools have firewall policies that block ICMP traffic.
A network engineer builds a solution in which all the schools access the competition through AWS Site-to-Site VPN connections. The network engine...
Let's break down each option and determine the most effective and cost-efficient solutions.
Option A: Monitor the state of the VPN tunnels by using Amazon CloudWatch. Create a CloudWatch alarm that uses Amazon Simple Notification Service (Amazon SNS) to notify people at the affected school if the tunnels are down.
- Reasoning: AWS Site-to-Site VPN automatically publishes tunnel state changes (up/down) to CloudWatch metrics. By creating a CloudWatch alarm based on these metrics, the network engineer can easily detect when a VPN tunnel goes down and trigger an SNS notification to the affected school. This approach uses AWS-native tools and directly leverages the existing VPN infrastructure, making it cost-effective and easy to implement.
- Acceptance: This solution is efficient because it uses existing infrastructure and native AWS services for monitoring and notifications. No additional infrastructure (e.g., Lambda functions) is needed, keeping it cost-effective and scalable.
- Selected for Cost-Effectiveness: This option is a straightforward, low-cost solution that meets the requirements.
Option B: Create a scheduled AWS Lambda function that pings each school's on-premises customer gateway device. Configure the Lambda function to send an Amazon Simple Notification Service (Amazon SNS) notification to people at the affected school if the ping fails.
- Reasoning: Pinging each on-premises device via a Lambda function may not be practical or efficient because:
- The schools block ICMP traffic, so the pings would fail.
- This solution could be more expensive due to the need for Lambda invocations and external network traffic to the on-premises devices.
- Rejection: This option won't work because ICMP is blocked, and it adds unnecessary complexity and cost by relying on external traffic and custom Lambda functions.
Option C: Create a scheduled AWS Lambda function that uses the VPC Reachability Analyzer API to verify the connectivity. Configure the Lambda function to send an Amazon Simple Notification Service (Amazon SNS) notification to people at the affected school if failure occurs.
- Reasoning: VPC Reachability Analyzer is typically used for analyzing AWS network connectivity, not external connections like VPNs. It won't be directl...
Author: Madison · Last updated Jun 30, 2026
A company securely connects resources that are in its VPC to a software as a service (SaaS) solution from a SaaS provider. The SaaS solution is hosted in the AWS Cloud and is powered by AWS PrivateLink. The company uses a PrivateLink endpoint to access the SaaS solution behind the SaaS provider's Network Load Balancer (NLB).
The company recently added a new Availability Zone and new subnets...
Let's break down each option and analyze the situation:
Option A: The CIDR block of the new subnets conflicts with the SaaS provider's CIDR block.
- Reasoning: PrivateLink endpoints allow secure, private access to SaaS solutions hosted by AWS. If there were a CIDR block conflict between the VPC subnets and the SaaS provider's CIDR block, it could cause issues when creating a VPC endpoint. However, AWS PrivateLink generally avoids such conflicts by using a private IP address space that should not overlap with your VPC.
- Rejection: This scenario is unlikely. AWS PrivateLink manages the IP ranges for communication between the VPC and the SaaS service to avoid conflicts. CIDR conflicts are not a common reason for the failure to deploy an endpoint.
Option B: The enableDnsHostnames attribute and enableDnsSupport attribute were not configured on the new subnets in the new Availability Zone.
- Reasoning: The enableDnsHostnames and enableDnsSupport attributes must be enabled in a VPC to allow DNS resolution for resources in the VPC. If these attributes were not configured correctly, it could prevent the resolution of the DNS names associated with the PrivateLink endpoint. However, this would typically affect all DNS-related functionality and not specifically the deployment of PrivateLink endpoints.
- Rejection: While this might cause DNS resolution issues, it does not directly explain the problem with deploying the new interface endpoint in a different Availability Zone. This issue is more related to DNS resolution than to the core reason for the failure in creating the endpoint.
Option C: The SaaS provider does not offer the solution in the new Availability Zone a...
Author: StarryEagle42 · Last updated Jun 30, 2026
A company wants to use an AWS Network Firewall firewall to secure its workloads in the cloud through network traffic inspection. The company must record complete metadata information, such as source/destination IP addresses and protocol type. The company must also record all network traffic flows and any DROP or ALERT actions that the firewall takes for traffic that the firewall processes. The Network Firewall endpoints are placed in the correct subnets...
To meet the requirements outlined, the network engineer needs to ensure that all relevant metadata, including source/destination IP addresses, protocol type, and traffic flows (including any DROP or ALERT actions), are captured by AWS Network Firewall. The goal is to log network traffic flows and the actions taken by the firewall (such as drop or alert), and to ensure that all relevant information is recorded for security and monitoring purposes.
Analyzing Each Option:
Option A:
- Create a firewall policy to ensure that traffic is processed by stateless or stateful rules according to needs. Select Amazon CloudWatch Logs as the destination for the flow logs.
- This option involves setting up flow logs with CloudWatch Logs, but it doesn’t explicitly address the need to capture both flow logs and alert logs. Also, it lacks detail on logging specific firewall actions (DROP, ALERT). CloudWatch is useful for monitoring but is not sufficient alone to meet the complete logging requirements, especially when distinguishing between stateful or stateless logs.
Option B:
- Create a firewall policy to ensure that traffic is processed by stateless or stateful rules according to needs. Configure Network Firewall logging for alert logs and flow logs. Select a destination for logs separately for stateful and stateless engines.
- This option is a better choice because it explicitly mentions configuring both alert logs and flow logs for Network Firewall. It allows for separate destinations for stateful and stateless logs, which gives flexibility for precise monitoring. This is more comprehensive in fulfilling the requirements, as it directly covers both flow logs and alerts.
Option C:
- Create a firewall policy to ensure that a stateful engine processes all the traffic. Configure Network Firewall logging for alert logs and flow logs. Select a destination for alert logs and flow logs.
- This option locks the firewall policy to a stateful engine, which might be overly restrictive if the workload requires both stateful and stateless traffic processing. While it does address logging the required flow and alert logs, the requirement for flexible rule sets (stateless or stateful processing) might be better suited by Option B, which allows for more flexibility.
Option D:
- Create a firewall policy to ensure that a stateful engine processes all the traffic. Configure VPC flow...
Author: Sam · Last updated Jun 30, 2026
A company is building a new workload on AWS that uses an Application Load Balancer (ALB). The company has configured a new ALB target group that uses slow start mode. A team begins registering Amazon EC2 instances as targets in the new target group. During testing, the t...
To determine why the targets did not enter slow start mode, we need to review how AWS Application Load Balancer (ALB) slow start mode works and the possible causes of this issue.
Understanding Slow Start Mode:
Slow start mode in ALB is designed to allow new targets to gradually increase the amount of traffic they handle as they warm up, preventing them from being overwhelmed by requests when they are first registered. However, this feature only works under specific conditions.
Analyzing the Options:
Option A: The ALB configuration uses the round robin routing algorithm for traffic.
- The round robin algorithm is the default routing method for ALB, and it works well with slow start mode. The round robin algorithm does not prevent targets from entering slow start mode, as it simply distributes traffic across healthy targets in a cyclic manner.
- Reason for rejection: The routing algorithm is not the cause of the problem. This option is irrelevant because round robin will not prevent slow start mode.
Option B: The target group did not contain at least one healthy target configured in slow start mode.
- Slow start mode only applies to healthy targets. If no healthy targets exist in the target group or if the targets are not properly registered, slow start mode will not be triggered. Also, if a target is not in a healthy state, it cannot enter slow start mode.
- Reason for selection: This is the correct option because slow start mode requires at lea...
Author: Emily · Last updated Jun 30, 2026
A network engineer is using AWS Direct Connect connections and MACsec to encrypt data from a corporate data center to the Direct Connect location. The network engineer learns that the MACsec secret key might have been compromised. The network engineer n...
In this scenario, the network engineer needs to update the MACsec secret key for the AWS Direct Connect connection because the current key might have been compromised. The solution needs to involve creating or modifying a key and updating the connection with the correct security credentials.
Analyzing the Options:
Option A: Create a new MACsec secret key that uses an AWS Key Management Service (AWS KMS) AWS managed key. Associate the new pre-shared key, Connection Key Name (CKN), and Connectivity Association Key (CAK) with the connection.
- AWS KMS AWS managed keys are automatically managed and rotated by AWS, and they are not ideal for highly specific use cases where the user needs full control over the key's lifecycle (like in this case, where the key needs to be updated manually due to a compromise).
- Reason for rejection: While AWS KMS AWS managed keys are convenient, they do not provide the level of control needed for this situation, especially because the network engineer needs to manually manage the key after compromise.
Option B: Create a new MACsec secret key that uses an AWS Key Management Service (AWS KMS) customer managed key. Associate the new pre-shared key, Connection Key Name (CKN), and Connectivity Association Key (CAK) with the connection.
- AWS KMS customer managed keys allow the network engineer to have full control over key creation, rotation, and management. This option enables the creation of a new, uncompromised key and manually managing it. This is the correct solution because the engineer can create and associate a new key while maintaining control over its lifecycle.
- Reason for selection: This is the most appropriate solution because it provides control over the key management and allows for the creation of a new key to replace the compromised one.
...
