AWS Certified Advanced Networking - Specialty - (ANS-C01) Exam Questions

Correct options:

Records without a health check are always considered healthy. If no record is healthy, all records are deemed to be healthy - If a record in a group of records that have the same name and type doesn't have an associated health check, Route 53 always considers it healthy and always includes it among possible responses to a query.

If none of the records in a group of records are healthy, Route 53 needs to return something in response to DNS queries, but it has no basis for choosing one record over another. In this circumstance, Route 53 considers all the records in the group to be healthy and selects one based on the routing policy and on the values that you specify for each record.

If you're creating failover records in a private hosted zone, you must assign a public IP address to an instance in the VPC to check the health of an endpoint within a VPC by IP address

If you're creating failover records in a private hosted zone, note the following:

1. Route 53 health checkers are outside the VPC. To check the health of an endpoint within a VPC by IP address, you must assign a public IP address to an instance in the VPC.

2. You can create a CloudWatch metric, associate an alarm with the metric, and then create a health check that is based on the data stream for the alarm.

Incorrect options:

If you're routing traffic to any AWS resources that you can create alias records for, you need to create health checks for these resources too - If you're routing traffic to any AWS resources that you can create alias records for, don't create health checks for those resources. When you create the alias records, you set Evaluate Target Health to Yes instead.

More than half of the configured records with nonzero weights must be unhealthy before Route 53 starts to respond to DNS queries using records that have weights of zero - All the records with non-zero weights must be unhealthy before Route 53 starts to respond to DNS queries using records that have weights of zero.

When responding to queries, Route 53 includes only the healthy primary resources for active-active failover configuration - In active-active failover, all the records that have the same name, the same type, and the same routing policy are active unless Route 53 considers them unhealthy. Route 53 can respond to a DNS query using any healthy record.

In active-passive failover, when responding to queries, Route 53 includes only the healthy primary resources. If all the primary resources are unhealthy, Route 53 begins to include only the healthy secondary resources in response to DNS queries.

References:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-types.html

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-how-route-53-chooses-records.html

Correct option:

Configure the VPN connection in an Active/Active configuration and advertise a more specific prefix for tunnel A

You can enable access to your remote network from your VPC by creating an AWS Site-to-Site VPN (Site-to-Site VPN) connection, and configuring routing to pass traffic through the connection. A VPN connection refers to the connection between your VPC and your own on-premises network. Site-to-Site VPN supports Internet Protocol security (IPsec) VPN connections.

The type of routing that you select can depend on the make and model of your customer gateway device. If your customer gateway device supports Border Gateway Protocol (BGP), specify dynamic routing when you configure your Site-to-Site VPN connection. If your customer gateway device does not support BGP, specify static routing. If you use a device that supports BGP advertising, you don't specify static routes to the Site-to-Site VPN connection because the device uses BGP to advertise its routes to the virtual private gateway. If you use a device that doesn't support BGP advertising, you must select static routing and enter the routes (IP prefixes) for your network that should be communicated to the virtual private gateway.

A Site-to-Site VPN connection offers two VPN tunnels between a virtual private gateway or a transit gateway on the AWS side, and a customer gateway (which represents a VPN device) on the remote (on-premises) side.

To address the given requirement, you need to set the customer gateway device to prefer one VPN tunnel over the other by leveraging the order of preference criteria:

Advertise a more specific prefix to the virtual private gateway or transit gateway on the tunnel (Tunnel A for the given use case) that the customer prefers to receive traffic from AWS.

For matching prefixes where each VPN connection uses BGP, the AS PATH is compared and the prefix with the shortest AS PATH is preferred.

When the AS PATHs are the same length, and the first AS in the AS_SEQUENCE is the same across multiple paths, multi-exit discriminators (MEDs) are compared. The path with the lowest MED value is preferred.

via - https://aws.amazon.com/premiumsupport/knowledge-center/vpn-configure-tunnel-preference/

Incorrect options:

Configure the VPN connection in an Active/Passive configuration and advertise a more specific prefix for tunnel B

Configure the VPN connection in an Active/Active configuration and advertise a more specific prefix for tunnel B

• For the given use case, you need to advertise a more specific prefix for tunnel A as that's the preferred tunnel. So both these options are incorrect.

Configure the VPN connection in an Active/Passive configuration and advertise a more specific prefix for tunnel A - If the AWS VPN connection (dynamic routing type) has an Active/Passive configuration (tunnel A is UP, but tunnel B is DOWN), traffic from AWS to the on-premises network traverses tunnel A because it's in the UP state. So using a more specific prefix for tunnel A is irrelevant.

