Amazon Practice Questions, Discussions & Exam Topics by our Authors

A global company is establishing network connections between the company's primary and secondary data centers and a VPC. A network engineer needs to maximize resiliency and fault tolerance for the connections. The network bandwidth...

To meet the requirements of maximizing resiliency and fault tolerance, while ensuring network bandwidth greater than 10 Gbps, let's evaluate each option based on its technical merits, cost-effectiveness, and suitability for this scenario. Key Requirements: 1. Resiliency and fault tolerance: Connections should be reliable and able to handle failures gracefully. 2. Bandwidth greater than 10 Gbps: The total available bandwidth should exceed 10 Gbps. 3. Cost-effectiveness: The solution should achieve the desired result at the lowest possible cost. Option A: Set up a 100 Gbps connection at the primary data center that terminates at an AWS Direct Connect location. Set up a second 100 Gbps connection at the secondary data center that terminates at a second Direct Connect location. Ensure the connections are managed by separate providers. - Why it's rejected: - While this solution provides sufficient bandwidth (100 Gbps per connection), it is highly expensive due to the significant cost associated with 100 Gbps Direct Connect links. - It involves two separate high-capacity links, which would be an overkill for this requirement, especially when a lower-cost solution (such as two 10 Gbps links) would meet the bandwidth and fault tolerance needs. - This solution is not cost-effective given the company's requirement for greater than 10 Gbps but without the need for such massive capacity. Option B: Set up a 10 Gbps connection at the primary data center that terminates at an AWS Direct Connect location. Set up a second 10 Gbps connection at the secondary data center that terminates at a second Direct Connect location. Ensure the connections are managed by separate providers. - Why it's selected: - This solution provides resiliency and fault tolerance through the use of two separate 10 Gbps Direct Connect connections, ensuring that if one connection fails, the other can continue to provide connectivity. - The 10 Gbps bandwidth per connection meets the requirement for bandwidth greater than 10 Gbps (total of 20 Gbps). - The separate providers for each connection add an extra layer of fault tolerance, reducing the risk of a single point of failure. - Cost-effectiveness: This option is far...

Author: Joseph · Last updated Jun 30, 2026

A company's data center is connected to a single AWS Region by an AWS Direct Connect dedicated connection. The company has a single VPC in the Region. The company stores logs for all its applications locally in the data center. The company must keep all application logs for 7 year...

To meet the requirement of copying logs from an on-premises data center to an Amazon S3 bucket while ensuring secure and reliable connectivity, let's analyze the options and the factors that influence the selection: Key Considerations: 1. Direct Connect: Direct Connect allows private, dedicated network connections between the on-premises data center and AWS, which can be either public or private Virtual Interfaces (VIFs). 2. VPC Endpoint for S3: To securely connect your VPC to Amazon S3, you can use a VPC endpoint. There are two types of endpoints for Amazon S3: - Gateway endpoint: Allows you to privately connect your VPC to S3. - Interface endpoint: Allows private connections to AWS services over PrivateLink, and is typically used for services not natively supported by a gateway endpoint. Option Breakdown: A) Create a public VIF on the Direct Connect connection. Create an Amazon S3 gateway endpoint in the VPC. - A public VIF is used to access AWS public services such as S3 or CloudFront over Direct Connect. - Gateway endpoint is a perfect fit for S3 because it provides direct, private access to Amazon S3 from your VPC. - Pros: Cost-effective, simple, and native support for S3. - Cons: Not ideal for highly sensitive or private workloads that require more granular control over network traffic (though this is a minor concern here). B) Create a private VIF on the Direct Connect connection. Create an Amazon S3 gateway endpoint in the VPC. - Private VIF is used for accessing AWS services like EC2 over Direct Connect, within a VPC. - Gateway endpoint allows you to connect privately to S3 over Direct Connect without using public internet paths. - Pros: Fully private, avoids internet traversal...

Author: Harper · Last updated Jun 30, 2026

A company is planning to host a secure web application across multiple Amazon EC2 instances. The application will have an associated DNS domain in an Amazon Route 53 hosted zone. The company wants to protect the domain from DNS poisoning attacks. The company also wants to allow web browsers to...

Key Considerations: 1. DNS Security: To protect against DNS poisoning attacks, DNS Security Extensions (DNSSEC) should be configured. DNSSEC ensures the integrity of DNS responses by cryptographically signing DNS records, allowing clients to verify the authenticity of the responses. 2. Web Application Authentication: To authenticate users to a web application using a trusted third-party, public X.509 certificates signed by a recognized certificate authority (CA) should be used. Self-signed certificates are not trusted by browsers and cannot facilitate this authentication in a secure manner. Option Breakdown: A) Configure the Route 53 hosted zone to use DNS Security Extensions (DNSSEC). Install self-signed X.509 certificates on the EC2 instances. - DNSSEC is properly configured here, which protects against DNS poisoning. - However, using self-signed X.509 certificates is not appropriate for user authentication because web browsers do not trust self-signed certificates by default. This would lead to security warnings in browsers, and users would be unable to authenticate properly. - Cons: While DNSSEC helps protect DNS data, self-signed certificates do not provide the trusted authentication needed for the web application. B) Configure a Name Authority Pointer (NAPTR) record in the Route 53 hosted zone. Install X.509 certificates that are signed by a public certificate authority on the EC2 instances. - NAPTR records are typically used for services like VoIP and are not typically relevant to securing web application traffic over HTTPS. - While X.509 certificates signed by a public C...

Author: Deepak · Last updated Jun 30, 2026

A company is planning to use an AWS Transit Gateway hub and spoke architecture to migrate to AWS. The current on-premises multi-protocol label switching (MPLS) network has strict controls that enforce network segmentation by using MPLS VPNs. The company has provisioned two 10 Gbps AWS Direct Connect connections to provide resilient, high-speed, low-latency connectivity to AWS. A security engineer needs to apply the concept of network segmentation to the AWS environment to ensure that virtual routing and forwarding (VRF) is logically separated for each of the company's software development environments. The number o...

