A zone diagram shows a firewall between two subnets that traffic no longer traverses - what does an intruder gain, and what has to move?
answer
- a drawing is not in the forwarding path
- routing decides reachability, not the diagram
- a filter never asked logs nothing
- enforcement moves on a change night
basics
~20 sA diagram is a claim, not a control. If routing carries the traffic around the firewall, an intruder crossing between those subnets meets no filter at all. Only moving the enforcement point onto the real path fixes it, and that costs a change window.
solid answer
~50 sThe intruder gains a path with no policy on it. They never read the drawing; they follow the forwarding decision the fabric makes hop by hop, and if a newer path - a second pod, a stretched overlay segment, a direct interconnect built after an acquisition - reaches the same destination without transiting that device, the rules on the device are simply not evaluated. So the answer to "is the zone enforced" is a question about the path, not about the rule base. Fixing it means the packets have to have no way round: either the enforcement point is placed where every path between the two zones already converges, or the routing is changed so they converge on it. Both are change-window work with an owner and a rollback, and often a re-addressing problem underneath. Redrawing the diagram to match reality changes nothing an attacker experiences.
go deeper
Be ready to say plainly that a diagram is an intention and the routing is the reality, and that a filter which is never on the path filters nothing.
Explain the concrete ways a path appears that the diagram never showed - a new pod, a stretched overlay segment, an interconnect built after a merger - and why none of them raise an alarm.
Show that you would treat 'is it enforced' as a path question first, and that you can name what relocating enforcement costs: a path change, a policy translation, flow discovery, a window and a rollback.
Own the framing that segmentation is a claim your organisation makes to auditors, customers and its own board, and that the claim is only as good as the last time somebody reconciled it with the forwarding path.
## What a zone diagram actually asserts A zone diagram asserts *intent*: these two groups of systems are meant to be separated, and this box is meant to be the thing that separates them. It is an architectural claim made by people. It is not consulted by any packet. What is consulted by a packet is the forwarding state of every device between source and destination: routing tables, the fabric's overlay mappings, the switching decision inside a hypervisor, a route learned over an interconnect. If that chain never includes the device holding the policy, the policy has no effect on the traffic. A rule base that is not on the path is documentation with a CLI. | The diagram asserts | What actually decides | | --- | --- | | Zone A and Zone B are separated by a filter | Whether every path from A to B transits the filtering device | | The rule base is the policy between the zones | Which device makes the forwarding decision for that address pair | | The boundary is where the drawing puts it | The boundary is wherever packets have no way round | ## Why the drawing and the network drift apart Zone models are drawn once and the estate keeps growing. The characteristic case is a merged estate a year after an acquisition: two address plans, two zone diagrams, two of everything shared, and a fabric built in a hurry so the two sides can talk. That fabric is a path nobody drew. The same thing happens without an acquisition - a second leaf-spine pod stood up for capacity, a segment stretched across an overlay so a workload could move without changing address, a direct interconnect added for a latency-sensitive integration. Each is a legitimate engineering decision, and each can reach the destination without traversing the routed aggregation boundary that was cut between the two zones years ago. Nobody experiences this as a failure. The applications work. The diagram still hangs in the wiki. Nothing alerts, because a filter that is never asked a question logs no denies. ## What the intruder gains An intruder who has landed anywhere in Zone A and wants Zone B does not need to defeat the filter, evade a signature, or find a permitted flow to ride. They need reachability, and reachability is exactly what the unmapped path hands them. The whole value of the boundary - that it subtracts destinations - is gone for every pair that path serves. Worse for the defender, the gap is invisible in the place a defender would look: the firewall's logs are quiet, and quiet reads like healthy. Be precise about the direction of the claim in an interview. A quiet rule base proves that the device was not asked, not that nothing crossed. A green architecture review proves that the drawing was reviewed, not that traffic obeyed it. ## What it costs to make it true again This is the part candidates skip, and it is what the question is really testing. Making the boundary true is not an edit; it is one or more of: - **A path change** - withdraw or re-scope the routes that let traffic bypass, so the pair converges on the enforcement point. That changes the traffic path of live applications. - **A policy move** - the rule set has to exist at the new enforcement point, translated to that device's interfaces and to whatever addressing is really in use on both sides. - **A discovery step** - you cannot write the permit set from the old rule base alone, because the old rule base only ever saw the flows that transited it. - **Sometimes re-addressing** - two merged estates with overlapping ranges cannot be filtered on address until one side moves, which is a project, not a night. Every one of those needs a maintenance window, a change owner who will be on the call when something breaks, and a rollback. That is the real price of a boundary: not the appliance, but the sequence of nights in which the estate has to keep working while enforcement is relocated. ## The line to say out loud "A boundary is real only where the packets have no other way round it." Everything else - the drawing, the rule base, the review - is a claim about a boundary, and claims are what get inherited from the last architect.
- Someone proposes updating the diagram to match how traffic really flows. Is that remediation?No. It is honest documentation, and it is worth doing, but it removes no reachability. After the redraw the intruder has exactly the same unfiltered path they had before. Remediation is the enforcement point moving onto that path, with the change windows and rollback that implies. Treating the redraw as the fix is how a known gap gets closed on a tracker while staying open on the wire.
- You copy the old rule set onto a device on the new path. Is the zone now enforced?Only if that device is on every path between the two zones, including the overlay and any interconnect, and only if the rules were translated to the addressing actually in use on both sides. A partial move leaves a bypass, and a bypass is the whole gap. Also expect the copied rule set to be incomplete: it only ever saw flows that transited the old device.
- The firewall's deny counters are at zero for that zone pair. What does that tell you?Almost nothing on its own. Zero denies is equally consistent with a well-behaved estate, with a permit rule matching everything first, and with no traffic ever reaching the device. It is a prompt to check whether the device sees the pair at all, not evidence that the boundary held.
A floor plan showing a locked door between two wings does not lock anything. If someone cut a corridor between them last year, the door is still locked and completely irrelevant.
saying these in an interview costs you the question
- Treats the architecture diagram as evidence that traffic is filtered
- Says updating the documentation closes the gap
- Assumes a device in the path on paper is in the path in the fabric
- Reads a quiet rule base as proof nothing crossed
- Ignores that moving enforcement needs an outage window and an owner