CompTIA Network+ N10-009 (N10-009) — Questions 451–472

An AAA server handles authentication, authorization, and accounting for network access, not centralized management, auto-discovery, configuration management, or performance monitoring of network devices.

A SIEM (Security Information and Event Management) system focuses on security event collection, correlation, and alerting, not on network device auto-discovery, configuration management, or performance monitoring.

A DHCP server assigns IP addresses and network configuration parameters to clients; it does not provide centralized management, monitoring, auto-discovery, or configuration management of network devices.

A question asking for a system to control user access to network resources, enforce policies, and log access attempts for compliance would make an AAA server the correct answer.

An organization needs to collect, analyze, and correlate security logs from multiple sources (e.g., firewalls, servers, applications) to detect and respond to security incidents in real time. Which system should be deployed?

An organization needs to automatically assign IP addresses to devices on a subnet and ensure that network configuration (e.g., default gateway, DNS) is consistently applied without manual intervention.

Candidates may confuse AAA's centralized control of network access with centralized management of devices, or think AAA includes device monitoring features.

Candidates may confuse SIEM with NMS because both involve monitoring and centralized management, but SIEM is security-focused while NMS handles network infrastructure.

Candidates may confuse DHCP's role in network configuration with broader network management capabilities, or think that DHCP's auto-assignment feature is similar to auto-discovery.

CRC errors on a fiber link with link lights on typically indicate signal degradation or physical layer issues, not duplex mismatches, which usually cause frame check sequence errors or late collisions on copper links, not on single-mode fiber.

The question states the link is 10 km, which is within the typical range for single-mode fiber (up to 40 km or more). CRC errors are more likely due to signal degradation or dirty connectors, not cable length.

When troubleshooting intermittent connectivity or performance issues on a copper Ethernet link (e.g., Cat5e) where link lights are on but there are errors, checking duplex settings is the next step after verifying cables, as mismatched duplex can cause high error rates.

If the question described a link exceeding the maximum distance for the fiber type (e.g., 100 km on single-mode without repeaters) or if the cable was installed with excessive bends or splices causing attenuation, then verifying cable length or loss budget would be the next step.

Candidates often associate CRC errors with duplex mismatches from common Ethernet troubleshooting scenarios, but they overlook that fiber links are almost always full-duplex and duplex mismatch is rare on modern fiber interfaces.

Candidates may confuse CRC errors with distance-related issues like signal attenuation, assuming that exceeding the cable length specification causes bit errors, but in this scenario the length is standard and the problem points to optical power issues.

Telnet transmits data, including credentials, in plaintext, so it does not provide encryption for remote terminal sessions, which is required by the question.

SNMP is used for network monitoring and management of device configurations, not for establishing remote terminal sessions. It does not provide an interactive command-line interface for routers and switches.

HTTP is not encrypted and is used for web traffic, not for remote terminal sessions to manage routers and switches.

In a scenario where the question specifies a legacy network with no security requirements or asks for a protocol that does not require encryption, Telnet would be correct for remote terminal access.

A question asking for a protocol to collect performance metrics or monitor device status from multiple routers and switches, especially when encrypted communication is required (SNMPv3).

When the question asks for a protocol to access a web-based management interface on a network device without encryption requirements, HTTP would be correct.

Candidates often confuse Telnet with SSH because both provide remote terminal access, and they may overlook the encryption requirement or assume Telnet can be secured with other measures.

Candidates may confuse SNMP's role in network management with remote terminal access, or think that because SNMP can manage devices, it can also be used for interactive sessions.

Candidates may confuse HTTP with HTTPS or think that web-based management is equivalent to terminal sessions, overlooking the encryption requirement.

MAC flooding involves sending many frames with different source MAC addresses to overflow the switch's CAM table, not forging ARP replies to associate a MAC with a gateway IP.

DHCP snooping is a security feature that filters untrusted DHCP messages to prevent rogue DHCP servers, not a method for forging ARP replies to associate a MAC with a gateway IP.

DNS spoofing involves corrupting DNS resolution to redirect traffic to malicious sites, not forging ARP replies to associate a MAC address with a gateway IP.

A question describing an attack where an attacker sends a flood of packets with random source MAC addresses to force a switch into hub mode, allowing traffic sniffing, would have MAC flooding as the correct answer.

