Text preview & study summary
Okta Certified Administrator - Identity Access Management SSO MFA Lifecycle Directory
A free sample of 5 questions from this quiz, shown in full with answer choices and explanations. No interactivity — everything is visible on this page for study and review.
Want to test your knowledge? Launch the Interactive Exam Simulator
Question 1
A user's Okta account has been compromised. The security team needs to immediately revoke all active sessions and access tokens for this user without permanently deactivating the account. What action should the Okta administrator take?
Explanation
For immediate security response to a compromised account without permanent deactivation: (1) Clear All Sessions — in the user's profile in the Okta Admin Console (or via API `DELETE /api/v1/users/{userId}/sessions`), this immediately invalidates ALL active Okta sessions globally (across all devices and applications). The user is immediately logged out of all SSO-connected apps. (2) Revoke OAuth/OIDC Tokens — using the Okta API, revoke all active OAuth 2.0 access tokens and refresh tokens for the user. (3) Additionally, consider resetting the user's password to prevent further logins and requiring MFA re-enrollment if the factor was compromised. Suspension (Option B) also works but is more disruptive. Password change (Option A) doesn't automatically invalidate existing sessions. Account deletion (Option D) is irreversible and loses audit history.
Question 2
An Okta administrator is reviewing the Okta System Log and finds unusual login activity. They see multiple failed login attempts followed by a successful login from an IP address in an unexpected country, all for the same user account within a 5-minute window. Which Okta security feature would have detected and potentially blocked this behavior automatically?
Explanation
Okta ThreatInsight is a built-in threat detection feature that analyzes login request behavior across all Okta organizations. It detects: (1) Credential stuffing attacks (many failed logins from distributed IPs), (2) Brute force attacks (many failed attempts on a single account), (3) Anomalous IP behavior (IPs associated with malicious activity across Okta's network). ThreatInsight can be configured to: Audit (log threats without blocking), Block requests from risky IPs, or Require MFA (step-up authentication) for risky login attempts. This specific scenario — multiple failures then success from unexpected country — triggers ThreatInsight's anomaly detection. IP Blocklist (Option A) requires knowing the bad IPs in advance; ThreatInsight is adaptive. Password complexity (C) doesn't address behavioral anomalies.
Question 3
An Okta administrator is configuring Single Sign-On (SSO) for a SaaS application that supports SAML 2.0. The application requires the NameID format to be "EmailAddress" and needs the user's department included as an attribute. What Okta configuration achieves this?
Explanation
When configuring SAML 2.0 SSO in Okta: (1) In the "SAML Settings" section of the app configuration, set NameID format to "EmailAddress" and NameID value to `${user.email}` or `appuser.email`. (2) Under Attribute Statements, add custom attributes: Name=`department`, Value=`${user.department}` (maps from the Okta Universal Directory `department` profile attribute). These attributes are included in the SAML assertion sent to the application. Okta's Universal Directory stores user attributes from various sources (AD, manual, API), and the SAML attribute statements can reference any UD attribute using `${user.attributeName}` syntax. OIDC uses JSON claims (not SAML assertions) and is a separate protocol.
Question 4
A large organization is deploying Okta across multiple subsidiaries, each requiring complete isolation of users, applications, and policies while sharing a single Okta subscription. Which Okta architecture feature should the administrator evaluate?
Explanation
Within a single Okta org, isolation between subsidiaries can be achieved through: (1) Delegated Administration — assign admin roles scoped to specific groups (Subsidiary A Admins can only manage Subsidiary A users and their assigned apps). (2) Group-based access control — separate groups per subsidiary with their own app assignments, policies, and attribute mappings. (3) Okta Identity Governance — provides fine-grained access request and certification workflows with organizational boundaries. For COMPLETE isolation (separate admin consoles, zero data visibility between subsidiaries, separate security policies), separate Okta orgs (Option A) is required but costs more. For most enterprise subsidiaries requiring administrative delegation but not complete data isolation, delegated administration within a single org (Option C) is the practical solution. UD Groups alone (Option D) don't provide admin isolation.
Question 5
An Okta administrator is troubleshooting why a user cannot access a SAML application. The user reports receiving a "403 Forbidden" error after attempting to log in. Where should the administrator investigate?
Explanation
Troubleshooting SAML SSO failures in Okta: (1) Okta System Log (Reports > System Log) — search for the user's login events. SAML events show details including: whether the authentication was successful in Okta, the SAML assertion sent, and any errors detected. Look for `user.authentication.sso` events. (2) Application Assignment — verify the user or their group is assigned to the application in the application's Assignments tab. If not assigned, Okta won't generate a SAML assertion. (3) NameID matching — the NameID in Okta's SAML assertion must match the identifier the SP uses to recognize the user (usually email or username). A mismatch causes the SP to reject the authentication. (4) SAML tracer — browser extension that captures SAML assertions for detailed debugging. A 403 from the SP often means Okta authentication succeeded but the SP denied access.