CCNA Network Mgmt Ops Questions

To ensure redundancy for AWS Direct Connect, you should provision two Direct Connect connections at different locations (option C) to eliminate a single point of failure, and configure BGP with different ASNs on each connection (option E) to enable path diversity and automatic failover. Option A is incorrect because a single private VIF (or multiple VIFs) on a single connection still creates a single point of failure. Option B is incorrect because while a VPN backup provides some redundancy, it is not one of the two required actions for a highly available Direct Connect architecture—the question specifically asks for actions using Direct Connect.

Option D is incorrect because multiple VIFs on a single connection do not provide physical path diversity; they share the same underlying connection.

The most likely cause of intermittent traffic drops from on-premises to a VPC via Direct Connect and Transit Gateway is asymmetric routing due to missing or incorrect route propagation. Asymmetric routing can occur when the forward path (on-premises to VPC) is valid, but the return path (VPC to on-premises) lacks a specific route in the Transit Gateway route table. This causes packets to be dropped intermittently as route propagation changes or routing tables are updated.

Option A is incorrect because latency spikes are not typical of intermittent drops, and the VPN backup path is not mentioned as active. Option B is incorrect because MTU mismatch usually causes consistent packet loss for large packets, not intermittent drops. Option C is incorrect because BGP keepalive timer mismatches would cause sustained session loss rather than intermittent drops.

Therefore, option D is correct.

The most likely cause of health check failures is an incorrect health check path configured in the target group. The security group configuration described in the stem should allow health check traffic because the EC2 security group explicitly allows inbound traffic from the ALB security group. However, if the target group's health check path does not match the actual endpoint on the EC2 instances (e.g., it expects a 200 response from a specific URL that is not available), the health checks will fail.

Option B is incorrect because ALBs can be placed in private subnets without issue. Option C is incorrect because the stem states the EC2 security group allows inbound traffic from the ALB security group. Option D is incorrect because outbound rules on the ALB security group do not affect inbound health checks.

The most likely cause is that the CloudFormation template is attempting to add a security group rule that already exists. AWS CloudFormation does not allow duplicate security group rules; if the same protocol, port range, and source (CIDR or security group) are specified, the update will fail with a conflict error. Option A is incorrect because the CIDR block not being in the same VPC is not a factor for security group rules; they can reference external CIDRs.

Option B is incorrect because a deleted security group would result in a different error (e.g., referencing a non-existent group). Option C is incorrect because exceeding service quotas yields a different error message.

The recommended approach uses a centralized S3 bucket with default encryption using a KMS CMK and a bucket policy that allows cross-account writes. This ensures logs are encrypted at rest centrally without requiring per-account KMS keys. Option A is wrong because KMS keys in each account would complicate key management and cross-account access.

Option C is wrong because SSE-S3 encryption does not use a CMK and does not provide the same level of control. Option D is wrong because denying access unless encryption headers are present is not a reliable way to enforce encryption; bucket policies can be bypassed if headers are not included, and shared KMS keys are not recommended.

BGP communities allow AWS to tag routes from Direct Connect and VPN with different community values, enabling route preference control. By configuring the VPN routes with a lower preference (higher local preference via communities), traffic prefers Direct Connect when available. If Direct Connect fails, the VPN routes become active, providing failover.

Option B (MED) influences inbound routing from external peers, not outbound preference within AWS. Option C (BFD) detects link failures faster but does not control route selection. Option D (AS_PATH prepending) is used to deprioritize routes outbound, not between Direct Connect and VPN.

The Direct Connect Gateway has an allowed prefixes list that filters which BGP prefixes are accepted from the on-premises network. If the prefix is not in that list, it will not be propagated to the Transit Gateway route table. Option A is incorrect because route propagation on the Transit Gateway route table is used for VPC attachments, not for Direct Connect prefixes.

Option B is incorrect because BGP community attributes are used for tagging and influencing routing policies, not as a prerequisite for prefix acceptance. Option C is incorrect because the Transit Gateway association with the Direct Connect Gateway is already present as stated in the question, so this cannot be the cause.

