I85PREP
⌘ K
Okta Certified Consultant study materials
Okta Certified Consultant study resources

Okta Certified Consultant practice questions

One question at a time. Build your Okta Certified Consultant understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Implementing Okta in various environments

An organization wants users to authenticate against its on-premises Active Directory without installing any Okta agent on domain controllers. Which Okta integration should the consultant recommend?

  1. Universal Directory import via CSV
  2. LDAP interface with password delegation
  3. Active Directory agent with delegated authentication Correct answer.
  4. SAML federated identity provider

Explanation

The Okta Active Directory agent installs on a domain-joined Windows server and enables delegated authentication, so user credentials are validated by AD without exposing domain controllers directly. It also handles import and profile mastering. LDAP interface is for directory lookups, not AD password validation.

Question 2Implementing Okta in various environments

A consultant needs to provision users from Okta into a SCIM 2.0-compliant application that supports both create and update operations. Which Okta feature accomplishes this?

  1. Access Certification campaign
  2. SAML Just-in-Time provisioning
  3. Universal Directory profile mastering
  4. Lifecycle Management provisioning Correct answer.

Explanation

Lifecycle Management (LCM) provisioning pushes create, update, and deactivate operations to downstream apps via SCIM or proprietary connectors. JIT provisioning only creates users at login and does not handle deactivation or updates.

Question 3Implementing Okta in various environments

Users must be able to sign in to Okta using their existing Microsoft Entra ID credentials, with Okta remaining the central policy engine for downstream apps. Which configuration pattern fits?

  1. Okta Org Authorization Server with OIDC
  2. Okta as SAML IdP with Entra ID as SP
  3. Okta RADIUS agent for Entra ID
  4. Entra ID as inbound SAML IdP for Okta Correct answer.

Explanation

Configuring Entra ID as an inbound SAML identity provider lets users authenticate at Entra ID and be asserted into Okta, which then applies its own sign-on policies for downstream applications. Okta stays the hub while Entra ID handles primary authentication.

Question 4Implementing Okta in various environments

A company wants to protect an on-premises Java application with Okta without modifying its source code. Which approach is most appropriate?

  1. Okta Workflows connector
  2. Okta Access Gateway reverse proxy Correct answer.
  3. Okta Advanced Server Access
  4. Okta Verify push factor

Explanation

Okta Access Gateway is a reverse proxy deployed in the data center that fronts legacy on-premises web applications and enforces Okta authentication via SAML or header injection without code changes. It is designed specifically for this hybrid scenario.

Question 5Implementing Okta in various environments

A consultant must ensure that when a user is deactivated in Okta, their session in a SAML-integrated application is terminated. Which capability addresses this?

  1. SAML single logout (SLO) configured on the app Correct answer.
  2. Session lifetime set to 15 minutes
  3. Force re-authentication in sign-on policy
  4. Okta FastPass device check

Explanation

SAML single logout sends a logout request to the service provider when the Okta session ends, terminating the app session. Short session lifetimes only reduce exposure; they do not proactively end the downstream session at deactivation.

Question 6Implementing Okta in various environments

An administrator needs to import users from a Workday HR system so that Okta treats Workday as the authoritative source for name and department attributes. Which setting must be configured?

  1. Workday as a provisioning target
  2. Workday as an access certification source
  3. Workday as a SAML identity provider
  4. Workday as profile master for those attributes Correct answer.

Explanation

Designating Workday as the profile master makes Okta accept attribute updates from Workday and prevents other sources from overwriting them. This is the standard HR-as-master pattern.

Question 7Implementing Okta in various environments

A customer wants to use Okta as the identity provider for an application that only supports OpenID Connect. Which Okta component issues the ID token?

  1. Okta RADIUS agent
  2. Okta LDAP interface
  3. Custom Authorization Server
  4. Org Authorization Server Correct answer.

Explanation

The Org Authorization Server is the built-in issuer used for OIDC sign-in to applications and supports the /oauth2/v1 endpoints. Custom Authorization Servers are used for API access scenarios.

Question 8Implementing Okta in various environments