References:

https://aws.amazon.com/premiumsupport/knowledge-center/vpn-configure-tunnel-preference/

https://docs.aws.amazon.com/vpn/latest/s2svpn/cgw-dynamic-routing-examples.html

Correct option:

Multicast traffic is only supported within and between VPC attachments to a Transit Gateway. Hence, peering Transit Gateways across regions will not work in this scenario

Service discovery means that a service client, such as a network file system browser, does not need to have explicit, configured, knowledge of the hostnames or IP addresses of servers offering that service. To enable service discovery, multicast-based protocols are necessary.

To support multicast and broadcast, the network has to create additional copies of non-unicast packets. An Ethernet switch, for instance, receiving a broadcast frame on one of its ports will send copies of that frame on all of its other ports. Multicast is handled similarly, but more efficiently, by replicating frames potentially only to a subset of ports. This flooding behavior is the key principle that enables service discovery because it allows both ‘announcement’ and ‘query’ type traffic to permeate the entire network.

In the Amazon VPC environment, AWS Transit Gateway can perform this task of selectively flooding multicast traffic to multiple destinations. AWS Transit Gateway acts as a virtual routing appliance and can flexibly connect Amazon VPCs with no single point of failure and the ability to scale to thousands of VPC interconnections. Connected VPCs can all be in the same AWS account or separate accounts.

Multicast routing limitations in AWS Transit Gateway: via - https://docs.aws.amazon.com/vpc/latest/tgw/tgw-multicast-overview.html

Incorrect options:

Multicast traffic is only supported over AWS Direct Connect, hence the data center (accessible via Transit Gateway 2) will be discoverable to the proposed service discovery application via Transit Gateway 1

Multicast traffic is only supported over AWS Direct Connect and AWS Site-to-Site VPN. Multicast is not supported on Transit Gateway peering attachments

Multicast traffic is only supported over VPC and VPN attachments to a Transit Gateway. AWS Direct Connect and Transit Gateway peering attachments do not support multicast traffic

As discussed above, you can only route multicast traffic within and between VPC attachments to a Transit Gateway. Multicast routing is not supported over AWS Direct Connect, AWS Site-to-Site VPN, and peering attachments. Hence, these three options are incorrect.

Reference:

https://aws.amazon.com/blogs/networking-and-content-delivery/automating-service-discovery-using-aws-transit-gateway-multicast-with-igmp/

Correct options:

Amazon SNS

Amazon Inspector

Amazon Inspector is an automated security assessment service that helps you test the network accessibility of your Amazon EC2 instances and the security state of your applications running on the instances.

You can perform network security assessments via your own custom solutions, however, that entails significant time and effort. You might need to run network port-scanning tools to test routing and firewall configurations, then validate what processes are listening on your instance network ports, before finally mapping the IPs identified in the port scan back to the host’s owner.

To make this process simpler for its customers, AWS offers the Network Reachability rules package in Amazon Inspector, which is an automated security assessment service that enables you to understand and improve the security and compliance of applications deployed on AWS. The existing Amazon Inspector host assessment rules packages check the software and configurations on your Amazon Elastic Compute Cloud (Amazon EC2) instances for vulnerabilities and deviations from best practices.

via https://aws.amazon.com/blogs/security/amazon-inspector-assess-network-exposure-ec2-instances-aws-network-reachability-assessments/

You can use these rules packages to analyze the accessibility of critical ports, as well as all other network ports. For critical ports, Amazon Inspector will show the exposure of each and will offer findings per port. When critical, well-known ports (based on Amazon’s standard guidance) are reachable, findings will be created with higher severities.

via https://aws.amazon.com/blogs/security/amazon-inspector-assess-network-exposure-ec2-instances-aws-network-reachability-assessments/

The findings also have recommendations that include information about exactly which Security Group you can edit to remove the access. And like all Amazon Inspector findings, these can be published to an SNS topic for additional processing or you could use a Lambda to automatically remove ingress rules in the Security Group to address a network reachability finding. For the given use-case, the network engineer can use the SNS topic to send the notifications to the team.

Incorrect options:

AWS Shield - AWS Shield is a managed service that protects against Distributed Denial of Service (DDoS) attacks for applications running on AWS. AWS Shield Standard is automatically enabled to all AWS customers at no additional cost. AWS Shield Advanced is an optional paid service. AWS Shield Advanced provides additional protections against more sophisticated and larger attacks for your applications running on Amazon EC2, Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53. AWS Shield cannot be used to assess network exposure of EC2 instances on specific ports.

