An inventory finds nine accounts with no named owner and no known workload — how did they appear, and how do you close them?
answer
- issuing without decommissioning
- ownership is cheap only at issue
- months of silence in the audit trail
- quarantine is reversible, closure is not
- expiry date on every temporary account
basics
~20 sUnowned accounts appear when vending has no decommissioning half: owners leave, projects end, and some accounts were never issued through the process at all. Close them by proving disuse from platform signals, quarantining reversibly, then closing and reclaiming what they held.
solid answer
~50 sAn estate accumulates unclaimed accounts because issuing is easy and closing is nobody's job. They arrive four ways: an account created outside the vending path, a trial that ended, an owner who left, and a reorganisation that orphaned a whole group. The way out is evidence, then a reversible step, then closure. Prove disuse from the platform's own signals — no principal has made a management API call for months, no charges beyond stored data, no credentials still being exchanged. Then **quarantine**: attach a restrictive policy above the account so nothing new can be created while anyone who needs it has time to object. Only then close: reclaim the address range to the plan, keep the centrally collected audit records, and remove the account from its grouping. Finally fix the cause at issue — an owner record with a review date, and an expiry on temporary accounts.
go deeper
Understand that an account which exists is an account somebody must answer for; if nobody is named on it, nobody notices what happens inside it.
Be able to say what evidence would show an account is genuinely unused, and why a small charge is not the same thing as an empty account.
Demonstrate the reversible step: quarantine with a restrictive policy above the account first, so a wrong guess is undone by detaching a policy instead of by a recovery.
Argue that issuing and closing are one lifecycle: a vending process with no expiry, no owner review and no decommissioning path is a machine for producing accounts nobody can justify.
## Why the pile exists Vending solves the front half of a lifecycle. A request produces an account in minutes, which is exactly what it was built for. The back half — noticing that an account no longer has a purpose and removing it — has no trigger, no requester and usually no owner, so it does not happen. Four routes produce most unclaimed accounts: - **Created outside the process.** Somebody with the right permission made an account directly, so no request, purpose or owner was ever recorded. - **The project ended.** A trial or a migration finished; the account was the only artefact nobody deleted. - **The person left.** The owner record named an individual and was never renewed, so the account outlived its only human reference. - **The organisation moved.** A team was merged or dissolved and its accounts were inherited by nobody in particular. ## Why nobody closes them The reason is risk asymmetry, not laziness. Closing an account that mattered is a visible, attributable incident; leaving it alone is invisible. Without evidence, the rational individual choice is always to leave it, and that choice is made again by every person who notices. A process that relies on somebody being brave will never clear the pile. What clears it is supplying **evidence** and a **reversible step** so that being wrong is cheap. ## What an unclaimed account actually costs - **Security.** Identities and credentials inside it remain valid and nobody is watching what uses them. An account with no owner has no one reading its alerts. - **Truth about the estate.** Every statement of the form "all our accounts do X" is now false, and you cannot tell which statements matter until something happens. - **Capacity.** It occupies a slot against whatever ceiling the organisation has on how many accounts it may hold, and it holds an address range the plan has marked as used. - **Data.** Whatever it stores has a retention obligation nobody is managing, in either direction — kept too long, or deleted when someone finally gets bold. ## Proving disuse No single signal is sufficient; together they make a case. 1. **The audit trail of management API calls.** Months with no principal acting in the account is the strongest single indicator, and it covers every caller rather than the ones you thought of. 2. **The shape of the charges.** Charges that are only storage suggest nothing is running; charges that vary with the time of day suggest something still is. A small total is not the same as an empty account. 3. **Credential use.** Whether any identity in the account is still exchanging credentials tells you if an automated caller depends on it. 4. **Inbound references.** A trust relationship from another account, a name still resolving to something inside it, a pipeline that deploys there. This is the signal that catches the account that looks idle and is load-bearing. ## Quarantine, then close 1. Attach a restrictive policy above the account so nothing new can be created or changed inside it, and announce a date. 2. Wait a full business cycle. A month-end or quarter-end job that runs from that account will surface here and nowhere else. 3. Close it: reclaim the address range to the central plan, remove the account from its grouping, and keep the audit records — which are already in the central collection account, if the baseline did its job. Platforms differ in whether a closed account can be reopened, for how long, and what remains billable while closure completes, so confirm those specifics before treating closure as undoable. Quarantine is the step that is reliably reversible; closure is not the place to be guessing. ## Fixing the cause at issue Everything above is remediation; the cure is in the vending request. Record a **named individual** owner plus a review date, so ownership expires unless renewed. Record the **purpose**, so a later reader can judge relevance. Put an **expiry date** on anything temporary, which converts an indefinite obligation into a dated question asked of someone who still remembers the context. Then make the rule automatic: an account whose owner review lapses goes to quarantine on its own, rather than waiting for an annual inventory. And close the side door. An account created outside the vending path is the seed of this entire problem, because it is unowned from the first minute. Detecting new accounts that the process did not issue belongs in the same job as this cleanup.
- Which platform signals separate an idle account from a quiet but real one?The audit trail of management API calls says whether any principal has acted and over what period. The shape of the charges says whether something is running or merely stored. Credential use says whether an automated caller still depends on it. A quiet account running a steady service shows charges and traffic but few management calls, which is precisely why one signal alone is never enough.
- Why record an expiry date when a temporary account is issued?Because it turns an indefinite obligation into a dated one. An account issued for a trial with a stated end date raises its own question on that date, and the question reaches a named person who still remembers the context. Without it, the account's only future prompt is a security review or an unexplained bill, years later.
An unclaimed account is a rented storage unit paid by company card: nobody opens it, nobody cancels it, and no one still working here can say what is inside.
saying these in an interview costs you the question
- Closes the account straight away, since nobody claimed it
- Takes a small bill as proof that the account is empty
- Thinks an unclaimed account is only a cost problem
- Expects ownership to be reconstructed as easily as recorded
- Assumes closing an account is instant and reversible everywhere