An acquired company's accounts are attached under your existing grouping tree — what changes for them at that moment, and what does not?

## What attaching an account actually is Bringing an acquired company into your estate feels like a migration and is not one. Attaching their accounts under a node of your grouping tree changes **where those accounts sit in the hierarchy** and nothing else directly. Nothing is copied, nothing is re-created, nothing is redeployed. That is what makes it cheap — and what makes it dangerous, because the effects it *does* have land instantly on systems that are already running. The two effects are the tree's two directions. ## What changes the moment they attach **1. The inherited policy set.** Every policy attached to every node above their new position now applies to them. Because inheritance is resolved when a call is made rather than stamped into the account, this takes effect on the next request, with nothing to restart. The practical shape of it: - A permission granted **inside** the account is still there, unchanged. What changes is whether it is **effective**, because a restriction above the account can refuse a call the local grant allows. - The failure therefore looks like a permission error from a job that has not changed and whose grant has not changed — and the audit trail of management API calls is where you see the denials. - Infrequent work is where this bites. A daily job fails the next morning and someone notices; a monthly reconciliation run or a quarterly key rotation fails weeks later, long after the move has stopped being the obvious suspect. **2. The billing roll-up.** Their metered usage begins consolidating into your organisation's bill, itemised per account. Where your platform pools usage for tiered pricing or lets a term commitment be drawn on across the tree, their consumption starts counting toward that pool too. How charges *already incurred* before the move are presented differs between platforms — some restate history under the new shape, some leave it where it was recorded — so confirm it before promising anyone a continuous report. ## What does not change | aspect | after attachment | |---|---| | resources and data inside the accounts | untouched, still running, still in the same places | | identities defined inside the accounts | not rewritten; the same principals with the same grants | | the accounts' own quota pools and limits | still per-account | | private network ranges and reachability | unchanged; the tree is not a network | | trust the accounts granted to outside parties | still there unless something explicitly refuses it | | the accounts' identifiers and names | unchanged | The last two deserve emphasis because candidates get them backwards in both directions. Joining your tree does **not** connect anything to your networks, and it does **not** by itself cut the acquired accounts off from third parties they had granted access to. Those are separate mechanisms with separate work behind them. ## How to stage the attachment so nothing breaks 1. **Attach into a holding node that inherits little or nothing**, so the accounts are in your tree and under your bill before they are under your rules. You have separated the two directions deliberately. 2. **Watch the audit trail for denials** over a window long enough to cover their infrequent jobs — a month at minimum if they run monthly work. Compare the effective permissions of their key roles before and after. 3. **Move them to their intended node**, in batches small enough that a rollback is a single move back rather than a project. 4. **Then tighten**, once you know what the acquired workloads actually do rather than what their documentation says they do. ## Where an exception genuinely has to exist Sometimes an acquired workload legitimately needs something your inherited policy refuses, and it cannot be changed before the deal closes. The options are structural, and worth naming in that order: place the accounts at a node that does not inherit the refusing policy; narrow the policy so the legitimate case is not covered; or change the workload. Parking them permanently at a node with no inherited rules is not an option — it is the same as not attaching them, with the paperwork of having done so. ## The point the question is testing That you can separate **contents** from **effective permissions**. Nothing inside the account changes, and simultaneously what the account may do changes completely. Candidates who have only read about hierarchies say either "everything moves" or "nothing happens"; candidates who have run an integration know it is precisely one of the two directions arriving before anyone was ready for it.