Which Okta feature allows a consultant to map an Okta attribute to an application's expected username format without changing the user's Okta login?

  1. Password policy
  2. App username format setting Correct answer.
  3. Global session policy
  4. Network zone

Explanation

The application's username format setting defines how Okta generates the app-specific username (for example, email or AD-style) independently of the Okta sign-in identifier. It is configured per application.

Question 9Implementing Okta in various environments

A consultant is deploying Okta for a workforce where some users must be blocked from signing in outside the corporate IP range. Where should this restriction be enforced?

  1. Okta Verify enrollment policy
  2. Password policy complexity rules
  3. Global session policy with a network zone condition Correct answer.
  4. Application sign-on policy with an MFA requirement

Explanation

Global session policy evaluates conditions such as network zones before establishing an Okta session, so blocking outside the corporate range prevents any app access. It is the correct layer for org-wide access restrictions.

Question 10Implementing Okta in various environments

When configuring the Okta AD agent for high availability, which practice is recommended?

  1. Install agents only on workstations
  2. Install a single agent on a domain controller
  3. Rely on the LDAP interface instead of agents
  4. Install the agent on multiple domain-joined servers in the same domain Correct answer.

Explanation

Okta recommends installing the AD agent on at least two member servers per domain to provide redundancy; agents should not be installed on domain controllers. Multiple agents in the same domain share load and provide failover.

Question 11Implementing Okta in various environments

An application requires that only members of a specific Okta group be assigned, and that membership changes take effect immediately without manual reassignment. Which configuration supports this?

  1. Enable self-service registration
  2. Assign individual users to the application
  3. Enable Just-in-Time provisioning only
  4. Assign the group to the application Correct answer.

Explanation

Assigning a group to an application means membership is evaluated dynamically, so adding or removing a user from the group changes app access automatically. Individual assignments require manual updates.

Question 12Implementing Okta in various environments

A consultant needs to import users from an on-premises LDAP directory that is not Active Directory. Which Okta capability is designed for this?

  1. SCIM outbound provisioning
  2. SAML inbound federation
  3. Okta LDAP agent for generic LDAP directories Correct answer.
  4. Active Directory agent

Explanation

Okta provides an LDAP agent that connects to generic LDAP directories (such as OpenLDAP or Oracle Directory) for import and delegated authentication, separate from the AD-specific agent. It supports profile import and password validation.

Question 13Implementing Okta in various environments

A customer wants Okta to authenticate users to a RADIUS-based VPN appliance. Which Okta component is required?

  1. Okta LDAP interface
  2. Okta RADIUS agent Correct answer.
  3. Okta Provisioning agent
  4. Okta Access Gateway

Explanation

The Okta RADIUS agent runs on a server in the customer network and translates RADIUS authentication requests into Okta authentication, enabling MFA for VPN and network devices. It is the standard integration for RADIUS clients.

Question 14Implementing Okta in various environments

In a multi-tenant deployment, a consultant must ensure that users from two different Okta orgs can access a shared application without duplicate accounts. Which approach is appropriate?

  1. Enable self-service registration in both orgs
  2. Use SCIM to sync users between orgs
  3. Federate one org to the other via inbound SAML Correct answer.
  4. Merge both orgs into one Universal Directory

Explanation

Federating one Okta org to another using inbound SAML allows users from a partner or subsidiary org to authenticate in their home org and access apps in the target org, avoiding duplicate identities. This is the standard multi-org pattern.

Question 15Implementing Okta in various environments

A consultant wants to enforce that administrators must use phishing-resistant authenticators when accessing the Okta Admin Console. Which policy type is used?

  1. Password policy
  2. Application sign-on policy
  3. Global session policy
  4. Admin console access policy with authenticator requirements Correct answer.

Explanation

Okta provides an admin console access policy that can require specific authenticators, such as FastPass or FIDO2, for administrative access. It applies specifically to the Admin Console, separate from end-user sign-on.

Question 16Implementing Okta in various environments

An application supports SAML but requires that the assertion be signed with a customer-specific certificate. What should the consultant configure?

  1. Set the app to use OIDC instead
  2. Enable request signing only
  3. Upload a custom signing certificate in the app's SAML settings Correct answer.
  4. Change the Org Authorization Server issuer

