How to Implement Secure Network Designs for CompTIA Security+ (SY0-601)

A practical guide to segmentation, DMZs, VPNs, NAC, wireless security, and Zero Trust in scenario-based exam questions

Secure network design is really about one habit: place the right control at the right trust boundary. That’s the basic logic behind a lot of Security+ secure network design questions, especially when you’re dealing with the newer exam objectives and the scenario-style stuff they like to throw at you. The exam might dress it up as a guest Wi‑Fi issue, a public web app, a remote admin need, or a regulated segment, but the job’s really the same every time: figure out what you’re protecting, find the trust boundary, and put the right control there so only the minimum necessary access gets through.

For exam purposes, remember a few traps. VLANs are not the same as enforced security. Encryption is not the same as authorization. An IDS is not an IPS. A VPN is not a replacement for segmentation. A reverse proxy isn’t the same thing as a web application firewall, and that distinction trips people up all the time. If you keep those differences straight in your head, a lot of the scenario questions get way less messy.

Core design principles that drive the right answer

Confidentiality, integrity, and availability still matter, obviously, but when you’re designing a network, they turn into very practical decisions instead of abstract theory. TLS and IPsec are there to protect data while it’s moving across the network, so you’re preserving confidentiality and integrity in transit. Firewalls, ACLs, and IPS devices are the policy enforcers here—they’re the stuff that actually blocks traffic you don’t want moving around. Redundant links, clustered firewalls, and VPN failover support availability. Security+ often rewards the answer that balances all three rather than the answer that only sounds “most secure.”

Defense in depth also matters. If one control fails, another should still reduce impact. That is why strong designs combine segmentation, AAA, VPN security, logging, hardened management access, and monitoring. Least privilege and implicit deny are equally important: allow only required traffic, then deny everything else by default.

Segmentation and isolation controls

Segmentation limits blast radius and reduces lateral movement. At the technical level, I usually think of this as something you can enforce at a few different layers.

• Layer 2: VLANs, private VLANs, port security, DHCP snooping, dynamic ARP inspection, BPDU guard
• Layer 3/4: inter-VLAN ACLs, router ACLs, stateful firewalls, internal segmentation firewalls
• Layer 7: application-aware policy, reverse proxies, WAFs, identity-aware access controls

VLANs do split up broadcast domains, sure, but by themselves they’re not a real security boundary. In a lot of modern environments, honestly, the real problem isn’t the technology itself — it’s misconfiguration. I’ve seen bad trunking, overly permissive inter-VLAN routing, and firewall rules that might as well say, ‘sure, everybody talk to everybody.’ That’s usually where the actual enforcement happens: once traffic has to cross from one subnet to another and hits an ACL or a firewall, the policy finally starts to matter.

A practical layout might look something like this, and honestly, this is the kind of setup I’ve seen hold up well in real environments:

VLAN 10 Users 10.10.10.0/24 VLAN 20 Servers 10.10.20.0/24 VLAN 30 Management 10.10.30.0/24 VLAN 40 Guest 10.10.40.0/24 VLAN 50 Voice 10.10.50.0/24

If inter-VLAN routing is happening on a Layer 3 switch, ACLs can handle the basic filtering pretty well. If the environment has sensitive systems, though, I’d usually lean toward an internal segmentation firewall. You get stateful inspection, better logging, and cleaner policy control, which makes a big difference when the stakes are higher. That’s especially useful when you need tighter control over user-to-server, server-to-server, or user-to-management traffic — the stuff that tends to get messy fast if you don’t put guardrails in place.

A vendor-neutral policy example might look something like this:

Allow Users -> App_Servers : HTTPS, required app ports Deny Users -> Management : Any Allow Voice -> Call_Manager: SIP, RTP, DNS, NTP Allow Guest -> Internet : DNS, HTTP, HTTPS Deny Guest -> Internal : Any Allow Mgmt_Jump -> Network_Devices : SSH, HTTPS, SNMPv3 Deny Any -> Any : Log

