How do you justify a second enforcement hop behind the VPN head-end when cost and a peer argue for one box?
answer
- a value statement loses to a number
- write the consequence, per position
- you write the claim, they sign it
- price your own proposal first
- the cheap variant: move, do not buy
basics
~20 sStop arguing defence in depth. Write what a fully-owned head-end could originate from each candidate position, have a risk owner sign it, price the second hop honestly, and offer the variant that needs no purchase.
solid answer
~50 sA slogan loses to a budget line, so convert the argument into a decision someone must sign. Write, for each candidate position, exactly what a fully-owned head-end could originate: from the core VLAN it is everything the core routes; from a screened tier it is an enumerable list you can print, including the authentication flow you cannot remove. Hand both to the risk owner — your job is the claim, not the verdict. Then price your own proposal: a throughput licence sized for peak, a second rule base that will drift, dual change windows, an extra failure domain whose posture you must declare, and the exception pressure that will ask for a broad allow. Finally offer the cheap variant, because it usually wins: land the leg in a screened tier that already has an enforcement point.
go deeper
Know that a security design has a price and that someone other than the engineer decides whether it is worth paying.
Be able to itemise what a second enforcement hop costs — licence, second configuration, extra hop, extra failure domain — rather than only its benefit.
Show how you would write the consequence of each landing position concretely enough that a non-engineer can compare them, and how you would test the claim afterwards.
Own the whole decision record: the written claim, the risk owner's signature, the declared failure posture, the cheaper variant you offered, and the review cadence that keeps the design from decaying into an exception list.
## Why the technical argument loses this room At a design review, "defence in depth" is a value statement and the peer's "one box, half the cost, half the operational burden" is a number. Numbers beat values. The way to win — or to lose honestly — is to convert your position into something with the same shape as theirs: **a written claim about consequence, and a price**. ## The artefact: a blast-radius statement per position For each candidate landing zone, state in writing what a fully compromised head-end could originate. Not what it is *expected* to do; what it *could* do. - **Inside leg on the core VLAN:** everything the core routes, sourced as ordinary internal traffic, with no device other than the compromised appliance in a position to deny it. - **Inside leg in a screened tier behind a separately administered device:** an enumerable list — the authentication flow to the identity store, logging and time, plus whatever else that rule base permits from the head-end's address. It is a list you can print and hand over. That difference is the whole decision, and stating it as two paragraphs someone must sign changes the conversation from architecture taste to accepted risk. **You write the claim; the risk owner accepts or rejects it.** An architect who tries to own the decision as well as the claim usually gets neither. ## The price, stated by you before it is used against you Credibility here comes from being the person who names the cost first: - **Licence and sizing** for peak remote-access load, not average. - **A second rule base** describing the same intent, which drifts; every new internal service is two changes, often in two teams. - **Dual change windows** and a slower path for routine requests, which is what people actually feel. - **A new failure domain.** The extra device can take remote access down alone. Declare the failure posture — for remote access, failing closed is normally defensible because it is an optional path with a known alternative — and get that signed too, because at 3 a.m. someone will want to bypass it. - **Latency and MTU** on both directions of every remote flow, on top of tunnel overhead. - **Exception pressure.** The first broad allow for the head-end's address, requested for backup or clustering or a migration, converts the second position back into the first. Without a named owner and a review cadence for that rule base, the design has a shelf life. ## The move that usually wins Offer the variant that delivers the same consequence claim without the purchase: relocate the inside leg into a screened tier that **already** has an enforcement point in front of it. You pay a routing change, an outage window, and the negotiation to remove any leftover adjacency that would let return traffic skip the device. You still inherit the second rule base and its drift, but not the licence and not a new failure domain. Proposing this makes you the person solving the peer's problem rather than the person spending their budget. ## What to concede Concede that if both devices are administered by the same team with the same credentials, the second hop bounds a network-level compromise but not a full administrative takeover — so if the budget only stretches to the hop and not to separating administration, say what the hop does and does not buy. Concede that the enumerable list is not empty. Conceding the weak parts is what makes the strong parts believable, and a peer who cannot get you to overclaim generally stops trying. ## The decision record Whatever is chosen, the output is a record: the two statements, the chosen position, the accepted residual, the failure posture, the owner of the second rule base, and the review cadence for exceptions to it. That record is what someone reads in two years when a request arrives to add a broad allow, and it is the only thing that makes the answer "no" survivable by the person who has to say it. ## Interview framing The interviewer is checking whether you can operate where the money is. Lead with the written claim and who signs it, price your own proposal before the peer does, offer the cheaper variant, name what you concede, and finish with the review cadence. A candidate who only says "terminate outside, it is best practice" has not been in this room.
- The risk owner accepts the core-VLAN landing to save the money. What do you do?Record it as an accepted residual with their name on it, in the same words you wrote the claim in, and then spend your effort on what is still available at no capital cost: tightening what the head-end's inside leg can address, removing standing administrative reachability to the box, and setting a review date tied to the next refresh. Escalating past a decision that was legitimately taken is how architects lose the next argument.
- What failure posture would you propose for the extra device, and who signs it?Fail closed for remote access, signed by the business owner of remote working rather than by the network team. Remote access is an optional path with alternatives, and a device that fails open under load is not a boundary you can make a claim about. The signature matters because the pressure to bypass arrives during an outage, when the person who wants it is senior and the person refusing is on call.
- How do you stop the second rule base from decaying into a broad allow?Name an owner for it who is not the head-end's administrator, require every permitted origination from the head-end to appear on the written list attached to the design record, and review that list on a fixed cadence rather than per request. The point is that adding a line requires editing the blast-radius claim someone signed — which is a much harder conversation than editing a rule.
saying these in an interview costs you the question
- Arguing defence in depth without pricing the second hop
- Presenting the decision as the architect's to make rather than the risk owner's
- Claiming the second device bounds a takeover under shared administration
- Ignoring that remote access now has an extra failure domain
- Treating a new appliance as the only way to reach the outside position
- No review cadence for exceptions to the second rule base