A question describing an attack where a rogue DHCP server assigns false IP configurations to clients, causing traffic interception, would have DHCP snooping as the correct answer (e.g., 'What attack is mitigated by DHCP snooping?').

A question describing an attacker intercepting DNS queries and returning fake IP addresses to redirect users to a phishing site would make DNS spoofing the correct answer.

Candidates may confuse ARP poisoning with MAC flooding because both attacks manipulate MAC address tables and are used for man-in-the-middle or traffic interception purposes.

Candidates may confuse DHCP snooping with ARP poisoning because both involve manipulating network mappings (IP-MAC) and are often covered together in security training.

Candidates may confuse network-layer attacks, thinking 'spoofing' in DNS spoofing is similar to ARP spoofing, or they may misremember the specific attack vector for ARP poisoning.

SNMPv1 does not support encryption or authentication; it uses community strings in plaintext, so it cannot provide the required security for data origin authentication and encryption.

SNMPv2c uses community strings for authentication, which are transmitted in plaintext, and does not provide encryption or data origin authentication, failing the question's requirements.

SNMPv2 (and SNMPv2c) lacks encryption and authentication; it only uses community strings in plaintext, which does not meet the requirement for encrypted and authenticated data origin.

A question asking for the simplest SNMP version that is widely supported for basic monitoring in a trusted, isolated network where security is not a concern, and only read-only access is needed.

A question asking for the simplest SNMP version that supports bulk retrieval of MIB data (e.g., GETBULK) and uses community-based authentication, without requiring encryption or strong authentication.

A question that asks for a version that supports bulk retrieval of MIB data (GetBulk) or improved error handling, without requiring security features, would make SNMPv2 the correct answer.

Candidates may confuse SNMPv1 with being 'secure enough' for basic monitoring, or they may not realize that SNMPv1 lacks any security features beyond a plaintext community string.

Candidates may confuse SNMPv2c's community strings as providing some form of authentication, or they may recall that SNMPv2c is widely used and mistakenly think it supports encryption.

Candidates may confuse SNMPv2 with SNMPv3, thinking that 'v2' implies improved security, or they may recall that SNMPv2 introduced some enhancements but overlook that security was not addressed until v3.

Root guard is used to enforce the root bridge position in a spanning-tree topology, not to disable ports upon receiving BPDUs. It does not prevent unauthorized switches from causing loops by disabling the port.

Loop guard is designed to prevent alternate or root ports from becoming designated ports in the absence of BPDUs, not to disable a port upon receiving a BPDU. It does not protect against rogue switches sending BPDUs.

UDLD (Unidirectional Link Detection) detects unidirectional links but does not disable a port upon receiving BPDUs; it is not designed to prevent rogue switches or loops caused by BPDU reception.

Root guard would be correct in a scenario where an administrator wants to ensure that a specific switch remains the root bridge and prevent any other switch from becoming root by sending superior BPDUs. For example, on a port connected to a customer switch, root guard would disable the port if a superior BPDU is received.

A question describing a scenario where a unidirectional link failure causes a loop, and the solution must prevent a port from transitioning to forwarding state when BPDUs stop arriving (e.g., due to a faulty cable).

UDLD would be correct in a scenario where a network administrator needs to detect and disable ports that are only transmitting in one direction, preventing issues like routing loops or STP failures due to unidirectional links.

Candidates may confuse root guard with BPDU guard because both involve BPDUs and port disabling, but root guard focuses on maintaining root bridge status rather than preventing unauthorized switches.

Candidates may confuse loop guard with BPDU guard because both deal with loops and BPDUs, but loop guard addresses missing BPDUs rather than unexpected BPDUs.

Candidates may confuse UDLD with BPDU guard because both involve loop prevention, but UDLD focuses on unidirectional links rather than unauthorized BPDU reception.

Duplex mismatch typically causes constant errors or complete link failure, not intermittent flapping. The symptoms here (up/down flapping with acceptable optical power) point to a physical layer issue like dirty connectors, not a duplex configuration problem.

Speed mismatch typically causes a link to not come up at all or to flap continuously, but the question states optical power levels are within range, and the issue is intermittent. Speed mismatch would usually be constant, not intermittent, and is less common on fiber links with auto-negotiation.

A VLAN mismatch would cause connectivity issues but typically results in a stable link state (up/up) with no communication, not intermittent flapping of the link status. The link flapping indicates a physical layer problem, not a layer 2 configuration issue.

