Why do engineers sign in to a production cloud account through the company directory instead of each holding a local platform login?
answer
- one person, one place
- membership, not credentials
- leaving cuts every federated path
- groups map to access profiles
- the account's own logins survive
basics
~20 sFederated workforce logins keep one copy of each person, in the company directory: cloud access follows group membership, and disabling the directory account cuts every federated sign-in at once. Local platform logins are extra credentials nobody remembers to delete.
solid answer
~50 sBecause the company directory should be the only place a person exists. With federated workforce logins the account holds no user record for anyone: the person authenticates to the directory, and the platform issues a session carrying the named set of permissions mapped to their directory groups. Access is therefore granted by **membership** — a joiner is added to a group, a mover's old access drops off with the old group, and disabling a leaver's directory account stops every federated sign-in at once instead of leaving one forgotten local login per account. It also puts one password and second-factor policy over everyone, and makes the sign-in record name a person rather than an account-local user. The limit is worth saying aloud: it removes nothing that was created *inside* the account — local logins, static keys and integration credentials survive the directory account being disabled.
code
json · 9 lines{
"account": "ledger-production",
"grants": [
{ "directoryGroup": "payments-engineers", "accessProfile": "ledger-operator", "sessionMinutes": 60 },
{ "directoryGroup": "payments-oncall", "accessProfile": "ledger-break-fix", "sessionMinutes": 60 },
{ "directoryGroup": "finance-reporting", "accessProfile": "ledger-read-only", "sessionMinutes": 240 }
],
"localLogins": []
}go deeper
Know the one-sentence reason: the directory is the single place a person exists, so access follows group membership and disabling the person stops every federated sign-in at once.
Be able to describe the mechanics — the account stores a rule mapping a directory group to a named access profile, not a user record — and say why a session already issued runs to its expiry.
Show that you have offboarded someone for real: name what survives a directory disable, and describe how you reconcile the account's own principals back to the directory so nothing lingers.
The trade-off you own is where the mapping lives and who may change group membership, since that group is now the real production grant and needs tighter control than the account it points at.
## Two ways a cloud account can know a person A cloud account can hold a **local platform login** — a user record created inside the account itself, with its own password, its own second factor and its own permissions — or it can **trust the company directory** and create no user record at all. In the federated arrangement the person authenticates to the directory, the directory asserts who they are and which groups they belong to, and the platform issues a session carrying the **access profile** (a named set of permissions the account defines) that it has mapped to those groups. Nothing about the person is stored in the account. What is stored is a *rule*: this directory group receives this access profile in this account. That difference sounds administrative, and it is actually the whole of your offboarding story, your sign-in policy and the usefulness of your sign-in records. ## What the directory buys you | Question | Local platform login | Directory-federated login | |---|---|---| | Where the person exists | once in every account they use | once, in the company directory | | How access is granted | edited per person, per account | by group membership | | What disabling them removes | only what someone remembers to delete | every federated sign-in path, at once | | Whose sign-in policy applies | whatever that account was set to | the company's, uniformly | | What the sign-in record names | an account-local user | the directory person and the profile used | ## Group membership is the grant - Access is expressed as a mapping from a **directory group** to an **access profile** in a named account, not as a list of people held inside the account. - A joiner gets working access by being added to the group their role implies; nobody edits the account. - A mover's access changes because their membership changed, and the previous team's access leaves with the previous group. - A leaver loses every federated sign-in path when the directory account is disabled, because there is nothing left to assert who they are. - Reviewing access becomes reviewing two small lists — group membership, and the group-to-profile mapping — rather than walking every account one identity at a time. The cost is that the mapping itself becomes sensitive: whoever can add a person to a group can grant production. That is why the group mapped to a production profile is normally a separate, tightly held group from the one mapped to a sandbox, and why changes to the mapping are themselves reviewed. ## What federation does not remove This is the part candidates miss, and on a real estate it is exactly where the residue lives. 1. **Logins created inside the account.** A local platform login, and any long-lived static key made by one, has no connection to the directory at all. Disabling the person in the directory does not touch it. 2. **The founding owner credential.** The identity the account was created with predates federation and is not federated. 3. **Integrations.** A third-party tool that was handed its own credential into the account keeps working with it. 4. **Sessions already issued.** A federated session that has already been minted normally runs until it expires; disabling the directory account stops the *next* sign-in. Session lifetime is what bounds that gap, which is why short lifetimes are the usual setting for a production profile. So 'we federated our logins' is a true statement about new access and an incomplete statement about existing access. The migration is only finished when the local logins are gone and something keeps checking that none have come back. ## Why this is asked on a first screen It is the cheapest way to find out whether a candidate has ever been on the other side of an offboarding. The weak answer is 'it is more convenient, one password to remember'. The answer that lands names the single source of truth and its consequences: one place a person exists, access that follows membership instead of being copied per account, one uniform second-factor policy, and a record that names a person rather than an account-local user whose owner nobody can reconstruct a year later. A candidate who adds 'and it does nothing about whatever was created inside the account' has clearly done the work. Where providers differ, they differ on the shape of the mapping rather than the model: the group-to-profile rule may be held in the account, assigned from the directory side, or kept in a central place that pushes both. Every large platform supports the arrangement, and every one of them still supports local logins as well, which is why those keep turning up in accounts that were created before anyone thought about it.
- An engineer moves from the payments team to the data team. What changes, and what does not?Their group membership changes, so the next sign-in issues a session for the new team's access profile and the old team's profile is simply no longer mapped to them. What does not change on its own: a session already issued keeps the old profile until it expires, and anything granted to them directly inside an account — a local login, a static key, a one-off exception — was never tied to the group and stays.
- Why does disabling someone in the directory not always mean they are out?Because the directory only controls the federated path. A local login created inside the account, a static key made by one, or a credential issued to an integration authenticates against the account itself and never consults the directory. Offboarding is only complete when the account's own principals have been reconciled against the directory and the unmatched ones removed.
saying these in an interview costs you the question
- Federation is only about convenience and adds nothing to security
- A local platform login is fine as long as its password is strong
- Disabling the directory account also kills any static keys the person created
- Every federated person still needs a matching local login in each account
- Access is granted per person in the account, not by directory group
- One shared login is acceptable as long as the directory owns it