Question.16 A company is using a NAT gateway to allow internet connectivity for private subnets in a VPC in the us-west-2 Region. After a security audit, the company needs to remove the NAT gateway. In the private subnets, the company has resources that use the unified Amazon CloudWatch agent. A network engineer must create a solution to ensure that the unified CloudWatch agent continues to work after the removal of the NAT gateway. Which combination of steps should the network engineer take to meet these requirements? (Choose three.) (A) Validate that private DNS is enabled on the VPC by setting the enableDnsHostnames VPC attribute and the enableDnsSupport VPC attribute to true. (B) Create a new security group with an entry to allow outbound traffic that uses the TCP protocol on port 443 to destination 0.0.0.0/0 (C) Create a new security group with entries to allow inbound traffic that uses the TCP protocol on port 443 from the IP prefixes of the private subnets. (D) Create the following interface VPC endpoints in the VPC: com.amazonaws.us-west-2.logs and com.amazonaws.us-west-2.monitoring. Associate the new security group with the endpoint network interfaces. (E) Create the following interface VPC endpoint in the VPC: com.amazonaws.us-west-2.cloudwatch. Associate the new security group with the endpoint network interfaces. (F) Associate the VPC endpoint or endpoints with route tables that the private subnets use. |
16. Click here to View Answer
Answer: ACD
Explanation:
The correct combination of steps is ACD. Here’s why:
- A. Validate that private DNS is enabled on the VPC: CloudWatch agent communication relies on resolving DNS names for the AWS services.
enableDnsHostnames
andenableDnsSupport
must be enabled at the VPC level to allow instances within the VPC to resolve AWS service endpoints through the Amazon DNS server. This allows the CloudWatch agent to find the proper endpoints even without direct internet access. Without this, the agent will fail to resolve the CloudWatch endpoint, and metrics will not be sent. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html - C. Create a new security group with entries to allow inbound traffic that uses the TCP protocol on port 443 from the IP prefixes of the private subnets: While not strictly necessary for the CloudWatch agent to send metrics, VPC endpoints (created in the next step) require a security group. The endpoint’s security group needs to allow traffic from the resources using the endpoint. The most secure approach is to limit traffic only from the IP ranges of the private subnets. This ensures only resources within the private subnets can access the CloudWatch endpoints. This is not an outbound rule on the instances. It is an inbound rule on the VPC endpoint.
- D. Create the following interface VPC endpoints in the VPC: com.amazonaws.us-west-2.logs and com.amazonaws.us-west-2.monitoring. Associate the new security group with the endpoint network interfaces: Interface VPC endpoints provide private connectivity to AWS services without requiring internet gateways, NAT devices, or VPN connections. Creating endpoints for
com.amazonaws.us-west-2.logs
andcom.amazonaws.us-west-2.monitoring
allows the CloudWatch agent to securely send logs and metrics directly to CloudWatch over the AWS network. Associating the security group (created in step C) with the endpoint network interfaces controls the traffic flow to the endpoint. These are the correct service names. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-agent-vpc-endpoints.html
Why other options are incorrect:
- B: Creating a new security group with an outbound rule to 0.0.0.0/0:443 would be applicable if the instances were still using the NAT Gateway. Since the goal is to remove the NAT gateway, this option is incorrect.
- E:
com.amazonaws.us-west-2.cloudwatch
is not the correct endpoint. The required endpoints arecom.amazonaws.us-west-2.logs
andcom.amazonaws.us-west-2.monitoring
. - F: The VPC endpoints are associated with the subnets via route tables during the endpoint creation. There isn’t a separate “associate with route tables” step that the engineer performs after endpoint creation. The wizard in the console or the CLI command will ask for which route table the endpoint will affect.
Question.17 An international company provides early warning about tsunamis. The company plans to use IoT devices to monitor sea waves around the world. The data that is collected by the IoT devices must reach the company’s infrastructure on AWS as quickly as possible. The company is using three operation centers around the world. Each operation center is connected to AWS through Its own AWS Direct Connect connection. Each operation center is connected to the internet through at least two upstream internet service providers. The company has its own provider-independent (PI) address space. The IoT devices use TCP protocols for reliable transmission of the data they collect. The IoT devices have both landline and mobile internet connectivity. The infrastructure and the solution will be deployed in multiple AWS Regions. The company will use Amazon Route 53 for DNS services. A network engineer needs to design connectivity between the IoT devices and the services that run in the AWS Cloud. Which solution will meet these requirements with the HIGHEST availability? (A) Set up an Amazon CloudFront distribution with origin failover. Create an origin group for each Region where the solution is deployed. (B) Set up Route 53 latency-based routing. Add latency alias records. For the latency alias records, set the value of Evaluate Target Health to Yes. (C) Set up an accelerator in AWS Global Accelerator. Configure Regional endpoint groups and health checks. (D) Set up Bring Your Own IP (BYOIP) addresses. Use the same PI addresses for each Region where the solution is deployed. |
17. Click here to View Answer
Answer: C
Explanation:
The correct answer is C: Set up an accelerator in AWS Global Accelerator. Configure Regional endpoint groups and health checks.
Here’s a detailed justification:
AWS Global Accelerator is specifically designed to improve the availability and performance of applications for global users. It achieves this by directing traffic to the optimal endpoint based on network conditions and endpoint health. In this scenario, the company has IoT devices scattered globally and wants the data to reach its AWS infrastructure as quickly and reliably as possible across multiple regions.
Global Accelerator uses the AWS global network to optimize the path from the IoT devices to the nearest healthy endpoint in one of the company’s AWS Regions. It accomplishes this via static anycast IPs that serve as the entry point for traffic. Because the company has operation centers connected via Direct Connect in different Regions, Global Accelerator can direct traffic to the closest operation center with healthy endpoints, even if one Region or Direct Connect link experiences issues. Endpoint groups are configured for each Region, allowing traffic to be dynamically routed to the healthy Region. Health checks are used to monitor the health of the application endpoints within each Region.
Option A, Amazon CloudFront with origin failover, is primarily designed for caching static and dynamic content closer to users for improved performance and is less suited for TCP-based real-time data ingestion from IoT devices. It’s better suited for distributing content than reliably accepting and routing data.
Option B, Route 53 latency-based routing, makes routing decisions based on latency. While it’s useful for routing users to the Region with the lowest latency, it doesn’t provide the same level of fault tolerance and global traffic management as Global Accelerator, particularly in the presence of multiple network paths (landline and mobile). More over, R53 is a DNS service, which relies on resolution and propagation.
Option D, Bring Your Own IP (BYOIP) addresses, allows the company to use its own IP address range with AWS. While useful for IP address management and reputation, it doesn’t directly address the requirement for high availability and optimized routing to the nearest healthy endpoint. BYOIP simply lets you use your own IP addresses in AWS, it doesn’t inherently improve routing or availability. It would need to be combined with a routing solution, but Global Accelerator is a more direct and effective solution.Global Accelerator provides both a stable entry point and global routing, maximizing availability and minimizing latency.Authoritative links:
AWS BYOIP: https://aws.amazon.com/byoip/
AWS Global Accelerator: https://aws.amazon.com/global-accelerator/
Route 53 Routing Policies: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
Amazon CloudFront Origin Failover: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html
Question.18 A company is planning a migration of its critical workloads from an on-premises data center to Amazon EC2 instances. The plan includes a new 10 Gbps AWS Direct Connect dedicated connection from the on-premises data center to a VPC that is attached to a transit gateway. The migration must occur over encrypted paths between the on-premises data center and the AWS Cloud. Which solution will meet these requirements while providing the HIGHEST throughput? (A) Configure a public VIF on the Direct Connect connection. Configure an AWS Site-to-Site VPN connection to the transit gateway as a VPN attachment. (B) Configure a transit VIF on the Direct Connect connection. Configure an IPsec VPN connection to an EC2 instance that is running third-party VPN software. (C) Configure MACsec for the Direct Connect connection. Configure a transit VIF to a Direct Connect gateway that is associated with the transit gateway. (D) Configure a public VIF on the Direct Connect connection. Configure two AWS Site-to-Site VPN connections to the transit gateway. Enable equal-cost multi-path (ECMP) routing. |
18. Click here to View Answer
Answer: C
Explanation:
The correct answer is C because it provides a high-throughput, encrypted connection between the on-premises data center and AWS, specifically tailored for the given scenario.
Here’s a detailed justification:
The core requirement is encrypted traffic over a high-bandwidth connection between on-premises and AWS. MACsec provides hardware-based encryption at the data link layer (Layer 2) and is specifically designed for Direct Connect connections. This encryption method minimizes overhead and provides significantly higher throughput compared to IPsec VPNs, which operate at Layer 3.
Configuring a transit VIF is essential for connecting the Direct Connect connection to the transit gateway. The transit gateway acts as a central hub, allowing the on-premises network to connect to multiple VPCs within AWS through the Direct Connect connection. Associating the Direct Connect gateway with the transit gateway allows the propagation of routes between your on-premises network and the AWS environment, routed through the Transit Gateway.
Option A uses a public VIF and Site-to-Site VPN. While Site-to-Site VPN provides encryption, it introduces significant overhead due to IPsec encapsulation and software processing. This limits throughput and would not maximize the 10 Gbps Direct Connect connection. A public VIF isn’t directly routed to the transit gateway but over public endpoints which defeats the purpose of using direct connect.
Option B proposes an IPsec VPN to an EC2 instance. This approach incurs considerable overhead, similar to Option A, due to IPsec and the limitations of the EC2 instance’s processing capacity. Additionally, managing and scaling a VPN solution on EC2 instances is complex and may introduce availability concerns. The transit VIF to a transit gateway provides a more seamless and managed approach.
Option D tries to improve throughput using ECMP with two Site-to-Site VPN connections. While ECMP can increase aggregate bandwidth, the inherent overhead of IPsec remains, and it doesn’t leverage the full potential of the Direct Connect connection and isn’t as efficient as MACsec. Furthermore, managing two VPN connections adds operational complexity. A public VIF isn’t directly routed to the transit gateway but over public endpoints which defeats the purpose of using direct connect.
In summary, MACsec on Direct Connect with a transit VIF provides the optimal balance of encryption and high throughput, directly addressing the stated requirements for migrating critical workloads.
Relevant documentation:
- AWS Direct Connect MACsec: https://aws.amazon.com/directconnect/macsec/
- AWS Transit Gateway: https://aws.amazon.com/transit-gateway/
- AWS Direct Connect Gateways: https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html
Question.19 A network engineer must develop an AWS CloudFormation template that can create a virtual private gateway, a customer gateway, a VPN connection, and static routes in a route table. During testing of the template, the network engineer notes that the CloudFormation template has encountered an error and is rolling back. What should the network engineer do to resolve the error? (A) Change the order of resource creation in the CloudFormation template. (B) Add the DependsOn attribute to the resource declaration for the virtual private gateway. Specify the route table entry resource. (C) Add a wait condition in the template to wait for the creation of the virtual private gateway. (D) Add the DependsOn attribute to the resource declaration for the route table entry. Specify the virtual private gateway resource. |
19. Click here to View Answer
Answer: D
Explanation:
The CloudFormation template is failing because the route table entry (static route) is likely being created before the virtual private gateway (VGW) is fully provisioned. The route entry creation depends on the VGW being available. CloudFormation attempts to create resources in parallel, and without explicit dependencies, it might try to create the route before the VGW is ready, leading to an error and rollback.
Option D correctly addresses this dependency issue. By adding the DependsOn
attribute to the route table entry resource declaration and specifying the VGW resource, we explicitly tell CloudFormation to create the VGW first. CloudFormation will then wait until the VGW is successfully created before proceeding to create the route table entry that depends on it. This enforces the correct order of operations and resolves the dependency conflict.
Option A is incorrect because simply changing the order of resource declarations in the template doesn’t guarantee the order of resource creation. CloudFormation can still attempt to create resources in parallel unless explicit dependencies are defined.
Option B is incorrect because the route table entry depends on the VGW, not the other way around. Specifying the route table entry resource in the DependsOn
attribute of the VGW would create a circular dependency, which is not what we need. The route table entry needs to know about the VGW, not the VGW needing to know about the route table entry.
Option C, adding a wait condition, is generally not recommended for dependencies between AWS resources created within the same CloudFormation stack. DependsOn
is a cleaner and more appropriate solution for expressing resource dependencies. Wait conditions are better suited for situations where you need to wait for an external process or service to complete before proceeding.
Therefore, the most effective solution is to explicitly define the dependency between the route table entry and the VGW using the DependsOn
attribute.
Refer to the following AWS documentation for further details on DependsOn
attribute and CloudFormation resource dependencies:
AWS CloudFormation Resource Creation Options (for understanding wait conditions and why they are not the ideal choice here)
Question.20 A company operates its IT services through a multi-site hybrid infrastructure. The company deploys resources on AWS in the us-east-1 Region and in the eu-west-2 Region. The company also deploys resources in its own data centers that are located in the United States (US) and in the United Kingdom (UK). In both AWS Regions, the company uses a transit gateway to connect 15 VPCs to each other. The company has created a transit gateway peering connection between the two transit gateways. The VPC CIDR blocks do not overlap with each other or with IP addresses used within the data centers. The VPC CIDR prefixes can also be aggregated either on a Regional level or for the company’s entire AWS environment. The data centers are connected to each other by a private WAN connection. IP routing information is exchanged dynamically through Interior BGP (iBGP) sessions. The data centers maintain connectivity to AWS through one AWS Direct Connect connection in the US and one Direct Connect connection in the UK. Each Direct Connect connection is terminated on a Direct Connect gateway and is associated with a local transit gateway through a transit VIF. Traffic follows the shortest geographical path from source to destination. For example, packets from the UK data center that are targeted to resources in eu-west-2 travel across the local Direct Connect connection. In cases of cross-Region data transfers, such as from the UK data center to VPCs in us-east-1, the private WAN connection must be used to minimize costs on AWS. A network engineer has configured each transit gateway association on the Direct Connect gateway to advertise VPC-specific CIDR IP prefixes only from the local Region. The routes toward the other Region must be learned through BGP from the routers in the other data center in the original, non-aggregated form. The company recently experienced a problem with cross-Region data transfers because of issues with its private WAN connection. The network engineer needs to modify the routing setup to prevent similar interruptions in the future. The solution cannot modify the original traffic routing goal when the network is operating normally. Which modifications will meet these requirements? (Choose two.) (A) Remove all the VPC CIDR prefixes from the list of subnets advertised through the local Direct Connect connection. Add the company’s entire AWS environment aggregate route to the list of subnets advertised through the local Direct Connect connection. (B) Add the CIDR prefixes from the other Region VPCs and the local VPC CIDR blocks to the list of subnets advertised through the local Direct Connect connection. Configure data center routers to make routing decisions based on the BGP communities received. (C) Add the aggregate IP prefix for the other Region and the local VPC CIDR blocks to the list of subnets advertised through the local Direct Connect connection. (D) Add the aggregate IP prefix for the company’s entire AWS environment and the local VPC CIDR blocks to the list of subnets advertised through the local Direct Connect connection. (E) Remove all the VPC CIDR prefixes from the list of subnets advertised through the local Direct Connect connection. Add both Regional aggregate IP prefixes to the list of subnets advertised through the Direct Connect connection on both sides of the network. Configure data center routers to make routing decisions based on the BGP communities received. |
20. Click here to View Answer
Answer: CE
Explanation:
Here’s a breakdown of why options C and E are the correct choices for ensuring cross-Region data transfers continue during private WAN issues, without altering normal routing behavior:
Understanding the Requirements
The core goal is to maintain shortest-path routing when the private WAN is healthy and to failover to AWS infrastructure in case the WAN link fails. The solution must not impact the original traffic routing when the network is operating normally.
Why C is Correct
- Adding the aggregate IP prefix for the other Region and the local VPC CIDR blocks to the list of subnets advertised through the local Direct Connect connection: This means the Direct Connect gateway (and hence, the local Direct Connect connection) will advertise aggregate routes for the VPCs in both the local region and the remote region. This enables the data center routers to learn routes to the remote region’s VPCs via Direct Connect in addition to the private WAN.
Why E is Correct
- Remove all the VPC CIDR prefixes from the list of subnets advertised through the local Direct Connect connection. This stops advertising specific VPC CIDRs via the local Direct Connect connection, which were originally limiting traffic to preferred paths.
- Add both Regional aggregate IP prefixes to the list of subnets advertised through the Direct Connect connection on both sides of the network. This means the Direct Connect gateway (and hence, the local Direct Connect connection) will advertise the aggregate routes for the VPCs in both the local region and the remote region. This enables the data center routers to learn routes to the remote region’s VPCs via Direct Connect in addition to the private WAN.
- Configure data center routers to make routing decisions based on the BGP communities received. By leveraging BGP communities, the data center routers can be configured to prefer the routes learned via the private WAN (e.g., by assigning a higher local preference to routes received from the WAN). If the WAN fails, the routes learned via Direct Connect (with lower preference) will then be used. This ensures the traffic fails over to the AWS backbone without disrupting the original preferred path.
Why other options are Incorrect
- A: Advertising only the entire AWS environment aggregate route through Direct Connect would mean that all traffic, even within the same region, could potentially be routed through the Direct Connect to the other region, which violates the shortest path objective during normal operations.
- B: This approach doesn’t solve the failover problem because data center routers might still prefer routes advertised from the local region via the Direct Connect.
- D: Advertising the entire AWS environment aggregate route through Direct Connect would cause all traffic destined to AWS to route via the Direct Connect connection instead of the shorter path over the WAN. This removes the shortest path objective during normal operations.
Supporting Resources
- AWS Transit Gateway: https://aws.amazon.com/transit-gateway/
- AWS Direct Connect: https://aws.amazon.com/directconnect/
- BGP Communities: https://datatracker.ietf.org/doc/html/rfc1997 (RFC defining BGP Communities)