Okta Certified Administrator · Part I

Identity and Access Management

36% of the exam — the single largest domain.

Identity & Access Management

Module 4: Architecture

2 sub-topics · this deck covers sub-topic 2 of 2 — the last one in this module

The Exam Bullet

"Demonstrate knowledge of high availability requirements on advanced agents (e.g., RADIUS, MFA, OPP)"

Module 1 already covered HA for the AD agent specifically. This sub-topic asks whether that same principle — and its practical consequences — hold up across the other "advanced" agent types too.

The Connection Back to Module 1

The core HA rule doesn't change by agent type: run 2+ agents, on separate physical servers, so one agent going down doesn't take down authentication. That principle — established for the AD agent in Module 1 — applies the same way to RADIUS, MFA, and OPP agents.

Too few agents relative to authentication volume produces the identical symptom every time: queued or failed logins, regardless of which agent type is under-provisioned.

A Real Reliability-Adjacent Mechanism — Password Sync

One specific agent-dependent feature with real documented requirements: syncing passwords from Okta to Active Directory, making Okta the source of truth instead of AD.

"The user's current Okta password is pushed to AD the next time the user successfully signs in to Okta." This requires an integrated AD instance, and the AD agent's service account needs password reset and change permissions.

The Gotcha — Mutually Exclusive With Delegated Auth

Password sync only works for Okta-sourced users — not AD-sourced ones — and critically, delegated authentication must be disabled.

Delegated auth (Module 1, Sub 1) = Okta asks AD "is this password right?" Password sync = Okta pushes ITS password TO AD. These are opposite directions — you can't run both against the same account.

Also: after a pushed user is activated, they land in a "must change password at next logon" state and have to sign into Okta first before the sync actually takes effect.

The Exam Angle

Watch for scenario questions built around these traps:

→ "MFA or RADIUS logins are slow/queuing under load." = same HA fix as Module 1 — more agents, separate servers.

→ "Org wants Okta to be the password source of truth, pushing to AD." = password sync, which requires disabling delegated auth first.

One Line To Remember

HA for RADIUS/MFA/OPP agents = the same rule as AD agents: 2+ agents, separate servers. Password sync (Okta → AD) is the mirror image of delegated auth (AD → Okta) — they can't both be enabled for the same account; sync requires delegated auth OFF, Okta-sourced users, and service-account password-reset rights.

Sources: help.okta.com — radius-best-pract.htm · Security_Using_Sync_Password.htm

✓ Module 4: Architecture — complete (2 of 2 sub-topics)