DHCP practice questions

Check the DHCP server logs to see if it is receiving Discover messages.

Why wrong: Checking the DHCP server logs for Discover messages is premature in this scenario. Because the DHCP server resides on a different subnet than the clients, server-side logs will only show Discover packets if the router's VLAN 20 interface has an IP helper-address configured to forward broadcast DHCP requests. If the helper-address is missing, the router drops the broadcast at the VLAN boundary, and the server never sees any Discover traffic—so the absence of such messages in the logs would merely confirm the relay misconfiguration, not diagnose it. This step is valid only after confirming that the relay configuration is correct, and it wastes troubleshooting time by skipping the most fundamental cause.

Attempt to ping the DHCP server's IP address from the host's APIPA address.

Why wrong: The host's APIPA address (169.254.x.x) is a link-local address. Without a default gateway or a routable IP, pinging an address on a different subnet will not work, even if the DHCP server is reachable. This test does not confirm DHCP functionality and is not a standard troubleshooting step for DHCP failures.

Restart the DHCP service on the server and recheck the host.

Why wrong: Restarting the DHCP service is a disruptive action and should not be the first step, especially when the root cause likely lies in the network configuration (missing relay). It does not address the underlying issue and may cause unnecessary downtime.

The default gateway must be removed from the DHCP scope.

Why wrong: Removing the default gateway from the DHCP scope would eliminate the router as the next hop, breaking all off-subnet communication. The problem is isolated to hostname resolution while IP connectivity succeeds, so a missing gateway would cause total network failure, not just DNS failure. Therefore, the default gateway must remain in the scope and cannot be the cause.

The clients must use PPP before DNS works.

Why wrong: PPP (Point-to-Point Protocol) is a WAN data-link encapsulation used on serial or DSL links, not a service required for DNS on an Ethernet LAN. DNS resolution operates over IP and is independent of the data-link protocol; clients do not need PPP to send DNS queries. This option incorrectly conflates a WAN technology with local DHCP operation and is unrelated to the VLAN 70 issue.

The VLAN must be converted to the native VLAN on all trunks.

Why wrong: The native VLAN in 802.1Q trunks carries untagged frames; changing VLAN 70 to native would affect trunk tagging and could cause broadcast or misdelivery issues. However, the symptom is specifically that clients reach services by IP but not by hostname, indicating a DNS problem, not a Layer 2 forwarding issue. If the native VLAN were misconfigured, general connectivity would fail, not just name resolution.

DNS: Assigns IP addresses dynamically to devices on a network

Why wrong: Dynamic IP assignment is the job of DHCP (Dynamic Host Configuration Protocol), which leases IP addresses, subnet masks, default gateways, and other parameters to clients for a set duration. DNS is a peer-to-peer name-resolution service that stores resource records; it has no mechanism for leasing or reclaiming IP addresses. So, attributing dynamic address assignment to DNS is incorrect because that service belongs exclusively to DHCP.

DNS: Synchronizes time across network devices

Why wrong: Precise time synchronization across network devices is handled by NTP (Network Time Protocol), which distributes Coordinated Universal Time (UTC) to maintain accurate clocks for log correlation, authentication, and timestamping. DNS handles only name-to-address (and related) queries, and it has no protocol operations for reading or setting device clocks. Therefore, DNS cannot serve as a time-synchronization protocol.

DNS: Manages and monitors network devices

Why wrong: Managing and monitoring network devices—such as polling CPU, memory, interface status, and generating alerts—is the function of SNMP (Simple Network Management Protocol), whose managed objects are defined in MIBs. DNS is strictly a resolution service that translates names to IP addresses as part of application-layer lookups; it does not collect device metrics or perform management operations. Describing DNS as a network management protocol is inaccurate because that role belongs to SNMP.

Change the AP from Ethernet to PPP encapsulation.

Why wrong: PPP (Point-to-Point Protocol) is a WAN encapsulation used on serial or dial-up links, not on Ethernet LAN segments where access points typically connect. Changing the AP's encapsulation to PPP would not affect CAPWAP, which runs over UDP/IP and expects Ethernet framing on the local LAN. The exhibit gives no indication of a serial link or PPP requirement, so this action is unrelated to the AP's inability to join the controller.

