Your accounts could be grouped by environment, business unit or compliance scope, but each hangs at exactly one place — how do you choose?

middleshould knowfreq 48%

answer

three candidate axes, one tree
an account has exactly one parent
the tree goes to the policy-bearing axis
prefer the axis that changes least
the rest survive as labels

basics

~20 s

Give the tree to the axis your mandatory restrictions are written in terms of, preferring the axis that changes least often. An account has exactly one parent, so only one axis can be the tree; the others survive as labels on accounts.

solid answer

~50 s

An account hangs at exactly one place, so exactly one axis gets to be the tree. I choose it with two tests. First, which axis are my strongest restrictions written in terms of — because a policy attached at a node reaches exactly that node's subtree, so an axis that is not the tree cannot be targeted in one attachment. Second, which axis is most stable — companies reorganise their business units routinely and almost never reorganise what "production" means, and every reorganisation of the tree's axis is a batch of account moves. Those two tests usually point at environment or compliance scope rather than at the org chart. The axes I did not pick do not vanish: they become labels carried on each account, used for reporting and, depending on the platform, as conditions inside policies.

An account hangs at exactly one place, so exactly one axis gets to be the tree. I choose it with two tests. First, **which axis are my strongest restrictions written in terms of** — because a policy attached at a node reaches exactly that node's subtree, so an axis that is not the tree cannot be targeted in one attachment. Second, **which axis is most stable** — companies reorganise their business units routinely and almost never reorganise what "production" means, and every reorganisation of the tree's axis is a batch of account moves. Those two tests usually point at environment or compliance scope rather than at the org chart. The axes I did not pick do not vanish: they become labels carried on each account, used for reporting and, depending on the platform, as conditions inside policies.

code

pseudocode · 16 lines

pseudocode

# reach of an attachment = the subtree under it
function accountsReached(node):
    reached = node.accounts
    for each child in node.children:
        reached = reached + accountsReached(child)
    return reached

# the axis that IS the tree: one attachment, exact reach
attach(policy = "deny-unapproved-regions", at = node("production"))
# reaches accountsReached(production) - by construction, forever

# an axis that is NOT the tree: no single node matches it
matching = [a for a in allAccounts if a.labels["unit"] == "payments"]
# options: attach once per matching account and keep this list correct,
# or express the label as a condition inside the policy itself
# - check what your platform lets a condition read.

go deeper

for a junior

Recall that an account sits at exactly one place in the grouping tree, so only one way of grouping the estate can be the tree itself. Environment is the most common choice.

for a middle

Explain the mechanism behind the choice: an attachment reaches exactly one subtree, so the axis the tree is built on is the axis you can write a rule for in one place.

for a senior

Argue it from an estate you have run: which restrictions were mandatory, which axis they were written in, and why the axis that reorganises most is the one you kept out of the tree.

for a principal

The judgment is who is told no. Finance, security and the auditor all want the shape; decide which one owns it, and state on the record what the others get instead and what that costs them.

The constraint that makes this a real decision

In an account grouping tree, an account has exactly one parent. There is no way to hang one account under both "production" and "payments business unit" so that it inherits from both. That single-parent rule is what turns a filing question into a design decision: several ways of grouping the estate are genuinely useful, and only one of them can be the tree.

The candidate axes on a real estate are usually three:

Environment — production, staging, development, sandboxes.
Business unit — the product line, department or cost centre that owns the account.
Compliance scope — the accounts inside a regulated perimeter, versus everything else.

Why the axis is chosen by the policy, not by the org chart

A policy attached at a node reaches exactly the accounts in that node's subtree. So the axis you build the tree on is the axis along which you can write a rule once. Every other axis has to be expressed another way: by attaching the same policy at each matching node or account and keeping that list correct forever, or by putting the membership in a label and relying on whatever your platform lets a policy condition do with labels.