Key Considerations: 1. Network Segmentation: The company needs to ensure that their development environments are logically separated, which includes managing overlapping address spaces. 2. MPLS VPN Integration: The company's MPLS VPNs need to be integrated with AWS and support VRF to logically segment network traffic, as the number of MPLS VPNs is expected to increase in the future. 3. Operational Overhead: The solution must minimize operational overhead, meaning it should be scalable and easy to manage as the company expands its network. Option Breakdown: A) Deploy a software-defined WAN (SD-WAN) head-end virtual appliance and an SD-WAN controller into a Transit Gateway Connect VPC. Configure the company's edge routers to be managed by the new SD-WAN controller and to use SD-WAN to segment the traffic into the defined segments for each of the company's development environments. - SD-WAN is typically used for flexible, software-defined network management that simplifies connecting various sites and provides granular traffic control. - While SD-WAN can provide network segmentation, this approach introduces additional complexity and operational overhead by introducing an SD-WAN controller and virtual appliances, which would require monitoring, management, and possible integration complexities. - Cons: SD-WAN is a powerful tool but adds operational overhead, especially in an environment that already has complex MPLS VPN requirements. It's an unnecessary layer for the task at hand. B) Configure IPsec VPNs on the company edge routers for each MPLS VPN for each of the company's development environments. Attach each IPsec VPN tunnel to a discrete MPLS VPN. Configure AWS Site-to-Site VPN connections that terminate at a transit gateway for each MPLS VPN. Configure a transit gateway route table that matches the MPLS VPN for each Transit Gateway VPN attachment. - IPsec VPNs are a viable option for securely connecting on-premises networks with AWS. - This solution requires configuring multiple Site-to-Site VPN connections, which would be cumbersome to manage and scale, especially as the number of MPLS VPNs increases. The manual management of individual VPNs, along with the required route tables for each VPN attachment, adds significant complexity and operation...

Author: Ava · Last updated Jun 30, 2026

A company is planning to migrate to AWS and use multiple VPCs in multiple AWS Regions. A network engineer must connect the eu-west-1 and eu-central-1 Regions to the company headquarters and branch office, respectively. The network engineer created a production VPC, named Prod A, with a CIDR block of 10.0.0.0/16. Prod A runs in an account in eu-west-1. The network engineer then created another production VPC, named Prod B, with a CIDR block of 10.1.0.0/16. Prod =D0=92 runs in a different account in eu-central-1. The network engineer performed the following steps to try to achieve the required connectivity: 1. Created one transit gateway in each Region 2. Shared and accepted the transit gateways with the production accounts in both Regions 3. Configured the peering attachment between both transit gateways 4. Attached both VPCs to the respective Region transit gateway 5. Created both transit gateway route tables and associated the attachments with ...

Key Considerations: 1. Transit Gateway Peering: The network engineer has already configured a peering connection between the two Transit Gateways in different regions (eu-west-1 and eu-central-1). This should allow inter-region routing, but proper route propagation and static routing must be configured to ensure traffic can flow correctly. 2. VPC Route Tables: Proper route propagation and static routes are critical for ensuring traffic is directed to the correct Transit Gateway and between the VPCs. 3. VPC CIDR Conflicts: The VPCs have distinct CIDR blocks (10.0.0.0/16 for Prod A and 10.1.0.0/16 for Prod B), so no direct IP overlap issues arise here, but proper routing must be in place. Option Breakdown: A) Modify the IP address of the peering attachment to a wider range. - The peering attachment between Transit Gateways does not require a wider IP range. The CIDR blocks for the VPCs (10.0.0.0/16 and 10.1.0.0/16) are already distinct and do not conflict, so changing the IP address range of the peering attachment is unnecessary. - Cons: This option does not directly address the problem of routing configuration between the Transit Gateways and VPCs. B) Delete the static routes that were in the transit gateway route table to send traffic to the remote VPC and enable route propagation instead. - Static routes in the Transit Gateway route tables are meant to direct traffic between VPCs. However, since the Transit Gateway is already connected to the VPCs and route propagation is enabled, static routes may be redundant. Enabling route propagation will allow the Transit Gateway to dynamically learn the VPC routes from the VPC route tables, making manual static routes unnecessary. - Pros: By enabling route propagation on the Transit Gateway route tables, traffic can automatically be routed between regions wit...

Author: Lina Zhang · Last updated Jun 30, 2026

A company hosts an application on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are part of an Amazon EC2 Auto Scaling group. To comply with new security standards, the company must capture all application access data, including server response codes, request paths, latency, and client...

Key Considerations: 1. Application Access Data: The company needs to capture key metrics like server response codes, request paths, latency, and client IP addresses. These are typically available through the Application Load Balancer (ALB) access logs, which provide detailed information about client requests and responses. 2. Performance Analysis: The company requires the ability to query and analyze the captured data, which suggests using a tool that supports easy querying and analysis, such as Amazon Athena. 3. Operational Simplicity: The solution should minimize complexity, be scalable, and provide a straightforward way to access the necessary data for analysis. Option Breakdown: A) Enable VPC flow logs on the ALB subnets. Store the logs to an Amazon S3 bucket. Query the logs in the S3 bucket by using Amazon Athena. - VPC Flow Logs capture network-level data about traffic flowing through the VPC, including IP addresses, ports, and traffic flow. However, they do not capture detailed application-level information like request paths, server response codes, or latency. - Cons: VPC Flow Logs are useful for network-level monitoring but do not meet the requirement of capturing detailed application access data as specified in the use case. B) Configure Amazon VPC Traffic Mirroring on all EC2 elastic network interfaces. Deploy a third-party monitoring appliance from AWS Marketplace in a private subnet. Use Amazon Data Firehose to send all mirrored traffic to the monitoring appliance. Query the logs directly from the monitoring appliance. - VPC Traffic Mirroring is a highly detailed solution for capturing network traffic at the packet level. While it can capture all traffic, this is more detailed than needed for the use case, and using third-party monitoring appliances introduces unnecessary complexity. - Cons: Traffic mirroring can gener...

