skip to content

Why is a region-scoped resource invisible to the same platform API call made against a different region?

level: middleimportance: should knowfreq 46%

answer

  1. scope is a property of the service
  2. the endpoint answers for one region
  3. listing everything means iterating regions
  4. identity and billing sit above regions
  5. a forgotten region still bills

basics

~20 s

Because most resources and the endpoints that list them are scoped to one region: the call is answered by that region's own management plane, which knows nothing about another region's resources. Only a small set of platform services is genuinely global.

solid answer

~50 s

Scope is a property of the service, not of your intent. Most platform capabilities are regional: the resource exists inside one region, and the management endpoint you call is that region's, so a listing call answers only for the region it was addressed to. A smaller set sits above regions — the account itself, its identity records, billing, and on many platforms the organisation hierarchy and parts of the global traffic entry tier — and those answer once for the whole account. Three practical consequences follow. An inventory tool has to iterate regions and then add the account-wide services, or it will under-report. A resource left in a region nobody looks at keeps existing, keeps billing and keeps its access surface. And a name that is unique within one region may not be unique across the estate, because uniqueness is scoped the same way the resource is.

go deeper

for a junior

Remember that a management call is addressed to a region. An empty result usually means you asked the wrong region, not that the resource disappeared.

for a middle

Explain the split: most services are regional and answered by that region's plane, while account identity, billing and a few entry-tier services are account-wide, so inventory means iterating regions plus the global set.

for a senior

Show the operational consequences you have actually hit — forgotten regions still billing and still reachable, name collisions that were legal, and tooling that reported a subset with total confidence.

for a principal

The standard worth owning is that every inventory, budget and security control enumerates regions deliberately, including the ones nobody deploys to, so absence from a dashboard never doubles as evidence of absence.

## Scope is a property of the service Every platform capability answers a question you rarely ask explicitly: **where does this thing exist?** There are two common answers. - **Regional.** The resource lives inside one region, its state is held by that region's own management plane, and the endpoint you call to create, list or delete it is that region's endpoint. A call addressed to another region is answered by a different plane that has never heard of your resource. - **Global.** The resource exists once for the whole account, above any region. It is answered by one plane, appears in one namespace, and does not need a region in the request at all. A console that shows you a region selector is displaying this fact, not creating it. When a listing comes back empty for something you are certain exists, the first hypothesis is almost always that the request went to the wrong region — not that the resource was deleted. ## What is usually regional - Compute capacity, and the machine-level resources around it. - Your private address ranges and their subnets, which are carved per region and per zone. - Most managed data services, which run inside a region and replicate inside it. - The audit and metric records of management calls, which are recorded where the call was answered. ## What usually sits above a region - The **account** itself and its identity records: principals, their attached permissions, and the trust relationships between accounts. - **Billing and usage**, which aggregates the whole estate. - The **grouping above the account**, where an organisation hierarchy exists, along with the policies attached to it. - Parts of the **traffic entry tier** — a global name or a global entry point that directs callers to regional capacity. Platforms genuinely differ in where they draw this line. On some, a larger share of naming, policy and routing is account-wide; others keep almost everything regional and expose only identity and billing above the region. That is why the durable skill is asking *what scope is this service* rather than memorising a list. | | Regional service | Global service | |---|---|---| | Where state lives | In one region's management plane | Once, for the whole account | | Listing behaviour | Answers for the addressed region only | Answers once, wherever called | | Name uniqueness | Usually unique within the region | Usually unique across the account | | Inventory cost | One call per region | One call total | | Failure exposure | One region's plane | One shared plane for everyone | ## What follows in practice 1. **Inventory has to iterate.** "List everything" is a loop over regions plus a pass over the account-wide services. A tool that calls one endpoint reports a subset and looks authoritative doing it. 2. **Forgotten regions persist.** A proof of concept created in a region nobody monitors keeps running, keeps appearing on the bill, and keeps whatever network and permission exposure it was given. It is invisible precisely because the tooling is regional and nobody addressed that region again. 3. **Uniqueness is scoped.** A name that collides is a name in the same scope. Two resources of the same name in different regions may both be legitimate, which is why identifiers and naming conventions usually encode the region. 4. **Global does not mean free of failure.** A global service is one shared plane. Its scope is a convenience for you and a concentration for everyone. 5. **Authentication and execution are different scopes.** A credential that works account-wide still has to have its action executed by the plane that owns the resource; succeeding at proving who you are says nothing about whether the regional plane can act right now. ## A worked example A team believes a resource was deleted: their listing command returns nothing. The credential is valid, so identity is not the problem. They re-run the same command with the request addressed to the region the resource was created in, and it appears immediately, untouched, still billing. Nothing failed. The first call was answered by a plane that legitimately had no record of it, and the tooling never made the region explicit enough for anyone to notice. ## Where this answer stops This is about **scope** — which plane answers for what. What to do when a regional management plane is degraded rather than merely elsewhere, and how a system should be designed not to depend on it, belongs to the reliability material; whether a given service even exists in a given region belongs to the parity material. The point here is simply that a region is a boundary for *management*, not only for failure.

  • What practical harm does a resource left in a region nobody looks at cause?
    It keeps costing money, keeps whatever network reachability and permissions it was created with, and keeps ageing out of patching and inventory. Because regional tooling never addresses that region, the resource is absent from dashboards while fully present in reality, which is exactly the combination that turns a forgotten experiment into an incident.
  • If identity is account-wide, why can a regional problem still stop you creating resources?
    Because proving who you are and executing the action are answered by different planes. A globally valid credential authenticates fine, then the create call is handed to the region that owns the resource. If that regional plane cannot act, the request fails despite perfect authentication — the two are simply scoped differently.
  • Why do naming conventions so often encode the region?
    Because uniqueness is scoped like the resource. A regional service usually only enforces that a name is unique within its own region, so the same name can legitimately exist several times across an estate. Encoding the region makes an identifier unambiguous in logs, tickets and inventories where the scope is not otherwise visible.

saying these in an interview costs you the question

  • Assumes one API call returns every resource in the account
  • Thinks a single console view implies a single global control plane
  • Believes a resource name is unique everywhere in the account
  • Treats a region-scoped result as proof the resource is gone
  • Assumes copying a resource definition also copies its data across regions