SCIM Interview Questions: Provisioning, Deactivation, and Identity Drift

SCIM does not answer whether a user successfully signed in. It addresses a different lifecycle: creating, updating, finding, and removing or deactivating identity records across systems. In an interview, the hard part is not reciting POST /Users; it is preventing a lost response, a renamed email address, or a failed deactivation from leaving the wrong person with access.

This guide separates the SCIM core schema in RFC 7643 from the protocol in RFC 7644. Its joiner-mover-leaver case is an original practice exercise, not a report of a named employer's prompt. The question record is practice material, not a prediction of an exact interview.

The 60-second SCIM interview answer

SCIM defines a common identity schema and HTTP protocol for provisioning resources such as Users and Groups. A client, often driven by an identity provider or provisioning system, sends create, read, update, delete, filter, and related requests to a service provider. The service provider assigns its resource id; the provisioning client may assign externalId to correlate the record with its own domain. userName is a login-oriented identifier in the User schema, but it should not automatically serve as the durable cross-system key when names or email addresses can change.

For a reliable integration, map (tenant, provisioning authority, externalId) to the provider's immutable resource ID, define the intended attribute ownership, handle retries without creating duplicate users, and reconcile actual state against desired state. Deactivation needs a verified access outcome, not just an HTTP 200. RFC 7643 says active is a Boolean administrative status whose definitive meaning is determined by the service provider. A typical false value suspends login, but an interviewer should ask how the actual product handles sessions, API tokens, group access, and retention.

Original case: joiner, mover, leaver

A company has three tenants in a SaaS application. Its HR system hires Avery into tenant A; a month later Avery changes teams and needs a different group; then Avery leaves. The provisioner uses SCIM to synchronize a User and Group membership. During the hire, the service creates a user but the response is lost. During the move, another administrator changes the group manually. During the departure, the deactivation request times out. The interviewer asks you to design safe recovery.

Begin by identifying the source of truth for each attribute. HR may own employment status and legal name; the identity provider may own assigned application groups; the SaaS app may own local preferences. A broad full-record replacement from the provisioner could erase application-owned fields. Conversely, allowing local administrators to overwrite an authoritative deactivation could leave an ex-employee active. State an ownership map before writing a sync loop.

For the joiner, use the provisioner's stable person identifier as externalId within that provisioning domain, and store the returned provider id. Do not rely on email alone: Avery can change surname, lose a mailbox, or share an address pattern with a rehire. RFC 7643 defines externalId as client-issued and scoped to the provisioning domain. That scope is not the same as global uniqueness. In a multi-tenant app, the lookup must include the tenant and client identity; two tenants can both use externalId = 42 without representing the same person.

For the mover, calculate desired group membership and issue a targeted change. For the leaver, determine whether the contract calls for active: false, removal from groups, eventual deletion, or a combination. The RFC does not promise that one Boolean revokes all sessions or tokens in every product. Confirm provider behavior and verify effective access. This is a security consequence, so “the PATCH returned 200” is only one checkpoint.

Lost responses and safe create retries

The hire request sends POST /Users and the network times out. A naive retry sends a second POST and may create a duplicate. The correct answer is unknown outcome. Query for the user by a stable, tenant-scoped external identifier when the provider supports that filter, or consult the integration's durable mapping and audit trail. If a matching record exists, read and reconcile it. If not, retry creation under a duplicate-detection policy. Handle 409 Conflict as an investigation of identity, not an invitation to change the username until something works.

RFC 7644 supports filtering and describes externalId as a useful correlation key, but the standard does not magically enforce your chosen tenant-wide uniqueness rule. Service-provider capabilities and filters vary. A robust integration records the outbound operation ID, request hash, result when known, and the provider ID. It also treats a returned match as provisional until the tenant, externalId, and identity attributes agree. Matching on displayName or email alone can attach the wrong human to an existing account.

For updates, a retry may be safer if it sets a desired value rather than toggling one. “Replace active with false” is easier to repeat than “flip active.” Yet idempotent intent does not eliminate concurrent-write conflicts. If the provider supports versioning, read meta.version/ETag and send If-Match on a change, then re-read and recompute after a precondition failure. RFC 7644 includes conditional request examples; a specific provider's advertised support still needs verification. A blind retry of stale group state can undo a newer administrator action.

PATCH, PUT, and attribute ownership

SCIM PATCH expresses operations such as add, remove, and replace, including paths into multi-valued attributes. PUT is a resource replacement operation. The choice is not cosmetic: a broad replacement can drop fields not present in the client's partial view. For a mover, a narrow group-member update or user attribute patch is usually easier to reason about, subject to the provider's supported capabilities and the agreed ownership model. RFC 7644 provides examples of both PATCH and PUT.