Author: Siddharth · Last updated Jun 30, 2026

A company has five VPCs in the us-east-1 Region. The company hosts an internal web application in us-east-1. One of the company's VPCs. named VPC-A, needs to connect to an external partner's AWS environment. The partner's environment is in the same AWS Region where the partner hosts a new version of the company's web application. The partner hosts its version of the application in a VPC named VPC-B. The company has Amazon EC2 instances in VPC-A that need to connect to the web application in VPC-B A network engineer notices that the partner's VPC-B and the company's VPC-A use the same IP space. The network engineer needs...

To solve the issue of allowing EC2 instances in VPC-A to connect to the web application in VPC-B, while keeping the existing environment unaffected, the network engineer needs to work with VPCs that have overlapping IP address spaces. The selected solution should meet the following requirements: - Allow connectivity between the two VPCs. - Avoid affecting the existing infrastructure of both the company and the partner. - Handle overlapping IP spaces between VPC-A and VPC-B. Option analysis: A) Establish a VPC peering connection between VPC-A to VPC-B. - Explanation: VPC peering allows traffic to flow between two VPCs, but there are some limitations when it comes to overlapping IP ranges. VPC peering will not work if both VPCs use the same IP address range, as traffic cannot be routed properly. - Rejection Reason: Since VPC-A and VPC-B have overlapping IP address spaces, this option will not work. B) Ensure the partner creates a VPC endpoint service that uses a Network Load Balancer in VPC-B. - Explanation: A VPC endpoint service allows connections from other VPCs or AWS accounts to access resources in a private VPC, but it typically requires a well-defined, non-overlapping IP space and a specific use case where a service is exposed through an NLB. - Rejection Reason: This option doesn’t address the problem of overlapping IP spaces and is more suited for exposing services to external VPCs or accounts, not for direct communication between VPCs with overlapping IP ranges. C) Deploy a VPC endpoint in VPC-A that uses a VPC endpoint service that is shared by the partner. - Explanation: VPC endpoints can allow private connections between VPCs and AWS services, but they are designed primarily for services such as S3, Dynam...

Author: GlowingTiger · Last updated Jun 30, 2026

A company has a hybrid environment that connects an on-premises data center to the AWS Cloud. The hybrid environment uses a 10 Gbps AWS Direct Connect dedicated connection. The Direct Connect connection has multiple private VIFs that terminate in multiple VPCs. To comply with regulations, the company must encrypt all WAN traffic, regardless of the underlying transpo...

To meet the requirement of encrypting all WAN traffic over the AWS Direct Connect connection without affecting the company's bandwidth capacity, let's analyze each option carefully. Option analysis: A) Create a public VIF. Configure a new AWS Site-to-Site VPN connection to use the new public VIF. - Explanation: A public VIF (Virtual Interface) connects to public AWS services, not private VPCs. A Site-to-Site VPN connection over a public VIF would route traffic over the internet, which defeats the purpose of using Direct Connect and does not comply with the regulation requiring encryption on all WAN traffic. The VPN would also add overhead, potentially impacting bandwidth. - Rejection Reason: This option uses a public VIF, which doesn’t meet the requirement of encrypting WAN traffic between the on-premises data center and the AWS Cloud while maintaining bandwidth. B) Configure MAC security (MACsec) support on the port of the existing Direct Connect connection. Change the encryption mode to must_encrypt. - Explanation: MACsec (Media Access Control Security) is a security standard for encrypting traffic at the data link layer (Layer 2). By enabling MACsec on the port of the existing Direct Connect connection, the company can encrypt all traffic between the on-premises data center and AWS over Direct Connect without affecting the underlying bandwidth. The "must_encrypt" setting ensures that encryption is always applied. - Selected: This is the ideal solution because it meets the regulatory encryption requirement while ensuring there is no impact on the bandwidth capacity (since it works at the data link layer). Additionally, it doesn't require the company to create a new connect...

Author: SolarFalcon11 · Last updated Jun 30, 2026

A company needs to capture and log traffic for Nitro-based Amazon EC2 instances to comply with regulations. The company's network team has prepared a solution that enables VPC traffic mirroring and sends traffic to a second set of EC2 instances in an Auto Scaling group. The network team has added a Network Load Balancer (NLB) in front of the EC2 instances the traffic will be sent to. However, the ...

To solve the issue of traffic mirroring not being sent to the EC2 instances behind the Network Load Balancer (NLB), let's break down the key points and the options provided. Key factors to consider: - Traffic Mirroring: Traffic mirroring captures traffic at the elastic network interface (ENI) level of Amazon EC2 instances. It is designed to capture and replicate traffic for analysis, and the mirrored traffic is sent to a specific destination for logging or analysis. - Network Load Balancer (NLB): The NLB is a Layer 4 (Transport Layer) load balancer that operates at the TCP/UDP level. It is designed to handle high throughput and low latency. However, the traffic mirrored must be directed to an appropriate target that can handle it. Option analysis: A) Select the NLB as a source for traffic mirroring. Use a UDP listener. - Explanation: NLBs operate at Layer 4 (TCP/UDP) and do not serve as a "source" for traffic mirroring. Traffic mirroring requires an ENI on an EC2 instance or a network interface as the source, not a load balancer. Using a UDP listener is also not relevant in this case because the NLB is not the correct entity to capture traffic for mirroring. - Rejection Reason: NLB cannot act as the source for traffic mirroring. It is used as a target, not a source, for mirroring traffic. B) Select the NLB as a target for traffic mirroring. Use a TCP listener and a UDP listener. - Explanation: The NLB can be a valid target for traffic mirroring, but this option includes unnecessary complexity by specifying both TCP and UDP listeners. The main issue is that NLBs do not operate in a way that would support receiving mirrored traffic over both TCP an...

Author: Ishaan · Last updated Jun 30, 2026