A technician reports that a link is up but has a high number of CRC errors and slow performance. After checking, both switches are set to different duplex modes (one half, one full). In that scenario, duplex mismatch is the most likely cause.

A technician connects two switches and the link fails to establish. The switches have different fixed speed capabilities (e.g., one is 100 Mbps and the other is 1 Gbps) and auto-negotiation is disabled. In this scenario, speed mismatch is the most likely cause.

A VLAN mismatch would be correct in a scenario where two switches are connected and the link is up/up, but devices on the same VLAN cannot communicate across the link, or there is no traffic passing despite a stable link.

Candidates may confuse intermittent flapping with duplex mismatch because both can cause connectivity issues, but they overlook that duplex mismatch usually results in persistent errors rather than link state changes.

Candidates may confuse symptoms of speed mismatch (link flapping) with those of dirty connectors, or they may overgeneralize that any flapping is due to speed/duplex issues without considering the intermittent nature and acceptable power levels.

Candidates may confuse VLAN mismatch with other misconfigurations that cause intermittent issues, or they might think that VLAN mismatch can cause link flapping due to spanning tree or other protocols reacting to the misconfiguration.

Duplex mismatch typically causes CRC errors and frame check sequence failures, which would appear in interface error counters. Since the technician checked and found no errors, duplex mismatch is unlikely.

Incorrect MTU typically causes packet fragmentation or drops, not varying latency with no interface errors. The symptoms of high and varying latency without errors point to CPU overload, not MTU issues.

Route flapping typically causes intermittent connectivity and routing table instability, not consistently high latency with varying ping responses and no interface errors.

A question describes intermittent connectivity or slow performance between two directly connected devices, and the interface error counters show CRC errors or runts. In that scenario, duplex mismatch is a common cause.

Incorrect MTU would be correct if users report that large file transfers fail or are slow, while small transfers work fine, and the traceroute shows no response or 'fragmentation needed' messages at a specific hop, with no latency variation.

A question describes intermittent connectivity to a remote site, with traceroute showing the route changing between different paths and the route appearing and disappearing in the routing table. The correct answer would be route flapping.

Candidates often associate high latency with layer 1 or 2 issues like duplex mismatch, but they overlook that duplex mismatch usually produces visible errors on the interface counters.

Candidates may confuse MTU issues with latency problems because both can affect file transfer performance, and MTU misconfiguration is a common cause of network slowdowns in remote office scenarios.

Candidates may associate any routing issue with 'flapping' and confuse high latency with route instability, especially when traceroute shows a problematic hop.

Routers use IP addresses to make forwarding decisions, which operate at Layer 3 (Network). Layer 1 is the physical medium (cables, signals) and does not involve IP addresses.

A router makes forwarding decisions based on IP addresses, which are Layer 3 (Network layer) addresses. Layer 2 (Data Link layer) uses MAC addresses for forwarding within a local network, not IP addresses.

Routers make forwarding decisions based on IP addresses, which operate at Layer 3 (Network). Layer 4 (Transport) handles end-to-end communication and port numbers, not IP routing.

A question asking 'At which OSI layer do hubs and repeaters operate?' would have Layer 1 as the correct answer, as these devices simply regenerate signals without addressing.

This option would be correct for a question like: 'At which OSI layer does a switch primarily operate to make forwarding decisions based on MAC addresses?' In that context, Layer 2 is the correct answer.

A question asking which OSI layer handles segmentation, flow control, and error recovery (e.g., TCP/UDP) would have Layer 4 as the correct answer.

Candidates may confuse the physical transmission of data (Layer 1) with the routing function, or think that routers deal with physical connections.

Candidates may confuse routers with switches, as both forward traffic, or they may think that IP addresses are handled at Layer 2 because they associate IP with Ethernet frames.

Candidates may confuse the router's use of IP addresses with higher-layer functions like port-based filtering, or mistakenly think routers inspect transport-layer headers for forwarding decisions.

TFTP lacks encryption and authentication, making it unsuitable for secure backups over the internet.

FTP transmits data in plaintext, including authentication credentials, and does not provide encryption or authentication for the backup files, failing the security requirements.

HTTP does not provide encryption or authentication by default; it transmits data in plaintext, making it unsuitable for secure backup of router configurations over the internet.

A network administrator needs to quickly transfer a router configuration file to a local TFTP server on the same LAN segment, with no security requirements.