Remove the AP IP address so it can obtain an IP address automatically via DHCP.

Why wrong: Removing the static IP and switching to DHCP does not address the root cause because the problem is a layer 3 reachability misconfiguration, not the method of address assignment. If the DHCP scope also provides the same incorrect default gateway, the AP will obtain a valid address but still be unable to reach the controller. Even a dynamically assigned address requires a correct gateway to forward CAPWAP traffic; the static IP itself is not preventing the AP from joining.

Disable DHCP on the controller for all APs.

Why wrong: Disabling DHCP on the controller globally is incorrect because the exhibit indicates that the problem is specific to this AP's default gateway, and other APs are already joining successfully. Such a global change would disrupt DHCP-based provisioning for all access points, including the healthy ones, without correcting the faulty gateway on the problematic AP. The issue lies in the AP's local IP routing configuration, not in the controller's DHCP service.

The SSID broadcast setting, because the client must not be joined correctly.

Why wrong: The SSID broadcast setting only controls whether the network name appears in probe responses, not whether an already-associated client can send or receive traffic. Because the client successfully joined and pulled an address from the correct subnet, it is not a join failure. If broadcast were disabled, the client would still be able to connect if it manually knew the SSID, and would not explain an application-specific issue.

The voice VLAN on the wired access port connected to the AP uplink.

Why wrong: The voice VLAN on the wired access port is used to separate VoIP traffic from data traffic on the wired infrastructure, and it does not affect how a wireless client forwards traffic after joining a WLAN. A client that has already received an address from the correct subnet is clearly operating on the data VLAN, not the voice VLAN, and general employee access works correctly. Since the problem is restricted to one application, changing the voice VLAN setting on the AP uplink would have no bearing on this scenario.

The OSPF router ID on the client device.

Why wrong: OSPF router IDs are used by routers participating in OSPF to identify themselves in link-state advertisements; end-client devices such as laptops or phones do not run OSPF and never exchange routing protocol information with the network. A client's network stack obtains an address via DHCP and uses a default gateway for off-subnet traffic, so OSPF router ID is irrelevant. The application-specific failure cannot be caused by a parameter that does not exist on the client device.

1. Enable DHCP relay on the VLAN 20 interface. 2. Configure the DHCP pool for VLAN 10. 3. Exclude addresses from the pool. 4. Verify DHCP operations.

Why wrong: This is incorrect because DHCP relay should be configured after the DHCP server pool is set up. Enabling relay before the server is ready may cause clients to send requests that cannot be answered.

1. Exclude addresses from the pool. 2. Enable DHCP relay on the VLAN 20 interface. 3. Configure the DHCP pool for VLAN 10. 4. Verify DHCP operations.

Why wrong: This is incorrect because the DHCP pool must be created before excluding addresses. Exclusions are part of the pool configuration and cannot be applied before the pool exists.

1. Configure the DHCP pool for VLAN 10. 2. Enable DHCP relay on the VLAN 20 interface. 3. Exclude addresses from the pool. 4. Verify DHCP operations.

Why wrong: This is incorrect because exclusions should be configured before enabling relay. Although the pool is created first, exclusions are part of the pool configuration and should be done before moving to relay.

Configure a default gateway on PC-A with the IP address 192.168.10.1.

Why wrong: This is incorrect because PC-A has an APIPA address (169.254.23.45), which indicates it did not receive a DHCP lease. Manually setting a default gateway does not resolve the underlying issue of DHCP failure. The PC must first obtain a valid IP address via DHCP before a default gateway can be used.

Change the VLAN on SW1's interface connected to PC-A from VLAN 10 to VLAN 1.

Why wrong: This is incorrect because PC-A is configured for VLAN 10, and the DHCP pool is on subnet 192.168.10.0/24, which is associated with VLAN 10. Changing to VLAN 1 would place PC-A in a different subnet, preventing it from receiving a DHCP lease from R1's pool. The VLAN configuration is correct as is.

