User and Group Management
Domain 1: User and Group Management
This domain tests how Okta represents identities and access: user lifecycle, profile mastering, group rules, app assignment, and group push. Expect scenario questions about why a user is (or is not) in a group, why an app tile appears, and what happens when a rule or source changes.
Core rules
- Okta user status drives access: Staged users have no credentials; Active users can authenticate; Suspended users keep assignments but cannot sign in; Deactivated users cannot sign in and can be reactivated. Deactivation is not deletion.
- Groups are the scalable assignment unit. Assign an app to a group, then membership controls the app tile and access. Direct user assignment still works but does not scale.
- Group rules use Okta Expression Language. A rule adds matching users automatically; manual removal is blocked while the rule owns membership. Deleting a rule does not remove existing members; it converts them to manual membership.
- The built-in Everyone group cannot be deleted or manually edited; use it deliberately because it can grant broad access.
- Group push sends Okta group membership to a connected app. It is one-way from Okta unless the app supports bidirectional sync; local app changes do not automatically return to Okta.
Worked example
A rule condition user.department == "Sales" and user.title == "Manager" adds sales managers to 'Sales Managers'. Assign the CRM app to that group. A user moved to 'Account Executive' loses rule membership and the app tile. If the rule is deleted instead, the user remains in the group until an admin removes them. Reasoning: rule membership is dynamic; deletion freezes current membership.
Traps
Do not confuse deactivation with deletion. Do not expect group push to reconcile app-side changes. Do not manually remove rule-managed members and expect it to stick. Do not use Everyone for sensitive apps without checking staged and service accounts.