26% of Part II — hands-on configuration, not multiple choice.
5 tasks · this deck covers task 5 of 5 — the last one in this task set
↑ User Management OverviewWe've already met group rules once, back in Identity & Access Management. This task is the hands-on half — actually building one — plus a real restriction that didn't come up the first time.
Group rules automate membership based on user attributes — Attribute-Based Access Control (ABAC). Common uses: mapping multiple AD groups into one Okta group, populating groups from attributes like department or cost center, and automating app-role provisioning instead of manual assignment.
The 2,000-rule-per-org limit is the same fact from IAM Module 1's "HR as a Source" content — this isn't a new number, just the same ceiling showing up again in the hands-on context.
This is a real restriction not covered when we first met group rules — you can't automate your way into granting admin access. That has to stay a deliberate, manual action.
Only super admins and org admins can edit rules. Individual group admins can't even view or search rules — unless they manage all groups org-wide.
Basic condition rules support string attributes only. If the condition you need depends on a non-string attribute, a basic rule won't get you there.
Watch for these in your own sandbox run:
→ Trying to build a rule that auto-assigns users into an admin group — it's blocked by design.
→ A group admin who can't find the Rules tab at all — expected, unless they manage all groups.
Sources: help.okta.com — usgp-about-group-rules.htm
✓ User Management — 5 of 5 courses complete (labs still to come)