An administrator needs to transfer files within a trusted local network where security is not a concern, and the devices support FTP for simple file transfers without encryption overhead.

A question asking for a protocol to transfer configuration files within a secure internal network where encryption is not required, or when using HTTPS (HTTP over SSL/TLS) for secure web-based management interfaces.

Candidates may associate TFTP with router configuration backup due to its simplicity and common use in local network environments, overlooking the security requirements for internet-based transfers.

Candidates may associate FTP with file transfer automation and overlook its lack of encryption, assuming it is sufficient for remote backups over the internet.

Candidates may confuse HTTP with HTTPS, assuming it provides security, or think that web-based management is sufficient for automated backups without considering encryption requirements.

PVC-jacketed cable is not allowed in plenum spaces because it produces toxic smoke and supports flame propagation, violating building codes that require low-smoke, fire-resistant materials.

Riser-rated cable is designed for vertical runs between floors, not for plenum spaces where air circulates. Building codes require plenum-rated cable in plenums due to its low smoke and flame spread properties.

LSZH cable is designed to emit low smoke and no halogens when burned, but it is not specifically rated for plenum spaces; plenum-rated cable is required by building codes for air-handling spaces due to its fire-resistant and low-smoke properties.

PVC-jacketed cable would be correct for a question about general-purpose horizontal cabling in non-plenum areas (e.g., within walls or conduit) where cost is a primary concern and fire codes are less strict.

A question asking which cable type is required for vertical cable runs between floors in a building (e.g., in elevator shafts or riser closets) would have riser-rated cable as the correct answer.

In a scenario where the cable is installed in a non-plenum, confined space (e.g., inside a metal conduit or in a residential area) and the primary concern is reducing toxic gas emissions during a fire, LSZH cable would be the correct choice.

Candidates may assume PVC is standard for all indoor cabling and overlook the special fire and smoke requirements of plenum spaces.

Candidates may confuse 'riser' with 'plenum' or assume that any fire-resistant cable is acceptable in plenums, not realizing that plenum spaces have stricter requirements.

Candidates may confuse LSZH with plenum-rated cable because both are associated with fire safety and low smoke, but they are governed by different standards and applications.

High output power can cause co-channel interference and cell overlap, but the question states channel utilization is above 80%, which points to congestion from too many APs on the same or overlapping channels, not power levels.

Intermittent disconnections with high channel utilization are more likely caused by co-channel interference from too many access points on the same or overlapping channels, not by microwave ovens, which typically cause non-Wi-Fi interference that is constant rather than intermittent.

Weak signal strength causes low throughput or disconnections at the client, but the question states channel utilization is consistently above 80% on the 2.4 GHz band, indicating congestion from many devices or access points, not weak signal.

In a scenario where clients experience disconnections but channel utilization is low, and a site survey shows excessive signal overlap and high RSSI from neighboring APs, then output power being too high is the likely cause.

A technician reports periodic, severe signal degradation on the 2.4 GHz band during lunch hours. A spectrum analyzer shows non-Wi-Fi interference spikes. In this scenario, microwave ovens are the most likely cause.

A technician is troubleshooting a wireless network where users in a specific area report frequent disconnections. A site survey shows low RSSI values for client devices in that area. In this scenario, weak signal strength would be the most likely cause.

Candidates may confuse symptoms of high channel utilization with those of excessive power, or they may recall that high power can cause interference and assume it leads to high utilization.

Candidates know that microwave ovens operate in the 2.4 GHz band and can cause interference, so they may jump to this familiar cause without considering that the high channel utilization points to Wi-Fi congestion rather than external interference.

Candidates may associate intermittent disconnections with weak signal, overlooking that the given high channel utilization points to congestion rather than signal strength issues.

Performing a firmware upgrade does not directly address the goal of restoring a failed switch with minimal downtime; it is a proactive maintenance task unrelated to rapid replacement.

Monitoring CPU utilization helps identify performance issues but does not prepare for switch replacement or reduce downtime after a failure; it is a proactive monitoring task, not a recovery task.

A question asking 'Which task ensures switches have the latest security patches and feature updates?' would make firmware upgrades the correct answer.

A question asking 'Which task helps identify potential switch overload before it causes network issues?' would make monitoring CPU utilization correct, as it detects high usage that could lead to performance degradation.

