What can a cloud account's founding owner credential do that even a full administrator identity in that account cannot?
answer
- the identity the account was born with
- outside the permission model, not inside it
- a short account-level reserved list
- never used, so any use alerts
- second factor held apart, rotate after
basics
~20 sThe founding owner credential is the identity a cloud account was created with, and the platform reserves a short list of account-level actions for it — closing the account, changing its registration and billing details, and recovering from a permission configuration that locked everyone else out.
solid answer
~50 sIt is the identity the account was created with, and it sits outside the account's own permission model rather than inside it. Providers differ on the exact list, but every one of them reserves a few **account-level** actions for it: cancelling or closing the account, changing the account's own registration, billing and ownership details, and unwedging the account when its permission configuration has locked out every administrator. Because it cannot be constrained by the grants inside the account and generally cannot be deleted, the control is operational rather than technical: it is given its own second factor, that factor is held apart from the password, it is not used for daily work, and any sign-in with it raises an alarm on its own. A common mistake is treating it as 'the strongest administrator' and leaving it in the team's everyday reach.
go deeper
Remember that the identity a cloud account was created with is special, is kept sealed away with its own second factor, and is not what anyone should be using to do daily work.
Explain the structure: it sits outside the account's permission model rather than inside it, which is why a short list of account-level actions cannot be delegated to any grant.
Show the operating discipline — two-person opening, an alarm on any use at all, rotation afterwards — and name the quiet failures: an expired second factor, a departed holder, an unread recovery mailbox.
The call you own is what the organisation may still depend on it for. Every routine task that needs it erodes the alarm, so the standard is that nothing recurring is allowed to require it.
## What the credential actually is Every cloud account is created by somebody, and the identity that created it is the account's **founding owner credential**. It is not a member of the account's permission model; it is the thing the permission model hangs from. Administrator identities inside the account exist because something granted them their permissions, and what grants can also revoke, constrain or misconfigure. The founding owner credential is not granted anything — it simply *is* the account. That structural difference is the whole answer, and everything else follows from it. ## The short reserved list Providers differ on exactly what is on the list, and the honest answer in an interview says so. What is common across large platforms: - **Closing or cancelling the account itself.** No grant inside the account produces this, because the account is the container the grants live in. - **Changing the account's own registration.** The billing arrangement, the contact and security addresses, the support arrangement, and who owns the account. - **Recovering from a lockout.** If someone attaches a policy that denies everything to everyone, or deletes the last working administrator path, there is nothing inside the account able to fix it. The founding owner credential is how the account is unwedged. - **A handful of account-wide settings** that each provider keeps at the account level rather than delegating. Everything else — creating and deleting resources, attaching permissions, reading the record of management API calls — is grantable, and therefore belongs to a normal administrator identity, ideally a federated one. ## Why 'never use it' is a control and not a slogan A credential that is used once a quarter is watched. A credential that is used every day is background noise. The reason the founding owner credential is kept out of daily work is not superstition about its power; it is that **its use becomes a signal**. If it is never used, then a single sign-in with it is, on its own, an alertable event that a human is expected to react to within minutes. The moment it becomes a convenient way to do something that a grant could have done, that signal is gone and cannot be bought back. This is also why day-to-day administration should not run through it even during an incident. If an engineer needs administrator permissions at three in the morning, that is a break-glass path with an approval, an expiry and an alarm — not a reason to fetch the account's founding credential. | | Founding owner credential | Day-to-day administrator identity | |---|---|---| | How it is reached | a stored secret plus a second factor held apart from it | federated sign-in from the company directory | | What it can do | what any administrator can, plus a short reserved list | everything the account can grant | | How often it is used | as close to never as the platform allows | every working day | | What watches it | an alarm on any use at all | the ordinary record of management API calls | | What happens afterwards | rotate the secret and the second factor, review the use | nothing special | ## How it is held The access model around it, rather than the storage mechanics, is what an interview is asking about: 1. **Give it a second factor, and hold that factor separately from the secret.** One person holding both is one person who is the account. 2. **Require more than one person to open it.** Two-person control turns a single bad decision, or a single compromised person, into a conversation. 3. **Record every opening**, including the ones that turn out to be unnecessary, and tie each to an incident or a change. 4. **Rotate the secret and the second factor after any use**, and when anyone who could reach it leaves. 5. **Remove every other use for it.** If billing alerts, a support ticket or a monthly task still need it, fix that first, or the credential will keep being fetched. A second factor that expires, a stored secret whose holder has left, and a recovery contact address pointing at a mailbox nobody reads are the three ways this quietly stops working, and all three are only found when it is actually needed. ## What an interviewer listens for The weak answer is 'it is the most powerful user, so protect it'. The answer that lands has three parts: *what* it uniquely keeps (a short account-level list, and providers differ), *why* it cannot be tidied away (it generally cannot be deleted and cannot be constrained by grants inside the account, so the control has to be operational), and *what the team actually does* (second factor held apart, two-person opening, alarm on any use, rotate afterwards). A candidate who also says 'and I would check that nothing routine still depends on it' has seen the failure mode that matters.
- Where should it live, and who should be able to reach it?Out of everyday reach: the secret sealed somewhere that records every opening, its second factor held by a different person or in a different place, and at least two people required to bring the halves together. Opening it should be an event with a name attached and a reason recorded, not something an on-call engineer can do quietly at three in the morning.
- What should happen the moment it is used?An alarm to a channel a human is on the hook for, not a log line anyone may read later. Then the use is tied to an incident or a change record, and when the work is finished the secret and the second factor are both rotated and resealed. The review afterwards asks a single question: what did this do that a grant could not have done?
- Why not simply delete it once proper administrators exist?Because on most platforms it cannot be deleted — it is the account's own identity, not a member of it — and because the recovery case is real: a permission change that locks out every administrator leaves nothing else able to fix the account. What you can delete are the reasons to use it, and any long-lived key it may have created.
saying these in an interview costs you the question
- It is just the strongest administrator, so a wide grant equals it
- Delete it once real administrator identities exist in the account
- Keep it in the shared team store so on-call can reach it quickly
- It needs no second factor, since nobody ever signs in with it
- Rotating it is pointless because it is never used
- Any administrator can grant themselves what it can do