How to Use Labs, Practice, and PBQ Workflow
Key Takeaways
- Labs turn abstract concepts into operational memory: observe, change, verify, and document.
- PBQs often reward careful reading, topology labeling, and eliminating impossible placements before moving items.
- Practice questions should be reviewed for reasoning, not just score.
- Command output practice should focus on what the output proves and what it does not prove.
- Use small repeatable labs for DHCP, DNS, VLANs, routing, wireless, NAT, VPNs, and troubleshooting tools.
Labs Make Network+ Stick
Reading a definition tells you what a DHCP server does. A lab shows you the lease, default gateway, DNS server, renewal behavior, and failure mode when the scope is wrong. Network+ rewards that kind of operational understanding.
Lab Loop
Use this loop for every small lab:
| Step | Action | Example |
|---|---|---|
| 1 | Predict | "If DNS is wrong, IP pings may work but names fail." |
| 2 | Observe baseline | Record IP, gateway, DNS, route, link status, and working tests |
| 3 | Change one thing | Disable DHCP, change VLAN, block a port, alter DNS |
| 4 | Test | Use ping, traceroute, nslookup/dig, ipconfig/ifconfig/ip, netstat/ss |
| 5 | Explain | Write what the output proves and what remains unproven |
| 6 | Restore | Return the lab to a known-good state |
High-Value Lab Topics
| Topic | Build or simulate | What to prove |
|---|---|---|
| DHCP | Client, scope, gateway, DNS option | Client addressing depends on correct lease options |
| DNS | A record, CNAME, failed resolver | Name failure is not always network failure |
| VLANs | Access port, trunk, wrong VLAN | Layer 2 segmentation controls broadcast domains |
| Routing | Two subnets and a gateway | Traffic leaves the local subnet through a route |
| NAT | Private client to public destination | Source translation changes return path behavior |
| Wireless | SSID, channel, authentication | Association, signal, and authentication are separate clues |
| VPN | Tunnel policy and route | Encrypted paths still need routing and allowed traffic |
PBQ-Style Workflow
PBQs can look busy. Slow the first 30 seconds down.
| Move | Why it helps |
|---|---|
| Read the task verb first | "Configure", "match", "place", and "troubleshoot" require different behavior |
| Label known-good facts | Prevents changing items that already satisfy the requirement |
| Identify boundaries | Internet edge, DMZ, access layer, distribution/core, wireless, server VLAN |
| Eliminate impossible choices | A modem is not a Layer 3 firewall; a switch access port is not a WAN circuit |
| Check constraints | Secure protocol, least privilege, redundancy, cost, or minimal downtime |
| Review before submit | PBQs often penalize one misplaced item in an otherwise good topology |
Practice Question Review Template
Do not just mark a question right or wrong.
| Field | Example entry |
|---|---|
| Topic | DNS troubleshooting |
| My answer | Replace the switch |
| Correct reasoning | IP connectivity works; name resolution fails |
| Miss type | Jumped layers too quickly |
| Repair drill | Five scenarios distinguishing DNS, gateway, DHCP, and link issues |
Scenario: Command Output Reasoning
A workstation shows an APIPA address in the 169.254.0.0/16 range. That output proves the client did not receive a usable DHCP lease. It does not by itself prove the DHCP server is down. The cause could be wrong VLAN, blocked DHCP relay, exhausted scope, disconnected cable, bad wireless association, or local firewall interference.
Good practice explains both sides: what the evidence proves and what still needs confirmation.
Put the PBQ workflow in the best order.
Arrange the items in the correct order
A client has a 169.254.x.x address. What does that most directly indicate?
Which habits improve PBQ performance? Select all that apply.
Select all that apply