A US-based company is expanding its business to Europe. A network engineer needs to extend the company's network infrastructure by setting up a new hub and spoke architecture in the eu-west-1 Region. The network engineer uses a transit gateway peering connection to connect the new resources in eu-west-1 to an existing environment in the us-east-1 Region. The hub and spoke architecture in each AWS Region includes an inspection VPC that uses AWS Network Firewall to centralize traffic inspection for each Region. To reduce costs, the network engineer decides to inspect inter-Region traffic by using the inspection VPC in the Region that originates the traffic. The network engineer configures the transit gateway route tables accordingly for e...

The issue of inter-Region communication not working in the described architecture can be solved by addressing how traffic is routed and inspected across the Regions. Let’s analyze the provided options carefully. Key factors to consider: - Transit Gateway: The transit gateway connects VPCs across Regions and can route traffic between VPCs in different Regions (via peering). - Inspection VPC with AWS Network Firewall: The goal is to inspect inter-Region traffic within the Region where the traffic originates to save costs. - Inter-Region Routing: The issue is likely related to how traffic is being routed between the Regions and how the traffic is being inspected by the Network Firewall. Option analysis: A) Configure Open Shortest Path First (OSPF) routing on the transit gateway peering connection to propagate the VPC CIDR blocks from each Region to the remote peer. - Explanation: OSPF is a dynamic routing protocol used to propagate routing information. Transit gateways in AWS don’t require dynamic routing like OSPF for inter-Region traffic; instead, static routing via the transit gateway route tables is commonly used. - Rejection Reason: AWS Transit Gateway route propagation does not rely on OSPF. Static route configuration in the route tables of the transit gateway is sufficient, and there is no need for OSPF in this case. B) Use AWS Resource Access Manager (AWS RAM) to share access between the transit gateways. Enable the Allow sharing with anyone setting. - Explanation: AWS Resource Access Manager (RAM) allows sharing of AWS resources, but it is primarily used to share resources like Transit Gateways across accounts. However, in this case, the issue does not seem to be about sharing access between accounts or regions; it's about routing and traffic inspection. - Rejection Reason: This option is irrelevant becaus...

Author: Samuel · Last updated Jun 30, 2026

A company runs applications in two VPCs that are in separate AWS Regions. One VPC is in the us-east-1 Region. The second VPC is in the us-west-1 Region. The company needs to establish connectivity between the two VPCs. The company also needs to connect the VPCs to applications that run in an on-premises data center. The current traffic requirement between the VPCs is 50 =D0=A2=D0=92 per month. The company expects traffic volume between the VPCs to increase. The traffic requirement from the VPCs to...

To determine the most cost-effective solution for connecting two VPCs in separate AWS Regions and connecting those VPCs to an on-premises data center, let's analyze the provided options and the requirements. Key factors to consider: 1. Traffic between VPCs: The company expects traffic between the VPCs to increase. The current traffic requirement is 50 TB per month, which may grow, so the solution should handle high-volume traffic efficiently. 2. Traffic to the on-premises data center: The data center traffic is 10 TB per month and is expected to remain constant, so the connection to the on-premises data center needs to be stable and cost-efficient. 3. Cost-effectiveness: The solution must provide high performance and scalability without incurring high costs. Option analysis: A) Create a transit gateway in each Region. Create VPN connections from the transit gateways to the on-premises firewall. Create a peering connection between the transit gateways. - Explanation: A transit gateway allows for scalable connectivity between multiple VPCs and on-premises data centers. Using peering between the transit gateways in two regions provides a cost-effective way to route traffic between the VPCs. However, using VPN connections for traffic to the on-premises data center can be costly and inefficient, especially if high throughput is required. - Rejection Reason: While the transit gateway solution scales well and is efficient for large VPC-to-VPC communication, the VPN connections to the on-premises data center could lead to higher operational costs. VPNs are typically slower than direct connections like AWS Direct Connect, which is more suitable for large data volumes between VPCs and on-premises environments. B) Create a virtual private gateway in each Region. Create VPN connections from the on-premises firewall to the virtual private gateways. Configure the on-premises firewall to route the traffic between the two VPCs. - Explanation: This option involves setting up VPN connections from the on-premises data center to each VPC using virtual private gateways (VGWs). The on-premises firewall would then route traffic between the two VPCs. However, configuring the firewall to route traffic between VPCs manually can become complex and...

Author: Nia · Last updated Jun 30, 2026

A company runs workloads in multiple VPCs. The company needs to securely access a workload in one of the VPCs, named VPC-A, from an on-premises data center. A network engineer sets up an AWS Site-to-Site VPN connection to a transit gateway. The network engineer configures dynamic routing for the connection, and communication works properly. Recently, the owner of VPC-A added another CIDR range to the VPC. The VPC-A owner created workloads that use the additional CIDR range. The company's on-premises network is unable to reach the new workloads. The network engineer ...

The task is to ensure that network connectivity between the company's on-premises data center and the workloads in VPC-A works correctly, even after the CIDR range in VPC-A is modified or expanded. Let's analyze each option to determine the most operationally efficient solution. Option A: Configure route propagation for VPC-A to the VPN attachment route table. - Analysis: Route propagation automatically updates the route table in the transit gateway based on the routes advertised by the connected VPCs and VPNs. If VPC-A's CIDR range changes, the transit gateway will automatically propagate those changes, which will ensure that the network connectivity is up to date without any manual intervention. - Why it's preferred: This option provides automatic updates whenever the CIDR of VPC-A changes, which eliminates the need for manual updates and ensures seamless scalability. It's also operationally efficient since it doesn’t require writing Lambda functions or setting up alarms, and it works automatically. - Key factors: Automatic propagation ensures minimal human intervention, scalability with future CIDR additions, and proper handling of route updates without manual configurations. Option B: Manually update the VPN attachment route table to include the new CIDR range. - Analysis: Manually updating the route table would require the network engineer to keep track of any changes to VPC-A's CIDR range. While this would work, it’s labor-intensive, error-prone, and doesn't scale well when there are frequent CIDR range changes in VPC-A. - Why it's not ideal: This option is not scalable and is prone to errors or missed updates. Additionally, it requires ongoing manual effort, which decreases operational efficiency. Option C: Configure an Amazon EventBridge rule to invoke an AWS Lambda functio...

