Service Implementation PBQs: DNS, DHCP, VLANs, and Firewall Direction

Reading a Combined PBQ in Order

The N10-009 exam includes performance-based questions (PBQs) - drag-and-drop or simulation tasks where you configure or repair a small network. They reward candidates who read in dependency order: addressing, then name resolution, then routing, then firewall policy, then service behavior. Guessing wastes the limited 90-minute clock.

Consider this design:

• VLAN 10 - Employees, 10.10.10.0/24, gateway 10.10.10.1
• VLAN 20 - Servers, 10.10.20.0/24, gateway 10.10.20.1
• VLAN 30 - Guests, 10.10.30.0/24, gateway 10.10.30.1
• VLAN 40 - Management, 10.10.40.0/24, gateway 10.10.40.1
• DNS and DHCP server: 10.10.20.10
• Web application: app.example.local at 10.10.20.50

Required behavior: employees reach the web app by name; guests reach only the internet; management administers servers; every VLAN gets correct DHCP options. Each requirement maps to one specific service or rule.

Mapping Requirements to Configuration

A frequent trap is setting a VLAN's gateway option to the server's IP. The gateway must be the routed SVI for that VLAN (10.10.10.1 for employees), never 10.10.20.10. Another trap: pointing every VLAN's DNS at an external resolver, which can break internal name resolution for app.example.local.

Notice how the design separates concerns. DHCP delivers the plumbing (address, mask, gateway, DNS server) so a client can communicate at all. DNS then turns the application name into the server's address. Routing carries the packet between VLANs through the Layer 3 switch. The firewall decides whether that flow is allowed. Finally the server must actually be listening. Each PBQ usually breaks exactly one of these links, and the artistry is recognizing which symptom maps to which link rather than reconfiguring everything.

For example, a client with a 169.254 address has a DHCP problem and you never even reach DNS; a client that resolves a name but cannot connect has already passed DHCP and DNS, so you move down to routing and firewall.

Firewall Direction Is Stateful

Firewall rules are scoped to source, destination, service, and action - and modern firewalls are stateful, so they track each connection by the side that initiates it and automatically permit the return traffic.

Direction is the load-bearing detail. A rule that allows Server VLAN -> Employee VLAN on HTTPS does not let an employee open a browser session to the server, because for a client-initiated connection the source is the employee and the destination is the server. Because the firewall is stateful, you only write the rule in the initiating direction; the response is allowed automatically.

Troubleshooting Order, Traps, and a Walkthrough

When a user says "the app is down," follow dependencies instead of guessing:

1. Verify the client's IP, mask, gateway, and DNS server are correct.
2. Verify the name resolves to the intended address.
3. Verify the client can route to the destination subnet.
4. Verify a firewall rule allows the client-to-service flow.
5. Verify the service is listening on the expected port.
6. Verify the application itself is healthy.

PBQ walkthrough

Facts: employees in VLAN 10 hold 10.10.10.x addresses; their DNS is 10.10.20.10; app.example.local resolves to 10.10.20.50; both ping and HTTPS to 10.10.20.50 fail; the only HTTPS rule is Server VLAN -> Employee VLAN. Best answer: leave DHCP and DNS alone (they return correct values), add an allow rule Employee VLAN -> 10.10.20.50 on TCP 443, keep guest-to-internal denied, and log the default-deny rule. The reversed firewall rule is the key clue - a new client-initiated HTTPS session needs the employee as source and the server as destination.