Candidates may think keeping firmware current is essential for reliability, but it does not speed up recovery after a failure.

Candidates may think that monitoring CPU utilization is part of regular maintenance that indirectly aids recovery, but they overlook that the question specifically focuses on minimizing downtime after a failure, not preventing it.

QoS marking for classification and prioritization uses Layer 3 fields like DSCP or IP Precedence, not the source IP address. The source IP identifies the sender but does not carry QoS priority information.

Source port number is a transport-layer field used for identifying applications, but QoS marking for voice traffic is typically done at Layer 3 using DSCP (e.g., EF for voice), not by source port.

MAC addresses operate at Layer 2 and are not used for QoS marking in IP networks; QoS classification and prioritization rely on Layer 3 fields like DSCP or IP precedence.

If the question asked about filtering traffic from a specific host for QoS policing or shaping, the source IP address would be used to match packets from that host. For example, 'Which field is used to identify traffic from a particular subnet for bandwidth limiting?'

In a scenario where a firewall or router must prioritize traffic based on application type without relying on DSCP markings, source port number can be used to classify voice traffic (e.g., UDP port 5060 for SIP).

In a Layer 2 QoS scenario, such as configuring Class of Service (CoS) on a switch to prioritize traffic based on MAC addresses or VLAN tags, MAC address could be used for classification.

Candidates may think that since IP addresses are used in ACLs for traffic classification, they can also be used for QoS marking, but marking requires a dedicated field like DSCP, not the source IP itself.

Candidates may think source port numbers are used for QoS classification because they associate specific ports with voice protocols (e.g., SIP, RTP), but DSCP is the standard method for packet marking in QoS.

Candidates may confuse Layer 2 QoS mechanisms (like CoS) with Layer 3 QoS (DSCP), or think MAC addresses can be used for traffic prioritization because they are unique identifiers.

DNS resolves domain names to IP addresses, not IP addresses to MAC addresses. The question specifically asks for mapping an IP address to a MAC address on a local network, which is ARP's function.

DHCP is used to dynamically assign IP addresses and other network configuration parameters to devices, not to resolve IP addresses to MAC addresses. The resolution of IP to MAC addresses on a local network is performed by ARP.

ICMP is used for network diagnostics (e.g., ping, traceroute) and error reporting, not for resolving IP addresses to MAC addresses. The Address Resolution Protocol (ARP) is the correct protocol for this purpose.

DNS would be correct if the question asked: 'Which protocol is used to resolve a fully qualified domain name (e.g., www.example.com) to an IP address?' or 'Which protocol translates human-readable domain names into numerical IP addresses?'

A question asking 'Which protocol automatically assigns IP addresses to devices on a network?' would have DHCP as the correct answer. Also, 'Which protocol provides IP configuration including subnet mask and default gateway?' would be answered with DHCP.

ICMP would be correct for a question like: 'Which protocol is used to test reachability and measure round-trip time to a remote host?' or 'Which protocol is used by the ping command?'

Candidates often confuse 'resolution' tasks, assuming DNS handles all address resolution, or they misread the question as resolving a name to an IP rather than an IP to a MAC.

Candidates may confuse DHCP with ARP because both operate at the network layer and involve IP addresses, but they serve different purposes. The similarity in acronyms (both four-letter protocols) can also cause confusion.

Candidates may confuse ICMP with ARP because both operate at the network layer and are involved in local network communication, or they may mistakenly think ICMP handles address resolution due to its role in network diagnostics.

802.1X is a port-based network access control protocol used for authentication, not for tagging frames with VLAN information. It does not provide VLAN tagging capabilities.

802.11 is a wireless networking standard (Wi-Fi), not a protocol for tagging VLAN frames on Ethernet links between switches.

802.3 is an Ethernet standard that defines physical and data link layer specifications, but it does not include VLAN tagging. VLAN tagging is accomplished by 802.1Q, which inserts a VLAN tag into the Ethernet frame.

A network technician needs to implement secure access control on a switch port to authenticate devices before granting network access. Which protocol should be used?

When a question asks which standard defines wireless LAN communication, such as 'Which IEEE standard is used for Wi-Fi networks?'

A question asking which standard defines the basic frame format for Ethernet networks, such as 'Which IEEE standard specifies the frame format for wired Ethernet?' would have 802.3 as the correct answer.