Author: Madison · Last updated Jun 30, 2026

A company is migrating its internet VPN connections to dedicated AWS Direct Connect connections. The company needs to set up the Direct Connect connections so that all network communications are encrypte...

The goal here is to ensure that all network communications over the AWS Direct Connect connections are encrypted in transit. Since Direct Connect itself doesn't encrypt traffic by default, encryption needs to be implemented either through MACsec (Media Access Control Security) or IPsec (Internet Protocol Security). Let's go through each option: Option A: Create new Direct Connect connections while requesting MACsec ports. - Analysis: AWS Direct Connect supports encryption through MACsec on dedicated connections, which provides encryption at Layer 2 (data link layer). By requesting MACsec-enabled ports when setting up new Direct Connect connections, the communication will be encrypted as it travels over the physical link. - Why it's selected: This option ensures that all network communication over the Direct Connect links is encrypted at Layer 2, which is a requirement for securing transit between the on-premises network and AWS. Option B: Create a MACsec Connectivity Association Key Name (CKN) and Connectivity Association Key (CAK) pair. Associate the pair with each new connection. - Analysis: For MACsec to work, you need to create a CKN and CAK pair, which are used to establish and secure the encryption keys on both ends of the Direct Connect link. This is crucial for enabling MACsec encryption, as it ensures that both the AWS and on-premises devices can securely communicate using the shared encryption keys. - Why it's selected: This step is necessary for setting up MACsec and ensuring the communication is encrypted. Without it, MACsec cannot be activated. Option C: Update the on-premises routers to use MACsec and the shared Connectivity Association Key Name (CKN) and Connectivity Association Key (CAK) pair. - Analysis: For MACsec to work, the on-premises router must also be configured to use the same MACsec encryption standards and the CKN/CAK pair. This step is necessary to ensure that the on-premises network can communicate securely with AWS ove...

Author: Ava · Last updated Jun 30, 2026

A company has an application VPC and a networking VPC that are connected through VPC peering. The networking VPC contains a Network Load Balancer (NLB). The application VPC contains Amazon EC2 instances that run an application. The EC2 instances are part of a target group that is associated with the NLB in the networking VPC. The company configures a third VPC and peers it to the networking VPC. The new VPC contains a new version of the existing application. The new version of the application runs on new EC2 instances in an application subnet. The new version of the application runs i...

To establish connectivity between the new version of the application in the new VPC and the Network Load Balancer (NLB) in the networking VPC, we need to address a few key considerations. The main goal is to ensure that the NLB can route traffic to the EC2 instances running the new version of the application in the newly peered VPC. Let's go through the options: Option A: Register the new application EC2 instances with the NLB by using the instance IDs. - Analysis: The NLB can register EC2 instances as targets by their instance IDs or IP addresses. Using instance IDs is a valid method for registering the EC2 instances. However, when working across VPCs (especially when VPCs are in different Availability Zones or regions), using instance IDs can be problematic if the instances are in a different VPC. - Why it's not ideal: In a multi-VPC scenario, the NLB typically registers instances using IP addresses (which are globally reachable) rather than instance IDs, as instance IDs are not accessible across VPCs unless additional configurations (such as VPC peering) are made. - Why it’s rejected: Registering by instance ID is generally not the best practice when instances are across VPCs due to potential issues with resolving the IDs over the peering connection. Option B: Register the new application EC2 instances with the NLB by using instance IP addresses. - Analysis: When the NLB is used across VPCs, registering the EC2 instances by their private IP addresses is a recommended approach. This ensures that the NLB can route traffic to the correct instance in the peered VPC. Since the instances are in different Availability Zones but within the same region, the NLB will use the private IPs to reach the EC2 instances. - Why it’s selected: Registering by IP addresses works across VPC peering and ensures that traffic can be properly routed. This is the preferred method when instances are in different VPCs and the NLB needs to send traffic to them. Option C: Configure the NLB in the Availability Zone where the new application EC2 instances run. - Analysis: The NLB is typically configured to route traffic to instances in different Availability Zones, and it automatically handles routing to healthy targets across these zones. However, the NLB does not need to be specifically configured to route traffic to an Availability Zone that has the new version of the application, as it should already be able to distribute traffic across multiple AZ...

Author: Daniel · Last updated Jun 30, 2026

A company uses AWS Site-to-Site VPN connections to encrypt traffic between the company's on-premises location and a single VPC. The Site-to-Site VPN connections use two 1 Gbps AWS Direct Connect connections with public VIFs. The company plans to add 15 additional VPCs in the same AWS Region. The company must maintain the same level of encryption that the Site-to-Site VPN connections currently provide for each connection between the on-premises location and the new VPCs. The new connections must not use public I...

The company is looking to extend its Site-to-Site VPN connections with encryption between its on-premises location and additional VPCs, with minimal operational overhead, while maintaining the same encryption level provided by the current Site-to-Site VPN connections. Let's analyze each option: Option A: Create a transit gateway and a Direct Connect gateway. Associate the transit gateway with the Direct Connect gateway. Attach all the new VPCs to the transit gateway. - Analysis: The AWS Transit Gateway allows for scalable and efficient connectivity between multiple VPCs and on-premises locations. By associating the Transit Gateway with the Direct Connect gateway, you can use private Direct Connect connections (with encryption through the Site-to-Site VPN connections) for all VPCs. The new VPCs can be easily attached to the transit gateway, avoiding the need to set up individual VPN connections for each VPC. This is a highly scalable solution that maintains the encryption level. - Why it's selected: This option provides centralized management for the connections, reduces the number of configurations, and meets the requirement for maintaining encryption between the on-premises location and the VPCs while minimizing operational overhead. This also ensures that no public IP addresses are involved. Option B: For each new VPC, create a new Direct Connect private VIF to a Direct Connect gateway. Associate all VPCs with the Direct Connect gateway. - Analysis: This approach involves creating individual Direct Connect connections with private VIFs (Virtual Interfaces) for each new VPC, and then associating the VPCs with the Direct Connect gateway. Although this setup allows private IP communication and ensures encryption, it increases the complexity and operational overhead by requiring configuration for each VPC, making it less efficient. - Why it's rejected: This approach does not scale efficiently, as it requires manual setup and management for each VPC, which increases operational overhead compared to using a transit gateway. Option C: Assign a private IP CIDR block to the transit gateway. - Analysis: When using a transit gateway, private IP addresses are typically used for communication between the transit gateway and VPCs. A ...