Add the 'ip helper-address' command on R1's interface connected to SW1.

Why wrong: This is incorrect because the DHCP server is on R1 itself, not on a remote server. The 'ip helper-address' command is used to forward DHCP broadcasts to a DHCP server on a different subnet. Since R1 is the DHCP server, no helper address is needed; the router will respond to DHCP requests on its directly connected interface.

On R1, change the helper-address to 192.168.10.255 and the excluded-address range to 192.168.10.1 192.168.10.10. On SW1, enable DHCP snooping globally and for VLAN 10, and set all ports as trusted.

Why wrong: This is incorrect because the helper-address should be the DHCP server's IP (192.168.10.1), not the broadcast address (192.168.10.255). Also, setting all ports as trusted defeats the purpose of DHCP snooping, as it would allow rogue servers on any port.

On R1, change the helper-address to 192.168.10.1 and the excluded-address range to 192.168.10.1 192.168.10.254. On SW1, enable DHCP snooping globally and for VLAN 10, and set interface G0/1 as untrusted.

Why wrong: This is incorrect because the excluded-address range excludes almost all addresses (192.168.10.1 through 192.168.10.254), leaving only the broadcast address for clients, which is not usable. Also, the port facing the DHCP server (R1) must be trusted, not untrusted.

On R1, change the helper-address to 192.168.10.1 and the excluded-address range to 192.168.10.1 192.168.10.10. On SW1, enable DHCP snooping globally and for VLAN 10, and set interface G0/1 as untrusted.

Why wrong: This is incorrect because the port facing the DHCP server (R1) must be trusted. Setting it as untrusted would cause DHCP snooping to drop DHCP server messages (OFFER, ACK) from R1, preventing clients from obtaining IP addresses.

Another DHCP scope

Why wrong: A DHCP scope is a pool of IP addresses that a server hands out to clients; it controls address assignment, not traffic measurement. Adding another scope would only expand the number of leases available, and while it might indirectly change addressing, it would not reveal which applications or conversations fill the interface. The 'high utilization' observed via SNMP therefore remains an unexplained aggregate number, not a conversation detail.

A new STP priority

Why wrong: STP priority is a spanning-tree election value that determines which switch becomes the root and which redundant paths are placed in blocking state. Reconfiguring it can move traffic to a different physical path, but it offers zero visibility into existing flows. The administrator needs a flow-based telemetry source, not a topology-control parameter, to see the specific traffic causing high utilization.

A larger OSPF metric

Why wrong: OSPF metric (cost) is a routing parameter that influences shortest-path selection, not a tool for inspecting live traffic. Even with a larger metric on an interface, the administrator would only see route changes, never which source/destination pairs are consuming the interface's bandwidth. SNMP utilization counters are aggregate, so OSPF tuning cannot break down the utilization by conversation.

The DHCP pool is misconfigured: the excluded-address range should be 192.168.50.1 192.168.50.9, but the helper-address on GigabitEthernet0/0 is correct because it forwards DHCP requests to the remote server. The relay agent configuration is missing on GigabitEthernet0/1.

Why wrong: This is incorrect because the helper-address on GigabitEthernet0/0 is not needed; R1 is the DHCP server for that subnet, so broadcasts should not be forwarded elsewhere. Adding a helper-address would cause DHCP requests to be forwarded to the remote server unnecessarily.

The DHCP pool is correctly configured with excluded-address 192.168.50.1 192.168.50.9. The issue is that the 'ip helper-address' on GigabitEthernet0/1 is missing; it should be added to forward requests to the remote server. Additionally, the 'ip helper-address' on GigabitEthernet0/0 is correct because it forwards requests from VLAN 50 to the remote server.

Why wrong: This is incorrect because the excluded-address range is correct, but the helper-address on GigabitEthernet0/0 is still unnecessary and should be removed. The problem statement says clients on VLAN 50 are not receiving addresses, which is due to the excluded-address covering the entire pool, not the helper-address on G0/0.

