Your accounts sit in a grouping tree above the account level — what travels down that tree, and what travels up it?

## What sits above the account An **account** is the container a platform attaches isolation, billing and quota to. Once an organisation runs more than a handful of them, the platform lets you arrange them in a **tree**: a root at the top, **grouping nodes** beneath it, and accounts hanging off those nodes. Every node can hold both accounts and further nodes, and every account has exactly one parent. That tree is not decoration and it is not a picture of the company. It is a **live control surface**, and it carries traffic in two directions at once: **policy down, money up**. Almost every question asked about organisation hierarchy is one of those two directions, or the fact that one tree has to serve both. ## Downward: an attachment reaches a whole subtree When you attach a policy to a grouping node it applies to **every account in the subtree beneath that node** — not only the accounts attached directly to it, but the accounts under its children, under their children, and so on to whatever depth the tree has. The attachment point *is* the decision, because it fixes the reach: - attach at the root and you have written a rule for the entire estate; - attach at the node holding the production accounts and the rule stops at the production boundary; - attach at one account and the rule has a reach of one. Two properties of that inheritance matter in practice: 1. **It is evaluated, not copied.** The inherited set is resolved when a call is made, not stamped into the account when it joined. Move an account to a different node and what applies to it changes at once, with nothing to redeploy and nothing to restart. 2. **The account below cannot undo it.** That is the entire reason for placing a rule above the account rather than inside it: a local administrator can hand out permissions inside the account, but cannot grant past a restriction that sits above it. What genuinely differs between platforms is the *kind* of policy the layer above the account can carry. On some, that layer is purely restrictive — it can only subtract from what the accounts below may do, and permissions must still be granted inside each account. On others, grants themselves inherit downward, so a permission given at a node is held by every account beneath it. Know which model you are on before you say the word "inheritance", because the consequence of a mistake points in opposite directions in the two. ## Upward: charges consolidate Usage is metered where it happens — in the account that ran the workload or stored the bytes. What the tree adds is that those charges **roll up**, so the organisation is billed once at the root instead of account by account. - **Per-account detail survives the roll-up.** Consolidation is an aggregation, not a blend; which account incurred what is exactly the data that makes charge-back possible at all. - **Pooling can change the total, not only who pays it.** Where a platform prices a dimension in tiers, or lets a term commitment be drawn on by any account in the tree, the consolidated estate can reach a cheaper effective rate than the same accounts standing alone. - **Consolidation is a money fact, not an isolation fact.** One bill does not mean one failure domain, one quota pool or one permission set. Accounts kept separate for isolation stay separate when their charges are added together. ## The two directions side by side | | travels down the tree | travels up the tree | |---|---|---| | what moves | the policy attached at a node | metered usage and its charges | | decided by | the attachment point you chose | the account the usage happened in | | resolved | at call time, on every request | at the end of the billing period | | changed by | moving the attachment, or the account | moving the account | | failure when wrong | a rule reaching too far, or not far enough | a report nobody can act on | ## Why interviewers ask it Because the grouping decides **what a policy can reach**, and because one tree has to satisfy two audiences that want different shapes. Finance reads the roll-up and wants the tree to look like the cost centres. Security writes the attachments and wants it to look like the trust boundaries. Only one of them gets the tree, and the loser gets labels — which is why the choice of grouping axis is the next question in this subject and why it is expensive to revisit. ## Ways candidates get it backwards - Calling the tree "just consolidated billing", which sees one direction and misses the one that can stop a deployment. - Believing an attachment covers only the node's direct children, which under-estimates its reach by however many levels sit below. - Believing an account's own administrator can waive what is inherited from above. - Believing consolidation discards per-account detail, which would make the roll-up useless for anything except paying the invoice.