Author: Ethan · Last updated Jun 30, 2026

A company hosts application servers on premises and on Amazon EC2 instances in a VPC. The application servers access data that is hosted in an Amazon S3 bucket through the public internet. The EC2 instances in the VPC use an AWS Site-to-Site VPN for connectivity with the on-premises application servers. New company regulations state that all traffic between the appli...

To meet the requirement that all traffic between the application servers and the S3 bucket must remain private and not use public IP addresses, we must ensure that traffic between the on-premises servers and S3 is routed through private network paths. Let's evaluate the options based on the goal of achieving this in the most cost-effective manner: Option A: Configure an S3 gateway endpoint. Modify the route table with the appropriate route for the endpoint. Access the S3 bucket through the gateway endpoint from the EC2 instances. - Analysis: An S3 gateway endpoint allows private communication between the VPC and S3 over AWS's private network, without using public IP addresses or the public internet. By modifying the route table for the EC2 instances, traffic destined for S3 is routed through the gateway endpoint. This ensures that traffic between EC2 instances and the S3 bucket is kept private and secure. - Why it's selected: This is the most cost-effective and straightforward solution because it uses a gateway endpoint, which does not incur data processing charges or require complex configurations. It meets the requirement to keep traffic private and does not use public IP addresses. Option B: Configure an S3 interface endpoint. Update the on-premises servers and EC2 instances to use the interface endpoint DNS name to access the S3 bucket. - Analysis: An S3 interface endpoint uses AWS PrivateLink to allow private connectivity between VPCs and S3, but it requires updating both on-premises servers and EC2 instances to use the interface endpoint's DNS name. The problem with this approach is that it requires significant changes to the configuration of the on-premises servers, which could lead to additional complexity and operational overhead. - Why it's rejected: While this solution does ensure private communication, the requirement to update the on-premises servers and the added complexity make it less cost-effective and operationally efficient compared to Option A. Option C: Conf...

Author: ElectricLionX · Last updated Jun 30, 2026

A company uses AWS Network Firewall to protect outgoing traffic for multiple VPCs that are in the same AWS account. Each VPC contains Amazon EC2 instances that host the company's applications. Each EC2 instance is tagged with the name of the application it hosts. The EC2 instances are in Auto Scaling groups. A Network Firewall stateful rule group must remain up-to-date, even wh...

To select the best option for maintaining an up-to-date AWS Network Firewall stateful rule group, we need to focus on minimizing administrative effort and ensuring that the solution is scalable, especially with Auto Scaling groups managing EC2 instances that are frequently launched or terminated. Option A: Create a network ACL for each application. Reference the network ACL in the stateful rule group. - Rejection Reason: Network ACLs are typically used for controlling inbound and outbound traffic at the subnet level, not for managing stateful connections. A network ACL can't dynamically reflect changes based on EC2 instance tags, nor does it scale effectively when instances are frequently launched or terminated in Auto Scaling groups. Also, referencing the ACLs in the stateful rule group might not capture the granularity needed for application-level traffic control, as Network ACLs operate on a subnet basis. Option B: Create a prefix list for each application. Reference the prefix list in the stateful rule group. - Rejection Reason: Prefix lists are useful for controlling traffic at the IP address level, and they allow you to group a collection of IP addresses or CIDR blocks. However, managing dynamic EC2 instance IP addresses through prefix lists would still require an external process to regularly update the list, as Auto Scaling groups will alter instance IPs over time. This method can work, but it introduces more management overhead compared to automatic tagging-based solutions. Option C: Create an AWS Lambda function that queries the EC2 instance tags for each application name and then updates the stateful rule group with the IP address of each instance. - Selection Reason: This option leverages au...

Author: CrimsonViperX · Last updated Jun 30, 2026

A company has multiple AWS Site-to-Site VPN connections between an on-premises environment and multiple VPCs. The Site-to-Site VPN connections use virtual private gateways and are configured with IPv4 addresses. The company hosts several internal applications in the VPCs. Application users have reported that the applications are performing slowly. A network engineer notices excessi...

In this case, the goal is to resolve excessive latency in the network path used by the Site-to-Site VPN connections. Let's review each option in terms of its effectiveness and suitability for resolving the latency issue. Option A: Use AWS Global Accelerator to deploy an accelerator on the existing Site-to-Site VPN connections. - Rejection Reason: AWS Global Accelerator is typically used to optimize the routing of traffic for internet-facing applications by using the AWS global network to reduce latency and improve performance. However, it is not designed to accelerate or optimize Site-to-Site VPN connections, which are primarily private connections between an on-premises network and AWS VPCs. Global Accelerator does not work for VPN connections because it does not have visibility into the VPN traffic path. This solution would not address the latency within the Site-to-Site VPN itself. Option B: Deploy a transit gateway and a new accelerated Site-to-Site VPN connection. - Selection Reason: A Transit Gateway is an AWS service designed to provide centralized connectivity between VPCs, on-premises environments, and other networks. By deploying a transit gateway and using an accelerated Site-to-Site VPN, you can benefit from AWS's optimized network backbone to reduce latency. The accelerated Site-to-Site VPN connections are designed to optimize traffic flow by taking advantage of AWS's global network infrastructure, potentially improving the performance and reducing latency for the applications in the VPCs. This solution can be very effective in improving the overall perfor...

Author: Andrew · Last updated Jun 30, 2026

