Okta Certified Administrator flashcards
Okta Certified Administrator · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- STAGED user status
- A user imported into Okta without credentials or app assignments. The user cannot authenticate until activated and assigned credentials.
- DEPROVISIONED user status
- A terminal user status indicating the account is removed from Okta. Reactivation requires re-import or explicit admin action; credentials are not retained.
- APP_GROUP membership
- A group imported from an application via profile mastering. Its membership is read-only in Okta and syncs from the source application.
- Everyone group scope
- Includes all ACTIVE, STAGED, RECOVERY, PASSWORD_EXPIRED, and LOCKED_OUT users. Excludes DEPROVISIONED and SUSPENDED users, so policies on it skip suspended accounts.
- Group rule evaluation
- Rules evaluate on user create and update. A user matching multiple rules joins the union of those groups. Rules do not retroactively update unchanged users.
- Profile attribute mastering
- Each Universal Directory attribute has one master system (Okta or an app). Only one source can master an attribute; conflicting masters cause sync failures.
- Full vs incremental import
- Incremental imports process changes since the last run. Full imports re-evaluate all users and can trigger deprovisioning if matching rules are misconfigured.
- Password policy precedence
- When a user belongs to multiple groups with different password policies, the strictest applicable policy wins. Precedence is not based on group creation date.
- Policy rule priority
- Rules within a policy are evaluated top-down. The first rule whose conditions match the user and context applies; a default rule is usually last.
- Global Session Policy
- Controls whether a user must authenticate and whether MFA is required at the Okta session level. Evaluated before app-specific sign-on policies.
- App Sign-On Policy
- Controls access to an individual application after the global session is established. Can require step-up authentication or deny access based on context.
- MFA enrollment policy
- Set per group to Required, Optional, or Disabled. If MFA is required and no factor is enrolled, sign-in is blocked until enrollment completes.
- Factor categories
- Knowledge (password), possession (push, TOTP, WebAuthn, SMS, voice, email), and biometric (Okta Verify biometrics). Rules can require specific factor types.
- FastPass passwordless
- Requires a phishing-resistant factor such as WebAuthn or Okta Verify with biometrics. Configured in the authentication policy rule, not the app policy.
- Network zones
- IP zones are static CIDR lists; dynamic zones use Okta Expression Language conditions evaluated per request. Both can be referenced in policy conditions.
- System Log retention
- Okta retains System Log events for a limited window (commonly 90 days). Older events are not queryable via the API or admin console.
- user.session.start event
- The System Log eventType for a sign-in attempt. Inspect outcome.result and outcome.reason to distinguish credential failures from status or policy denials.
- user.authentication.auth_via_mfa
- EventType logged when an MFA challenge occurs. The factor and outcome.reason fields reveal whether the factor is unenrolled or disallowed by policy.
- Provisioning log events
- app.generic.provision.* events record provisioning actions and errors. Common causes are missing required attributes, mapping conflicts, or app 4xx responses.
- API rate limiting
- Okta enforces per-endpoint limits. A 429 response includes X-Rate-Limit-Reset; back off and retry. Rate-limit events appear in the System Log.
- SAML signature failure
- Usually caused by an expired or mismatched IdP certificate, or clock skew beyond the assertion window (typically about 5 minutes). Verify metadata and time sync.
- Group rule not applying
- Confirm the rule is ACTIVE, the expression matches the user, and the profile was updated since rule creation. Rules do not retroactively apply to unchanged users.
- Super Admin role
- Full control over the tenant, including org-wide settings. Cannot be deleted; Okta recommends limiting the number of Super Admins to reduce risk.
- API token permissions
- Tokens are tied to the admin who created them and inherit that admin's permissions. Shown only once; revoke when the admin leaves or permissions change.
- Custom admin roles
- If licensed, allow granular permissions beyond built-in roles. Assign via the Admin Roles page and scope to specific groups or apps where supported.
- SAML app requirements
- Requires IdP metadata (entity ID and certificate) and the app's ACS URL. Signature validation and audience restriction must match the app configuration.
- OIDC app requirements
- Requires client ID and secret, redirect URIs, and scopes. OIDC uses token-based flows rather than SAML assertions for authentication and authorization.
- SCIM provisioning setup
- Enable API integration in the app, set the base URL and credentials, and map attributes. Profile mastering determines which system owns each attribute.
- Custom domain activation
- Requires DNS verification before activation. After verification, the custom domain is used for end-user URLs and email links.
- Preview vs production cells
- Features roll out to preview cells first. Some features require enabling in Settings > Features before appearing in the admin console.
- Okta Expression Language
- Used in group rules, attribute mappings, and dynamic zones. Functions include user.get and String.substringBefore; expressions evaluate at runtime.
- Least privilege principle
- Grant admins only the permissions needed for their role. Use Help Desk, Group Admin, or Read-Only roles instead of Super Admin where sufficient.