Question 727 of 1,389
CCNA Network Services and Security Practice Question
Exhibit
R1# show ip dhcp pool Pool LAN-POOL : Utilization mark (high/low) : 100 / 0 Subnet size (first/next) : 0 / 0 Total addresses : 254 Leased addresses : 253 Excluded addresses : 0 Pending events : 0 Subnet : 192.168.1.0/24 Current bindings : 253 Lease expiration : 7 days 0 hours 0 minutes Automatic bindings : 253 Manual bindings : 0 Conflict reservations : 0
Refer to the exhibit. A network administrator notices that newly connected devices on the 192.168.1.0/24 subnet are failing to obtain IP addresses via DHCP and are instead assigning themselves APIPA addresses. The administrator issues the show ip dhcp pool command on the router and receives the output shown. What is the most likely cause of this issue?
⚠ Common exam trap
Cisco often tests the concept that a long lease time can exhaust a DHCP pool even if the subnet is large, tricking candidates into thinking the issue is a subnet mask mismatch or a security feature like DHCP snooping.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The lease time is set to 7 days, causing old devices to hold IP addresses long after disconnecting.
A 7-day lease time means that IP addresses assigned to devices are held for a full week, even after those devices disconnect from the network. If the subnet is small (e.g., 192.168.1.0/24 provides 254 usable addresses) and many devices have come and gone, the DHCP pool can become exhausted, leaving no available addresses for new devices. When DHCP fails, clients fall back to APIPA (169.254.x.x) addresses per RFC 3927.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
DHCP snooping is blocking DHCP Offer messages on the VLAN.
Why it's wrong here
DHCP snooping is a security feature that filters DHCP messages on untrusted ports, but the provided output shows no signs of filtering—there are no dropped-packet counters or snooping-related statistics referenced. If snooping were blocking DHCP Offer messages, clients would not receive offers and the pool would remain relatively empty, not fully allocated. Here, the pool shows 253 active bindings out of 254, indicating addresses are being handed out normally; the problem is that all addresses are reserved. The exhibit focuses on pool usage and lease timing, not on Layer 2 security filtering, so DHCP snooping is not the cause.
- ✗
The DHCP pool has an address conflict, causing all addresses to be marked as ineligible.
Why it's wrong here
An address conflict would appear in the output as a nonzero value in the 'Conflict reservations' counter, but the exhibit explicitly lists 'Conflict reservations: 0'. Additionally, a conflict would mark only the conflicting address as ineligible, not the entire pool, and certainly would not result in 253 bindings. The pool is not suffering from conflicts; it is simply at maximum capacity because every free address is actively leased or reserved. The data clearly shows normal DHCP address assignment, not a state where addresses are unavailable due to conflicts.
- ✓
The lease time is set to 7 days, causing old devices to hold IP addresses long after disconnecting.
Why this is correct
The lease time is set to 7 days, and this long lease duration is why the pool remains exhausted even if some of the 253 bound clients have disconnected. DHCP does not reclaim an address when a client goes offline; it only frees the address when the lease expires or the client explicitly releases it. With a 7-day lease, any device that disconnects ahead of expiration still holds its IP address for up to a full week, starving new clients that request an address during that window. This matches the exhibit: 254 total addresses, 253 currently bound, and a 'Lease expiration' of 7 days.
- ✗
The pool's subnet mask is incorrectly configured as /24 instead of /25, limiting available addresses.
Why it's wrong here
The 'Total addresses: 254' shown in the output is exactly the usable host count for a /24 subnet (256 minus the network and broadcast addresses). If the mask were incorrectly set to /25, the pool would contain only 126 usable addresses, which contradicts the displayed total. Thus, the subnet mask is not limiting the pool; it is configured correctly as /24. Changing to /25 would halve the available addresses and worsen the exhaustion problem, so this cannot be the root cause.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓The lease time is set to 7 days, causing old devices to hold IP addresses long after disconnecting.Correct answer▾
Why this is correct
The lease time is set to 7 days, and this long lease duration is why the pool remains exhausted even if some of the 253 bound clients have disconnected. DHCP does not reclaim an address when a client goes offline; it only frees the address when the lease expires or the client explicitly releases it. With a 7-day lease, any device that disconnects ahead of expiration still holds its IP address for up to a full week, starving new clients that request an address during that window. This matches the exhibit: 254 total addresses, 253 currently bound, and a 'Lease expiration' of 7 days.
✗DHCP snooping is blocking DHCP Offer messages on the VLAN.Wrong answer — click to see why▾
Why this is wrong here
Candidates often prematurely blame security features when DHCP fails, ignoring the pool statistics right in front of them.
✗The DHCP pool has an address conflict, causing all addresses to be marked as ineligible.Wrong answer — click to see why▾
Why this is wrong here
A common mistake is assuming that conflicts always fill up a pool, but the zero value directly disproves this.
✗The pool's subnet mask is incorrectly configured as /24 instead of /25, limiting available addresses.Wrong answer — click to see why▾
Why this is wrong here
Misunderstanding subnet sizing often leads candidates to blame the mask, but the exhibit confirms the mask is appropriate for the pool size.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jul 4, 2026
This 200-301 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-301 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.