Explanation

Okta allows uploading a custom signing certificate in the application's SAML settings so assertions are signed with a certificate the service provider trusts. This is common when the SP requires a specific key.

Question 17Implementing Okta in various environments

A consultant is configuring Okta to provision users to an application that does not support SCIM and has no Okta connector. Which approach is feasible?

  1. Use Okta Workflows with the app's REST API Correct answer.
  2. Configure RADIUS provisioning
  3. Use the LDAP interface for provisioning
  4. Enable SAML JIT provisioning only

Explanation

When no connector exists, Okta Workflows can call the application's REST API to create and update accounts, providing custom provisioning. JIT only creates users at login and cannot deactivate them.

Question 18Implementing Okta in various environments

A customer uses Okta for SSO but wants to keep passwords in their on-premises AD and not store them in Okta. Which setting must be enabled?

  1. Self-service password reset
  2. Delegated authentication via the AD agent Correct answer.
  3. Password import from CSV
  4. Okta-managed password policy

Explanation

Delegated authentication routes password validation to Active Directory through the AD agent so Okta never stores the password. This is the standard configuration for keeping credentials on-premises.

Question 19Implementing Okta in various environments

A consultant must ensure an application receives the user's department attribute in the SAML assertion. What must be configured?

  1. An attribute statement mapping department to a SAML attribute Correct answer.
  2. A network zone containing the department
  3. A password policy rule for department
  4. A provisioning group named after the department

Explanation

SAML attribute statements map Okta profile attributes, such as department, into the assertion sent to the service provider. The SP reads the attribute name defined in the mapping.

Question 20Implementing Okta in various environments

A consultant needs to configure Okta so that users are prompted for MFA only when they access a sensitive application, while other apps require only password. Which configuration achieves this?

  1. Application sign-on policy with a step-up rule Correct answer.
  2. Authenticator enrollment policy
  3. Global session policy with MFA always required
  4. Password policy with complexity rules

Explanation

Application sign-on policies evaluate per application, so a step-up rule can require MFA for the sensitive app while other apps use a less strict policy. Global session policy would apply org-wide.

Question 21Implementing Okta in various environments

A customer has an existing Okta org and wants to add a second brand with a custom domain and separate sign-in page. Which Okta feature is used?

  1. Profile mastering
  2. Multibrand customization Correct answer.
  3. Custom authorization server
  4. Network zone

Explanation

Multibrand customization allows multiple branded sign-in experiences with distinct domains and styles within a single org. It is used for subsidiaries or partner-facing portals.

Question 22Implementing Okta in various environments

A consultant must implement Just-in-Time provisioning for a SAML app while ensuring that deactivated Okta users lose access immediately. Which combination is required?

  1. JIT provisioning plus self-service registration
  2. JIT provisioning plus lifecycle provisioning for deactivation Correct answer.
  3. JIT provisioning plus a longer session lifetime
  4. JIT provisioning plus a custom authorization server

Explanation

JIT creates accounts at login but does not deactivate them, so lifecycle provisioning must be enabled to push deactivation to the app. Combining both provides creation and termination.

Question 23Implementing Okta in various environments

A consultant is troubleshooting an AD agent that fails to authenticate users after a domain controller change. Which step is most appropriate first?

  1. Reinstall Okta Verify on all users
  2. Rotate the SAML signing certificate
  3. Verify the agent service account permissions and domain connectivity Correct answer.
  4. Disable the global session policy

Explanation

AD agent authentication depends on the agent service account having the correct permissions and connectivity to domain controllers. Verifying these is the first diagnostic step when authentication fails after infrastructure changes.

Question 24Implementing Okta in various environments

An organization requires that Okta provisioning to a SaaS app include custom attributes not present in the base SCIM schema. What should the consultant configure?

  1. A network zone
  2. A SAML attribute statement
  3. SCIM schema extension mapping in the app profile editor Correct answer.
  4. A password policy rule

Explanation

The app's profile editor can map custom Okta attributes to SCIM schema extensions supported by the application, enabling custom attribute provisioning. SAML attribute statements apply to assertions, not SCIM payloads.