Amazon CloudWatch - Amazon CloudWatch is a monitoring service for AWS cloud resources and the applications you run on AWS. You can use Amazon CloudWatch to collect and track metrics, collect and monitor log files, and set alarms. CloudWatch cannot be used to assess network exposure of EC2 instances on specific ports.

VPC Flow Logs - VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data can be published to Amazon CloudWatch Logs or Amazon S3. You can create a flow log for a VPC, a subnet, or a network interface. If you create a flow log for a subnet or VPC, each network interface in that subnet or VPC is monitored. You can use VPC Flow Logs to assess network exposure of EC2 instances on specific ports but the solution would entail significant development effort to parse through the logs and identify the exposed ports. So this option is incorrect.

Reference:

https://aws.amazon.com/blogs/security/amazon-inspector-assess-network-exposure-ec2-instances-aws-network-reachability-assessments/

Correct option:

Create four private VIFs, that is, one VIF each from the on-premises data center to each of the VPCs. Enable VPC peering between all VPCs

A Virtual Interface (VIF) is necessary to access AWS services, and can be either public, private or transit, like so:

Private virtual interface: A private virtual interface should be used to access an Amazon VPC using private IP addresses.

Public virtual interface: A public virtual interface can access all AWS public services using public IP addresses. A public virtual interface enables access to public services, such as Amazon S3.

Transit virtual interface: A transit virtual interface should be used to access one or more Amazon VPC Transit Gateways associated with Direct Connect gateways. You can use transit virtual interfaces with 1/2/5/10 Gbps AWS Direct Connect connections.

Direct Connect gateways only support routing traffic from Direct Connect VIFs to VGW (associated with VPC). VPC to VPC communication or VIF to VIF communication is not possible via Direct Connect gateways. Therefore, to send traffic between two VPCs, you must configure a VPC peering connection.

via - https://docs.aws.amazon.com/directconnect/latest/UserGuide/virtualgateways.html

The given use case requires data flow from the on-premises data center to each of the VPCs, so you must create one VIF each from the on-premises data center to each of the VPCs. If you are using VPC peering, on-premises connectivity (VPN and/or Direct Connect) must be made to each VPC. Resources in a VPC cannot reach on-premises using the hybrid connectivity of peered VPCs.

via - https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/vpc-peering.html

via - https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html

Incorrect options:

Create four private VIFs, that is, one VIF each from the on-premises data center to each of the VPCs. Route traffic between VPCs using the Direct Connect link - As mentioned in the explanation above, you cannot route traffic between VPCs using a Direct Connect link. So this option is incorrect.

Create a private VIF to the Audit department's VPC. Peer this VPC to all the other VPCs - Just a single VIF to the Audit department's VPC would not suffice the requirement of having data flow from the on-premises data center to each of the VPCs. Resources in a VPC cannot reach on-premises using the hybrid connectivity of peered VPCs.

Create a public VIF to the Audit department's VPC. Peer this VPC to all the other VPCs - This option has been added as a distractor. You can only create a transit virtual interface to connect to a transit gateway, a public virtual interface to connect to public resources (non-VPC services), or a private virtual interface to connect to a VPC. So you cannot create a public VIF to connect to a VPC.

References:

https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/vpc-peering.html

https://aws.amazon.com/directconnect/faqs/

https://docs.aws.amazon.com/directconnect/latest/UserGuide/virtualgateways.html

https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html

Correct option:

Configure your customer gateway to advertise the same prefix with the same Border Gateway Protocol (BGP) attributes on both public virtual interfaces

AWS Direct Connect links your internal network to an AWS Direct Connect location over a standard Ethernet fiber-optic cable. One end of the cable is connected to your router, the other to an AWS Direct Connect router. With this connection, you can create virtual interfaces directly to public AWS services (for example, to Amazon S3) or Amazon VPC, bypassing internet service providers in your network path. An AWS Direct Connect location provides access to AWS in the Region with which it is associated.

When using Direct Connect to transport production workloads between AWS services, it's a best practice to create two connections through different data centers or providers. You have two options on how to configure your connections:

Active/Active – Traffic is load-shared between interfaces based on flow. If one connection becomes unavailable, all traffic is routed through the other connection.

Active/Passive – One connection handles traffic, and the other is on standby. If the active connection becomes unavailable, all traffic is routed through the passive connection.

To configure an Active/Passive connection using a public ASN:

