skip to content

Where the Deny Lands

An enforcement point only enforces if there is no other route to the application, and legacy protocols and admin interfaces usually still have one. Interviewers ask where the deny actually lands.

on this pageshow

questions

4

A zero-trust deny runs at your platform's front gateway — which paths to the same application never touch it?

level: juniorimportance: must knowfreq 62%

answer

  1. draw every arrow, not the one on the diagram
  2. north-south is one path of several
  3. operators and batch jobs use no front door
  4. the control API answers on its own network
  5. paths with no enforcement need a named owner

basics

~20 s

Usually several: an operator opening a shell inside a running workload, node-level access to the host, the platform's own control API on a management network, workload-to-workload calls that never leave, and outbound batch traffic. A front gateway only sees what routing sends it.

solid answer

~50 s

The gateway enforces on north-south traffic that routing actually delivers to it, and on an internal container platform that is one path of five or six. The others: an operator opening a shell inside a running workload through the platform's control API; node-level access to the host, where an attacker reads the workload's own credentials off disk or memory; workload-to-workload calls between teams' services that never leave the internal network; batch jobs dialling outward to partner APIs; and whatever legacy client still connects to a database or message broker directly. Each of those is a path an adversary who already holds a platform credential or a foothold on one workload can use without the deny ever executing. The design step is to draw every arrow into the application, mark which one the deny runs on, and write down an owner for each arrow that has no enforcement.

go deeper

for a junior

Be ready to list the paths into one application out loud: front door, operator shell, node access, peer workloads, outbound jobs, legacy clients. Naming them in a scenario is what is being tested, not the fix.

for a middle

Explain why a gateway only enforces on traffic routing delivers to it, and what changes if you hairpin internal callers through it. Interviewers want the mechanism, not the slogan.

for a senior

Show the design habit: enumerate every arrow, mark where the deny actually executes, and produce a written exception with an owner for each arrow you cannot cover yet.

for a principal

Own the argument that an uncovered path is a budget question, not a technical one. Be ready to say which paths you will fund closing this year and who signs for the rest.

## The claim a gateway actually supports A zero-trust enforcement point denies exactly the traffic that reaches it. That is a statement about routing, not about architecture diagrams. When the deny lives on the front gateway of an internal container platform, what you have proven is: *requests that were routed to the gateway and refused did not reach the application*. You have proven nothing about requests that arrived by any other route. On a shared application platform, the arrows into one application typically look like this: | Path | Does the front gateway see it? | What an adversary needs | | --- | --- | --- | | User or partner request over north-south ingress | Yes | Nothing special — this is the path you designed | | Operator opens an interactive shell inside the running workload | No — it arrives through the platform's control API | A platform credential with exec-equivalent rights | | Node-level access to the host running the workload | No | A foothold on the node, or the node's own credentials | | Another team's workload calling this one directly | No — the traffic never leaves the internal network | An implant or a bug in any peer workload | | This application's batch job dialling out to a partner API | No — it is outbound | Control of the job, or of what the job talks to | | Legacy client connecting straight to the database or broker | No | Reachability plus the shared credential everybody has | | The platform's own management API answering on the management network | No — it is a different service entirely | Access to that network segment | The last two rows are the ones candidates forget, and they are the ones that get used. A legacy path exists because somebody could not be migrated; a management path exists because the platform has to be operable. ## Why this is the first question asked The common wrong answer is that the gateway is the chokepoint, so covering it covers the application. That is true only if every one of the rows above either does not exist or is separately denied. In a real estate none of them are absent — a platform without an operator path is a platform nobody can fix at 3am, and a platform without outbound batch traffic is not doing any work. So the honest answer to *where does the deny land* is a list, not a box. For each arrow you either: 1. **Route it through the same enforcement point** — put the internal callers through the gateway too, so east-west traffic pays the same toll. This costs latency, a hairpin through a shared box, and a capacity line item, and it does not work for paths the gateway cannot parse. 2. **Give it its own enforcement point** — a proxy in the workload's own network path, an admission check on the control API, a jump path with its own authentication for node access. 3. **Write it down as an exception with a named owner and an expiry** — the legacy client, the vendor appliance nobody can put an agent on, the break-glass path. Option 3 is not failure. Refusing to write it down is. An undocumented path is a path with no owner, and an owner is the only thing that ever gets it closed. ## What this costs Covering every arrow is where the money goes. Hairpinning east-west traffic through the front gateway multiplies its throughput requirement and puts every internal call behind one box's availability. Standing up a second enforcement point per workload means every workload now carries something extra that must be configured identically, and drift between two of them is a gap nobody can see from either console. Denying the operator path means the operator now needs an alternative that works under pressure, or they will find a way around it and you will discover that during the next incident. ## The wording that separates a good answer A good candidate does not answer with a control list. They answer with a drawing: here are six arrows into this application, the deny executes on one and a half of them, here is what I would do about each of the rest, and here is the name against the two I cannot fix this quarter. That is the artefact this question is fishing for.

  • You cannot cover one of those paths this quarter. What do you put in writing?
    A named exception: the path, why it exists, what the compensating control is, who owns it, and a date it is reviewed. An exception with an owner and an expiry gets closed; an undocumented path never does. The owner should be someone who can actually authorise the migration that removes it, not the security engineer who merely noticed it.
  • Would routing internal callers through the same front gateway solve this?
    It closes the east-west arrow at a real price: the gateway's throughput requirement now includes internal traffic, every internal call inherits its latency and its availability, and traffic the gateway cannot parse still passes untouched. It is a legitimate design, but it converts a visibility gap into a capacity and blast-radius decision that someone has to fund.
  • Where does the platform's own control API fit in this list?
    It is a separate application with its own front door, usually on a management network, and the deny at the application gateway does not apply to it at all. Anyone who reaches it with sufficient rights can reach inside the workload without ever generating a request the gateway sees. It needs its own enforcement point and its own access review.

A guarded front lobby proves nobody walked in the front door. It says nothing about the loading dock, the roof access the maintenance crew uses, or the phone line into the building's own control room.

saying these in an interview costs you the question

  • Calls the gateway the chokepoint because the diagram shows one arrow
  • Counts only inbound user traffic and forgets outbound batch calls
  • Assumes the platform control API is safe because it is internal
  • Treats the operator shell path as out of scope because it is authenticated
  • Says east-west traffic is covered without saying what routes it through the gateway

context

open as a page

Front gateway, device agent, or a proxy beside the workload: which still denies a compromised workload's call to its peer?

level: middleimportance: should knowfreq 55%

basics

~20 s

Only 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.

open as a page

An app's accept log shows connections from the node network, not the ingress gateway — what does that prove and what does it not?

level: seniorimportance: should knowfreq 44%

basics

~20 s

It proves the application accepted connections from a source that is not the enforcement point, so a path exists around the deny. It does not prove malice, does not identify who was behind them, and covers only the paths used during that window — not every path that exists.

open as a page

The platform team keeps a standing break-glass path around the enforcement point — how do you govern it?

level: principalimportance: nice to knowfreq 31%

basics

~20 s

Treat the bypass as its own control: one named owner, an expiry that defaults to removal, its own strong authentication, and every use reviewed by someone who did not make it. Then make the normal path fast enough at 3am that nobody prefers the bypass.

open as a page