Question 25Implementing Okta in various environments

A consultant must ensure that an Okta org meets a requirement where all API tokens are rotated every 90 days without breaking integrations. Which approach is most appropriate?

  1. Create new tokens, update integrations, then revoke old tokens Correct answer.
  2. Enable FastPass for API clients
  3. Revoke all tokens immediately and recreate them
  4. Disable the Org Authorization Server

Explanation

Rotating API tokens safely requires creating the new token, updating each integration to use it, verifying functionality, and then revoking the old token. Immediate revocation would break integrations.

Question 26Implementing Okta in various environments

A consultant is planning an Okta org for a workforce deployment and needs to decide how users will first be created in Okta. Which statement best describes the role of the Universal Directory in this design?

  1. It stores a unified user profile that can be sourced from multiple identity providers and directories Correct answer.
  2. It replaces the need for any external directory by hosting domain controllers inside Okta
  3. It functions solely as a read-only cache of Active Directory with no writable attributes
  4. It only stores users created through the Okta self-service registration page

Explanation

The Universal Directory is Okta's cloud user store that can hold a master profile populated from multiple sources, including HR systems, AD, LDAP, and manual creation. It supports attribute-level mastering so different sources can own different fields. It does not host domain controllers or act as a read-only cache.

Question 27Implementing Okta in various environments

A consultant is connecting Okta to an on-premises Active Directory forest using the Okta AD agent. Which network requirement must be satisfied for the agent to function?

  1. The agent host must be reachable from the internet on port 389 for inbound LDAP queries
  2. The agent host must have outbound HTTPS access to the Okta org and network access to the domain controllers Correct answer.
  3. The agent requires a site-to-site VPN terminating inside the Okta cell
  4. The agent must run on a domain controller itself to read directory changes

Explanation

The AD agent runs on a Windows server in the customer network and needs outbound TLS connectivity to the Okta org plus LDAP or RPC access to domain controllers. Inbound internet exposure is not required and would be a security risk. The agent can run on a member server, not only on a domain controller.

Question 28Implementing Okta in various environments

A customer wants Okta to be the identity provider for a SAML 2.0 application. Which value must the consultant provide to the application vendor so the app can validate assertions from Okta?

  1. The Okta IdP metadata containing the SSO URL and the public signing certificate Correct answer.
  2. The Okta agent installer package
  3. The Okta org's administrator recovery key
  4. The Okta API token generated for the application integration

Explanation

A SAML service provider needs the IdP metadata, which includes the SSO endpoint and the public certificate used to verify assertion signatures. API tokens and recovery keys are administrative secrets unrelated to SAML trust. The agent installer is for directory integration, not SAML federation.

Question 29Implementing Okta in various environments

A consultant is setting up Okta Verify with push notification for a workforce. Which factor category does Okta Verify push represent in Okta's authentication policy?

  1. A possession factor delivered through a registered device Correct answer.
  2. A location factor based on network zone
  3. An inherent factor based on biometric enrollment in Okta
  4. A knowledge factor based on a shared secret

Explanation

Okta Verify push is a possession factor because the user must hold the enrolled device that receives the push. Knowledge factors are things the user knows, such as passwords. Network zones are context conditions, not authenticator factors.

Question 30Implementing Okta in various environments

A consultant needs to assign an application to a large set of users based on their department attribute rather than by naming each user. Which Okta mechanism should be used?

  1. App-level provisioning mappings
  2. Application sign-on policy rules evaluated at authentication time
  3. Group rules that populate groups dynamically from user profile attributes Correct answer.
  4. Network zones applied to the application

Explanation

Group rules evaluate user profile attributes and automatically add or remove users from groups, which can then be assigned to applications. Sign-on policies control authentication conditions but do not assign applications. Provisioning mappings control attribute values sent to the app, not assignment scope.

Question 31Implementing Okta in various environments

A customer wants users to sign in to Okta with their existing corporate credentials while keeping the password authoritative on-premises. Which Okta deployment pattern fits this requirement?

  1. Passwordless authentication using only Okta FastPass
  2. AD integration with delegated authentication so Okta validates the password against AD Correct answer.
  3. SAML federation from Okta to an external IdP for all users
  4. Okta as the sole password store with password import disabled

