skip to content

Your partner only accepts calls from one fixed source address — which outbound path makes every call from an autoscaled batch arrive from it?

level: seniorimportance: should knowfreq 44%

answer

  1. the partner sees a path, not a workload
  2. one door, one address
  3. reserve the address independently
  4. per-zone gateways multiply the list
  5. verify from outside, not the console

basics

~20 s

Route all of the batch's outbound traffic through one address-translating gateway holding a reserved public address, and give the workloads no public addresses of their own. Replica count, restarts and replacements then do not change the address the partner sees.

solid answer

~40 s

Source-address stability is a routing decision, not a workload property. Point the batch subnets' default route at a single address-translating gateway whose public address is **reserved** rather than drawn from a pool at creation, and make sure no replica carries a public address of its own — otherwise some calls leave directly and arrive from an address the allowlist has never seen. Four things still break it: a per-zone gateway design, where each gateway has its own address and the partner must allowlist all of them; a gateway rebuilt without its reserved address; a more specific route sending some destinations out a different door; and any second egress path added later. Keep the set of addresses small, documented and owned, and treat a change as a coordinated one with the partner's own lead time.

go deeper

for a junior

Recall that the address a partner sees comes from the translating gateway the traffic left through, not from the workload that made the call.

for a middle

Explain how to make it stable: no public addresses on workloads, one default route to one gateway, and an address reserved independently so a rebuild reattaches it.

for a senior

Enumerate what breaks it in a real estate — per-zone gateways, a second exit, a more specific route, a rebuilt gateway — and verify from outside rather than trusting configuration.

for a principal

Treat the egress address set as a published interface with an owner and a deprecation window, and weigh the partner's human lead time as a real constraint on any network redesign.

## Why the address the partner sees is a routing property When a partner allowlists you by source address, the thing they are matching is whatever address the last translating hop put on your packets. Nothing about your workloads is visible to them: not the replica count, not the private addresses, not which zone a replica happened to start in. That makes the problem tractable, because a single routing decision fixes it — **every flow leaves through one device whose public address you control** — and it makes the failure modes specific, because each one is a way for some flow to leave through a different device. ## The design that holds 1. **No public address on any workload.** A replica holding its own public address leaves directly, with an address the partner has never seen, and the failure shows up only for the fraction of calls that landed on that replica. 2. **One address-translating gateway, with a reserved address.** Providers distinguish an address handed out at creation from one you allocated and hold independently of any resource. Only the second survives a rebuild. This is the single most common cause of an allowlist breaking months later during a routine replacement. 3. **A default route in each batch subnet targeting that gateway**, and no more specific entry quietly sending the partner's range somewhere else. 4. **A documented, owned list of the addresses the outside world sees your estate as** — short, explicit and reviewed when anything about egress changes. ## What multiplies the addresses | design choice | addresses the partner must accept | |---|---| | one gateway serving every subnet | one | | a gateway per zone, each subnet routed to its own | one per zone | | a second exit for some destinations (a circuit, another attachment) | one more, and only some calls use it | | workloads holding their own public addresses | one per workload, changing on replacement | The per-zone case is worth calling out because it is often the right decision for other reasons — a zonal device serving other zones is a concentration you may not want — and it costs you an allowlist entry per zone. That is fine when it is a deliberate trade-off recorded with the partner, and a mystery outage when it is discovered after the fact. ## What a source-address allowlist is actually worth Be honest about this in an interview, because a strong candidate volunteers it: - **It identifies a path, not a caller.** Anything routed through that gateway inherits the same trust — another team's workload in a subnet pointed at the same door looks identical to the partner. - **It is coarse and it is brittle.** It cannot express which service, which environment or which operation, and it breaks on a change the partner cannot see coming. - **It is a network control, not authentication.** It belongs underneath a credential the partner verifies, never in place of one. - **It has a human lead time.** Changing an allowlisted address is someone else's change-management process, measured in days, and that lead time is the real constraint on any egress redesign. ## Operating it - **Treat the egress addresses as a published interface.** They are as much a contract as an API is, and they should change through the same kind of coordination. - **Reserve first, route second.** Allocating the address independently of the gateway means a rebuild reattaches the same one. - **Verify from the outside.** The only trustworthy check is what a service outside your network reports as your source address, from every subnet the batch can run in — not what the console says the gateway holds. - **Watch for drift.** A new subnet added to the batch's deployment and associated with a different table is enough to send a fraction of calls out a different door, and the resulting failure looks intermittent rather than structural. The short answer: one translating gateway, one reserved address, no public addresses on workloads, one default route — and an explicit note of every case where that count is not one.

  • The batch runs in three zones and each zone routes to its own gateway. What must the partner accept?
    All three addresses. Each gateway translates onto its own, so a per-zone design trades a concentration you did not want for two extra allowlist entries. It is a reasonable trade as long as the full set is documented and given to the partner up front, rather than discovered when one zone's calls start failing.
  • Is a source-address allowlist enough to authorise the call?
    No. It identifies a path rather than a caller: anything routed through that gateway arrives with the same address and inherits the same trust. It cannot distinguish services, environments or operations, so it belongs underneath a credential the partner verifies, not instead of one.
  • What is the practical constraint when you need to change the egress address?
    The partner's own change process. Their allowlist is edited by people on their schedule, so the sequence is: allocate the new address, have both accepted in parallel, cut the route over, verify from outside, then have the old one removed. Treat the egress address as a published interface with a deprecation window.

saying these in an interview costs you the question

  • Says an autoscaled workload cannot have a stable source address
  • Assumes a rebuilt gateway keeps its address automatically
  • Treats a source-address allowlist as authentication
  • Forgets that a per-zone gateway means several addresses
  • Verifies the address from the console instead of from outside