That gives the first test: which axis are your non-negotiable restrictions written in terms of? In most estates the strongest rules are environment-shaped ("nothing in production may do this") or scope-shaped ("regulated data may not leave these places"), and almost none are business-unit-shaped. The business unit usually wants reporting, which the roll-up gives it anyway, from labels, without owning the tree.

The second test is stability. A tree built on an axis that changes is a tree you will be moving accounts around in:

axis	how often it changes	what a policy on it can say	usual verdict
environment	almost never	the strongest restrictions in most estates	the usual owner of the tree
compliance scope	rarely, and with notice	a hard perimeter an auditor asks about	owns the tree, or a branch of it
business unit	every reorganisation	ownership and budget, rarely prohibition	usually a label, not the tree

Combining axes without a second tree

You do not have to pick exactly one level, only one nesting. A common resolution is to let the stable, policy-bearing axis take the top levels and a second axis take the levels below it — environment at the top with business units beneath each environment node, or the reverse. That does genuinely buy you both, with one asymmetry worth stating out loud: the outer axis can be targeted with one attachment and the inner one cannot. "All production accounts" is one node if environment is on top; "all payments accounts" is then one node per environment, and the number of places you must remember grows with the tree.

The deeper you nest to capture more axes, the more precise your attachment points get — and the more moves a change of reality costs you. Depth is bought with future churn.

What happens to the axes you did not pick

They survive as labels on the account, and they remain useful:

Reporting. The consolidated bill keeps per-account detail, so a label is enough to answer whose spend a charge was, without that axis being the tree at all. (How those labels are governed and reported on is its own subject.)
Conditions. Platforms differ in how far a policy may branch on a label, so check what yours supports before designing a control that depends on it.
Navigation. People find accounts by the names and labels they carry as much as by where they sit.

What a label does not give you is the tree's structural guarantee. A label is metadata on the account; the account's position is the thing a policy attachment reaches by construction. If the auditor needs a boundary rather than a report, that axis has a claim on the tree itself.

Pitfalls

Copying the current org chart. It is the axis most likely to be different next year, and rebuilding the tree after each reorganisation is precisely the expensive operation this subject is about.
Assuming multi-parenting. Candidates often reach for "put it under both" — the single-parent rule is what the whole question rests on.
Treating the axes as interchangeable because labels exist. Labels can describe any axis; only the tree can be targeted with one attachment that nobody below can escape.
Choosing for the diagram. The prettiest tree on a slide is not the one that lets you write your mandatory restriction in one place.