Explanation

Delegated authentication lets Okta send the user's password to the on-premises AD agent for validation, so AD remains the password authority. Federation would make another IdP the authentication source, which is a different architecture. Storing passwords only in Okta or going fully passwordless changes the authority model.

Question 32Implementing Okta in various environments

A consultant is configuring inbound SAML federation so that an external IdP can authenticate users into Okta. What must be configured on the Okta side to establish trust?

  1. An Identity Provider entry in Okta that holds the external IdP metadata and routing rules Correct answer.
  2. A provisioning connection using SCIM outbound to the external IdP
  3. An Okta AD agent pointed at the external IdP's domain controllers
  4. A RADIUS client entry for the external IdP

Explanation

Inbound federation requires an Identity Provider object in Okta containing the external IdP's metadata, such as its SSO URL and signing certificate, plus routing rules that determine which users are sent to that IdP. SCIM, AD agents, and RADIUS are unrelated to inbound SAML trust.

Question 33Implementing Okta in various environments

A consultant must ensure that the Okta org sends sign-in notifications and password reset emails from a customer-controlled domain. Which configuration supports this?

  1. An application-specific branding theme
  2. Custom email domain configuration with the required DNS records Correct answer.
  3. A network zone covering the customer's mail relay
  4. A custom URL domain for the Okta org

Explanation

Okta supports custom email domains so notifications come from a branded sender domain, which requires publishing DNS records for verification and mail authentication. A custom URL domain changes the org sign-in hostname, not the email sender. Branding themes and network zones do not affect email delivery domains.

Question 34Implementing Okta in various environments

A consultant is designing Okta provisioning to a SCIM 2.0 application and needs to confirm which operations the connector must support for full lifecycle management.

  1. Only deactivate users when they are removed from Okta
  2. Create, read, update, and deactivate or delete users and groups Correct answer.
  3. Only create and read users
  4. Only group membership synchronization

Explanation

Full lifecycle provisioning through SCIM requires the connector to support creating, reading, updating, and deactivating or deleting users, and typically groups as well. Supporting only a subset leaves stale accounts or missed updates. Group-only synchronization does not cover user lifecycle events.

Question 35Implementing Okta in various environments

A consultant needs to configure an Okta org so that users in a specific group must re-authenticate with a factor after 15 minutes of inactivity when accessing a high-security application. Which Okta policy type should be used?

  1. A global session policy with a maximum session lifetime
  2. An application sign-on policy with a re-authentication frequency condition Correct answer.
  3. A password policy with a minimum length requirement
  4. An MFA enrollment policy with a required authenticator list

Explanation

Application sign-on policies can require re-authentication after a defined period or on access to a specific app, which is the right control for a high-security application. Global session policies govern org-wide session behavior rather than per-application re-authentication. Password and enrollment policies do not control session re-authentication timing.

Question 36Implementing Okta in various environments

A consultant is deploying Okta for a hybrid workforce and must ensure that users signing in from managed devices can skip MFA while unmanaged devices cannot. Which Okta capability enables this device-based condition?

  1. Device trust signals evaluated in authentication policy rules Correct answer.
  2. Behavioral anomaly detection thresholds
  3. Passwordless authentication with WebAuthn only
  4. Network zones based on public IP ranges

Explanation

Device trust integrates endpoint signals so policy rules can distinguish managed from unmanaged devices and apply different authentication requirements. Network zones evaluate IP addresses, not device management state. Anomaly detection and WebAuthn do not by themselves identify a device as managed.

Question 37Implementing Okta in various environments

A consultant must configure Okta to provision users to a SaaS application that supports SCIM but requires a non-standard unique identifier attribute. Where should the consultant define this attribute?

  1. In the application's provisioning profile mappings, mapping an Okta attribute to the SCIM attribute Correct answer.
  2. In the sign-on policy for the application
  3. In the global profile editor only, without touching the app mappings
  4. In the network zone assigned to the application

Explanation

