Network Engineer Pre-Employment Quiz: Assess Your Technical Expertise

When switching to a new switch and DHCP fails across devices, the absence of DHCP relay configuration is most often the cause. In multi-subnet or VLAN environments, DHCP relays forward client requests to the DHCP server. Without it, broadcasts don’t reach the server, and clients get no IP. Broadcast saturation, gateway changes, or ARP settings wouldn’t cause full DHCP failure across the board. DHCP relay being overlooked in reconfiguration is a critical but common oversight.

Duplicate IP errors usually arise when two machines have the same static IP, causing ARP conflicts. DHCP typically avoids this unless misconfigured, and full ARP tables wouldn’t show this specific error. IPv6 doesn't conflict with IPv4 since they operate on separate stacks. Manual static settings being duplicated—often by mistake or poor documentation—is the most common scenario leading to this log alert. That’s why this answer stands out as the most accurate.

If devices can’t reach the web and the router config was just changed, the most likely issue is a missing default gateway. The default gateway is what directs outbound traffic to external networks. If this is blank or incorrectly set, all web-bound traffic gets lost locally. While IP and DNS settings are relevant, without a valid gateway, even accurate IP addresses can’t get out. The firewall is a plausible issue but would likely block selectively, not universally. Hence, the correct answer is “Default gateway is missing.”

When VLANs can't communicate, it’s often because the trunk port between switches or routers isn’t correctly set up. A trunk port allows tagged traffic from multiple VLANs to traverse a single link, which is critical for inter-VLAN routing. If it’s not configured, the VLANs are isolated, even if routing exists elsewhere. Unsupported switches or DNS have no bearing here. Dynamic routing doesn’t apply unless already enabled between VLANs, and even then, without a trunk, it’s useless. So, trunk misconfiguration is the root issue.

DNS queries being delayed or timing out commonly point to server overload. When the server can’t handle the request volume or has high CPU/memory usage, response times suffer. DNS recursion, port blocking, or TTL settings would result in different failure symptoms—like immediate failure or limited resolution. Slow performance almost always means the DNS server is operational but overwhelmed. This makes “DNS server overloaded” the clearest and most direct root cause for the slowdown.

When a router loses configuration after reboot, it’s typically because the changes weren’t saved to startup config. In most devices (like Cisco), you must manually write the running configuration to non-volatile memory. Otherwise, it reverts to its previous saved state. Flash corruption or firmware issues would manifest differently—like complete boot failure or erratic behavior. Forgetting to save changes is a simple but frequent human error, and it matches the issue described exactly.

A Wi-Fi connection showing “No Internet” often points to DHCP issues. When a lease expires and isn’t renewed, devices keep a local IP or fall back to an APIPA address (169.x.x.x), leading to connection without true access. DNS cache and subnet mask issues typically cause resolution or routing errors, but wouldn’t fully cut off internet access. A captive portal can cause delays, but usually redirects rather than outright blocks connectivity. Therefore, a DHCP lease expiration is the most common culprit.

Destination Host Unreachable is a local device error, meaning it cannot find a route to the destination. The most probable reason is that the local interface is down or misconfigured. Unlike a “Request Timed Out” error which suggests a remote issue, this one suggests something wrong with the source. ICMP or NAT issues can affect ping responses but wouldn’t throw this specific error. Similarly, a wrong route could cause misdirection but not this host-level failure. Hence, the correct issue lies with the local network interface.

A traceroute failing after three hops often points to ICMP being blocked beyond a certain network boundary. Traceroute works by sending packets with gradually increasing TTL values, expecting ICMP time-exceeded responses. If an intermediate router or firewall is configured to ignore these, the path goes dark. DNS failure would block resolution entirely, not just partial hops. Packet loss would make the trace intermittent, not consistently cut off. Thus, ICMP blocking is the logical explanation.

When a VPN connects but internal resources are unreachable, split tunneling is the usual suspect. If split tunneling is misconfigured, the traffic meant for internal IPs may be routed through the public internet instead, causing the internal servers to appear unreachable. Subnet or DNS issues may play a role but wouldn't affect a working tunnel’s routing logic. Port forwarding applies more to NAT, not remote internal access. So, the routing misdirection caused by poor split tunneling setup is the real issue.