Candidates may confuse 802.1X with 802.1Q due to similar numbering, or mistakenly think that access control involves VLAN tagging.

Candidates may confuse 802.11 with 802.1Q due to similar numbering, or mistakenly think VLAN tagging applies to wireless frames.

Candidates may confuse 802.3 with 802.1Q because both are IEEE standards related to Ethernet, and they might think that the base Ethernet standard includes VLAN tagging.

Routing packets across networks is a function of the network layer (Layer 3), not the transport layer (Layer 4). The transport layer provides end-to-end communication and flow control.

Encoding data into electrical signals is a function of the physical layer, not the transport layer. The transport layer handles end-to-end communication and flow control, not signal encoding.

Determining the best path for data transmission is a function of the network layer (Layer 3), not the transport layer (Layer 4). The transport layer focuses on end-to-end communication and flow control.

This option would be correct for a question asking: 'Which of the following best describes the primary function of the network layer in the OSI model?'

This option would be correct for a question like: 'Which OSI layer is responsible for converting data into bits for transmission over a physical medium?' In that context, the physical layer's encoding function is the answer.

This option would be correct for a question like: 'Which OSI layer is responsible for routing and path determination?' In that context, the network layer performs this function.

Candidates often confuse the transport layer with the network layer because both deal with data delivery, and 'routing' is a common networking term that seems related to 'transport'.

Candidates may confuse the transport layer with lower layers, especially if they think of 'transport' as moving data across the wire, which involves signal encoding.

Candidates often confuse the transport layer's role in managing data segments with the network layer's path selection, especially since both involve end-to-end delivery concepts.

Scheduling the upgrade during a maintenance window is important but should not be the first step; the firmware must first be tested in a lab to ensure compatibility and stability before any scheduling or user notification.

Backing up the current configuration is important but should occur after testing the firmware in a lab environment, as testing ensures the firmware is stable and compatible before any changes are made to production systems.

Notifying users of a planned outage is important but should occur after the firmware has been tested and validated in a lab environment to ensure the upgrade is safe and necessary.

If the question asked 'After testing the firmware in a lab and backing up configurations, what is the next step in the upgrade process?' then scheduling during a maintenance window would be the correct answer.

In a scenario where the firmware has already been tested and approved, and the question asks for the next step before applying the upgrade to production, backing up the current configuration would be the correct answer.

In a scenario where the firmware upgrade has already been tested and approved, and the question asks for the step to perform just before the actual upgrade, notifying users of the planned outage would be the correct answer.

Candidates often think of operational planning first, overlooking that validation of the firmware itself is a prerequisite to any scheduling or communication steps.

Candidates often prioritize data preservation and mistakenly think backing up is the first step in any change process, overlooking the critical need to validate the firmware first to avoid corrupting backups with untested code.

Candidates may think that user notification is a critical first step to minimize disruption, overlooking the prerequisite of testing to prevent potential issues.

The question states that the default route points to an unreachable next-hop IP, and the administrator can ping the ISP's gateway. This indicates a static route misconfiguration, not a redistribution issue. Redistribution would only matter if a dynamic routing protocol were involved, but the problem is with a static default route.

The WAN interface is up (as stated), so it is not administratively down. An administratively down interface would show as 'down' or 'disabled', not 'up'.

The firewall blocking traffic to the cloud would not cause the router to have an unreachable next-hop IP for the default route; it would instead prevent traffic from passing through the firewall, but the router would still have a valid route.

In a scenario where OSPF or EIGRP is used and the default route is not being advertised into the routing domain, causing remote routers to lack a default route. For example, a router has a static default route but redistribution from static into OSPF is missing, so other routers don't learn it.

A question where the edge router's WAN interface is down or disabled (e.g., 'interface status shows administratively down') and users cannot access remote resources, with no other routing issues mentioned.

In a scenario where users cannot access cloud applications, the router has a valid default route, and pinging the ISP gateway succeeds, but traffic is still blocked, the firewall could be the cause if it is dropping traffic to the cloud IPs.

Candidates may confuse a missing default route with a redistribution problem, especially if they've studied dynamic routing protocols. They might assume the default route should be learned via a routing protocol rather than being statically configured.

Candidates may confuse 'interface up' with 'interface operational' and assume a down interface is the cause, or they may overlook the explicit statement that the interface is up.