SCIM attribute behavior is controlled through the application's provisioning profile mappings, where Okta attributes are mapped to the app's expected SCIM schema. The global profile editor can define attributes, but the app mapping is what sends them. Network zones and sign-on policies do not affect SCIM payloads.

Question 38Implementing Okta in various environments

A customer has multiple Okta orgs and wants users to move between them while preserving a single sign-on experience. Which approach should the consultant consider first?

  1. Replicating users manually in each org with identical passwords
  2. Federating the orgs using inbound SAML trust between them Correct answer.
  3. Using separate API tokens in each org for provisioning
  4. Configuring each org with its own independent MFA policy

Explanation

Federating Okta orgs with inbound SAML allows a user authenticated in one org to access applications in another without a second credential prompt. Manual replication and separate API tokens do not provide SSO. Independent MFA policies do not connect the orgs.

Question 39Implementing Okta in various environments

A consultant is configuring an Okta org for a regulated customer that requires all administrative actions to be traceable to an individual. Which configuration supports this?

  1. Disabling the System Log to reduce storage use
  2. Requiring administrators to use named individual accounts with MFA and reviewing the System Log Correct answer.
  3. Sharing a single administrator account with a long random password
  4. Using only API tokens for all administrative changes

Explanation

Named administrator accounts with MFA ensure actions can be attributed to individuals, and the System Log records administrative events for audit. Shared accounts remove accountability. Disabling logging or relying only on API tokens undermines traceability.

Question 40Implementing Okta in various environments

A consultant needs to configure Okta so that users are automatically deactivated in Okta when they are terminated in the HR source. Which design element is essential?

  1. A group rule that removes users from all groups
  2. A password policy that expires credentials every 30 days
  3. An application sign-on policy that denies access after hours
  4. HR import with a status mapping that translates the terminated status to Okta deactivation Correct answer.

Explanation

When HR is the master source, the import must map the HR status field so terminated employees become deactivated in Okta. Group rules and sign-on policies do not change the user's Okta status. Password expiration does not deprovision accounts.

Question 41Implementing Okta in various environments

A consultant is asked to enforce that Okta administrators can only sign in from the corporate network while regular users can sign in from anywhere. Which Okta configuration achieves this?

  1. A password policy requiring longer passwords for administrators
  2. A separate authentication policy for administrators that includes a network zone condition Correct answer.
  3. An application sign-on policy applied only to end-user applications
  4. A global session policy applied to all users with a longer timeout

Explanation

Okta allows authentication policies to be scoped to administrator groups, where network zone conditions can restrict sign-in to corporate IP ranges. Applying a policy to all users would also restrict regular users. Password complexity and app sign-on policies do not restrict administrator sign-in location.

Question 42Implementing Okta in various environments

A consultant must ensure that a SAML application receives group membership information so the app can authorize users by role. Which configuration is required?

  1. A password policy assigned to the group
  2. A group attribute statement in the SAML app configuration that includes the relevant groups Correct answer.
  3. A SCIM provisioning connection to the application
  4. A network zone assigned to the application

Explanation

SAML group attribute statements include group membership in the assertion so the service provider can authorize users. SCIM provisioning manages accounts and memberships through an API but is not required for assertion-based group delivery. Network and password policies do not affect assertion contents.

Question 43Implementing Okta in various environments

A consultant is troubleshooting why some users are not being provisioned to a SCIM application despite being assigned. Which area should be investigated first?

  1. The Okta org's custom email domain DNS records
  2. The password policy complexity requirements
  3. The application provisioning settings and the user's profile mappings and assignment status Correct answer.
  4. The network zone used in the global session policy

Explanation

Provisioning depends on the app being enabled for provisioning, the user being assigned, and the profile mappings being complete. Missing mappings or disabled provisioning features are common causes. Email domain, network zone, and password policy settings do not affect SCIM provisioning.

Question 44Implementing Okta in various environments

A consultant must configure Okta as a SAML identity provider for an application that requires encrypted assertions. What must be configured?

  1. A SCIM provisioning connection to the application
  2. The Okta IdP signing certificate uploaded to the application only
  3. The application's public certificate uploaded to Okta so assertions can be encrypted to it Correct answer.
  4. A network zone covering the application's servers