Allow your customer gateway to advertise the same prefix (public IP or network that you own) with the same Border Gateway Protocol (BGP) attributes on both public virtual interfaces. This configuration permits you to load balance traffic over both public virtual interfaces.

Check the vendor documentation for device-specific commands for your customer gateway device.

via - https://aws.amazon.com/premiumsupport/knowledge-center/dx-create-dx-connection-from-public-vif/

Incorrect options:

Set up the customer gateway to advertise the longer prefix on your primary connection - While configuring an Active/Passive connection using a private ASN, you need to set up the customer gateway to advertise the longer prefix on your primary connection. So this option is incorrect for the given use case.

Set up the customer gateway to advertise the longer prefix on your secondary connection - While configuring an Active/Passive connection using a private ASN, you need to set up the customer gateway to advertise the longer prefix on your primary connection. This option has been added as a distractor.

Active/active configuration from a public virtual interface is not supported using public ASN - If you're using a private ASN, load balancing on a public virtual interface is not supported. Active/active configuration from a public virtual interface is indeed supported using public ASN. So this option is incorrect for the given use case.

References:

https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html

https://aws.amazon.com/premiumsupport/knowledge-center/dx-create-dx-connection-from-public-vif/

Correct option:

The on-premises network would be unreachable as the local route would be preferred for all traffic destined for 172.31.1.0/24

You can enable access to your remote network from your VPC by creating an AWS Site-to-Site VPN (Site-to-Site VPN) connection, and configuring routing to pass traffic through the connection. A Site-to-Site VPN connection offers two VPN tunnels between a virtual private gateway or a transit gateway on the AWS side, and a customer gateway (which represents a VPN device) on the remote (on-premises) side. When you create a Site-to-Site VPN connection, you must specify the type of routing that you plan to use (static or dynamic) and update the route table for your subnet.

via - https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html

Site-to-Site VPN Components: via - https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html

If propagated routes from a Site-to-Site VPN connection or AWS Direct Connect connection overlap with the local route for your VPC, the local route is most preferred even if the propagated routes are more specific. For the given use case, the on-premises network would be unreachable as the local route would be preferred for all traffic destined for 172.31.1.0/24.

via - https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html

Incorrect options:

All traffic destined for 172.31.1.0/24 is routed via the virtual private gateway - This option is incorrect as the local route is most preferred even if the propagated routes are more specific since we have an overlap.

All traffic destined for 172.31.1.0/24 is routed via the internet gateway

All traffic destined for 172.31.1.0/24 is routed via the virtual private gateway or the internet gateway

These two options have been added as distractors since the use case does not mention having an internet gateway attached to the given VPC.

References:

https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html

https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html

https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html

Correct options:

For AWS Direct Connect connection, reuse your existing VIFs and enable them for dual-stack support

To use your Direct Connect connection for dual-stack traffic, you need to create one of the following virtual interfaces (VIFs): Private VIF, Public VIF, or Transit VIF, or reuse your existing VIFs and enable them for dual-stack support. The following considerations apply to dual-stack VIFs: 1. A virtual interface can support a BGP peering session for IPv4, IPv6, or both (dual-stack). 2. For the IPv6 stack, Amazon automatically assigns a /125 IPv6 CIDR for the BGP peering connection. 3. On Public VIFs, you must advertise to AWS /64 prefixes or larger.

Dual-stack connectivity on Amazon Direct Connect: via - https://aws.amazon.com/blogs/networking-and-content-delivery/dual-stack-ipv6-architectures-for-aws-and-hybrid-networks/

For dual-stack connectivity on the Site-to-Site VPN connection via a Transit Gateway, you need to create two VPN connections, one for the IPv4 stack and one for the IPv6 stack

Your Site-to-Site VPN connection on a Transit Gateway can support either IPv4 traffic or IPv6 traffic inside the VPN tunnels. This means that for dual-stack connectivity, you need to create two VPN connections, one for the IPv4 stack and one for the IPv6 stack. For the Site-to-Site VPN connection, you intend to use for IPv4 routing, each tunnel will have a /30 IPv4 CIDR in the 169.254.0.0/16 range, while for the VPN connection intended for IPv6 routing, each VPN tunnel will have two CIDR blocks: one /30 IPv4 CIDR in the 169.254.0.0/16 range and one /126 IPv6 CIDR in the fd00::/8 range.

Dual-stack configuration on AWS Site-to-site VPN: via - https://aws.amazon.com/blogs/networking-and-content-delivery/dual-stack-ipv6-architectures-for-aws-and-hybrid-networks/

