In a cloud platform, how does the account that owns and bills for resources differ from an engineer's sign-in identity?

middleshould knowfreq 44%

answer

container against actor
one word, two constructs
resources outlive the sign-in
which account, then as whom
the bill never names a person

basics

~20 s

The account is the container that owns resources, collects the bill and holds the quota pool. A sign-in identity is a principal acting inside that container. Resources belong to the account, so they outlive the identity that created them.

solid answer

~50 s

They are different constructs sharing one overloaded word. The account is the container: resources are created inside it, charges land on it, usage ceilings are counted against it, and it is the isolation boundary. A sign-in identity is a principal that acts within an account - a person, or a workload with its own identity receiving short-lived credentials. Principals are defined inside the account or trusted into it from an external directory; either way they act on the account's resources, they do not contain them. The practical consequences are the ones interviewers want: a resource created by an engineer keeps running and keeps charging the account after that engineer's identity is removed; a bill cannot be addressed to a person; and "which account?" and "as whom?" are two separate questions you have to answer separately when you debug an access failure.

They are different constructs sharing one overloaded word. The **account** is the container: resources are created inside it, charges land on it, usage ceilings are counted against it, and it is the isolation boundary. A **sign-in identity** is a principal that acts within an account - a person, or a workload with its own identity receiving short-lived credentials. Principals are defined inside the account or trusted into it from an external directory; either way they act *on* the account's resources, they do not contain them. The practical consequences are the ones interviewers want: a resource created by an engineer keeps running and keeps charging the account after that engineer's identity is removed; a bill cannot be addressed to a person; and "which account?" and "as whom?" are two separate questions you have to answer separately when you debug an access failure.

go deeper

for a junior

Hold the two apart: the account is the container that owns resources and receives the bill; a sign-in identity is a principal acting inside it. Resources keep running after the person is gone.

for a middle

Explain the consequences - charges attach to the account, ceilings are counted against it, the audit record lives in it while naming the acting principal - and that a workload identity is a principal too.

for a senior

Use the distinction to debug: establish which account holds the resource before touching any rights, then which principal is calling. Explain why a cross-account refusal is not fixed by broadening the caller alone.

for a principal

Consider the estate: where identities are administered, how ownership of resources survives people, and what you require at creation time so nothing becomes unattributable later.

One word, two constructs

Providers use "account" for both the container that owns resources and, casually, for the credential an engineer signs in with. Keeping them apart is not pedantry - almost every confused conversation about access, ownership or cost traces back to collapsing them.

The account is the container. Every resource is created inside exactly one. The bill is addressed to it. Most usage ceilings are counted against it. It is the isolation boundary: reaching resources in another account takes a deliberate grant, normally arranged on both the caller's side and the target resource's side.

A principal is something that acts. A human engineer signs in as one. A running service gets a workload identity and receives short-lived credentials without a human anywhere in the loop. Principals are defined inside the account, or trusted into it from an external directory the organisation already runs. Either way, a principal has standing in an account; it is not the account.

What follows, in practice

Question	Answered by the account	Answered by the identity
Who is charged for this resource?	Yes - always the account	No
Which resources survive a person leaving?	Yes - all of them	No
Which pool of usage ceilings does this draw on?	Yes	No
Who is allowed to perform this action?	Sets the boundary	Yes - the principal's rights decide
Where do the calls appear in the audit record?	The account's record	Recorded as the acting principal

The row that catches people is the second one. Removing a departing engineer's sign-in removes a principal. It does not remove, stop or transfer a single resource that principal created, because those resources were never theirs - they belong to the account, and they keep charging the account's bill. Orphaned resources with nobody left who knows what they are for is one of the most reliable findings in any cost review.

The last row is worth stating carefully too: the audit record lives in the account, and each entry names the principal that acted. Both halves are needed. "Someone deleted it" is answered by the record; "which someone" is answered by the principal on the entry.

Debugging with the distinction

When a call is refused, the distinction turns into two separate questions you should ask in order:

Which account is this resource in? If the answer is "a different one from the caller", no amount of fixing the caller's rights helps on its own - a cross-account grant normally needs arrangement on both sides, and an explicit deny will beat an allow wherever the platform evaluates one.
As which principal am I calling? Automation that behaves differently from an engineer running the same command is almost always running as a different principal, not encountering a different account.

Getting these the wrong way round produces the classic wasted afternoon: broadening a caller's rights over and over when the resource was never in that account at all.

Two refinements worth knowing

Identities can be trusted in rather than defined locally. Many organisations keep people in an external directory and let the account trust it, so engineers have no separate credential per account. That changes where the identity is administered; it does not change which account owns the resources or receives the bill.
Not every principal is a person. A workload identity attached to a running service is a principal in exactly the same sense, and during an incident it matters more, because it is the one that holds credentials continuously rather than for the length of a session.

