350-401 Network Assurance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Discover, then Offer, then Request, then Acknowledge

  Why this is correct

  This is the correct order because the client first broadcasts a Discover message, the server responds with an Offer, the client then sends a Request to formally ask for the offered IP, and the server finalizes with an Acknowledge message.

• ✗

  Discover, then Request, then Offer, then Acknowledge

  Why it's wrong here

  In the DHCP DORA process, the client cannot issue a DHCPREQUEST before receiving a DHCPOFFER because the Request is specifically the client's acceptance of an offered IP address and is only meaningful after an Offer has been made. If the client sends a Request first, it would lack the Server Identifier option and the offered IP address that the server provides in the Offer, leaving the server without the context needed to transition to the next state. The server, on receiving an unexpected Request, may silently discard it or wait for the proper Discover, causing the handshake to fail. Thus, the correct state machine mandates that the Offer always precedes the Request in the initial lease acquisition.

• ✗

  Offer, then Discover, then Request, then Acknowledge

  Why it's wrong here

  This sequence is invalid because the DHCP server cannot generate a DHCPOFFER spontaneously; it must first receive a DHCPDISCOVER broadcast from the client. The Discover message carries the client's hardware address, transaction ID, and optionally the requested parameters that the server uses to construct a valid Offer, so without that discovery the server has no basis to allocate an IP. Additionally, the DHCP protocol is client-initiated: since the client may have no IP address at startup, it broadcasts Discover to locate servers, and the server's Offer is a response to that broadcast. Starting with the Offer reverses the client-server interaction and violates the protocol's dependency on the client's broadcast.

• ✗

  Discover, then Offer, then Acknowledge, then Request

  Why it's wrong here

  In this ordering, the server sends a DHCPACK before receiving the DHCPREQUEST, which is premature and incorrect because the ACK is the server's final confirmation of the lease after the client has formally accepted the offered IP. The DHCPREQUEST packet is the client's explicit acceptance and also informs all other DHCP servers that it has chosen one offer, thereby preventing IP conflicts from multiple servers offering overlapping addresses. Without receiving that Request, the server would be acknowledging a lease the client has not accepted, potentially leading to an unrequested reservation and confusion in the client's state. The protocol therefore requires the order Discover -> Offer -> Request -> Acknowledge to ensure the client's acceptance precedes the server's final validation.

Go deeper

Related to this question