Your team gets a named scope on a cluster six other teams share — what does that scope separate, and what stays shared?
answer
- an administrative unit, not a partition
- names unique inside the scope only
- budgets and defaults attach per scope
- hosts, kernel and capacity stay shared
- cluster-wide objects belong to no scope
basics
~20 sA named scope separates object names, listings, and the access, budgets and defaults attached to it. It does not separate the hosts workloads land on, the kernel and capacity those hosts share, cluster-wide objects, or network reachability between scopes.
solid answer
~50 sA named scope is the unit of administration inside one cluster, not a partition of it. Inside the scope, workload names only have to be unique against other names in that same scope, listing objects returns that scope's objects, access is normally granted per scope, and a reservation budget plus a default reservation and ceiling attach to it. What it does not do is physical. The scheduler still draws from one pool of hosts, so your workloads land beside the other six teams' and share those hosts' kernel, page cache and finite capacity. Cluster-wide objects — the hosts, storage backends, cluster-wide configuration, installed extension types — belong to no scope. And traffic can usually cross between scopes until a network policy forbids it. It is soft separation: it prevents collisions and accidents, not a compromised workload.
go deeper
Recall that a named scope is a grouping inside one cluster: it keeps one team's object names and listings apart from another's, and nothing about it moves workloads onto different machines.
Explain both halves precisely — what attaches to a scope (names, access, a reservation budget, injected defaults) and what stays cluster-wide (the hosts, their kernel and capacity, storage backends, installed extension types).
Show you have been caught by the gap: a change to a cluster-wide object reaches every scope at once, and contention on a shared host reaches your workload no matter whose scope the noisy one lives in.
The tradeoff to own is how much separation you are actually buying. Soft separation is enough for naming, accounting and accidents; wanting more than that means another cluster and another fixed cost per team.
## What a named scope is A **named scope** is the unit of administration inside a single cluster: a name that objects are created under, that access is granted against, and that per-team settings hang off. It is cheap — a cluster commonly carries one scope per team, often one per team per environment — and creating another is an administrative decision rather than a capacity one. Because it is the first thing a team is handed when it onboards, it is also the thing teams most consistently over-read. A report-renderer team joining a cluster that six other teams already use hears *your own space* and pictures machines of its own. What it actually has is **soft separation**: an organising layer over hardware that everybody shares. ## What the scope separates - **Names.** A workload object named `renderer` in your scope and an object with the same name in another team's scope are two different objects. Neither team has to negotiate names with the other, and that is most of the day-to-day value. - **Listings and routine access.** Asking the platform what exists returns your scope's objects. Access is normally granted per scope, so a team can be trusted completely inside its own and have no reach outside it. - **Administrative attachments.** A reservation budget applies to the aggregate of what is declared inside the scope. A default reservation and ceiling can be injected into workloads in that scope that declare none. Both are per scope, so another team over-declaring cannot consume your allowance. - **A unit of deletion.** Removing the scope removes what was created under it, which is why short-lived scopes are a standard way to clean up after a test run. ## What the scope does not separate | Concern | Separated by the scope? | What that means on a shared cluster | |---|---|---| | Object names and listings | Yes | Two teams can own same-named objects and never see each other's | | Day-to-day access | Usually | Granted per scope — but a grant made at cluster level ignores scopes entirely | | Reservation budget and injected defaults | Yes | Each scope carries its own ceiling and its own defaults | | Hosts and placement | **No** | The scheduler draws from one pool; your workloads land beside everyone's | | A host's kernel, page cache and real capacity | **No** | Co-located workloads are processes on one machine, drawing on the same resources | | Cluster-wide objects | **No** | Hosts, storage backends, cluster-wide configuration and installed extension types belong to no scope | | Network reachability | **Not by default** | Traffic usually crosses between scopes until a policy rule forbids it | | Containment of a compromised workload | **No** | The scope is a naming and accounting construct, not a wall | ## Why the misreading is expensive Three consequences follow, and each arrives as a surprise to a team that read the scope as a partition: 1. **Contention crosses scopes.** A workload in someone else's scope, placed on the same host, draws on the same CPU, memory and page cache as yours. Your listing shows a quiet scope while your latency says otherwise, and no amount of looking inside the scope explains it. 2. **Cluster-wide changes land on everyone at once.** An upgrade, a change to a cluster-wide setting, or a newly installed extension type is not scoped. There is no such thing as rolling one of those out to one team, which is why the cluster-wide surface is the shared risk every tenant carries. 3. **Reachability is a separate decision.** Workloads in two scopes can usually call each other until someone writes a rule saying they may not. Assuming the scope did that quietly is how an internal endpoint ends up reachable by six teams that were never meant to have it. ## Working with soft separation Treat the scope as what it is, and buy anything more explicitly: - Write network rules where cross-team reachability matters; never infer them from the scope boundary. - Declare reservations and ceilings, so that contention on a shared host is bounded by design rather than discovered during an incident. - Keep an explicit list of what is cluster-wide, because that list is the change surface every team on the cluster shares. - When the requirement is genuinely that one team's workload must not be able to reach another's even after a compromise, that is an argument about separation strength, and the answer is a stronger boundary than a name — not a bigger budget or a second scope. The compact version to say out loud: a named scope separates what teams call things, what they can see, and what they are allowed to consume. It does not separate what they run on.
- Which objects on a cluster belong to no scope at all?The hosts themselves, the storage backends behind claims for durable storage, cluster-wide configuration, the installed extension types, and the scope objects. A change to any of them lands on every team at once, and an access grant made at cluster level is not contained by anyone's scope.
- Your team asks for a second named scope for its test copies. Is that a reasonable use of one?Yes. Scopes are cheap, and a separate one gives the test copies their own budget, their own injected defaults, their own access list and a single delete to clean up. What it does not give is separate hardware: a heavy test run still competes for the same hosts as production workloads on that cluster.
saying these in an interview costs you the question
- Assumes separate scopes mean workloads run on separate machines
- Believes a scope blocks traffic between teams by default
- Thinks every object on a cluster belongs to some scope
- Calls the scope a security boundary that contains a compromised workload
- Expects another team's load to be invisible because it sits in another scope