The DHCP pool is misconfigured: the excluded-address range should be 192.168.50.1 192.168.50.9. The 'ip helper-address' on GigabitEthernet0/0 should be removed. The relay agent configuration is correct because 'ip helper-address 203.0.113.10' is already configured on GigabitEthernet0/1.

Why wrong: This is incorrect because the relay agent configuration is missing; the helper-address on GigabitEthernet0/1 is not present. The option claims it is already configured, but the problem states that the relay agent configuration is missing.

interface GigabitEthernet0/0.10 encapsulation dot1Q 10 ip helper-address 192.168.10.100

Why wrong: This places the helper-address on the VLAN 10 subinterface, which does not help VLAN 20 hosts because broadcasts from VLAN 20 are not received on this interface.

interface GigabitEthernet0/0.20 encapsulation dot1Q 20 ip dhcp relay information option

Why wrong: The ip dhcp relay information option command adds DHCP option 82 information but does not forward broadcasts to a specific server; it is not a substitute for ip helper-address.

ip dhcp pool VLAN20 network 192.168.20.0 255.255.255.0 default-router 192.168.20.1

Why wrong: This configures R1 as a DHCP server for VLAN 20, but the requirement is to forward broadcasts to an existing server, not to have R1 act as a server.

Remove the 'ip dhcp excluded-address 192.168.1.1 192.168.1.10' command because it excludes too many addresses.

Why wrong: This is incorrect because excluding 10 addresses from a /24 subnet (254 usable addresses) is not excessive. The exclusion is necessary to reserve addresses for static devices like the router interface. The APIPA issue is not caused by this exclusion.

Change the DHCP pool network to 192.168.1.0/24 and add the default-router 192.168.1.1 command.

Why wrong: This change is unnecessary and would not resolve the problem because the DHCP pool on R1 already contains the correct 'network 192.168.1.0 255.255.255.0' and 'default-router 192.168.1.1' statements. The configuration as written is valid and would lease addresses properly if the DHCP service were enabled. Simply rewriting or re-adding these commands does nothing to activate the router's DHCP server engine, which is disabled by default and requires the 'service dhcp' global command. Without that global enable, the client will continue receiving no DHCP replies and will fall back to an APIPA address.

Configure the 'ip helper-address' command on the client's VLAN interface to forward DHCP requests to the server.

Why wrong: This is incorrect because the DHCP server is on the same router (R1) as the client's subnet. The 'ip helper-address' command is used to forward DHCP broadcasts to a remote server, which is unnecessary here. The client and server are on the same device.

DHCP is used primarily to translate private addresses into public addresses.

Why wrong: DHCP is not designed for address translation between private and public address spaces; that function belongs to Network Address Translation (NAT), typically implemented on routers or firewalls. DHCP's role is limited to dynamically assigning IP configuration—such as IP address, subnet mask, default gateway, and DNS servers—to hosts within a local network. While DHCP may work alongside NAT in many enterprise environments, conflating the two misidentifies their distinct purposes, as DHCP does not modify or translate IP headers.

DHCP replaces the need for subnet masks and default gateways.

Why wrong: DHCP does not eliminate the need for subnet masks and default gateways; rather, it automates the delivery of these essential parameters to clients. A subnet mask is still required to determine the network and host portions of an IP address, and a default gateway is essential for routing traffic outside the local subnet. Without these values, a client would be unable to determine which destinations are local or how to reach remote networks—DHCP simply distributes them automatically, saving administrators from manual configuration and reducing errors.

DNS and DHCP are both Layer 1 technologies.

Why wrong: DNS and DHCP operate at the application layer (Layer 7) of the OSI model, not at Layer 1. Layer 1 is the physical layer, which involves the transmission and reception of raw bit streams over physical media like cables, fiber, or radio waves. In contrast, DNS and DHCP use higher-layer protocols—DNS primarily uses UDP port 53 or TCP port 53, while DHCP uses UDP ports 67 and 68—and depend on Layer 3 (IP) and Layer 4 (UDP/TCP) services for their operation, making them clearly not Layer 1 technologies.

Enable DHCP snooping globally and on VLAN 20, configure interface G0/1 as trusted, and change the ip helper-address on the SVI for VLAN 20 from 10.0.0.3 to 10.0.0.2.

