Service Implementation PBQs: DNS, DHCP, VLANs, and Firewall Direction
Key Takeaways
- PBQs often combine services, addressing, segmentation, and firewall rules in one scenario.
- DNS must return the correct address before transport or application troubleshooting can succeed.
- DHCP scopes and relay must match VLAN and subnet design.
- Firewall direction matters: rules should be written from source to destination with required ports only.
- A default deny posture with explicit allows is safer and easier to reason about than broad any-to-any rules.
Performance-based questions often combine several simple pieces. The challenge is reading the scenario in the correct order: addressing, name resolution, routing, firewall policy, and service behavior.
Combined Design Example
Scenario:
- VLAN 10: Employee clients, 10.10.10.0/24.
- VLAN 20: Servers, 10.10.20.0/24.
- VLAN 30: Guests, 10.10.30.0/24.
- VLAN 40: Management, 10.10.40.0/24.
- DNS and DHCP server: 10.10.20.10.
- Web application: app.example.local at 10.10.20.50.
Required behavior:
- Employees can access the web application by name.
- Guests can access the internet only.
- Management can administer servers.
- Clients in each VLAN receive correct DHCP options.
Service Mapping
| Requirement | Service configuration |
|---|---|
| Employee name lookup | DNS A record app.example.local -> 10.10.20.50 |
| Employee addressing | DHCP scope for 10.10.10.0/24 with gateway 10.10.10.1 and DNS 10.10.20.10 |
| Guest addressing | DHCP scope for 10.10.30.0/24 with gateway 10.10.30.1 and approved DNS |
| Central DHCP server | DHCP relay configured on VLAN interfaces outside the server VLAN |
| Server management | Firewall allow from management VLAN to approved admin ports |
Do not configure the employee VLAN gateway as the server IP. The gateway should be the routed interface for that VLAN.
Firewall Direction
Firewall rules should be scoped to the source, destination, service, and action.
| Source | Destination | Service | Action | Reason |
|---|---|---|---|---|
| Employee VLAN | DNS server | DNS | Allow | Name resolution |
| Employee VLAN | Web app | HTTPS | Allow | Business application |
| Guest VLAN | Internal subnets | Any | Deny | Guest isolation |
| Guest VLAN | Internet | DNS/HTTP/HTTPS | Allow | Guest browsing |
| Management VLAN | Servers | SSH/RDP/HTTPS admin | Allow | Administration |
| Any | Any | Any | Deny/log | Default deny |
Direction matters. "Allow DNS server to employee VLAN" does not permit employees to initiate DNS queries if the firewall policy is evaluated by new connection source and destination.
Troubleshooting Order
When a user says "the app is down," avoid guessing. Work through dependencies.
- Verify the client has the correct IP address, mask, gateway, and DNS server.
- Verify the name resolves to the intended address.
- Verify the client can route to the destination subnet.
- Verify firewall rules allow the client-to-service flow.
- Verify the service is listening on the expected port.
- Verify the application itself is healthy.
This order separates DHCP, DNS, routing, firewall, and application faults.
Common PBQ Traps
| Trap | Why it is wrong |
|---|---|
| Broad allow from guest to internal | Violates segmentation requirement |
| DHCP scope uses wrong gateway | Clients cannot route outside their subnet |
| DNS A record points to old server | Name works but reaches wrong destination |
| Firewall rule source and destination reversed | Intended clients still cannot initiate sessions |
| Missing DHCP relay on new VLAN | Clients fail even though the DHCP server is healthy |
| Allow any-to-any temporarily | May pass connectivity but fails least-privilege requirement |
PBQ Walkthrough
Facts:
- Employees in VLAN 10 receive 10.10.10.x addresses.
- Their DNS server is 10.10.20.10.
- app.example.local resolves to 10.10.20.50.
- Pinging 10.10.20.50 fails, but HTTPS to 10.10.20.50 also fails.
- The firewall has an allow rule from Server VLAN to Employee VLAN for HTTPS.
Best answer:
- Keep DHCP and DNS unchanged because they are returning plausible values.
- Add or correct an allow rule from Employee VLAN to 10.10.20.50 for TCP 443.
- Keep guest-to-internal denied.
- Log the default deny rule for visibility.
The reversed firewall rule is the key clue. For a new client-initiated HTTPS connection, the source is Employee VLAN and the destination is the server.
Employees can resolve app.example.local to the correct server IP, but HTTPS fails. The only HTTPS allow rule is from the server VLAN to the employee VLAN. What is the best fix?
A new VLAN cannot obtain DHCP leases from a centralized DHCP server. Which items should be checked? Choose two.
Select all that apply
Order the troubleshooting workflow for a client that cannot reach an internal web app by name.
Arrange the items in the correct order