A partner-facing exchange tier terminates inbound sessions but may never open one inward — what does that deny an intruder who lands on it?
answer
- who is allowed to be the initiator
- no tier-sourced connection crosses inward
- connection direction is not data direction
- the interior still collects what you leave
- poll latency plus duplicated services
basics
~20 sIt denies them a network path they can start: no socket opened from a tier host reaches an interior service. It does not deny them the tier's own data, or content the interior later collects of its own accord.
solid answer
~50 sThe rule removes exactly one thing: the ability of a host in the exchange tier to be the *initiator* of a connection toward the interior. The inner firewall drops any tier-sourced connection attempt, so an intruder who owns the file-transfer box cannot scan interior ranges, dial a database port, or authenticate to an interior directory. What survives is everything the tier already holds — partner files in flight, the credentials in the tier's own configuration, the outbound path back to partner networks — and, critically, any content the interior collects on its own initiative: poison the drop location and the interior fetches it faithfully. The bill is architectural. Every integration that needs interior data must be inverted into a pull or a queue, which adds a poll interval to each transaction, and the supporting services the tier needs must be duplicated inside it rather than reached inward.
go deeper
Be ready to state the rule in one sentence — the tier answers connections and never starts one toward the interior — and to say where it is enforced: the inward-facing firewall, on the packet that opens the flow.
An interviewer expects you to separate the connection from the payload: explain how an interior-initiated collection still carries data inward, and why the reply needs no second inward permit.
Show what survives the rule. Name the residual paths — content the interior collects, the tier's stored data and keys, the outbound path to partners — and name the price you accepted: collection latency and duplicated supporting services.
Own the argument that the rule is worth its bill: what you tell a business owner who wants one synchronous inward call, how many exceptions the tier is permitted to hold at once, and who renews them.
## The rule, stated precisely An outward-facing exchange tier — the stand-alone zone that terminates partner file transfer, an ordering portal and a document-exchange service for counterparties — sits between the public internet and an interior nobody will let it touch. The classic rule that defines it is not "the tier is filtered" or "the tier is monitored". It is a statement about *who is allowed to be the initiator of a connection*: - The tier may **accept** connections from the internet (and from the interior). - The tier may **never open** a connection toward the interior. That is a rule the inner firewall — the leaf of the two-firewall sandwich that faces inward — can actually enforce, because a stateful filter decides on the packet that starts the flow. A connection attempt whose source address is in the tier and whose destination is inside is denied on the first packet; nothing that follows exists. ## Why it is stated that way and not as "the DMZ is untrusted" "Untrusted" is a label. "May not initiate" is a testable property. You can prove it: from a host in the tier, attempt a connection to an interior address and show it is refused, and produce that evidence on a schedule. That is the difference between a zone drawn on a diagram and a boundary you can defend in a review. ## What it actually denies an intruder Assume the worst realistic case: someone exploits the document-exchange service and now runs code as that service on a tier host. The rule takes away: - **Reconnaissance by connection.** They cannot sweep interior ranges, because every probe is an outbound connection attempt from the tier. - **Direct service access.** No database port, no file share, no interior management interface, no interior directory to authenticate against — even with a valid credential, because the credential never gets a socket to present itself on. - **Interactive footholds.** No shell dialled back to an interior jump host, no lateral move by remote administration. That is a genuinely large reduction, and it is the whole reason the tier exists as a separate thing rather than as "some servers on the inside with holes punched to them". ## What it does not deny — and this is where candidates lose the question 1. **Everything already in the tier.** Partner documents, orders, transfer credentials, the private keys the tier terminates TLS with, the partner account list. If your answer to "what did we lose?" is "nothing, it was only the DMZ", you have not looked at what the DMZ holds. 2. **The outbound path to partners.** The tier legitimately talks to counterparties. An intruder inherits that: an ordering portal that pushes files to a partner is a data path out and a way to reach the partner's estate from a host the partner trusts. 3. **Content the interior collects.** The rule constrains connections, not data. If an interior job polls a drop location in the tier, the intruder does not need an inward socket — they write into the drop and the interior collects it. The network-path risk has been converted into a content risk, and the interior side must treat what it collects as hostile input: fixed schema, size ceilings, no path traversal from filenames, no format the collector's parser cannot safely refuse. 4. **Replies on interior-opened connections.** When the interior opens a session to a tier service, a compromised tier host controls what comes back. Anything the interior does with that response — parsing, deserialising, rendering — is attack surface reached from a zone you declared untrusted. ## The price the defender pays The rule is not free, and an interviewer asks about the cost to see whether you have built one or only read about one: - **Inverted integrations.** Anything the tier needs from the interior becomes an interior-initiated pull or a message queue. That adds a poll interval to every transaction — a partner order that could have taken 200 ms of synchronous lookup now waits for the next collection cycle — and it makes the drop location a component you own, back up and monitor. - **Duplicated services.** The tier's own applications need name resolution, some directory for their service accounts, and a way to validate certificates. Each of those either becomes a hole inward, which weakens the rule, or a second copy living in the tier, with its own patching, backup and lifecycle. - **Exception pressure.** Sooner or later one integration needs a synchronous inward call, and the exception has to be argued, narrowed, documented and re-justified at every review. ## How to answer it in a loop Say the rule in terms of initiation, name the enforcement point (the inner firewall, on the connection-opening packet), then split the answer into denied / not denied / paid for. Candidates who stop after "it stops lateral movement" sound like they have read a diagram. Candidates who say "it stops them opening anything inward; it does not stop them poisoning what we come and fetch, and we pay for it in poll latency and duplicated services" sound like they have run one.
- If the tier may not initiate inward, how does a partner order ever reach an interior system of record?The interior comes and gets it. An interior job opens the connection outward to a queue or drop location in the tier and collects the message; the payload travels inward on a connection the interior started, so no inward-initiated permit exists. The cost is the collection interval and the need to validate everything collected as untrusted input.
- Name one thing the rule does not protect the interior from.Content-borne compromise. Whatever an intruder writes into the drop location, the interior fetches and parses. The same applies to responses on connections the interior opened to tier services — a compromised tier host chooses what comes back, so the interior's parser and deserialiser are reachable from a zone you have already declared untrusted.
- How would you prove to a reviewer that the boundary really denies?Test it from the untrusted side rather than reading the rule base. Run a scheduled attempt from a host in the tier to a set of interior addresses and ports, capture the refusals, and keep the output as evidence. A rule base that reads correctly and a boundary that behaves correctly are different claims, and only the second survives a change nobody told you about.
A night-deposit slot: the bank never opens a door outward to the courier, so the courier can never walk in — but whatever they push through the slot, the bank still takes inside and counts.
saying these in an interview costs you the question
- Says a compromised DMZ host is contained and harmless
- Thinks the rule also stops the interior's own pulls
- Confuses who opens the connection with which way data flows
- Forgets the tier holds partner data, keys and credentials
- Ignores the outbound path from the tier to partner networks
- Treats the tier as trusted once a firewall sits in front of it