| Question.11 A company is using custom DNS servers that run BIND for name resolution in its VPCs. The VPCs are deployed across multiple AWS accounts that are part of the same organization in AWS Organizations. All the VPCs are connected to a transit gateway. The BIND servers are running in a central VPC and are configured to forward all queries for an on-premises DNS domain to DNS servers that are hosted in an on-premises data center. To ensure that all the VPCs use the custom DNS servers, a network engineer has configured a VPC DHCP options set in all the VPCs that specifies the custom DNS servers to be used as domain name servers. Multiple development teams in the company want to use Amazon Elastic File System (Amazon EFS). A development team has created a new EFS file system but cannot mount the file system to one of its Amazon EC2 instances. The network engineer discovers that the EC2 instance cannot resolve the IP address for the EFS mount point fs-33444567d.efs.us-east-1.amazonaws.com. The network engineer needs to implement a solution so that development teams throughout the organization can mount EFS file systems. Which combination of steps will meet these requirements? (Choose two.) (A) Configure the BIND DNS servers in the central VPC to forward queries for efs.us-east-1.amazonaws.com to the Amazon provided DNS server (169.254.169.253). (B) Create an Amazon Route 53 Resolver outbound endpoint in the central VPC. Update all the VPC DHCP options sets to use AmazonProvidedDNS for name resolution. (C) Create an Amazon Route 53 Resolver inbound endpoint in the central VPUpdate all the VPC DHCP options sets to use the Route 53 Resolver inbound endpoint in the central VPC for name resolution. (D) Create an Amazon Route 53 Resolver rule to forward queries for the on-premises domain to the on-premises DNS servers. Share the rule with the organization by using AWS Resource Access Manager (AWS RAM). Associate the rule with all the VPCs. (E) Create an Amazon Route 53 private hosted zone for the efs.us-east-1.amazonaws.com domain. Associate the private hosted zone with the VPC where the EC2 instance is deployed. Create an A record for fs-33444567d.efs.us-east-1.amazonaws.com in the private hosted zone. Configure the A record to return the mount target of the EFS mount point. |
11. Click here to View Answer
Answer: BD
Explanation:
Here’s a detailed justification for why options B and D are the correct choices and why the other options are incorrect for resolving the EFS mounting issue across multiple AWS accounts using a transit gateway and custom DNS.
Understanding the Problem:
The core issue is that EC2 instances in multiple VPCs cannot resolve the EFS mount point (fs-33444567d.efs.us-east-1.amazonaws.com). This resolution needs to occur across multiple AWS accounts. Currently, the VPCs use custom DNS servers (BIND) that forward on-premises DNS queries but aren’t configured for resolving AWS service endpoints like EFS.
Why B and D are correct:
- B. Create an Amazon Route 53 Resolver outbound endpoint in the central VPC. Update all the VPC DHCP options sets to use AmazonProvidedDNS for name resolution.
- This approach directly addresses the inability to resolve AWS service endpoints. A Route 53 Resolver outbound endpoint allows you to forward DNS queries from your VPC to DNS servers outside the VPC (in this case, to Amazon’s DNS servers).
- By setting the DHCP options set to
AmazonProvidedDNS, you ensure that all VPCs now use the Amazon-provided DNS, which can resolve AWS service endpoints like those for EFS. This eliminates the need for custom BIND configuration for these AWS-specific zones. - https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html
- D. Create an Amazon Route 53 Resolver rule to forward queries for the on-premises domain to the on-premises DNS servers. Share the rule with the organization by using AWS Resource Access Manager (AWS RAM). Associate the rule with all the VPCs.
- Since the company still needs the VPCs to resolve queries for the on-premise domain, we can use the Route 53 Resolver to forward those queries from VPCs to the on-premise DNS servers. Using AWS RAM to share the rules allows the rule to be used across different AWS accounts within the organization. This will ensure that on-premise DNS queries are still resolved after the VPCs DHCP options sets have been updated to use the AmazonProvidedDNS.
- https://docs.aws.amazon.com/ram/latest/userguide/what-is.html
Why the other options are incorrect:
- A. Configure the BIND DNS servers in the central VPC to forward queries for efs.us-east-1.amazonaws.com to the Amazon provided DNS server (169.254.169.253).
- While technically feasible, this approach is less scalable and maintainable than using Route 53 Resolver. You’d have to manage BIND configuration, and it introduces a single point of failure in the central VPC. Plus, forwarding to
169.254.169.253directly is generally discouraged; usingAmazonProvidedDNSis the AWS-recommended method. - Also, it won’t address the on-premise DNS resolutions.
- While technically feasible, this approach is less scalable and maintainable than using Route 53 Resolver. You’d have to manage BIND configuration, and it introduces a single point of failure in the central VPC. Plus, forwarding to
- C. Create an Amazon Route 53 Resolver inbound endpoint in the central VPC. Update all the VPC DHCP options sets to use the Route 53 Resolver inbound endpoint in the central VPC for name resolution.
- Route 53 Resolver inbound endpoints are used to forward DNS queries from on-premises networks to AWS. This is the opposite of what’s needed here; you want AWS resources to resolve AWS service endpoints.
- E. Create an Amazon Route 53 private hosted zone for the efs.us-east-1.amazonaws.com domain. Associate the private hosted zone with the VPC where the EC2 instance is deployed. Create an A record for fs-33444567d.efs.us-east-1.amazonaws.com in the private hosted zone. Configure the A record to return the mount target of the EFS mount point.
- This approach only addresses the resolution issue for one VPC. It doesn’t scale to the requirement that development teams throughout the organization be able to mount EFS file systems. Also, manually creating A records and keeping them in sync is complex and error-prone, given that EFS mount targets can change. The
AmazonProvidedDNSautomatically resolves these.
- This approach only addresses the resolution issue for one VPC. It doesn’t scale to the requirement that development teams throughout the organization be able to mount EFS file systems. Also, manually creating A records and keeping them in sync is complex and error-prone, given that EFS mount targets can change. The
In summary, the combination of using AmazonProvidedDNS (option B) for resolving AWS service endpoints like EFS and using Route 53 Resolver rules for on-premises DNS resolution, which is shared across the organization using AWS RAM (option D), provides the most scalable, manageable, and robust solution.
| Question.12 An ecommerce company is hosting a web application on Amazon EC2 instances to handle continuously changing customer demand. The EC2 instances are part of an Auto Scaling group. The company wants to implement a solution to distribute traffic from customers to the EC2 instances. The company must encrypt all traffic at all stages between the customers and the application servers. No decryption at intermediate points is allowed. Which solution will meet these requirements? (A) Create an Application Load Balancer (ALB). Add an HTTPS listener to the ALB. Configure the Auto Scaling group to register instances with the ALB’s target group. (B) Create an Amazon CloudFront distribution. Configure the distribution with a custom SSL/TLS certificate. Set the Auto Scaling group as the distribution’s origin. (C) Create a Network Load Balancer (NLB). Add a TCP listener to the NLB. Configure the Auto Scaling group to register instances with the NLB’s target group. (D) Create a Gateway Load Balancer (GLB). Configure the Auto Scaling group to register instances with the GLB’s target group. |
12. Click here to View Answer
Answer: C
Explanation:
The requirement is end-to-end encryption between customers and EC2 instances without decryption at intermediate points. This means the load balancer cannot decrypt and re-encrypt the traffic. An Application Load Balancer (ALB) terminates SSL/TLS at the load balancer, thus decrypting the traffic. Therefore, option A is incorrect. Amazon CloudFront is a CDN and also terminates SSL/TLS; hence, it won’t meet the end-to-end encryption requirement without decryption. Therefore, option B is incorrect. A Gateway Load Balancer (GLB) is designed for deploying and managing virtual appliances, typically for deep packet inspection, intrusion detection and prevention, and other network security functions. While it doesn’t inherently decrypt traffic, it’s not the ideal choice for simply load balancing encrypted traffic directly to instances. Therefore, option D is incorrect. A Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP) and can forward encrypted traffic directly to the backend EC2 instances without decryption. This fulfills the end-to-end encryption requirement. The EC2 instances would need to handle SSL/TLS termination themselves. Therefore, option C correctly uses an NLB with a TCP listener to forward the encrypted traffic to the instances in the Auto Scaling group, ensuring no intermediate decryption.
Authoritative links:
| Question.13 A company has two on-premises data center locations. There is a company-managed router at each data center. Each data center has a dedicated AWS Direct Connect connection to a Direct Connect gateway through a private virtual interface. The router for the first location is advertising 110 routes to the Direct Connect gateway by using BGP, and the router for the second location is advertising 60 routes to the Direct Connect gateway by using BGP. The Direct Connect gateway is attached to a company VPC through a virtual private gateway. A network engineer receives reports that resources in the VPC are not reachable from various locations in either data center. The network engineer checks the VPC route table and sees that the routes from the first data center location are not being populated into the route table. The network engineer must resolve this issue in the most operationally efficient manner. What should the network engineer do to meet these requirements? (A) Remove the Direct Connect gateway, and create a new private virtual interface from each company router to the virtual private gateway of the VPC. (B) Change the router configurations to summarize the advertised routes. (C) Open a support ticket to increase the quota on advertised routes to the VPC route table. (D) Create an AWS Transit Gateway. Attach the transit gateway to the VPC, and connect the Direct Connect gateway to the transit gateway. |
13. Click here to View Answer
Answer: B
Explanation:
The correct answer is B: Change the router configurations to summarize the advertised routes. Here’s why:
The core problem is that the VPC route table is not being populated with routes from one of the on-premises locations, specifically the first data center advertising 110 routes. This points to a limit on the number of routes that a VPC route table can accept from a Direct Connect gateway. While AWS doesn’t publicly document hard limits for propagated routes from a DXGW to a VPC route table, exceeding a reasonable number of routes is a common issue.
Summarizing routes is the most operationally efficient way to solve this. By aggregating multiple smaller, specific routes into fewer, larger, more general routes, the total number of routes advertised to the Direct Connect gateway and subsequently propagated to the VPC route table is reduced. This allows the essential reachability information to be conveyed without exceeding any potential route limits. This solution addresses the problem at the source of the route advertisements (the on-premises routers) without requiring infrastructure changes or significant service disruptions.
Option A is incorrect because removing the Direct Connect gateway and creating private virtual interfaces directly to the VPG is not best practice and removes the central management capability the Direct Connect Gateway provides. This would require reconfiguring BGP sessions on the VPC side and create more configuration and management overhead.
Option C, opening a support ticket, might seem plausible if a hard quota was definitively the cause. However, summarizing routes is a better practice and more controllable solution, and you don’t have confirmation of an actual quota limit, so it is premature to rely on AWS increasing quotas. Furthermore, even if AWS granted an increased quota, the underlying problem of overly granular routing isn’t addressed.
Option D, using Transit Gateway, is a valid architectural choice for more complex scenarios and could solve the immediate problem. However, it introduces additional complexity and cost. For this relatively simple scenario, the most operationally efficient solution is route summarization. TGW should be considered when you need more advanced routing policies, shared services VPC connectivity, or more dynamic scaling than DXGW + VPC VPG provides.
Route summarization offers a targeted solution that directly addresses the route limits without impacting other parts of the network and is the most straightforward approach in this situation.
For further research, consult the AWS Direct Connect documentation and networking best practices, though explicit VPC route limits related to DXGWs aren’t clearly documented.
AWS Transit Gateway: https://aws.amazon.com/transit-gateway/
AWS Direct Connect: https://aws.amazon.com/directconnect/
| Question.14 A company has expanded its network to the AWS Cloud by using a hybrid architecture with multiple AWS accounts. The company has set up a shared AWS account for the connection to its on-premises data centers and the company offices. The workloads consist of private web-based services for internal use. These services run in different AWS accounts. Office-based employees consume these services by using a DNS name in an on-premises DNS zone that is named example.internal. The process to register a new service that runs on AWS requires a manual and complicated change request to the internal DNS. The process involves many teams. The company wants to update the DNS registration process by giving the service creators access that will allow them to register their DNS records. A network engineer must design a solution that will achieve this goal. The solution must maximize cost-effectiveness and must require the least possible number of configuration changes. Which combination of steps should the network engineer take to meet these requirements? (Choose three.) (A) Create a record for each service in its local private hosted zone (serviceA.account1.aws.example.internal). Provide this DNS record to the employees who need access. (B) Create an Amazon Route 53 Resolver inbound endpoint in the shared account VPC. Create a conditional forwarder for a domain named aws.example.internal on the on-premises DNS servers. Set the forwarding IP addresses to the inbound endpoint’s IP addresses that were created. (C) Create an Amazon Route 53 Resolver rule to forward any queries made to onprem.example.internal to the on-premises DNS servers. (D) Create an Amazon Route 53 private hosted zone named aws.example.internal in the shared AWS account to resolve queries for this domain. (E) Launch two Amazon EC2 instances in the shared AWS account. Install BIND on each instance. Create a DNS conditional forwarder on each BIND server to forward queries for each subdomain under aws.example.internal to the appropriate private hosted zone in each AWS account. Create a conditional forwarder for a domain named aws.example.internal on the on-premises DNS servers. Set the forwarding IP addresses to the IP addresses of the BIND servers. (F) Create a private hosted zone in the shared AWS account for each account that runs the service. Configure the private hosted zone to contain aws.example.internal in the domain (account1.aws.example.internal). Associate the private hosted zone with the VPC that runs the service and the shared account VPC. |
14. Click here to View Answer
Answer: BDF
Explanation:
The correct solution, BDF, efficiently addresses the company’s DNS registration challenges by leveraging Route 53 Resolver capabilities. Here’s why:
- B. Create an Amazon Route 53 Resolver inbound endpoint…: An inbound endpoint acts as a gateway for on-premises DNS servers to forward queries to Route 53 Resolver in the AWS shared services account. Creating a conditional forwarder on the on-premises DNS server for
aws.example.internaland directing it to the inbound endpoint ensures that all requests for AWS services are properly routed to AWS. This avoids direct exposure of AWS infrastructure IP addresses to internal DNS infrastructure. (Source: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) - D. Create an Amazon Route 53 private hosted zone named aws.example.internal…: This establishes a central location for managing DNS records related to AWS-hosted services within the shared account. It’s the root of the delegated AWS DNS namespace. This enables more granular control and allows for further sub-delegation of authority. This is a crucial part of the solution which allows the use of private hosted zones to resolve the names of the internal services.
- F. Create a private hosted zone in the shared AWS account for each account that runs the service…: By creating separate private hosted zones (e.g.,
account1.aws.example.internal) for each AWS account, the service creators gain the authority to manage their own DNS records. Associating these hosted zones with both the service VPC and the shared account VPC enables DNS resolution from both locations, ensuring internal employees can access the services using their desired DNS names.
Why other options are incorrect:
- A: Directly providing the service-specific DNS records to employees lacks scalability and doesn’t streamline the DNS registration process. It also doesn’t address centralized management.
- C: Creating a Resolver rule to forward
onprem.example.internalto on-premises is already the default behavior. - E: Launching EC2 instances with BIND adds unnecessary complexity, operational overhead, and costs. Route 53 Resolver offers a managed and highly available DNS solution. This is a legacy implementation and it will introduce more configuration changes.
In essence, the BDF combination establishes a streamlined and cost-effective DNS delegation model. Service teams get authority over their DNS records under aws.example.internal through private hosted zones, which reduces the manual change requests. Route 53 Resolver, via an inbound endpoint, connects the on-premises network to the delegated AWS DNS namespace. This provides the employees with access to services hosted on AWS.
| Question.15 A company has multiple AWS accounts. Each account contains one or more VPCs. A new security guideline requires the inspection of all traffic between VPCs. The company has deployed a transit gateway that provides connectivity between all VPCs. The company also has deployed a shared services VPC with Amazon EC2 instances that include IDS services for stateful inspection. The EC2 instances are deployed across three Availability Zones. The company has set up VPC associations and routing on the transit gateway. The company has migrated a few test VPCs to the new solution for traffic inspection. Soon after the configuration of routing, the company receives reports of intermittent connections for traffic that crosses Availability Zones. What should a network engineer do to resolve this issue? (A) Modify the transit gateway VPC attachment on the shared services VPC by enabling cross-Availability Zone load balancing. (B) Modify the transit gateway VPC attachment on the shared services VPC by enabling appliance mode support. (C) Modify the transit gateway by selecting VPN equal-cost multi-path (ECMP) routing support. (D) Modify the transit gateway by selecting multicast support. |
15. Click here to View Answer
Answer: B
Explanation:
The issue described points to asymmetric routing problems occurring due to the stateful nature of the IDS appliances in the shared services VPC. When traffic crosses Availability Zones, the return traffic might not be routed back to the same IDS instance that initially processed the outbound traffic, leading to connection failures because the stateful firewall in the IDS appliance doesn’t recognize the return traffic as part of an established connection.
Option B, enabling appliance mode support on the transit gateway VPC attachment for the shared services VPC, addresses this asymmetric routing problem. Appliance mode ensures that traffic flows are symmetrical, meaning that traffic originating from a source will always return through the same appliance. This resolves the issue of return traffic going to a different IDS instance, which would cause the stateful inspection to fail. By enabling appliance mode, the transit gateway ensures that both forward and return traffic for a connection are routed through the same IDS appliance, maintaining connection state and preventing intermittent connection issues.
Option A, enabling cross-Availability Zone load balancing on the transit gateway VPC attachment is incorrect. Cross-AZ load balancing distributes traffic across instances in different AZs, but doesn’t guarantee symmetric routing, which is required for stateful inspection.
Option C, enabling VPN ECMP routing, is not relevant in this scenario. ECMP is for distributing traffic across multiple VPN connections, not for managing traffic flow through IDS appliances in a shared services VPC.
Option D, enabling multicast support, is also not relevant as multicast is used for one-to-many communication, which isn’t the problem here. The issue is with the routing of unicast traffic and stateful inspection.
Therefore, enabling appliance mode support ensures consistent routing and allows the stateful IDS appliances to properly function, resolving the intermittent connection issues.
Reference link: https://docs.aws.amazon.com/vpc/latest/tgw/tgw-appliance-mode.html