skip to content

An internal platform issues each team a new cloud account from a template — what does that account land with before any workload runs?

level: middleimportance: must knowfreq 62%

answer

  1. issued, not assembled
  2. four facts true of every account
  3. logs leave the account from minute one
  4. address range comes from the central plan
  5. owner recorded at issue, not reconstructed

basics

~20 s

A vended account arrives with its baseline already applied: audit and platform logs delivered to a central collection account, a private address range allocated from the organisation's plan, guardrail policies in force above it, and a named owner recorded.

solid answer

~50 s

Vending turns "give me an account" into a request against a template, so the account is **issued**, not assembled by hand. What lands with it is the organisation's baseline. The audit trail of management API calls and the platform logs are delivered to a central collection account, with a policy above the account denying anyone inside from switching that delivery off. A private address range is allocated from the central address plan and carved into subnets. The account is created in the part of the organisation hierarchy whose guardrail policies apply, so the restrictive layer is in force from the first minute. And an ownership record exists: a named principal, a cost-attribution tag, a purpose, and an expiry for a temporary account. A hand-assembled account is usually right on three of those four and quietly wrong on the fourth.

code

json · 16 lines
json
{
  "request": {
    "team": "payments",
    "purpose": "checkout service, non-production",
    "ownerPrincipal": "payments-tech-lead",
    "costTag": "cc-4412",
    "expiresOn": null
  },
  "baseline": {
    "baselineVersion": 7,
    "auditDelivery": { "to": "central-log-collection", "localOptOut": "denied-by-policy-above" },
    "network": { "privateRange": "10.42.0.0/16", "allocatedBy": "central-address-plan" },
    "placement": { "grouping": "non-production", "inheritsPolicySet": true },
    "ownerReviewEveryDays": 180
  }
}

go deeper

for a junior

Know that an account is not blank space: in a well-run organisation it arrives with logging, a network and an owner already set, because somebody issued it rather than built it.

for a middle

Be able to name what a baseline lands and say why each item is applied at creation rather than afterwards, especially log delivery and address allocation, which are the two nobody retro-fits cleanly.

for a senior

Show that you check accounts instead of trusting them: compare two issued a year apart, and treat any missed baseline item as silent until an incident review or an audit finds it.

for a principal

The argument to make is that uniformity is the precondition for every estate-wide claim: a statement like "every account's logs are centralised" is only true if no account was ever assembled by hand.

## What issuing an account means An **account** is the platform's own unit of isolation: it holds resources, carries its own bill, and has its own quota pools. Any organisation past its first team ends up running many of them, and the interesting question is where a new one comes from. In a vending model, "give me an account" becomes a **request against a template**. The request records who will own the account, what it is for, and which environment class it belongs to. An automated path then creates the account, places it in the organisation hierarchy, and applies a **baseline** — the fixed set of settings the organisation has decided every account starts with. Nobody works down a checklist by hand, and no account exists that the process has never heard of. ## The four things a baseline lands 1. **Log and audit delivery.** The account's audit trail of management API calls and its platform logs are shipped to a central collection account owned by a different team, and a policy attached above the account denies anyone inside from turning that delivery off. The first hours of an account's life are exactly the hours you will later want a record of, and an administrator who can edit the record of their own actions leaves you a record you cannot lean on. 2. **A network already laid out.** A private address range is allocated from the organisation's central address plan and carved into subnets. Ranges that overlap cannot be joined privately — peering and transit both need distinct ranges — and renumbering an account that already serves traffic is a migration, not a change. 3. **Guardrails already attached.** The account is created inside the part of the hierarchy whose guardrail policies apply, so the restrictive layer above it is in force before the first resource exists. A guardrail introduced over an account that has already been built must first be reconciled against everything running under it. 4. **A recorded owner.** A named principal, a cost-attribution tag, a stated purpose and, for a temporary account, an expiry date. Ownership is the one fact that costs a form field now and costs archaeology later. ## Issued against assembled | Property | Issued from a template | Assembled by hand | |---|---|---| | Isolation boundary | The account | The same account — identical | | Log and audit delivery | Central, not switchable off locally | Whatever the builder remembered | | Private address range | Allocated from the plan | Often picked on the spot | | Guardrail coverage | Guaranteed by where it is placed | Depends on where it was created | | Owner and purpose | Captured in the request | Reconstructed later, badly | | Time to first use | Minutes, repeatable | Hours to weeks, never twice alike | The first row is the one candidates get wrong. Vending does **not** make an account more isolated — the boundary is a platform construct and it is the same however the account appeared. What vending buys is that every account is *known* and *uniform*, which is what makes an estate-wide statement ("every account's logs are in one place", "no account can operate outside these regions") true rather than aspirational. ## Why "quietly different" is the phrase that matters A hand-assembled account rarely fails loudly. Whoever built it knew the drill and got most of it right; one item was missed. The four baseline items are chosen precisely because a miss on any of them is **silent**: - Missing log delivery costs nothing until an incident review asks who deleted the data, and the answer lives in an account that was not recording. - An overlapping address range costs nothing until that account first has to reach another one privately. - A missing guardrail costs nothing until somebody builds in a place the organisation does not operate in. - A missing owner costs nothing until the account outlives the person who made it. None of that surfaces during setup, so "the team is shipping" is not evidence the account is correct. ## What vending is not - **Not a permission model.** Who may do what inside the account is a separate mechanism; a vended account with an over-broad administrator is still an over-broad administrator. - **Not continuous.** The template is read once, at creation. What the template gains afterwards does not travel back to accounts already issued. - **Not a decommissioning process.** Issuing is one half of a lifecycle; an organisation that vends and never closes accumulates accounts nobody claims. - **Not the grouping decision.** Where in the hierarchy the account is created is a design choice the template executes, not one it makes. The practical test: pick two accounts issued a year apart and ask, without logging into either, where their logs go, which ranges they hold, which policy set is above them, and who owns them. If that cannot be answered from the process, the organisation has an account-creation habit rather than an account-vending process.

  • Why is the audit trail delivered to an account the local administrator cannot write to?
    Because the record has to survive the person it records. An administrator who can edit or stop delivery inside their own account can remove the evidence of what they did there. Shipping outward to a collection account owned by another team, with a policy above denying local changes to that delivery, keeps the record usable during exactly the investigation it exists for.
  • Why allocate the private address range centrally instead of letting the team choose?
    Because overlap cannot be fixed in place. Two accounts whose ranges overlap cannot be joined privately, since peering and transit both require distinct ranges, and the only remedy is renumbering an account that is already serving traffic. Allocating from one plan at issue costs a lookup; finding a collision two years later costs a migration.
  • What does the vending request capture that the account itself cannot tell you later?
    Intent. An account can be inspected for what it contains, but not for why it was asked for, who is accountable for it, which environment class it was meant to be, or when it was supposed to stop existing. Those are recorded at the request or not at all, and every later decision about the account depends on them.

saying these in an interview costs you the question

  • Thinks the baseline is a naming convention teams agree to follow
  • Says logging can be added later as cheaply as it is issued
  • Claims a vended account is more isolated than a hand-built one
  • Lets each team pick its own private address range at creation
  • Treats vending as speed only, with contents left to the team