A managed entry point keeps its public address when the machines behind it are replaced, so what makes that address a separate rented resource?
answer
- the door is not the machine
- rented identity, not host property
- allocation outlives the instance
- three states: pooled, attached, idle
- release is explicit and final
basics
~20 sThe address is allocated from the platform's pool and held by the entry point resource, not by any machine. It outlives instance replacement, is usually charged while you hold it, and goes back to the pool only when you release it.
solid answer
~50 sA public address on a rented machine is a property of that machine's network attachment: it is handed out at start and, unless you reserved one, returns to the platform's pool when the instance is replaced. A managed entry point inverts that. The public identity — an address, or a name resolving to several — belongs to the **entry point resource**, so everything behind it is disposable: you can rebuild the fleet, shift between two versions, or scale the workload to nothing without any client noticing. That identity has its own lifecycle. It is allocated, it can sit idle while attached to nothing, it is usually charged for as long as you hold it, and releasing it hands it back to the platform. Deleting an entry point whose address you never reserved is the accidental version of releasing it.
go deeper
Recall that the public identity belongs to the entry point, not to the machines behind it, which is why replacing a machine is invisible to clients.
Explain the allocation's three states and what each costs: pooled, allocated-and-attached, allocated-and-idle, plus why releasing has no undo.
Show that you plan the identity before an environment is deleted or re-platformed, and that you know when a pinned address is worth the flexibility it takes away.
Frame the identity as a contract with people outside your team: who may depend on it, what you promise about it, and what it costs the organisation to change.
## The three things a managed entry point bundles A **managed entry point** is the front of your service that the platform runs instead of you running it on a machine you rent. Whatever a provider calls it, it bundles three things: a **reachable public identity** (an address, or a name that resolves to several addresses), a **pool of capacity** that accepts client connections and forwards them to your workloads, usually spread across more than one availability zone, and a place where **TLS is terminated** using a certificate. This question is about the first of the three, and it is the one that most often surprises someone whose experience is administering hosts, because on a host the public address feels like a property of the box. ## An address on a machine, and an address on the door On a rented machine, the public address is attached to that machine's network attachment. It is handed out when the instance starts and, unless you deliberately reserved one, it returns to the platform's pool when the instance stops or is replaced. That makes an instance address a poor thing for anyone outside to depend on: it has the lifetime of the instance, and instance lifetimes are short on purpose. A managed entry point inverts the relationship. The public identity belongs to the **entry point resource**. The machines, containers or functions registered behind it can be created, replaced, moved to another zone, or scaled to nothing, and the identity clients use does not move — because clients never held a machine's address in the first place. The entry point is the stable thing; everything behind it is disposable. | what holds the identity | how long it lives | what a replacement behind it does | safe for a client to depend on | |---|---|---|---| | an instance's own public address | as long as that instance | the address is lost and a new one appears | no | | the entry point's published name | as long as the entry point | nothing visible changes | yes | | a reserved address you allocated | until you release it | nothing visible changes | yes, once attached | ## The allocation has its own lifecycle Treat the public identity as a resource you hold, in one of three states: 1. **In the platform's pool** — unallocated, belonging to nobody. 2. **Allocated and attached** — held by your account and in use by an entry point. 3. **Allocated and idle** — still held by your account, attached to nothing. Two consequences follow, and both are asked about. First, a held allocation is usually **charged**, and on many platforms it is charged precisely while it is idle, because a scarce address sitting unused costs the provider the same as one in service. Second, releasing is an **explicit act with no undo**: once the allocation returns to the pool another tenant may take it, so you should not plan on recovering it. Deleting an entry point whose address you never reserved is that same release by accident. ## Why the mechanism matters beyond trivia - You can rebuild the entire fleet behind the door without telling a single client. - You can run two versions side by side and shift traffic between them, because the identity belongs to neither. - You can let capacity scale to nothing overnight without losing your place on the internet. - You can hand a partner one identity that survives your internal re-platforming. - You know, before you delete an environment, what has to be reserved if the identity must come back. ## Where provider designs differ Some platforms give each entry point a single stable address and let you pre-allocate it. Others publish a **name** in front of a set of addresses that the platform changes as the pool grows, moves or heals, and offer a pinned address only on certain tiers or for an extra charge. Both are the same model — the identity is the platform's resource rather than your machine's property — but the portable rule is: **depend on the published name unless you have explicitly reserved an address**, and if something really must depend on the address, make the reservation a deliberate, documented decision rather than an assumption. ## What holding an identity does not decide Holding a public identity says nothing about how requests are spread across your workloads, which one receives a given request, or how long a connection may sit idle — that behaviour is a separate subject. It also says nothing about **who may call you**: an address is reachability, and authorization is an entirely different mechanism. Being reachable at a stable address has never been, and is not, a permission.
- You delete a managed entry point and create a replacement the same afternoon. What must clients be told, and what would have avoided that?Unless you had reserved the address as its own resource, the identity went back to the platform's pool and the replacement drew a new one, so every client that depended on the old address has to be updated. Reserving the allocation first, then attaching it to the replacement, avoids the conversation entirely.
- Why is depending on the published name usually better than depending on the address, even when a stable address is available?The name lets the platform grow, move or heal the pool behind it without coordinating with you or your callers, and it leaves you free to change tier or region without a second migration. Pinning an address gives that flexibility away, so it should be a decision you took for a stated reason.
A rented number at a mail centre: the centre keeps the number, and you can change which desk sorts the post behind it without writing to anyone who sends you letters.
saying these in an interview costs you the question
- Thinks the public address belongs to the machine and dies with it
- Assumes a released address can be reclaimed later on request
- Believes an allocated address attached to nothing is free
- Treats the entry point's address as something configured on the host
- Expects an address to survive deleting an entry point that never reserved it