Candidates may think that any connectivity issue to cloud applications must be due to a firewall blocking traffic, overlooking that the problem is actually a routing issue indicated by the unreachable next-hop.

A network baseline documents performance metrics over time, not the logical relationships between devices or VLAN trunking.

A wiring diagram shows physical cable paths and connector pinouts, not logical relationships like VLAN trunking between switches.

A physical topology diagram shows the physical layout and connections of cables and devices, not logical relationships like VLAN trunking between switches.

When a question asks for a document that records normal network performance metrics (e.g., bandwidth utilization, latency) to compare against future anomalies, a network baseline is correct.

A wiring diagram would be correct if the question asked for a document detailing cable runs, patch panel connections, or physical wire routing for a new office installation.

When the question asks for a diagram that shows the physical location of devices, cable runs, and port connections for installation or troubleshooting physical connectivity.

Candidates may confuse 'baseline' with 'diagram' or think that documenting VLANs requires a baseline of traffic patterns.

Candidates may confuse 'wiring' with 'inter-switch links' and think a wiring diagram includes VLAN trunk information, but wiring diagrams focus on physical cabling, not logical data flow.

Candidates may confuse physical topology with logical topology, thinking that inter-switch links are physical connections, but the question specifically asks for logical relationships and VLAN trunking.

The question specifies a physical cabling issue, which is a Layer 1 (Physical layer) problem. The Transport layer (Layer 4) deals with end-to-end communication and data segmentation, not physical media.

The Data Link layer (Layer 2) handles framing, MAC addressing, and error detection, but not the physical cabling itself. The question specifically states the issue is related to physical cabling, which is Layer 1.

The Network layer (Layer 3) handles logical addressing and routing, not physical cabling issues. The administrator suspects a physical cabling problem, which is a Layer 1 concern.

A question about troubleshooting a connectivity issue where the problem is suspected to be related to port numbers, session multiplexing, or reliable data delivery (e.g., TCP vs UDP issues) would make the Transport layer the correct starting point.

A question asking where to investigate issues with MAC address conflicts, frame errors, or switch port configuration (e.g., duplex mismatch) would make the Data Link layer the correct starting point.

This option would be correct if the question asked about troubleshooting a routing issue, such as incorrect IP configuration or a routing table problem, where the investigation should start at the Network layer.

Candidates may confuse the OSI layers and think that all connectivity issues start at higher layers, or they may recall that the Transport layer is involved in end-to-end connectivity, but they overlook the specific mention of physical cabling.

Candidates may confuse the Data Link layer with physical cabling because it deals with network interfaces and media access control, or they might think troubleshooting always starts at Layer 2.

Candidates may confuse the Network layer with physical connectivity because they associate 'network' with all networking hardware, or they may think IP addressing is involved in cable troubleshooting.

The user can access the internet but not the internal web app, and nslookup returns 'Non-existent domain', indicating a DNS resolution failure. The web server being down on port 443 would not cause a DNS lookup to fail; it would cause a connection timeout or refusal after successful resolution.

The technician can ping the server's IP address successfully, indicating that network connectivity and firewall rules are not blocking traffic to the server. The issue is DNS resolution, not firewall filtering.

The user can access the internet and ping the server IP, but nslookup returns 'Non-existent domain', indicating a DNS resolution failure, not a browser misspelling. A misspelling would still result in a DNS query, not a 'Non-existent domain' error.

A user reports being unable to access an internal HTTPS website, but nslookup resolves the hostname correctly. The technician can ping the server IP, and telnet to port 443 fails. In this scenario, the web server not running on port 443 would be the correct answer.

A user cannot access an internal web application, and pinging the server's IP address fails. A firewall rule blocking the specific port (e.g., 443) would be the likely cause, especially if other services on the server are reachable.

In a scenario where a user reports being unable to access a website, but nslookup resolves correctly and the server is reachable, the most likely cause could be a typo in the browser's address bar. For example, if the user typed 'intranet.company,local' instead of 'intranet.company.local'.

Candidates may think that since HTTPS uses port 443, a port issue is a common cause of web access problems, and they overlook the DNS failure evidence provided in the question.

Candidates often assume that any connectivity issue to a web server is due to a firewall, overlooking that successful ping to the IP proves basic network access is allowed.

Candidates may assume that a simple typo is the easiest explanation for a web access issue, overlooking the DNS error message that clearly indicates the hostname cannot be resolved at all.