To ensure that all traffic between VPCs is inspected by the network virtual appliance in the inspection VPC, you must control the routing. Transit Gateway route tables (Option C) allow you to define which traffic is sent to the inspection VPC by associating attachments with specific route tables and adding static routes or propagating routes. This ensures that inter-VPC traffic is forced through the inspection appliance before reaching its destination.

Transit Gateway flow logs (Option A) only provide visibility into traffic but do not enforce inspection; they are a monitoring tool, not a routing mechanism. Therefore, Option C is correct, while Options A, B, and D are incorrect.

The NAT gateway requires an associated Elastic IP to function correctly. Without it, the NAT gateway cannot be created or fails to operate, leading to intermittent connectivity issues for instances in the private subnet. Since the instances rely on the NAT gateway for outbound traffic (e.g., to reach configuration endpoints or DNS), any failure in the NAT gateway can disrupt SSH sessions that depend on such outbound communication.

Option A is incorrect because the network ACL is set to default allow all, so it does not block ephemeral ports. Option B is incorrect because a proxy is not typically required for SSH connections in this setup. Option C is incorrect because security groups are stateful, meaning outbound rules do not block return traffic from allowed inbound connections.

VPC Flow Logs capture IP traffic at the network interface level, including DNS queries (port 53) to any destination, such as a custom on-premises resolver over VPN. AWS Network Firewall can inspect and log DNS traffic that passes through it, including queries to custom resolvers. Option A (Route 53 Resolver query logs) is incorrect because it only logs queries made to Amazon Route 53 Resolver, not to custom on-premises resolvers.

Option B (CloudWatch) is incorrect because CloudWatch does not directly capture network traffic; it can aggregate logs but cannot capture raw DNS packets. Option E (CloudTrail) is incorrect because it logs API calls to AWS services, not network traffic.

The network ACL exhibit shows inbound rule 100 allowing HTTP traffic (port 80) and rule 200 denying SSH traffic (port 22). Since NACL rules are evaluated in ascending order, when an SSH packet arrives, rule 100 does not match (it allows HTTP, not SSH), so rule 200 matches and denies the traffic. Thus, SSH is blocked.

Option A is wrong because the security group allows SSH. Option B is wrong because the subnet is associated with the NACL as stated. Option C is wrong because rule 300 is a higher-numbered rule and would only be evaluated if no earlier rule matched; here rule 200 already matches and denies SSH.

Options A, B, and C are correct. A: Multiple endpoint groups with traffic dials allow distributing traffic across regions based on desired percentages. B: Enabling health checks with a low threshold for failure detection ensures fast failover by quickly marking unhealthy endpoints.

C: Setting traffic dials for each endpoint group allows fine-tuning the distribution of traffic. Option D is incorrect because client IP address preservation is not related to traffic distribution or failover; it affects source IP visibility. Option E is incorrect because Route 53 weighted routing is unnecessary; Global Accelerator can handle distribution via endpoint groups and traffic dials.

Correct answer: Option A is correct because MTU mismatch between the on-premises router and AWS Direct Connect interface can cause packet fragmentation or drops, leading to intermittent connection timeouts. The default MTU for Direct Connect is 1500 bytes, but if the on-premises router uses a larger MTU (e.g., 9001 for jumbo frames), packets may be dropped or fragmented, causing timeouts. Option B is incorrect because routing misconfiguration would cause persistent failure, not intermittent.

Option C is incorrect because a VPN is not used as a primary path when Direct Connect is available. Option D is incorrect because security groups apply to traffic within the VPC, not to on-premises traffic over Direct Connect.

When using AWS Transit Gateway with VPN or Direct Connect, the on-premises network can advertise more specific BGP routes that override the default routes learned from the Transit Gateway. This causes traffic to take the path through the on-premises network instead of staying within the Transit Gateway. Option A is wrong because route tables are associated with the Transit Gateway attachments, not the VPCs themselves.

