A wired laptop has a 169.254 address. What would you investigate?

Instruction: Interpret the supplied evidence, explain the next comparison you would make, and describe a safe recovery attempt and verification. Separate a DHCP delivery problem from proof that a server has failed.

Context:

A Windows 11 laptop lost wired access after moving desks. Wi-Fi is off. The network normally assigns addresses automatically. These are fictional, shortened observations:

Get-NetAdapter: Ethernet | Status: Up
ipconfig /all, Ethernet:
  DHCP Enabled: Yes
  Autoconfiguration IPv4 Address: 169.254.23.51
  Subnet Mask: 255.255.0.0
  Default Gateway: (blank)
Neighboring managed PC: 10.24.6.34; gateway 10.24.6.1

The neighboring PC can open the internal portal. You may inspect the laptop and test an approved spare cable, but you cannot administer switches or DHCP servers.

Updated

Example Answer

I'd explain that the laptop has assigned itself a link-local address instead of receiving the expected DHCP configuration. That fits its lack of normal routed access, but it does not prove the DHCP server is down. The working neighbor narrows the scope without proving this desk has the same network configuration.

I'd confirm the affected adapter and record the time and configuration before changing anything. Then I'd check the cable seating and wall-port label, and compare this laptop on an approved known-working connection. Link Up only establishes a physical connection. If the laptop obtains a normal lease there, I'd send the original port details to networking for its VLAN, access-control, or DHCP path checks. If it fails there too, I'd investigate its adapter and DHCP client state.

With the user's agreement and the runbook's authority, I'd try the spare cable and one adapter-specific lease renewal after those checks, preserving the result. I would not guess a static address. I'd verify the expected address, gateway, name resolution, and the user's portal task. If it still fails, my escalation would include the comparisons and renewal error, with unnecessary identifiers removed.

What the interviewer is assessing

Essential: Recognize APIPA as evidence of missing expected DHCP configuration, and distinguish physical link from usable network access.

Stronger: Use the neighboring device and approved connection comparison to choose a client or network escalation; define application-level verification.

Red flags: Declare the DHCP server down, assign a guessed static address, or repeatedly reset every adapter.

Follow-up

Would you start with ipconfig /release on every adapter?

No. I would preserve the current evidence and target the affected adapter under the runbook. Releasing all leases can disrupt otherwise working connections, including a remote support session, without identifying why this desk failed.

Related Questions