Why wrong: This is incorrect because the access port (G0/1) should remain untrusted, not trusted. Trusting the access port would allow rogue DHCP servers connected to that port to send replies, defeating the purpose of DHCP snooping.

Enable DHCP snooping globally and on VLAN 20, configure interface G0/0 as trusted, and keep the ip helper-address as 10.0.0.3 because that is the correct server address.

Why wrong: Although trusting the uplink G0/0 is correct, the ip helper-address remains incorrectly set to 10.0.0.3. The DHCP server actually resides at 10.0.0.2, so the relay agent will forward client broadcasts to the wrong destination, and no DHCP replies will return. The command 'ip helper-address' must point to the real server IP; otherwise DHCP snooping alone does not fix the broken relay path.

Enable DHCP snooping globally and on VLAN 20, configure both interfaces G0/0 and G0/1 as trusted, and change the ip helper-address on the SVI for VLAN 20 from 10.0.0.3 to 10.0.0.2.

Why wrong: Configuring both G0/0 and G0/1 as trusted completely undermines DHCP snooping's security model. The access port G0/1 is the attachment point for end users, and a rogue DHCP server there would be allowed to send replies if trusted. Only the uplink G0/0 to the legitimate DHCP server should be trusted; all other ports should remain untrusted to filter unauthorized DHCP traffic.

Syslog is used to assign IP addresses dynamically to endpoints

Why wrong: Dynamic IP address assignment is performed by DHCP, which leases addresses from a configured pool and delivers client options like subnet mask and gateway, not by syslog. Syslog is purely an observability protocol used to forward log messages, and it has no mechanism or role in network address allocation, so this option incorrectly conflates a logging service with DHCP.

Syslog entries replace SNMP counters for interface statistics

Why wrong: Syslog is event-driven and reports discrete occurrences such as interface errors or configuration changes, while SNMP continuously tracks cumulative counters like bytes transmitted, packets dropped, and CRC errors from the MIB. These serve different purposes: SNMP provides quantitative traffic statistics for capacity planning and performance monitoring, whereas syslog delivers qualitative event notifications, so syslog cannot substitute for SNMP counters.

DNS

Why wrong: DNS (Domain Name System) resolves human-friendly hostnames such as example.com to numeric IP addresses through a hierarchical lookup process using UDP/TCP port 53. DNS servers are often assigned via DHCP, but DNS itself does not lease or allocate IP addresses to clients. A host must already have an IP address to query DNS, so it cannot hand out addressing.

NTP

Why wrong: NTP (Network Time Protocol) synchronizes clock time across network devices using UDP port 123, aligning timestamps for logs, authentication, and troubleshooting. It does not distribute any IP addressing or host configuration parameters; its sole function is time synchronization. Therefore, NTP cannot provide clients with IP addresses, subnet masks, or gateways.

TACACS+

Why wrong: TACACS+ (Terminal Access Controller Access-Control System Plus) is a Cisco AAA protocol that manages authentication, authorization, and accounting for administrative access to network devices over TCP port 49. It controls which administrators can log in and what commands they can run, but it is unrelated to client endpoint addressing. Hence, TACACS+ cannot assign IP parameters to hosts.

It is configured on the DHCP server interface to allow replies to reach clients on remote subnets.

Why wrong: The ip helper-address is configured on the router interface facing the clients, not on the server.

It automatically forwards all UDP broadcasts by default.

Why wrong: By default, only DHCP and a few other UDP services (like TFTP, DNS, and Time) are forwarded. Not all UDP broadcasts.

It prevents DHCP spoofing by validating the source MAC address of DHCP packets.

Why wrong: This describes DHCP snooping, not the ip helper-address command.

DNS automatically assigns IP addresses to hosts.

Why wrong: This is wrong because DHCP assigns IP configuration.

DNS replaces the need for subnet masks.

Why wrong: This is wrong because subnet masks still define address scope.

DNS elects the STP root bridge.

Why wrong: This is wrong because DNS and STP are unrelated.