Option B is wrong because the subnet route tables must point to the Transit Gateway for traffic to be routed correctly, but that would not cause traffic to go on-premises; rather, it would prevent traffic from reaching the Transit Gateway. Option D is wrong because VPC peering is not used with Transit Gateway in this scenario; conflicting routes could occur but the most likely cause is more specific BGP routes from on-premises.

Provisioning a NAT Gateway in each AZ allows instances in private subnets to initiate outbound traffic to the internet without relying on a single AZ, thus providing high availability and fault tolerance. Option E is correct because deploying an Application Load Balancer in each public subnet across multiple AZs ensures that the ALB can route traffic to healthy targets across AZs, providing high availability and fault tolerance for incoming client traffic. Option A is incorrect because an Internet Gateway is a VPC-level component that allows communication between the VPC and the internet; it is not something that needs to be 'attached' per se (it's already attached to the VPC), and it does not handle traffic distribution across AZs.

Option B is incorrect because a Network Load Balancer is suitable for TCP/UDP traffic, but the question does not specify protocol requirements; however, the primary reason it is not the best choice is that the requirement for high availability is better met with an Application Load Balancer for HTTP/HTTPS traffic, and the option says 'use a Network Load Balancer to distribute traffic across AZs' which is not the best fit for typical web applications. Option D is incorrect because a single NAT Gateway in one AZ creates a single point of failure; if that AZ goes down, outbound connectivity is lost.

Options C and E are correct. Checking the BGP session status and metrics on the virtual interface helps identify if there are BGP-related issues such as route flapping or session drops that could cause connectivity problems. Checking physical layer metrics like light levels and signal strength can reveal underlying physical issues with the Direct Connect connection.

Option A is incorrect because adding BGP peers does not address the symptoms of ConnectionReset and PacketDropRate. Option B is incorrect because increasing MTU could actually increase drop rates if the underlying physical layer has issues. Option D is incorrect because the VPN connection is not directly related to Direct Connect and increasing its bandwidth would not resolve issues with the Direct Connect connection.

Attaching the new VPC to the existing transit gateway allows immediate connectivity to the RDS VPC without changing existing routes, provided the transit gateway route tables are configured correctly. Option B is wrong because routing traffic through on-premises adds unnecessary latency and complexity. Option C is wrong because VPC peering requires route table updates in both VPCs, which contradicts the requirement to minimize routing changes.

Option D is wrong because migrating the RDS database would change the database endpoint and potentially cause downtime, and does not leverage the existing transit gateway.

The instance cannot reach the internet because the NAT gateway, although placed in a subnet labeled as public, is not in a functional public subnet—the subnet's route table must include a default route (0.0.0.0/0) pointing to an internet gateway. The problem statement indicates the NAT gateway has an Elastic IP, so association is not the issue. Instead, the likely cause is that the public subnet's route table lacks this route, meaning the NAT gateway cannot communicate with the internet gateway.

Option A is incorrect because the NAT gateway's Elastic IP is properly associated. Option C is incorrect because NACLs are properly configured. Option D is incorrect because the private subnet route table correctly points to the NAT gateway for 0.0.0.0/0.

To prefer the Direct Connect path, the engineer should make the VPN path less preferred in BGP path selection. AS path prepending on the VPN BGP advertisements artificially increases the AS path length, making the VPN route less preferred compared to the Direct Connect route (which has a shorter AS path). Option A is incorrect because local preference is a BGP attribute typically set on the receiving router within an AS, not on the Transit Gateway; the Transit Gateway does not set local preference for routes received from on-premises.

Option B is incorrect because you cannot decrease the AS path length below the actual path; the Direct Connect path already has the minimum path length. Option D is incorrect because setting a higher MED (Multi-Exit Discriminator) on the Direct Connect advertisements would make them less preferred (lower MED is better), which is the opposite of what is desired.

For VPC peering to work, each VPC's route table must have a route to the peer VPC's CIDR block pointing to the peering connection. Without these routes, traffic will not be directed across the peering link. Option A is incorrect because security groups are stateful and can allow traffic, but they are not the first check; the routing issue is more fundamental.

Option B is incorrect because network ACLs are stateless and could block traffic, but again, routing is the primary concern. Option D is incorrect because while the VPC peering connection status should be 'active' for traffic to flow, the most common issue after accepting the request is missing route table entries; thus, checking route tables should be the first step.

Security groups are stateful, meaning that if the web server initiates traffic to the database, the return traffic is automatically allowed regardless of outbound rules in the security group. However, network ACLs (NACLs) are stateless and require explicit inbound and outbound rules. In this scenario, the database server's security group is correctly configured to allow MySQL traffic from the web server's security group, indicating that the security group is not the issue.

The most likely cause is that the network ACL associated with the private subnet is blocking inbound MySQL traffic (port 3306) from the web server. Option A is incorrect because the route table for the private subnet does not need a route to the public subnet for traffic within the same VPC; local routes handle that. Option B is incorrect because security groups are stateful, so outbound traffic from the web server to the database is allowed by default.

Option D is incorrect because the database server does not need a route to the internet gateway for internal VPC communication.

BGP session flapping is often caused by mismatched BGP timers (hold timer and keepalive interval) between BGP peers. Verifying that these timers are consistent should be the first step. Option B is incorrect because MTU mismatch typically leads to packet loss or fragmentation, not BGP flapping.

Option C is incorrect because advertising the correct prefix is necessary for route propagation, but BGP session stability depends on timer and configuration compatibility. Option D is incorrect because the virtual interface state being 'available' is a prerequisite, but if it is available, flapping suggests a higher-layer configuration issue.

Options A, C, and D are correct. A: Amazon CloudWatch collects metrics and logs from AWS resources, enabling monitoring and alarms for anomalies in network performance. C: AWS Network Manager provides a global view of Transit Gateway networks and performance metrics, helping detect anomalies across VPCs and Direct Connect.

D: VPC Flow Logs capture IP traffic information for analysis, aiding in anomaly detection. Option B is wrong because AWS Trusted Advisor offers best practice checks, not real-time network monitoring. Option E is wrong because AWS X-Ray is for application tracing, not network performance.

If users can connect to the VPN but cannot reach resources in the VPC, the most likely cause is that the Client VPN endpoint lacks a subnet association. Without a subnet association, the endpoint cannot route traffic to the VPC. Option A is incorrect because authorization rules control which users can access specific resources, but the issue is broader connectivity.

Option C is incorrect because the security group controls inbound traffic to the endpoint, but the connection itself works; the problem is routing. Option D is incorrect because DNS configuration affects name resolution, not basic IP reachability.

When a Transit Gateway route table contains a propagated route from an on-premises network with a longer prefix (more specific) than the local VPC route, traffic destined for that specific CIDR will be sent to the on-premises network instead of using the inter-VPC route. This is because more specific routes take precedence over less specific ones. The suboptimal path occurs because the traffic is forced through the on-premises network, even though both VPCs are attached to the Transit Gateway and could communicate directly within AWS.

Option A is correct. Option B is incorrect because VPC peering is not used with Transit Gateway; if peering existed, it could create route conflicts, but the scenario describes Transit Gateway. Option C is incorrect because VPC Flow Logs are for monitoring traffic and do not affect routing.

Option D is incorrect because security groups are stateful firewalls that control traffic, but they do not determine routing paths; routing is controlled by route tables.

For EC2 instances to reach on-premises hosts, the VPC route table must have a route for the on-premises CIDR pointing to the Virtual Private Gateway. The engineer has that route. However, the on-premises hosts are in the 10.0.0.0/8 range, and the VPC also uses 10.0.0.0/16.

The issue is that the VPC route table has a local route for 10.0.0.0/16, which is more specific than the 10.0.0.0/8 route to the VGW. Traffic from EC2 to on-premises hosts within the 10.0.0.0/16 range will be routed locally within the VPC, not through the VGW. The on-premises hosts must be in a different CIDR than the VPC's CIDR, or the VPC must use a different CIDR.

Since the VPC uses 10.0.0.0/16, any on-premises host with an IP in that range will be considered local and won't go through the VGW. The solution is to ensure the VPC CIDR does not overlap with the on-premises CIDR.

A cluster placement group is designed for low-latency, high-throughput traffic by ensuring instances are in close proximity. Option B is incorrect because enabling enhanced networking and increasing instance size can improve throughput but does not directly reduce latency caused by inter-AZ distance. Option C is incorrect because moving instances to the same AZ helps, but a spread placement group still places instances on different racks, which introduces additional latency compared to a cluster placement group.

Option D is incorrect because VPC peering is used for connectivity between different VPCs; for intra-VPC traffic, adding a VPC peering connection does not reduce latency and may even add complexity.

Spoke VPCs need a default route (0.0.0.0/0) pointing to the transit gateway attachment to send internet-bound traffic to the inspection VPC. Option D is correct: in the inspection VPC, traffic from the transit gateway must be routed to the firewall appliances, inspected, and then sent back to the transit gateway for egress to the internet. Option E is correct: separate transit gateway route tables for the inspection VPC and spoke VPCs are required, with appropriate propagation and static routes to enforce traffic flow through the inspection VPC.

Option B is incorrect because service control policies (SCPs) can be used to restrict actions in AWS Organizations but do not directly enforce routing; routing is handled via route tables. Option C is incorrect because VPC Gateway Endpoints for S3 and DynamoDB do not affect internet traffic routing; they provide private access to those services.

The most likely cause is that the VPC attachments are using the default transit gateway route table instead of custom route tables. By default, a transit gateway has a default route table that is shared among all attachments, which can allow unintended inter-VPC traffic if the team did not explicitly associate each VPC attachment with a dedicated route table. The correct approach is to create individual route tables for each VPC and associate the respective VPC attachment with its custom route table, ensuring isolation.

Option A is incorrect because VPC route tables pointing to the transit gateway are necessary for VPCs to communicate via the transit gateway; they do not cause unintended traffic by themselves. Option B is incorrect because the issue is about which route table the attachments are associated with, not whether route tables exist. Option D is incorrect because propagating Direct Connect routes into all route tables would affect on-premises connectivity, but the issue is specifically inter-VPC traffic.

For a NAT Gateway to provide internet access to instances in a private subnet, it must have an Elastic IP (EIP) attached, and the private subnet's route table must include a route pointing to the NAT Gateway as the target for 0.0.0.0/0. Option A is wrong because NAT Gateways must reside in a public subnet (with a route to an Internet Gateway) to work. Option B is wrong because the NAT Gateway must be in the same VPC but not necessarily the same subnet as the EC2 instance; it should be in a public subnet.

Option D is wrong because an Internet Gateway is attached to the VPC, not to individual subnets; attaching an Internet Gateway directly to a private subnet is not a valid configuration.

Instances in a private subnet require a route to the NAT gateway to reach the internet. The private subnet's route table must have a default route (0.0.0.0/0) pointing to the NAT gateway as its target. Without this route, traffic from private instances sent to the internet will not be directed to the NAT gateway, and will instead remain in the VPC or be dropped.

Option A is incorrect because the NAT gateway itself resides in a public subnet and uses the internet gateway via that subnet's route table; it does not require its own route to the IGW. Option B is incorrect because security groups by default allow all outbound traffic, so this is unlikely to be the issue. Option C is incorrect because not having an Elastic IP would prevent the NAT gateway from having a public IP, but the question states a NAT gateway is set up, implying it has an Elastic IP; the more fundamental issue is the missing route.

Security groups act as a virtual firewall for VPC resources. If traffic from the on-premises network is not reaching the VPC, the security group rules must allow inbound traffic from the on-premises IP range. Option C is correct because the VPC route tables need a route for the on-premises network pointing to the virtual private gateway (VGW) to direct traffic correctly.

Option B is incorrect because the customer gateway is the on-premises VPN endpoint, and its association with the VPC is already established since the VPN tunnel is up. Option D is incorrect because NAT is not a requirement for site-to-site VPN; the issue is about routing, not address translation. Option E is incorrect because the tunnel is already up, so checking its status again does not help diagnose why traffic is not flowing.