The sentence to leave with

An account is answered by "where does this live and who pays for it"; an identity is answered by "who is acting". Resources belong to the account, principals act inside it, and the bill never has a person's name on it.

## One word, two constructs Providers use "account" for both the container that owns resources and, casually, for the credential an engineer signs in with. Keeping them apart is not pedantry - almost every confused conversation about access, ownership or cost traces back to collapsing them. **The account** is the container. Every resource is created inside exactly one. The bill is addressed to it. Most usage ceilings are counted against it. It is the isolation boundary: reaching resources in another account takes a deliberate grant, normally arranged on both the caller's side and the target resource's side. **A principal** is something that acts. A human engineer signs in as one. A running service gets a workload identity and receives short-lived credentials without a human anywhere in the loop. Principals are defined inside the account, or trusted into it from an external directory the organisation already runs. Either way, a principal has *standing in* an account; it is not the account. ## What follows, in practice | Question | Answered by the account | Answered by the identity | |---|---|---| | Who is charged for this resource? | Yes - always the account | No | | Which resources survive a person leaving? | Yes - all of them | No | | Which pool of usage ceilings does this draw on? | Yes | No | | Who is allowed to perform this action? | Sets the boundary | Yes - the principal's rights decide | | Where do the calls appear in the audit record? | The account's record | Recorded as the acting principal | The row that catches people is the second one. Removing a departing engineer's sign-in removes a principal. It does not remove, stop or transfer a single resource that principal created, because those resources were never theirs - they belong to the account, and they keep charging the account's bill. Orphaned resources with nobody left who knows what they are for is one of the most reliable findings in any cost review. The last row is worth stating carefully too: the audit record lives in the account, and each entry names the principal that acted. Both halves are needed. "Someone deleted it" is answered by the record; "which someone" is answered by the principal on the entry. ## Debugging with the distinction When a call is refused, the distinction turns into two separate questions you should ask in order: 1. **Which account is this resource in?** If the answer is "a different one from the caller", no amount of fixing the caller's rights helps on its own - a cross-account grant normally needs arrangement on both sides, and an explicit deny will beat an allow wherever the platform evaluates one. 2. **As which principal am I calling?** Automation that behaves differently from an engineer running the same command is almost always running as a different principal, not encountering a different account. Getting these the wrong way round produces the classic wasted afternoon: broadening a caller's rights over and over when the resource was never in that account at all. ## Two refinements worth knowing - **Identities can be trusted in rather than defined locally.** Many organisations keep people in an external directory and let the account trust it, so engineers have no separate credential per account. That changes where the identity is *administered*; it does not change which account owns the resources or receives the bill. - **Not every principal is a person.** A workload identity attached to a running service is a principal in exactly the same sense, and during an incident it matters more, because it is the one that holds credentials continuously rather than for the length of a session. ## The sentence to leave with An account is answered by "where does this live and who pays for it"; an identity is answered by "who is acting". Resources belong to the account, principals act inside it, and the bill never has a person's name on it.

An engineer leaves and their sign-in is removed. What happens to the resources they created?
They keep running and keep charging the account, because resources belong to the account rather than to the principal that created them. This is how orphaned spend accumulates: the only person who knew what a resource was for is gone, and nothing about removing their identity touched it. Attribution by tagging at creation time is what makes the survivors identifiable later.
A call from automation is refused where the same command works for you. Which question do you ask first?
Ask which account the resource is in before touching any rights. If it is a different account from the caller's, the fix is a cross-account grant arranged on both sides, not a broader permission on the caller. Only once the account matches is it worth asking which principal the automation runs as, since automation rarely runs as the engineer.

The account is the building and the lease; a sign-in identity is a keycard. Cancelling a keycard changes who can walk in, not who owns the furniture or who pays the rent.

saying these in an interview costs you the question

Uses account and sign-in identity as interchangeable words
Says resources are deleted when the engineer who created them is removed
Expects a bill to be addressed to the person who created the resource
Thinks trusting an external directory moves resource ownership out of the account
Treats only humans as principals, ignoring workload identities

In a cloud platform, how does the account that owns and bills for resources differ from an engineer's sign-in identity?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~3 min

One word, two constructs

What follows, in practice

Debugging with the distinction

Two refinements worth knowing

The sentence to leave with

▾common follow-ups2 questions

▾analogy~10 s

▾red flags5 flags

One word, two constructs

What follows, in practice

Debugging with the distinction

Two refinements worth knowing

The sentence to leave with

answer

go deeper