## The constraint that makes this a real decision In an account grouping tree, **an account has exactly one parent**. There is no way to hang one account under both "production" and "payments business unit" so that it inherits from both. That single-parent rule is what turns a filing question into a design decision: several ways of grouping the estate are genuinely useful, and **only one of them can be the tree**. The candidate axes on a real estate are usually three: - **Environment** — production, staging, development, sandboxes. - **Business unit** — the product line, department or cost centre that owns the account. - **Compliance scope** — the accounts inside a regulated perimeter, versus everything else. ## Why the axis is chosen by the policy, not by the org chart A policy attached at a node reaches exactly the accounts in that node's subtree. So the axis you build the tree on is the axis along which you can write a rule **once**. Every other axis has to be expressed another way: by attaching the same policy at each matching node or account and keeping that list correct forever, or by putting the membership in a label and relying on whatever your platform lets a policy condition do with labels. That gives the first test: **which axis are your non-negotiable restrictions written in terms of?** In most estates the strongest rules are environment-shaped ("nothing in production may do this") or scope-shaped ("regulated data may not leave these places"), and almost none are business-unit-shaped. The business unit usually wants *reporting*, which the roll-up gives it anyway, from labels, without owning the tree. The second test is **stability**. A tree built on an axis that changes is a tree you will be moving accounts around in: | axis | how often it changes | what a policy on it can say | usual verdict | |---|---|---|---| | environment | almost never | the strongest restrictions in most estates | the usual owner of the tree | | compliance scope | rarely, and with notice | a hard perimeter an auditor asks about | owns the tree, or a branch of it | | business unit | every reorganisation | ownership and budget, rarely prohibition | usually a label, not the tree | ## Combining axes without a second tree You do not have to pick exactly one *level*, only one *nesting*. A common resolution is to let the stable, policy-bearing axis take the top levels and a second axis take the levels below it — environment at the top with business units beneath each environment node, or the reverse. That does genuinely buy you both, with one asymmetry worth stating out loud: **the outer axis can be targeted with one attachment and the inner one cannot**. "All production accounts" is one node if environment is on top; "all payments accounts" is then one node per environment, and the number of places you must remember grows with the tree. The deeper you nest to capture more axes, the more precise your attachment points get — and the more moves a change of reality costs you. Depth is bought with future churn. ## What happens to the axes you did not pick They survive as **labels on the account**, and they remain useful: - **Reporting.** The consolidated bill keeps per-account detail, so a label is enough to answer whose spend a charge was, without that axis being the tree at all. (How those labels are governed and reported on is its own subject.) - **Conditions.** Platforms differ in how far a policy may branch on a label, so check what yours supports before designing a control that depends on it. - **Navigation.** People find accounts by the names and labels they carry as much as by where they sit. What a label does **not** give you is the tree's structural guarantee. A label is metadata on the account; the account's position is the thing a policy attachment reaches by construction. If the auditor needs a boundary rather than a report, that axis has a claim on the tree itself. ## Pitfalls 1. **Copying the current org chart.** It is the axis most likely to be different next year, and rebuilding the tree after each reorganisation is precisely the expensive operation this subject is about. 2. **Assuming multi-parenting.** Candidates often reach for "put it under both" — the single-parent rule is what the whole question rests on. 3. **Treating the axes as interchangeable because labels exist.** Labels can describe any axis; only the tree can be targeted with one attachment that nobody below can escape. 4. **Choosing for the diagram.** The prettiest tree on a slide is not the one that lets you write your mandatory restriction in one place.

Which axis do teams most often regret building the tree on, and why?
The business unit. It reads naturally on day one because it matches the org chart and the budget conversation, and then the company reorganises. At that point the tree either lies about who owns what or has to be redrawn account by account, while the restrictions people actually needed were environment-shaped all along and could have been attached once. Ownership is better carried as a label the bill can group by.
Your strongest restriction is written in terms of the axis you did not pick. What are your options?
Three, in increasing order of maintenance. Attach the policy at every node or account that matches, and accept that the list must be kept correct as accounts appear. Put the membership in a label and express the restriction as a condition on it, if your platform's conditions can read what you need. Or concede the axis was the wrong choice and regroup — which is the expensive option, and worth pricing before choosing it.
Can you get two axes by nesting one under the other?
Largely, yes, and it is the usual resolution: the outer axis takes the top levels and the inner one the levels beneath. The asymmetry is that the outer axis is targetable with a single attachment while the inner one needs one attachment per branch. Put the axis carrying your mandatory restrictions on the outside, and expect each extra level of nesting to cost you account moves the next time reality changes.

saying these in an interview costs you the question

Copies the current org chart and redraws it after every reorganisation
Thinks an account can hang under two nodes to inherit both
Says labels can express any grouping, so the tree's axis is arbitrary
Picks the axis that diagrams best rather than the one policy targets
Treats compliance scope as a label when the auditor wants a boundary

Your accounts could be grouped by environment, business unit or compliance scope, but each hangs at exactly one place — how do you choose?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The constraint that makes this a real decision

Why the axis is chosen by the policy, not by the org chart

Combining axes without a second tree

What happens to the axes you did not pick

Pitfalls

▾common follow-ups3 questions

▾red flags5 flags

The constraint that makes this a real decision

Why the axis is chosen by the policy, not by the org chart

Combining axes without a second tree

What happens to the axes you did not pick

Pitfalls

answer

go deeper