A transparent inline WAF sits in your virtual network's path; a routing change stops sending traffic through it — how do you find out?

## Two ways a control gets into the path A request-judging control is only in the path for one of two reasons. **It is a named hop.** Clients resolve a hostname to the control's address; it terminates their connection and opens its own to the application. A proxy you run works this way, and so does a rented edge ahead. **It is inserted transparently.** Clients resolve to the service address as before, and routing — a route table entry, a gateway, a segment the traffic must cross — steers packets through a device on the way. Nothing in the client's view mentions it. The security properties look the same on a diagram. The **failure** properties do not, and that difference is the whole question. ## Loud failure and silent failure When a named hop stops working, the service stops working. That is loud: an outage, a page, an incident, an immediate audience. It costs you availability — you have made the control a dependency of the service — but you cannot be quietly unprotected. When a transparent insertion stops being on the path, **nothing breaks**. The packets take the new route, the application answers, latency may even improve. There is no error to alert on, no failed health check, and the device itself is perfectly healthy — it simply has less to do. Meanwhile every request that would have been scored is served unscored, and the only party who benefits is the one whose requests would have been refused. How routes change in practice: a new subnet added for a team, a peering or gateway attachment, a failover path exercised for the first time, a second public address attached to the workload, a region brought up for capacity. All of these are ordinary changes made by people with no idea the control's presence depended on them. ## Monitor for judgment, not for health The operating rule is that **absence of errors proves nothing**, so you need positive evidence: | Evidence | What it proves | What it does not | | --- | --- | --- | | Device is up and healthy | The box works | Nothing about whether traffic reaches it | | Judged-request count vs origin's served-request count | The two agree, so most traffic traversed it | Nothing about a path with low volume | | Origin sees a marker the control adds | These specific requests were judged | Nothing about requests that arrive without it unless you alert on them | | A probe sent per path that must be refused | That path is judged right now | Nothing about paths you did not probe | The count comparison is the cheapest and catches a wholesale reroute quickly. The marker turns the question around: instead of asking whether the control saw the request, the origin asks whether the request was seen, and unmarked traffic becomes an alert rather than a silent success. The probe is the only one that proves the control still **denies** rather than merely observes — but it proves it for exactly one hostname, port and route at one moment, so probes multiply with paths. ## What each posture costs There is no free position here. - **Transparent inline**: no client-visible change, easy to insert, and a continuous evidence burden. Somebody must own the counts, the markers and the probes, and must add a probe whenever the estate grows a path. Skip that and the control is a belief, not a fact. - **Named hop you run**: instantly detectable failure, at the cost of becoming a single point of failure for the service and of owning the outage when it breaks. Most estates that get this right end up treating *the control is in the path* as something they measure per route, on the same footing as uptime, rather than something they configure once. The question an interviewer is really asking is whether you know that a security control can stop working without failing.