Okta Certified Administrator cheat sheet

User statuses: STAGED (imported, no credentials, cannot authenticate), PROVISIONED (imported and assigned an app but no Okta credentials), ACTIVE (can authenticate), RECOVERY, LOCKED_OUT, PASSWORD_EXPIRED, SUSPENDED (credentials retained but sign-in blocked), DEPROVISIONED (terminal; reactivation requires re-import or admin action).

Group types: OKTA_GROUP (created in Okta, membership managed in Okta), APP_GROUP (imported from an app via profile mastering, membership read-only in Okta), BUILT_IN (e.g., Everyone). APP_GROUP membership cannot be edited in Okta - it syncs from the source app.

Everyone group contains all ACTIVE, STAGED, RECOVERY, PASSWORD_EXPIRED, and LOCKED_OUT users; it excludes DEPROVISIONED and SUSPENDED users. Policies assigned to Everyone therefore do not apply to suspended users.

Group rules evaluate on user create/update; matching uses profile attributes and Okta Expression Language. A user can match multiple rules - the union of all matching rule groups applies. Rules do not retroactively re-evaluate unless users are updated or the rule is re-run.

Universal Directory profile: each attribute has a data type, a master (Okta or an app), and a mutability (read-only, read-write, immutable). Only one source can master an attribute; conflicting masters cause sync failures.

Import modes: incremental (delta since last run) vs full (re-evaluates all users and can deactivate/delete based on rules). Full imports are heavier and can trigger deprovisioning if matching rules are misconfigured.

Deprovisioning behavior depends on the app's provisioning settings: deactivate (default, reversible) vs delete (irreversible in some apps). Okta deprovisions only when the user is removed from all groups/apps assigned to that integration.

Password policy precedence: the strictest applicable policy wins when a user belongs to multiple groups with different policies. Policy evaluation order is not based on group creation date.

Policy types: Password, Sign-On (Authentication), MFA Enrollment, Global Session, App Sign-On, Profile Enrollment, and Identity Threat Protection. Each type has its own priority-ordered rule list; the first matching rule wins.

Priority order matters: rules are evaluated top-down; the first rule whose conditions match the user/context applies. A catch-all 'Default Rule' is typically last and applies to everyone not matched earlier.

Global Session Policy controls whether a user must authenticate (and whether MFA is required) at the Okta session level; App Sign-On Policy controls access to individual apps and is evaluated after global session.

MFA enrollment policy can be set to Required, Optional, or Disabled per group. If a user has no enrolled factor and the policy requires MFA, sign-in is blocked until enrollment completes.

Authentication policy factors: knowledge (password), possession (push, TOTP, WebAuthn, SMS, voice, email), and biometric (Okta Verify biometrics). A rule can require specific factor types or 'any factor'.

FastPass (passwordless) requires a phishing-resistant factor (WebAuthn or Okta Verify with biometrics) and is configured in the authentication policy rule, not the app policy.

Network zones (IP zones and dynamic zones) are referenced in policy conditions. A dynamic zone is defined by an Okta Expression Language condition evaluated per request; IP zones are static CIDR lists.

Policy simulation (where available) tests rule outcomes against a user and context without changing production. Behavior differs by policy type - verify against current tenant capabilities.

System Log is the primary diagnostic source: query by eventType, actor, target, outcome.result, and time range. Events older than the tenant's retention window (commonly 90 days) are not queryable via the API.

Common eventType prefixes: user.session.start (sign-in attempt), user.authentication.auth_via_mfa (MFA challenge), policy.evaluate_sign_on (policy evaluation), app.generic.provision.* (provisioning), and user.lifecycle.* (status changes).

A failed sign-in with outcome.result = FAILURE and reason = INVALID_CREDENTIALS usually indicates wrong password or a locked/disabled account; reason = LOCKED_OUT or PASSWORD_EXPIRED indicates status, not credential mismatch.

To debug MFA failures, filter on user.authentication.auth_via_mfa and inspect the 'factor' and 'outcome.reason' fields. A DENY outcome often means the factor is not enrolled or the policy does not allow it.

Provisioning errors: check the app's provisioning log (app.generic.provision.*) and the Okta System Log. Common causes are missing required attributes, attribute mapping conflicts, or the app returning 4xx responses.

API rate limits: Okta enforces per-endpoint limits (e.g., /api/v1/users, /api/v1/apps). 429 responses include X-Rate-Limit-Reset; back off and retry. Rate-limit events appear in the System Log as system.api_token.* or similar.

SAML troubleshooting: verify the IdP metadata (entity ID, ACS URL, certificate), check clock skew (SAML assertions typically allow ~5 minutes), and validate the audience restriction. A signature validation failure usually means the certificate is expired or mismatched.

Group rule not applying: confirm the rule is ACTIVE, the user matches the expression, and the user's profile has been updated since the rule was created (rules do not retroactively apply to unchanged users).

Admin roles: Super Admin (full control, cannot be deleted, only one per tenant), Org Admin (manage users/apps but not org-wide settings), Group Admin, Help Desk Admin, App Admin, and Read-Only Admin. Least privilege is the guiding principle.

API tokens are tied to the admin who created them and inherit that admin's permissions. Tokens are shown only once; store securely. Revoke tokens when the admin leaves or permissions change.

Custom admin roles (if licensed) allow granular permissions beyond the built-in roles; assign via the Admin Roles page and scope to specific groups or apps where supported.

App integrations: SAML 2.0, OIDC/OAuth 2.0, SWA, and bookmark-only. SAML requires IdP metadata and ACS URL; OIDC requires client ID/secret, redirect URIs, and scopes.

Provisioning (SCIM) requires enabling API integration in the app, setting the base URL and credentials, and mapping attributes. Profile mastering determines which system owns each attribute.

Org settings include branding, email templates, custom domains, and the Okta End-User Dashboard. Custom domains require DNS verification before activation.

Tenant lifecycle: production vs preview cells; features roll out to preview first. Some features require enabling in Settings > Features before they appear in the admin console.

Okta Expression Language is used in group rules, attribute mappings, and dynamic zones. Functions include user.get, String.substringBefore, and comparisons; expressions are evaluated at runtime, not stored as static values.