Explanation

Encrypted assertions require Okta to encrypt with the service provider's public certificate, which must be uploaded into the Okta application configuration. The Okta signing certificate is used for signature verification, not encryption. SCIM and network zones do not affect assertion encryption.

Question 45Implementing Okta in various environments

A consultant is planning an Okta deployment where a subset of users must authenticate with smart cards through an on-premises federation service. Which Okta feature should be used?

  1. SMS verification as the sole factor
  2. Password-only authentication with a longer password
  3. Okta Verify push for all users
  4. Inbound federation to an external IdP that performs smart card authentication Correct answer.

Explanation

When smart card authentication is performed by an external federation service, Okta can federate inbound to that IdP so users authenticate there and are then trusted by Okta. Okta Verify, passwords, and SMS are different authenticators and do not consume smart card credentials.

Question 46Implementing Okta in various environments

A consultant is configuring Okta to provision users into an application that does not support SCIM and has no connector. Which approach should the consultant recommend?

  1. Enable inbound SAML federation from the application
  2. Use the Okta Workflows or API-based integration to call the application's API for lifecycle events Correct answer.
  3. Configure an AD agent against the SaaS application
  4. Use a network zone to block unprovisioned users

Explanation

For applications without a SCIM connector, Okta Workflows or custom API integrations can call the app's API to create, update, and deactivate accounts. Inbound federation addresses authentication, not provisioning. AD agents connect to directories, not SaaS APIs, and network zones do not create accounts.

Question 47Implementing Okta in various environments

A consultant must ensure that when a user is suspended in Okta, all active sessions for that user are terminated across applications. Which Okta capability should be used?

  1. Assigning the user a stricter sign-on policy
  2. Removing the user from all groups
  3. Changing the user's password to force a reset
  4. Clearing the user's sessions from the user profile, which revokes Okta sessions and can trigger app logout where supported Correct answer.

Explanation

Clearing sessions from the user profile revokes the user's Okta sessions and, for apps that support it, propagates logout through single logout. Changing passwords, removing groups, or applying stricter policies does not immediately terminate existing sessions.

Question 48Implementing Okta in various environments

A consultant is designing an Okta org for a customer with strict data residency requirements. Which consideration is most relevant when selecting the Okta cell?

  1. The cell choice controls the SCIM schema used by applications
  2. The cell choice only affects the appearance of the sign-in page
  3. The geographic region of the Okta cell determines where user data is stored and processed Correct answer.
  4. The cell choice determines which authenticators are available

Explanation

Okta cells are deployed in specific regions, and the cell chosen determines where the org's data is hosted and processed. Branding, authenticator availability, and SCIM schemas are not determined by cell geography. Data residency planning therefore starts with cell selection.

Question 49Implementing Okta in various environments

A consultant must integrate Okta with an on-premises web application that supports only header-based authentication behind a reverse proxy. Which Okta component is required?

  1. A RADIUS server integrated with Okta
  2. A SCIM connector configured for the application
  3. An Okta Access Gateway deployed in the customer network Correct answer.
  4. An Okta AD agent installed on the application server

Explanation

Okta Access Gateway sits in front of legacy header-based applications and translates Okta authentication into the headers the app expects. The AD agent synchronizes directory data, SCIM provisions accounts, and RADIUS supports network device authentication. None of those provide header-based SSO for a legacy app.

Question 50Implementing Okta in various environments

A consultant is reviewing an Okta org's sign-on policy and finds that a rule allows access without any factor for a group that should require MFA. Which change should the consultant make?

  1. Add the group to a network zone
  2. Disable MFA enrollment for the affected group
  3. Delete all policy rules and recreate the org
  4. Reorder or modify the policy rules so the stricter rule is evaluated before the permissive rule Correct answer.

Explanation

Okta evaluates policy rules in order, and the first matching rule applies, so a permissive rule placed before a stricter one can bypass MFA. Reordering or tightening the rules ensures the intended requirement is enforced. Deleting rules, disabling enrollment, or adding a network zone does not fix rule precedence.