For more advanced setups, I’ve also seen VRFs, software-defined segmentation, and microsegmentation used to isolate workloads even more tightly. Security+ usually doesn’t expect deep vendor-specific detail there. The main thing to understand is that the goal is to reduce east-west trust inside the network.

A true air gap means physical isolation with no direct network connectivity. That’s different from logical isolation, which still uses networks but limits communication through segmentation and policy.

DMZs, screened subnets, and firewall architecture

A DMZ is a separate network segment used for public-facing services. A screened subnet is one common DMZ implementation pattern. The exam might use the terms a little loosely, but the safe mental model is simple: anything facing the Internet should be kept away from the internal LAN and only allowed inward through tightly controlled paths.

Common DMZ designs include:

• Three-legged firewall: one firewall with inside, outside, and DMZ interfaces
• Dual-firewall screened subnet: one firewall between Internet and DMZ, another between DMZ and internal network
• Cloud equivalent: public subnet, reverse proxy or load balancer, WAF, private application subnet, database subnet, security groups and network ACLs

A public web application is a classic example. Internet users should come in through a reverse proxy or load balancer in the DMZ, not straight at the backend systems. The reverse proxy lets you publish the service without exposing the backend servers directly to the Internet, and that’s really the whole point. A WAF is different: it inspects HTTP/S traffic for application-layer attacks such as SQL injection or malicious request patterns. Some platforms combine both capabilities, but conceptually they’re still doing two different jobs.

Internet | [Edge Firewall] | [DMZ: Reverse Proxy / WAF] | [Internal Firewall] | [App Tier] | [DB Tier]

Practical flow control matters. The database should not be reachable from the Internet or directly from the DMZ. NAT may publish only the reverse proxy’s public address. The reverse proxy then forwards approved requests to the application tier. If TLS is terminated at the proxy or load balancer, sensitive environments often require re-encryption to the backend rather than sending traffic in cleartext internally.

Good firewall design also means more than a few allow rules. Think about rule order, object groups, anti-spoofing, egress filtering, and logging. “Any-any” exceptions are easy to add and painful to remove. Outbound controls such as DNS filtering, secure web proxying, and egress deny rules can help expose malware command-and-control traffic.

ACL vs firewall vs NGFW vs microsegmentation

Exam shortcut: if the question asks for simple traffic filtering between subnets, ACLs may fit. If it asks for stronger trust-boundary enforcement, logging, or containment of lateral movement, a firewall or internal segmentation firewall is usually the better answer.

IDS, IPS, and security logging

An IDS is detective. An IPS is preventive and inline. IDS sensors often analyze mirrored traffic from a TAP or SPAN port, though they may also use host telemetry or cloud traffic copies. IPS devices sit in the path, so tuning and high availability matter; fail-open versus fail-closed behavior can become a business decision.

Detection depth also matters. Signature-based systems are good at known threats. Anomaly-based systems can catch unusual behavior, but yeah, they can also throw more false positives at you. Encrypted traffic limits visibility unless the organization performs approved TLS inspection.

For practical monitoring, I’d want logs from firewalls, VPN concentrators, RADIUS and TACACS+ servers, DHCP, DNS, wireless controllers, IDS/IPS, switches, and the endpoints that actually matter. In other words, don’t just log the obvious stuff — log the control points. Use centralized logging or a SIEM, protect log transport with something like syslog over TLS when you can, and keep time synchronized with a hardened internal NTP hierarchy or authenticated time services if the platform supports them. If the clocks are off, the logs get a lot less useful. Good retention and access control matter too; forwarding logs alone is not enough.

VPN design and secure remote access

Remote access VPNs are for individual users, while site-to-site VPNs connect entire networks together. Remote access products may use IPsec/IKEv2 or TLS-based VPNs, and people still call them ‘SSL VPNs’ sometimes, even though the modern versions are really using TLS. For exam logic, the main question is whether the need is user access or network-to-network connectivity.

