Secure Network Architecture: Zones, Device Placement, Firewalls vs. IDS/IPS, and Secure Protocols

You can buy the best inspection engine on the market, plug it into the wrong place, and learn nothing. Security+ Domain 3 is unusually practical about this: objective 3.2 is essentially a list of placement decisions, and the exam turns them into scenarios where every answer names a real product and only one sits where it could possibly see the traffic. Here is the architecture that makes those questions easy: zones, placement, firewalls, detection, and the protocol swaps you should recognize instantly.

Zones: the map every design starts from

A security zone is a group of systems that share a trust level and are separated from other zones by an enforcement point. That last clause is the whole idea. Zones are not VLANs, labels, or diagrams; a zone exists only where something inspects and decides at its boundary.

The classic three-tier layout still frames the exam's scenarios:

The screened subnet, the term that replaced "DMZ", exists for one reason: internet-facing services get compromised, and when they do, the attacker should land somewhere that cannot reach the domain controllers. If your web server sits on the same flat network as finance, you do not have a screened subnet, you have a web server.

Two related ideas the exam pairs with zones: east-west traffic (server to server, inside a zone) needs its own segmentation, because perimeter enforcement never sees it; and management interfaces belong in their own restricted zone reached through a jump server, never exposed alongside the services they administer.

Device placement: inline vs. tap, active vs. passive

Two independent choices define what any security device can do. Confusing them is the most common way to lose an objective 3.2 question.

A device on a SPAN port or network TAP can never block, no matter how good its detection is: the packet has already been delivered by the time the copy arrives. A device inline can block, and inherits a new problem: it is now a single point of failure for the traffic it inspects.

Which brings up the pair of terms the exam loves:

• Fail-open: if the device dies, traffic keeps flowing. Availability preserved, security lost.
• Fail-closed (fail-secure): if the device dies, traffic stops. Security preserved, availability lost.

There is no universally right answer, and that is exactly why it is a good exam question. A firewall protecting cardholder data fails closed. An inline sensor on a hospital's clinical network usually fails open, because a network outage in that context is itself a safety event. Read the scenario for what the organization cannot afford to lose.

Firewalls: four generations, one job

Every firewall answers "should this traffic pass?". They differ in how much they understand before answering.

Two placement notes that turn into exam points. A WAF protects an application, so it sits in front of that application (usually as a reverse proxy in the screened subnet) while a forward proxy sits in front of your users and controls where they can go. And a UTM appliance bundles firewall, filtering, and inspection into one box, which is convenient for a small site and a concentrated failure domain for a large one.

IDS vs. IPS, and why detection tuning is a security decision

Same engine, different placement, opposite failure modes.

How they detect matters as much as where they sit. Signature-based detection matches known patterns: precise, cheap, and blind to anything new. Anomaly-based (behavioral) detection flags deviation from a learned baseline: capable of catching novel attacks, and prone to alarming about the quarterly batch job.

That difference drives a real design decision. False positives on an IDS cost analyst time. False positives on an inline IPS cost availability. You have just blocked legitimate traffic. This is why organizations commonly run new signatures in alert-only mode first and promote them to blocking after they have proven themselves against real traffic.

Secure protocols and port selection

Objective 4.5 is largely a vocabulary test, and it is free marks if you know the swaps on sight. Every row below is the same story: a protocol designed in an era of trusted networks, and its authenticated, encrypted replacement.

Two nuances worth carrying into the exam. DNSSEC signs records, it does not encrypt them. It provides authenticity and integrity, while DoT and DoH provide confidentiality; they solve different problems and the exam tests the distinction. And SNMPv3 is the only version that offers authentication and encryption; v2c "security" is a community string sent in the clear, which is to say a password shouted across the room.

The failure modes the exam actually tests

Most scenario questions are built from a short list of recognizable architecture mistakes:

• The flat network. One broadcast domain, no internal enforcement, so any compromised laptop can reach any server. Segmentation is the answer, and it is the answer to a startling number of questions.
• The permissive rule at the bottom. A firewall policy ending in allow any any is a firewall in name only. Deny by default, permit by exception, and review rules on a schedule: old rules for decommissioned systems are how paths reopen.
• The sensor nobody reads. An IDS generating 40,000 alerts a day into an empty queue provides documentation of your breach, not defense against it. Tuning is a control, not housekeeping.
• The exposed management plane. RDP or SSH on a management interface reachable from the internet remains one of the most reliable initial-access paths in the wild. Management belongs behind a jump server or VPN, always.
• The encrypted blind spot. Once traffic is TLS, your inspection devices see metadata and nothing else. Decryption at a controlled point buys visibility and costs privacy and performance: decide deliberately, document the exceptions, and never decrypt categories like health or banking traffic by accident.

Each of these is a placement or policy failure rather than a product failure, which is the underlying lesson of objective 3.2: architecture decides what your controls are even capable of.

Network architecture is the backbone of Security+ Domain 3, which also covers architecture models, data protection, and resilience. It pairs directly with Zero Trust, which replaces the perimeter assumption these designs were built on, with the certificates that make the secure protocols above trustworthy, and with the incident response process that runs when a zone boundary is crossed. Work all 26 topics with our Security+ Domain 3 study guide.

#SecurityPlus #SY0701 #NetworkSecurity #Firewalls #IDS #IPS #Segmentation #SecureProtocols #ZeroTrust #CompTIA #CyberSecurity