Front gateway, device agent, or a proxy beside the workload: which still denies a compromised workload's call to its peer?
answer
- field of view is decided by routing
- the device agent has no device here
- east-west traffic never reaches the edge
- one enforcement point becomes hundreds
- who is paged when the proxy fails
basics
~20 sOnly the proxy in the workload's own network path. A front gateway never sees a call that does not route to it, and a device agent enforces for a user's endpoint — a compromised workload is not an enrolled device. The proxy's price is one enforcement point per workload to keep consistent.
solid answer
~50 sAn implant on one workload calling a peer service inside the platform never crosses the front gateway, because that traffic is not routed there — the gateway can only deny what arrives at it. A device agent is the wrong shape entirely: it enforces on a user's endpoint using that endpoint's posture, and the attacker here is a server-side process with an inherited service credential, not an enrolled laptop. That leaves an enforcement point sitting in the workload's own network path, which is the only one of the three that is unavoidable for an east-west call. What it costs is real: you now operate one enforcement point per workload instead of one for the estate, their configurations drift, workloads that cannot be fronted need an exception, and the platform team owns a new failure mode where the proxy, not the application, takes the outage. That trade is the question — not which control is best.
go deeper
Know that a control can only deny traffic that reaches it, and that traffic between two internal services usually does not reach the edge at all.
Explain the field of view of each of the three positions and say precisely why a device agent cannot help a server-to-server flow. That distinction is the question.
Price the workload-adjacent position out loud: configuration drift across hundreds of enforcement points, the workloads that cannot carry one, and the outage your team just adopted.
Argue the mixed estate: which flows are worth per-workload enforcement, which stay behind the edge, and what the exception list you are signing for actually contains.
## Three positions, three different fields of view A zero-trust decision is worthless until something executes the deny. There are three common places to put that something, and they differ not in policy but in *what traffic is physically obliged to pass them*. **Front gateway (north-south).** Sits at the platform edge. Every request routed to it can be authenticated, authorised and denied. Its field of view is exactly the set of flows that routing delivers to it. It sees a user hitting an application; it does not see one workload calling another inside the platform, because that traffic has no reason to go near it. **Device agent.** Runs on an endpoint and decides whether that endpoint's traffic may reach a resource, using signals it can gather locally. Its field of view is one device's outbound traffic. It is the right control for the laptop-to-application problem and it is structurally unable to help with a server-side process: there is no enrolled device, and the credential in play is a service identity the workload was issued, not a user's. **Proxy beside the workload.** An enforcement point in the workload's own network path, so that any call the workload makes or receives passes it regardless of who initiated it. This is the only one of the three that is unavoidable for an east-west call. ## The scenario that separates them A batch worker on the shared platform is compromised — a dependency it pulled at build time carried an implant, and the process now holds the service credential the platform issued that workload. It starts calling a peer service's internal API, using that credential, from inside the platform network. | Enforcement position | Does the deny execute? | Why | | --- | --- | --- | | Front gateway | No | The call never routes to the edge; nothing arrives to be denied | | Device agent | No | There is no enrolled endpoint; the actor is a server process | | Proxy in the workload's path | Yes | Every call the workload makes traverses it by construction | The common wrong answer from a competent engineer is *the gateway, because we already terminate and authorise there*. The correcting fact is that terminating at the edge tells you nothing about a flow that never goes to the edge. Authorisation quality and enforcement reach are independent properties, and only the second one is decided by position. ## What the workload-adjacent position costs This is the half candidates skip, and it is the half the interviewer is paying for. 1. **N enforcement points instead of one.** A front gateway is one thing to configure, patch, capacity-plan and reason about. A proxy per workload is hundreds. They will drift. Two workloads with the same intended policy and different effective policy is a gap that neither console shows you. 2. **Something must be true for every workload.** Any workload that cannot carry the proxy — an appliance you did not build, a legacy binary with a fixed network stack, a job whose runtime you do not control — is an exception, and every exception is a hole in exactly the property that made this position attractive. 3. **A new outage owner.** When the proxy fails, the application is down and the application team did not change anything. The platform team inherits that page, and that is an organisational cost as much as a technical one. 4. **Resource overhead per workload.** Memory and CPU alongside every instance, and added latency on every internal hop, multiplied by the number of hops a request makes. 5. **It still does not cover everything.** An attacker with node-level access sits underneath the proxy, and an operator opening a shell inside the workload is already past it. ## How to answer it well Say what each position can and cannot see, name the one that covers the east-west case, then price it — and finish by naming what still gets through even after you pay. An answer that stops at *use a proxy beside every workload* has chosen a control; an answer that adds *and here are the workloads that cannot carry one, here is who signs for those, and here is the failure mode I have just moved onto my team* has designed one. It is also fair to say the positions are not exclusive. Most real estates run the gateway for north-south, workload-adjacent enforcement for the flows that matter most, and a written exception list for the rest — because covering every flow at every position is a bill nobody has agreed to pay.
- Could you fix this by hairpinning east-west traffic through the front gateway instead?You can, and some estates do. The cost is that the gateway's capacity now has to carry internal traffic volumes, every internal call inherits the edge's latency and availability, and the traffic pattern becomes a single blast radius. It also only works for flows the gateway can address and parse; anything that talks a protocol it does not understand passes as an opaque tunnel.
- What does an attacker with node-level access do about the workload-adjacent proxy?They sit underneath it. If the enforcement point runs alongside the workload on the same host and the attacker controls the host, they can reach the peer service directly, read the workload's credentials, or alter what the proxy sees. Workload-adjacent enforcement raises the cost of east-west movement; it does not survive an adversary who owns the layer beneath it.
- How do you decide which flows deserve workload-adjacent enforcement first?Start where a lateral call would be worst and where the flow is well understood: the services holding regulated data, the shared credential stores, the platform's own control plane. Those give you the largest reduction per enforcement point deployed, and they are the flows you can describe precisely enough to write a deny that will not break a business path on the first day.
saying these in an interview costs you the question
- Says the gateway covers east-west because it authorises everything
- Proposes a device agent for a server-side workload with no endpoint
- Claims a proxy beside every workload makes lateral movement impossible
- Ignores that workloads which cannot carry a proxy become exceptions
- Never names who is paged when the enforcement point itself fails