An auditor asks you to prove a managed store cannot be reached from the internet — why is a private endpoint alone not proof?
answer
- the claim is about every caller
- the front door was never withdrawn
- the rule belongs on the thing being called
- route and acceptance are separate mechanisms
- refuse anything not arriving through the endpoint
basics
~20 sAn endpoint adds a private route; it does not retract the service's public front door. Any caller holding a valid credential still reaches that store from anywhere. The proof needs a resource-attached rule that refuses calls not arriving through the named endpoint.
solid answer
~40 sThe endpoint changes how *your* workloads get there. It does not change what the provider publishes to everyone else: the store's public address is still answered, still listening, and still willing to serve any request that presents an accepted credential. So a leaked credential or a forgotten automation outside the estate is unaffected by the private path. What closes it is a **resource-attached rule on the store** — a condition that allows only requests arriving through the named endpoint and denies the rest, evaluated by the service regardless of who the caller is. The network side (no internet route out of the workload subnets, filtering at the boundary) constrains your own traffic and is necessary, but it cannot constrain a caller you do not operate.
code
json · 17 lines{
"appliesTo": "store/customer-documents",
"rules": [
{
"effect": "allow",
"principal": "workload-identity/document-service",
"action": ["object:read", "object:write"],
"condition": { "arrivedVia": "private-endpoint", "endpointName": "documents-endpoint-a" }
},
{
"effect": "deny",
"principal": "any",
"action": ["object:any"],
"condition": { "arrivedViaIsNot": "private-endpoint" }
}
]
}go deeper
Hold on to the distinction: an endpoint changes the road your traffic takes, while who is allowed through the door is decided by the service.
Explain why the restriction has to live on the resource rather than on identities, and what the condition is actually testing about the request.
Sequence the rollout so enforcement lands after verification, name what the deny will break, and separate the preventive control from the detective alert.
Decide the estate standard: which data tiers must refuse the public path, how new stores inherit it through a guardrail, and what the loss of fallback costs in availability.
## The claim and what actually supports it "The store cannot be reached from the internet" is a claim about **every possible caller**, not about your workloads. A private endpoint is a statement about your workloads only: it gives them a route that stays on the provider's network. The store's public front door is a shared, published surface, and one tenant creating an endpoint does not withdraw it. So the honest answer to the auditor decomposes into three independent controls, each covering a different population of callers: 1. **Route** — the endpoint, plus the absence of an internet path from the workload subnets, means your traffic *takes* the private path. 2. **Resolution** — the private answer attached to those networks means your clients *find* the private path without being reconfigured. 3. **Acceptance** — a rule attached to the store itself refuses any request that did not arrive through the named endpoint, which is the only one of the three that binds callers outside your estate. Only the third supports the claim as stated. The first two support a weaker and still useful claim: that your own traffic does not leave the provider's network. ## Why the rule must be attached to the resource Permissions come in two shapes: attached to the **caller** (an identity carries what it may do) and attached to the **resource** (the thing being called carries who may reach it and on what terms). An identity-attached rule can only constrain principals you administer. The threat here is precisely the caller you do not administer — a credential that leaked, a partner's automation, an account created outside your boundary. Only a rule on the store evaluates *every* arriving request, including theirs. The condition the rule tests is the arrival path: the service knows whether a request came through a private endpoint and which one. In the common evaluation model an explicit deny outranks any allow, so the deny-unless-private rule survives an over-broad allow elsewhere — which is what makes it an evidence-grade control rather than a preference. ## What each control does and does not cover | Control | Covers | Does not cover | |---|---|---| | Endpoint in your range | your workloads' route | anyone else's route | | Private answer attached to your networks | your clients finding it | clients outside those networks | | No internet route from the subnet | your workloads leaving | callers arriving from elsewhere | | Resource-attached deny on the store | every caller, including unknown ones | the endpoint's own availability | | Guardrail above the account | new stores created without the rule | stores that already exist | ## The order to build them in 1. Create the endpoint and attach the private answer, so your own traffic is already on the private path. 2. **Verify** that it is — resolve from inside the network and confirm the address is in your prefix, because the next step will start refusing anything still on the public path. 3. Add the resource-attached deny. Expect it to find callers nobody knew about; that discovery is the control working, and it is why the order matters. 4. Add a guardrail above the account so a newly created store cannot ship without the rule, and an alert on refused public-path attempts so you learn about the ones that are still trying. ## Two directions to keep straight - **A preventive control stops the action; a detective control tells you it happened.** The resource-attached deny is preventive. An alert on public-path attempts is detective, and describing the alert as if it closed the path is the misstatement an auditor will catch. - **The private path does not imply permission, and permission does not imply a private path.** They are separate mechanisms that happen to be configured together here. A workload can be perfectly authorized and still be refused because it arrived publicly; a caller can arrive through the endpoint and still be refused because its credential grants nothing. ## The cost of getting it right Once the store accepts only the private path, the private path becomes a dependency with no fallback — by design. If the endpoint is placed in a single zone and that zone is lost, the workloads cannot fail back to the public address, because you deliberately made it refuse them. That is the correct trade for a regulated store and it is also the thing to say out loud in the review, because it converts a network convenience into a availability-relevant single path that deserves redundant placement.
- Why can an identity-attached permission not deliver the same guarantee?Because it only reaches principals you administer. The callers the auditor is worried about — a leaked credential, an automation outside your boundary — carry identities you never wrote a rule for. Only a rule attached to the store is evaluated for every arriving request, whoever sent it.
- What breaks the moment you add the deny, and how do you avoid an outage?Anything still resolving publicly starts being refused: forgotten batch jobs, a network that never received the private answer, an operator tool. Verify the private path is actually in use first, then run the rule in a reporting mode if the platform offers one, and alert on refused public-path attempts before enforcing.
- Once the store refuses the public path, what new availability question does that create?The private path has no fallback by construction. If the endpoint is placed in one zone and that zone is lost, callers cannot revert to the public address because you made it refuse them. That argues for a placement per zone, and for saying so explicitly in the design review.
saying these in an interview costs you the question
- Claims a private endpoint makes the service unreachable from the internet
- Puts the restriction only on identities the team administers
- Treats an alert on public-path calls as if it prevented them
- Adds the deny before confirming anything is on the private path
- Assumes an over-broad allow elsewhere outranks an explicit deny
- Forgets that refusing the public path removes the fallback