Server+ PBQ Lab: Multi-VLAN DHCP, DNS, and Routing Outage

The correct remediation is to restore the VLAN 40 DHCP relay on the L3 switch so client DHCP broadcasts are forwarded to the central DHCP server, confirm the VLAN 40 DHCP scope options are still valid, and then save the running configuration to startup configuration. The APIPA address on the affected workstation proves the client is not receiving a DHCP lease at all. Since the DHCP service and scope are healthy, and other VLANs can lease addresses normally, the root cause is not a global DHCP failure or scope exhaustion. The relay/helper configuration is the missing link between the isolated client VLAN and the centralized DHCP server. Saving the L3 configuration matters because a live fix that is not written to startup configuration can disappear after a switch reload.

The correct answer also fixes APP-SRV-04 by changing its default gateway to the SVI for its current VLAN. The server has a valid static IP address and can communicate locally, which means its NIC is not completely broken and the VLAN is not entirely unavailable. Its failure to reach routed services points to a routing problem, and the stale gateway left over from the server move explains why same-subnet communication works while cross-VLAN access fails. Changing unrelated settings such as DNS suffixes, restarting the server, or assigning public gateway information would either fail to solve the routing problem or create a worse configuration.

The DNS portion is intentionally subtle. Basic DNS lookups can succeed because UDP 53 is allowed, so this is not a total DNS outage. The failure appears when the application repository validation triggers a larger DNS response or TCP fallback, and TCP 53 is blocked between the application server VLAN and the internal DNS servers. The clean fix is not to open broad access or declare the repository broken; it is to add a scoped firewall rule allowing TCP 53 only from the application server subnet or object group to the approved internal DNS servers. That restores the required DNS behavior while preserving least privilege.

The DHCP/DNS restart answer is wrong because it treats the symptoms as failed services rather than failed network paths and configuration boundaries. Restarting DHCP or DNS does not restore a missing VLAN relay, does not correct the moved server’s default gateway, and does not allow TCP DNS fallback through the firewall. Expanding the DHCP pool and enabling a reverse lookup zone are also distractions: the scope is not exhausted, and reverse DNS is not the cause of APIPA or repository validation failure.

The static-client answer is wrong because it bypasses the DHCP problem instead of fixing it. Giving OPS-WS-17 a static address may make that one workstation appear healthier, but it leaves the VLAN relay broken for every other DHCP client on the segment. It also ignores the moved server’s gateway issue and the TCP 53 firewall issue, so the complete outage chain remains unresolved. This is a classic bad workaround: it changes an endpoint to hide the symptom instead of correcting the infrastructure fault.

The broad-firewall answer is wrong because it prioritizes “making traffic pass” over safe remediation. An ANY/ANY permit from the application servers may mask the DNS and repository symptoms, but it violates least privilege and creates a security compliance failure. Setting APP-SRV-04 to use a public default gateway is also incorrect because the server needs to route through the internal SVI for its VLAN, not bypass internal routing controls. A Server+ candidate should restore the specific required service flows, not flatten the firewall policy.

The UDP-only DNS answer is wrong because it stops at a shallow validation point. A normal nslookup result proves that basic DNS over UDP can work, but it does not prove that all required DNS behavior is functional. The repository validation failure shows that TCP 53 is still required for this application path. Flushing DNS caches or changing the preferred DNS server may change the order of lookup attempts, but it does not fix a firewall rule that blocks TCP DNS fallback.