Okta Administrative Configuration
Domain 4: Okta Administrative Configuration
This domain tests org-level setup and delegation: admin roles, org security, branding, domains, IdPs, network zones, API tokens, and extensibility. Questions focus on least privilege and blast radius.
Core rules
- Okta admin roles are assigned to users or groups. Super Admin is unscoped; Org Admin manages most settings; App Admin, Group Admin, Help Desk Admin, and custom roles can be scoped. Use custom roles and group assignment for least privilege.
- Help Desk Admin can reset passwords and MFA but should not hold Super Admin. API tokens inherit the creating admin's privileges, so treat them as secrets, rotate them, and never share personal tokens.
- Network zones define trusted IP ranges and are used in policies. Trusted proxies tell Okta to read the client IP from
X-Forwarded-For; misconfiguration can make every request look internal. - Org security settings include admin console MFA, Okta Support access, session lifetime, and clickjack/CSP controls. Branding and custom domains affect sign-in and email trust, not authorization.
- Inbound IdPs federate authentication; outbound provisioning and group push manage downstream apps. Inline hooks run synchronously and can block authentication if they time out; event hooks are asynchronous.
Worked example
A help desk team must reset MFA only for the 'Contractors' group. Create a custom role with permission to reset factors and view users, assign it to the help desk group, and scope the role to the Contractors group. Do not assign Super Admin. Test with a help desk account against a contractor and a non-contractor. Reasoning: scoped delegation limits blast radius and satisfies least privilege.
Traps
Do not scope Super Admin-it is global. Do not create API tokens under a super admin for convenience. Do not confuse network zones with app assignments. Do not enable trusted proxies without validating header handling. Do not assume branding changes policy.