Your vending template gained two guardrails this year, yet accounts issued before that still lack them — why does a template alone not keep an estate aligned?
answer
- a template fires once
- no link left after creation
- vintage, not a console edit
- record the baseline version per account
- inherited reaches back, copied never does
basics
~20 sA template fires once, at creation, and stamps a copy; nothing links the account to it afterwards, so accounts diverge by vintage. Closing the gap needs a baseline version on every account, an idempotent re-apply, and controls inherited from above rather than copied.
solid answer
~50 sIssuing is an **event**, not a relationship. The template runs at creation, stamps its settings into the account, and then has no further connection to it, so an estate diverges by **vintage**: each account carries the baseline as it stood the day it was issued. That is a different problem from someone removing a control inside an account, and it takes a different fix. Three moves close it. Record the baseline version on every account, so "which accounts are behind" is a query rather than an investigation. Make the baseline safe to apply twice and sweep in waves that report before they remediate, because re-applying to an account that has been live for a year can disturb what the team built on it. And move whatever can live above the account into the inherited policy set, because an inherited control reaches every account below it the day it changes and a copied one never does.
code
pseudocode · 17 linescurrentBaseline = 7
behind = []
for each account in organisation.accounts:
if account.baselineVersion >= currentBaseline:
continue // issued at or after the current baseline
missing = controlsIn(currentBaseline) - controlsIn(account.baselineVersion)
behind.add({ account: account, missing: missing })
// report first: nothing above this line changes an account
for each entry in behind:
if entry.account.wave != thisWave:
continue
notifyOwner(entry.account, entry.missing)
apply(entry.missing, to = entry.account) // applying twice must be safe
entry.account.baselineVersion = currentBaselinego deeper
Remember that creating something from a template copies that template at that moment; later edits to the template do not travel to what was already created from it.
Explain the difference between a control copied into each account at issue and one attached above the accounts, and say which of the two picks up a change without anyone visiting an account.
Show that you would record a baseline version per account and sweep in waves that report before they remediate, since re-applying to a year-old live account can disturb what the team built on it.
The position to hold is that a baseline is a versioned product with consumers: additive changes are cheap, tightenings need a rollout plan, and you must always be able to state which accounts are on which version.
## Issuing is an event, not a relationship When an account is created from a template, the template is **read once**. Its settings are copied into the new account and the run ends. No live link is left behind: the account does not subscribe to the template, and the template does not know which accounts it produced unless the process recorded that separately. Everything below follows from that single property. An organisation that has been vending for three years therefore holds accounts of several **vintages**. Each is internally consistent with the rules as they stood on its issue day. Nothing went wrong inside them; the organisation moved on and they did not. This is why an estate can pass every review of its *process* and still fail a review of its *accounts*. ## Two divergences, two causes | | Vintage divergence | Local removal | |---|---|---| | What happened | The baseline gained something after the account was issued | Someone inside the account changed or removed part of what it landed with | | Where the evidence is | The baseline version the account carries | The audit trail of management API calls | | The fix | Apply what the newer baseline adds | Restore it, then remove the permission or add the guardrail that allowed it | | If you apply only the other fix | The gap returns with the next baseline change | The same person removes it again next week | Treating these as one problem is the usual error, and it produces a sweep that keeps re-fixing the same account forever. Note the scope here: comparing every resource in an estate against a declared description is a separate discipline with its own tooling. The narrower question this leaf owns is which baseline version an account carries and what the current one adds. ## Why re-running the template is not the fix 1. **It was written to create, not to converge.** Re-run over a live account and it may try to create what already exists, or overwrite settings the team has legitimately changed since. 2. **Parts of the baseline are now load-bearing.** The team probably extended the network the baseline laid out; re-asserting the original subnets is a production change wearing a governance label. 3. **It has no wave control.** Running everywhere at once converts a governance gap into an incident, and an incident caused by a governance sweep sets governance back a year. So the baseline has to become **idempotent** (safe to apply twice) and **partial** (able to apply only what is missing) before any of this is safe. ## Copy against inheritance The deeper fix is to stop copying what does not have to be copied. - A restrictive policy attached **above** the accounts, in the hierarchy, is evaluated where it is attached. Change it and every account below is covered the same day, with nobody visiting an account. Coverage becomes a property of placement. - Things that can exist only **inside** an account — its address ranges and subnets, the configuration that delivers its logs outward, its own records — cannot be inherited. They have to exist in the account, and they are exactly the parts that go stale by vintage. That gives a design question for every new baseline item: can this live above the account? If yes, it maintains itself. If no, it joins the set you must sweep, and it should earn its place there. What a policy above the account can express at all is a separate subject with its own limits. ## Running the sweep so it produces action 1. Record `baselineVersion` on every account at issue, and again on every successful apply. "Which accounts are behind" then becomes a query, not an archaeology project. 2. **Report before remediating.** The first pass should change nothing and produce a list of accounts, the controls each one lacks, and the owner who will hear about it. 3. **Wave the rollout**, least critical accounts first, each wave's owners told beforehand. The accounts whose failure you can least afford go last, never first. 4. **Re-record the version** after each apply. An account whose version never advances is your real backlog; without that field the sweep has no memory and repeats itself. ## What still goes wrong - A baseline with no version at all. Then "is this account current" can only be answered by inspecting it, and the answer expires immediately. - A sweep that remediates on its first pass. It will find the one account where the missing control was missing deliberately, and it will find it in production. - An assumption that inheritance covers everything. It covers restriction well and creation not at all: no policy above an account can carve that account a subnet or wire its log delivery. The honest summary is that a template gives you uniform accounts at a moment in time, and only a recorded version plus a deliberate sweep gives you a uniform estate over time.
- Which parts of a baseline can be inherited from above the account, and which must be stamped into it?Restrictive policy can generally live above the account, where it is evaluated for everything below and changes take effect without visiting an account. Anything that exists only inside the account — its address range, its subnets, the configuration that ships its logs outward — has to be created there. Those are the parts that go stale by vintage and need the sweep.
- How do you decide which accounts a baseline change reaches first?By blast radius and reversibility. Start with accounts you own or that hold nothing in production, confirm the change applies cleanly and is safe to apply twice, then move outward in waves with each wave's owners warned beforehand. The accounts whose failure you can least afford are the last wave, never the pilot.
saying these in an interview costs you the question
- Believes the template keeps accounts aligned after they are created
- Re-runs the template over live accounts without reporting first
- Treats a never-received control and a removed one as one fix
- Says stamping a copy and inheriting from above are equivalent
- Assumes older accounts are fine because nobody has complained