A company has a transit gateway in a single AWS account. The company sends flow logs for the transit gateway to an Amazon CloudWatch Logs log group. The company created an AWS Lambda function to analyze the logs. The Lambda function sends a notification to an Amazon Simple Notification Service (Amazon SNS) topic when a VPC generates traffic that is dropped by the transit gateway. Each notification contains the account ID. VPC ID, and total amount of dropped packets. The company wants to subscribe a new Lambda function to the SNS topic. The new Lambda function must...

To meet the requirements, the goal is to create a solution where a new Lambda function is subscribed to an SNS topic, and this function should automatically apply a network ACL to the transit gateway attachment subnets to block traffic that is identified in each notification. Let's analyze the available options in detail: Option A: Configure the existing Lambda function to add the destination IP addresses of the dropped traffic to each SNS notification. Configure the new Lambda function to create an outbound rule by using the destination IP addresses in the network ACL. - Rejection Reason: A network ACL controls traffic entering or leaving a subnet. However, the destination IP addresses of dropped traffic should generally be blocked on the inbound side of the traffic path, not the outbound side. If the Lambda function only creates an outbound rule based on the destination IP addresses, it would not effectively prevent the traffic from reaching the VPC in the first place. Hence, this option is not appropriate. Option B: Configure the existing Lambda function to add the source IP addresses of the dropped traffic to each SNS notification. Configure the new Lambda function to create an inbound rule by using the source IP addresses in the network ACL. - Rejection Reason: The source IP addresses of the traffic that is dropped are irrelevant for preventing traffic from entering the VPC. By blocking inbound traffic based on the source IP, the rule would prevent the traffic from reaching the VPC. However, we need to prevent traffic from leaving the VPC, which is typically done by blocking traffic on the outbound side. This makes the use of source IP addresses for inbound rules unsuitable for the objective of blocking outgoing traffic. Opt...

Author: Aditya · Last updated Jun 30, 2026

A company has multiple VPCs with subnets that use IPv4. Traffic from the VPCs to the internet uses a NAT gateway. The company wants to transition to IPv6. A network engineer creates multiple IPv6-only subnets in an existing testing VPC. The network engineer deploys a new Amazon EC2 instance that has an IPv6 address into one of the subnets. During testing, the network engineer discovers that the new EC2 instance is not able to communicate wit...

The goal is to enable communication between an IPv6-only EC2 instance and an IPv4-only service on the internet. Let's analyze each option and see how it addresses the requirement. Option A: Enable DNS64 for the IPv6-only subnets. Update the route tables for the IPv6-only subnets to send traffic through the NAT gateway. - Rejection Reason: DNS64 is a mechanism that allows IPv6 clients to communicate with IPv4 servers by synthesizing IPv6 addresses for IPv4 resources. However, simply enabling DNS64 and routing traffic through the existing NAT gateway does not solve the problem, because the NAT gateway is only designed to handle IPv4 traffic. A NAT gateway cannot natively support the translation between IPv6 and IPv4. This approach would not allow the EC2 instance to reach the IPv4-only service. Option B: Enable NAT64 for the testing VPC. Reconfigure the existing NAT gateway to support IPv6. - Rejection Reason: NAT64 is a mechanism that allows IPv6 clients to communicate with IPv4-only resources by performing address translation. However, NAT64 requires the use of a specific NAT64 gateway, which is not the same as a regular NAT gateway. The existing NAT gateway does not support IPv6-to-IPv4 translation. While reconfiguring the NAT gateway to support IPv6 is a necessary step, it does not directly address the need for IPv6-to-IPv4 translation, which NAT64 is specifically designed for. Option C: Enable DNS64 for the new EC2 ...

Author: Zara · Last updated Jun 30, 2026

A company deployed an application in two AWS Regions in one AWS account. The company has one VPC in each Region. The VPCs use non-overlapping private CIDR ranges. The company needs to connect both VPCs to a single on-premises data center to test the application. The application requires up to 800 Mbps of throughput. A network engineer needs to est...

To establish connectivity between the two VPCs and the on-premises data center with a throughput requirement of up to 800 Mbps, let's evaluate each solution in terms of ease of management, throughput, and overall operational complexity. Option A: Order a 2 Gbps Direct Connect connection for the data center. Configure a virtual private gateway in each VPC. Create a private VIF for each virtual private gateway, and associate the virtual private gateways with the Direct Connect connection. Configure static routes in the VPC route tables and in the data center router. - Rejection Reason: While Direct Connect offers a high-speed, dedicated connection with predictable performance, the need to manually configure static routes in both the VPC route tables and the data center router introduces higher operational overhead. This requires ongoing management of route configurations, which may be challenging as the network grows or changes over time. Additionally, using static routing makes it less flexible for dynamic changes or scaling. Option B: Order a 2 Gbps Direct Connect connection for the data center. Configure a virtual private gateway in each VPC. Create a private VIF for each virtual private gateway, and associate the virtual private gateways with the Direct Connect connection. Configure Open Shortest Path First (OSPF) routing between the private VIF and the data center. - Rejection Reason: While OSPF provides dynamic routing and better flexibility than static routing, it introduces more complexity in managing the Direct Connect connection and route exchanges. Setting up and managing OSPF requires both operational expertise and coordination between the AWS environment and the on-premises network. Additionally, this setup could be more complex than necessary, especially when simpler solutions can meet the performance requirements. Option C: Configure a custo...

Author: Noah · Last updated Jun 30, 2026

A company runs a workload in a single VPC on AWS. The company's architecture contains several interface VPC endpoints for AWS services, including Amazon CloudWatch Logs and AWS Key Management Service (AWS KMS). The endpoints are configured to use a shared security group. The security group is not used for any other workloads or resources. After a security review of the environment, the company determined that the shared security group is more permissive than necessary. The company wants to make the rules associated with the security group more restrictive. The changes to the security group rules must not prevent the resources in the VPC from using AWS services through interface VPC endpoints. The changes must prevent unnecessary access. The security group currently uses the ...