Important design choices include:

• MFA: required for remote access whenever possible
• Certificates: often used for device or gateway validation
• Full tunnel vs split tunnel: full tunnel gives more centralized inspection; split tunnel reduces load but increases exposure
• Always-on or kill switch controls: help prevent traffic leakage outside the tunnel
• DNS handling: internal DNS must resolve internal resources correctly, especially over full tunnel
• Role-based authorization: VPN access should land users only where they need to go

Split tunneling is risky because the endpoint can end up bridging trusted and untrusted networks, and that weakens centralized visibility, DNS control, and DLP effectiveness. If the exam asks for the most secure remote-user design, full tunnel plus MFA and restricted access is usually the stronger answer.

For vendors or administrators, add a jump host or bastion. VPN access alone is not least privilege.

Administrative access hardening and AAA

Management traffic should be separated from user traffic. Use a management VLAN, or if the environment’s more critical, go with out-of-band management. Restrict source IPs, use dedicated admin accounts, prefer SSH, HTTPS, and SNMPv3, turn off insecure protocols, and require MFA. Privileged access workstations or hardened jump hosts are a lot better than managing core systems from everyday laptops, and I’d strongly recommend that approach whenever you can.

RADIUS and TACACS+ both fall under AAA, but they usually show up in slightly different roles. That’s one of those distinctions people mix up all the time.

Strong admin design also includes session logging, configuration backup protection, RBAC, secrets handling, and control-plane protections such as rate limiting or authenticated routing adjacencies where applicable.

How 802.1X, NAC, and enterprise wireless actually work

802.1X is one of the most testable access-control topics. The three main roles are:

• Supplicant: the endpoint requesting access
• Authenticator: the switch port or wireless AP/controller controlling access
• Authentication server: usually RADIUS

Basic flow: the device connects, the authenticator blocks normal traffic, the supplicant and RADIUS server exchange EAP authentication through the authenticator, and then the switch or access point opens access based on the result. Once you picture it that way, it’s a lot easier to remember. NAC can also add posture checks—patch level, disk encryption, EDR status, MDM compliance—before it assigns a VLAN, a downloadable ACL, or a quarantine network.

NAC definitely improves admission control, but it doesn’t replace endpoint security or internal segmentation after access has already been granted. And, honestly, devices can still get compromised later.

Not every device supports 802.1X, and that’s a really important real-world limitation. Printers, phones, cameras, and some IoT systems may need MAB (MAC Authentication Bypass), restricted VLANs, or tightly scoped ACLs. That’s a pretty common real-world exception, and it’s also a good exam clue.

For wireless, enterprise deployments should use WPA2-Enterprise or WPA3-Enterprise with 802.1X, EAP, and RADIUS. That’s the right model for business networks, plain and simple. Strong methods include EAP-TLS, which uses client certificates and depends on a working PKI. PEAP and similar methods may still appear, but certificate-based authentication is generally stronger. WPA3-Enterprise can support stronger cryptography, including higher-assurance modes in some environments, though you still need to check compatibility before rolling it out. Protected Management Frames, or PMF/802.11w, help defend against certain deauthentication and disassociation attacks, which is a nice extra layer when the gear supports it.

Guest wireless should use separate SSIDs mapped to separate VLANs with Internet-only policy. BYOD usually belongs in a limited-access segment with a captive portal or some kind of onboarding control. Corporate, guest, and IoT wireless should not share the same trust level just because they all use Wi‑Fi.

WIDS and WIPS are also different. A WIDS detects rogue APs and suspicious wireless activity. A WIPS can actively contain or prevent some threats depending on platform, policy, and legal constraints.

Zero Trust and ZTNA vs VPN