To configure an IPv6-enabled VPC attachment for the Transit Gateway, the VPC and the attachment subnets need to have associated IPv6 CIDRs. The remaining Transit Gateway configurations continue to have the same functionalities across both stacks

AWS Transit Gateway is a network transit hub that you can use to interconnect your VPCs and hybrid networks for both IPv4 and IPv6 stacks. All Transit Gateway concepts and constructs – attachments, peering connections, associations, propagations, and routing – continue to have the same functionalities across both stacks. Note that to configure an IPv6-enabled VPC attachment to the Transit Gateway, the VPC and attachment subnets need to have associated IPv6 CIDRs.

Dual-stack AWS Transit Gateway Routing: via - https://aws.amazon.com/blogs/networking-and-content-delivery/dual-stack-ipv6-architectures-for-aws-and-hybrid-networks/

Incorrect options:

AWS Site-to-Site VPN connection on a Transit Gateway can support both IPv4 traffic and IPv6 traffic inside the VPN tunnels. Hence, no changes are required on this connection

To use Direct Connect connection for dual-stack traffic, you need to create separate virtual interfaces (VIFs- Private VIF or Public VIF or Transit VIF) for each stack

AWS Transit Gateway does not support IPv6 traffic. Hence, VPC peering should be considered for dual-stack traffic

These three options contradict the explanation provided above, so these options are incorrect.

Reference:

https://aws.amazon.com/blogs/networking-and-content-delivery/dual-stack-ipv6-architectures-for-aws-and-hybrid-networks/

Correct options:

10.2.0.2

169.254.169.253

Domain Name System (DNS) is a standard by which names used on the internet are resolved to their corresponding IP addresses. A DNS hostname is a name that uniquely and absolutely names a computer; it's composed of a hostname and a domain name. DNS servers resolve DNS hostnames to their corresponding IP addresses. Public IPv4 addresses enable communication over the internet, while private IPv4 addresses enable communication within the network of the instance (either EC2-Classic or a VPC).

via - https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html

via - https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html

To support DNS resolution, Amazon provides DNS server at the 169.254.169.253 IPv4 address or the reserved IP address at the base of the VPC IPv4 network range plus two. So for the given use case, 10.2.0.2 is also reserved by Amazon for DNS resolution.

The Dynamic Host Configuration Protocol (DHCP) provides a standard for passing configuration information to hosts on a TCP/IP network. The options field of a DHCP message contains configuration parameters, including the domain name, domain name server, and the netbios-node-type. By default, all instances in a nondefault VPC receive an unresolvable hostname that AWS assigns (for example, ip-10-0-0-202). You can assign your own domain name to your instances, and use up to four of your own DNS servers. To do that, you must create a custom set of DHCP options to use with the VPC.

via - https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html

Incorrect options:

10.0.0.2

10.1.0.2

169.254.169.254

These three options contradict the explanation provided above, so these options are incorrect.

References:

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html

Correct option:

Longest prefix match, Static routes, Direct-Connect BGP routes, VPN BGP routes

AWS uses the most specific route in your route table that matches the traffic to determine how to route the traffic (longest prefix match). If your route table has overlapping or matching routes, the following rules apply:

If propagated routes from a Site-to-Site VPN connection or AWS Direct Connect connection overlap with the local route for your VPC, the local route is most preferred even if the propagated routes are more specific.

If propagated routes from a Site-to-Site VPN connection or AWS Direct Connect connection have the same destination CIDR block as other existing static routes (longest prefix match cannot be applied), AWS prioritizes the static routes whose targets are an internet gateway, a virtual private gateway, a network interface, an instance ID, a VPC peering connection, a NAT gateway, a transit gateway, or a gateway VPC endpoint.

When a virtual private gateway receives routing information, it uses path selection to determine how to route traffic. The longest prefix match applies. If the prefixes are the same, then the virtual private gateway prioritizes routes as follows, from most preferred to least preferred:

BGP propagated routes from an AWS Direct Connect connection

Manually added static routes for a Site-to-Site VPN connection

BGP propagated routes from a Site-to-Site VPN connection

via - https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html

Incorrect options:

Direct-Connect BGP routes, VPN BGP routes, Longest prefix match, Static routes

Static routes, Longest prefix match, Direct-Connect BGP routes, VPN BGP routes

Longest prefix match, Direct-Connect BGP routes, Static routes, VPN BGP routes

These three options contradict the explanation provided above, so these options are incorrect.

Reference:

https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html