To meet the company's requirements of making the security group rules more restrictive while still allowing necessary communication between VPC resources and AWS services through the interface VPC endpoints, let's break down each rule and evaluate which ones can be removed or modified: Inbound Rules: - Inbound - Rule 1: - Protocol: TCP - Port: 443 - Source: 0.0.0.0/0 (any IP address) - This rule allows traffic from any IP address to reach the interface VPC endpoints over port 443 (HTTPS). This is very permissive and should be tightened. - Inbound - Rule 2: - Protocol: TCP - Port: 443 - Source: VPC CIDR block - This rule allows traffic from within the VPC to the interface VPC endpoints over port 443. This is more restrictive and seems necessary for internal communication within the VPC. Outbound Rules: - Outbound - Rule 1: - Protocol: All - Port: All - Destination: 0.0.0.0/0 (any IP address) - This rule allows all outbound traffic to any destination. This is very permissive and should also be tightened, as it opens the door to unnecessary communication. Evaluation of Each Option: - A) Outbound - Rule 2: - There's no "Outbound - Rule 2" in the original configuration, so this...

Author: Vikram · Last updated Jun 30, 2026

A company uses transit gateways to route traffic between the company's VPCs. Each transit gateway has a single route table. Each route table contains attachments and routes for the VPCs that are in the same AWS Region as the transit gateway. The route tables in each VPC also contain routes to all the other VPC CIDR ranges that are available through the transit gateways. Some VPCs route to local NAT gateways. The company plans to add many new V...

To determine the most operationally efficient solution for adding new VPC CIDR ranges to the route tables in each VPC, let's evaluate the options provided: A) Create a new customer-managed prefix list. Add all VPC CIDR ranges to the new prefix list. Update the route tables in each VPC to use the new prefix list ID as the destination and the appropriate transit gateway ID as the target. - Explanation: A customer-managed prefix list allows you to group multiple CIDR blocks into a single object, which can then be referenced in route tables. This would be effective if you want to manage a set of CIDR blocks and refer to them consistently across route tables. However, this approach requires manual updates to the route tables whenever a new VPC is added, which can become cumbersome and does not fully automate the process for future VPC additions. This solution is operationally efficient in the short term but can require manual updates as new VPCs are added. B) Turn on default route table propagation for the transit gateway route tables. Turn on route propagation for each route table in each VPC. - Explanation: This option enables automatic route propagation, meaning that the transit gateway will automatically propagate routes to the VPC route tables. When a new VPC is connected to the transit gateway, the VPC's CIDR block is automatically added to the appropriate route tables. This is a highly efficient and scalable solution because it automates the process of updating VPC route tables with the correct routes to new VPC CIDR ranges as they are connected to the transit gateway. - Key Benefit: This solution simplifies the process and scales as the number of VPCs grows. No manual updates to the route tables are required when new VPCs are added. C) Update the route tables in each VPC to use 0.0.0.0/0 as the destination and the appropriate transit gateway ID as the target. - Explanation: This ...

Author: Lucas · Last updated Jun 30, 2026

A company has several AWS Site-to-Site VPN connections between an on-premises customer gateway and a transit gateway. The company's application uses IPv4 to communicate through the VPN connections. The company has updated the VPC to be dual stack and wants to transition to using IPv6-only for new workloads. When the company tries to com...

To solve the issue of enabling IPv6 support for the AWS Site-to-Site VPN connections with minimal operational overhead, we need to consider the available options in the context of supporting IPv6 traffic for existing and future workloads while keeping the solution simple and efficient. A) Create a new Site-to-Site VPN connection that supports IPv6. - Explanation: AWS allows the creation of Site-to-Site VPN connections that support both IPv4 and IPv6 traffic. This approach involves setting up a new VPN connection that can handle IPv6 communication. This solution would require minimal changes to the existing infrastructure, as it leverages AWS’s native support for IPv6 on the VPN connection. - Key Benefit: Creating a new Site-to-Site VPN connection that supports IPv6 is simple and straightforward. This solution does not require any significant changes to existing configurations but allows for IPv6 traffic to pass through. - Why Rejected: This option involves creating a new connection. While this might work, it requires a bit of additional setup and changes in both the on-premises network and AWS side. It introduces some operational overhead. B) Create a new Site-to-Site VPN connection to a self-managed Amazon EC2 instance that runs open source software. - Explanation: This option suggests setting up a custom VPN solution where an EC2 instance runs open-source VPN software to handle IPv6. This adds complexity and operational overhead because the company would need to manage and maintain the EC2 instance and VPN software itself. - Why Rejected: This solution introduces unnecessary complexity and operational overhead. Managing custom VPN software is not the most efficient solution, especially when AWS offers native support for IPv6 VPN connections. C) Update the existing Site-to-Site VPN connections...

Author: Leah · Last updated Jun 30, 2026

A company plans to use an Amazon Snowball Edge device to transfer files to the AWS Cloud.Which activities related to a Snowba...

To determine which activities related to an Amazon Snowball Edge device are available to the company at no cost, we need to review the pricing model and the specific usage terms associated with Snowball Edge. AWS charges for various components, such as device usage, data transfer, and the duration of usage. Let’s break down each option to understand their relevance and associated costs. Option A: "Use of the Snowball Edge appliance for a 10-day period" - Analysis: When a company rents a Snowball Edge device, they are generally given 10 days of usage for free. The cost is usually incurred after this 10-day period. - Why selected: This is the correct answer as AWS provides 10 days of free usage for the Snowball Edge appliance. The company can transfer data into AWS during this period without incurring additional costs related to the duration of use. - Scenario where it might be used: Ideal for companies transferring large amounts of data within a short time frame and aiming to avoid excessive costs. They can plan the transfer to occur within the free 10-day period. Option B: "The transfer of data out of Amazon S3 and to the Snowball Edge appliance" - Analysis: AWS does charge for data outbound from S3 to a Snowball Edge device. Data transfer into AWS (from the Snowball Edge device to S3) typically does not incur additional charges, but transferring data out of S3 to the device involves cost. - Why rejected: This activity is not free and incurs charges ...

Author: Kai · Last updated Jun 9, 2026