There is still a race. The provisioner reads that Avery belongs to Group A; an admin adds Avery to Group B; the provisioner sends a full replacement based on stale state. Group B disappears. An ETag or version precondition can surface this race so the client can re-read, merge according to ownership rules, and retry. If the provider lacks usable conditional updates, the integration needs a documented conflict policy, tighter write ownership, and reconciliation checks. Do not claim “PATCH is always safe” if the patch removes all members or targets the wrong filtered value.

Another trap is partial success across User and Group resources. The User may be updated while Group membership fails. The integration should represent these as separate operations with a shared desired-state version and a visible incomplete status. Retry the failed part and reconcile both resources. Treat the sync as a workflow, not a single transaction guaranteed by the protocol.

Deactivation is an access test, not just a field update

RFC 7643 says the active attribute's definitive meaning is provider-defined. A false value commonly means the user can no longer log in, but the actual application might have long-lived sessions, API keys, delegated access, or local accounts outside the SCIM-managed population. Before claiming a departure is complete, define the required access outcome: new login blocked, existing sessions invalidated if promised, managed group access removed, and audit evidence retained. Verify those conditions through supported administrative or test interfaces; do not use a real employee's account as an unsafe ad hoc test.

DELETE /Users/{id} is a different operation. It may remove the resource, affect retention and audit trails, or be unsuitable for a reversible suspension. The provider's policy and contractual data-retention needs decide whether deactivation, deletion, or staged cleanup is appropriate. The standard's endpoint existence does not force one lifecycle for every company. In an interview, ask whether the organization wants a reversible leave, legal hold, later rehire mapping, and eventual erasure.

For the timeout in the original case, treat outcome as unknown. Read the provider User by the known id and inspect active plus the relevant access controls. Retry the desired deactivation if necessary. Escalate and alert if the source says “departed” while the target remains active beyond the permitted window. A dashboard that counts only successful API calls may miss the highest-risk drift.

Reconciliation catches identity drift

Identity drift means desired and observed state diverge: Avery is disabled upstream but active downstream, belongs to the wrong group, is duplicated under a renamed email, or is attached to the wrong tenant. Periodic reconciliation should read the provider's Users and Groups, join by stable scoped identifiers, compare only attributes the provisioner owns, and produce a repair or human-review action. If the provider paginates results, fetch all pages; a partial scan can make missing users look normal.

Do not immediately overwrite every mismatch. A deliberate local exception may be allowed, or a manual group addition may be evidence that ownership rules are underspecified. The reconciliation result should identify the source version, target version, attribute owner, expected value, observed value, and proposed action. For security-critical deactivation, use an urgent path and clear owner; for cosmetic display-name drift, batch review may be appropriate. This prioritization is an editorial design recommendation, not an RFC requirement.

Measure drift as both counts and age. “Twelve mismatches” hides whether one departed user remained active for three days. Track time from authoritative departure to verified access revocation, create retries that remain unresolved, duplicate identity candidates, and failed conditional updates. Preserve request IDs and audit records without logging sensitive attributes or credentials unnecessarily. A repair job must also avoid resurrection: it should never re-enable a leaver merely because it replayed an old joiner event after a newer departure version.

Interview decision table

Event	Unsafe shortcut and Better next step
POST /Users times out	Unsafe shortcut: POST again immediatelyBetter next step: Search/reconcile by tenant-scoped external ID and durable operation record.
Email changes	Unsafe shortcut: Create another accountBetter next step: Keep stable identity mapping; update owned attributes.
Group PATCH conflicts	Unsafe shortcut: Retry stale change foreverBetter next step: Re-read version and merge under ownership policy.
active: false succeeds	Unsafe shortcut: Declare all access revokedBetter next step: Verify the provider's effective login/session/token behavior.
Reconciliation finds extra access	Unsafe shortcut: Delete it silentlyBetter next step: Check authority, risk, and exception policy; repair or escalate.

This table is an original practice asset. It makes a key distinction visible: SCIM gives an interoperability surface, while your application still needs identity matching, concurrency control, and operational evidence. A strong answer describes both the standard operation and the failure mode it cannot solve by itself.

Final interview takeaway

Answer SCIM questions as a reconciliation problem with a security consequence. Define which system owns each attribute, keep id, externalId, and userName distinct, treat network timeouts as unknown outcomes, use conditional updates where supported, and verify effective access after deactivation. Practice the IAM system design question by tracing one joiner, one mover, and one leaver through both desired state and observed provider state.

Sources and Further Reading

• RFC 7643: SCIM Core Schema
• RFC 7644: SCIM Protocol
• RFC 7643: Common Attributes, including externalId
• RFC 7644: Querying and filtering resources

Research checked September 28, 2026. RFC behavior is distinct from a provider's supported features, attribute mapping, session handling, and retention policy; verify those in the actual integration.