Zero Trust is not a product. It is an architectural approach based on continuous verification, strong identity, device trust, least privilege, and reduced implicit trust. In practice, it uses signals such as user identity, device posture, location, risk, and requested application to make access decisions through policy decision and enforcement points.

A classic VPN extends network access. ZTNA typically brokers access to a specific application or resource instead of dropping the user onto a broad internal subnet. That cuts down on lateral movement and lines up much better with least-privilege goals.

On the exam, if the goal is secure remote access to one application with reduced lateral movement, ZTNA is often stronger than a broad VPN. If the need is full administrative or network connectivity, VPN plus segmentation and a jump host may still be the right answer.

Resilience and high availability

Secure design must still survive failure. Redundant firewalls, clustered VPN concentrators, multiple links, backup RADIUS and TACACS+ servers, and load balancer health checks all help support availability and keep the environment from falling over when one piece fails.upport availability.lability. Active/passive designs are usually simpler, while active/active designs can boost throughput but they also add more complexity. State synchronization and configuration parity matter because redundant devices without synchronized sessions or matching rules can still create outages or policy gaps.

Also remember fail-secure versus fail-safe tradeoffs. During IPS tuning, some organizations prefer alert-only first to avoid blocking legitimate traffic. NAC, firewalls, and remote access solutions may need explicit decisions about what happens if an authentication or inspection component fails.

Troubleshooting and validation

Security+ questions often hide troubleshooting inside design scenarios. A simple troubleshooting method is: verify the path, verify authentication, verify policy, and then verify the logs.

• Segmentation failure: check VLAN membership, trunk/access configuration, SVI or gateway placement, routing, ACL/firewall hit counts, and packet captures from both source and destination zones.
• Guest Wi-Fi can reach internal resources: confirm SSID-to-VLAN mapping, controller ACLs, firewall rules, and whether a guest subnet was accidentally routed into internal space.
• DMZ app published but backend fails: check NAT, reverse proxy configuration, allowed backend ports, TLS certificate validity, DNS resolution, and whether the internal firewall permits only the required flow.
• VPN tunnel up but app unreachable: verify route or traffic selectors, split-tunnel policy, internal DNS, endpoint posture status, and firewall rules for the VPN address pool.
• 802.1X failures: inspect supplicant configuration, certificate validity, RADIUS reachability, shared secrets, switch or AP authenticator settings, and fallback handling such as MAB or remediation VLANs.
• Wireless auth issues after certificate renewal: check trust chain, expired intermediate CA certificates, EAP method mismatch, and controller policy updates.

Validation is just as important as design. Test from each trust zone, review deny logs, confirm explicit allowed flows, and document expected paths. In regulated environments, segmentation validation itself may become audit evidence.

High-yield Security+ scenarios

Guest wireless: separate SSID, separate VLAN, Internet-only firewall policy. Best answer when the goal is visitor access without internal exposure.

Public-facing web app: DMZ or equivalent segmented public zone, reverse proxy, possibly WAF, tightly restricted backend access. Best answer when publishing a service to the Internet.

Remote administration: VPN plus MFA plus jump host in a management network, with TACACS+ or centralized AAA and session logging. Best answer when protecting privileged access.

Regulated or payment systems: isolated segment, internal segmentation firewall, strict admin path, centralized logging, minimal reachable paths. Best answer when reducing scope and lateral movement.

BYOD and unmanaged devices: NAC, dynamic VLAN assignment, quarantine or limited-access policy, not full corporate access. Best answer when device trust is uncertain.

Final exam checklist

• Identify the asset.
• Identify the trust boundary.
• Choose the control that enforces policy there.
• Prefer layered answers over single-tool answers.
• Eliminate distractors: VLAN alone, encryption alone, IDS when blocking is needed, VPN when least privilege is still missing.

The best Security+ answer is usually not the flashiest technology. It is the control that most directly reduces risk at the correct boundary while preserving visibility and reasonable availability. Think like a designer: contain, verify, restrict, and monitor.