POE-001
Certified Expert - PingOne
Part of Certified Expert - PingOne
Validates advanced knowledge of the PingOne platform and the ability to manage solutions and implement use cases. Each voucher code is valid for a single exam attempt only.
Independent study aid built from the public exam blueprint. Not affiliated with, authorized by, or endorsed by ping. Objectives are transcribed and mapped by hand, so this page may contain mistakes or may have fallen behind the vendor's current material: exam objectives, versions, numbering and availability all change without notice. Treat ping's own certification portal as the source of truth and verify against it before you book anything.
Objective 1: Identification
POE-001.1.01 Determine services required for specific use cases.
What to know:- The PingOne platform is a menu of services: SSO, MFA, DaVinci, Authorize, Verify, Credentials, Protect, and the Directory underneath.
- Exam framing is scenario-to-service mapping: identity proofing means Verify, verifiable credentials mean Credentials, risk signals mean Protect, orchestration means DaVinci.
- Services are enabled per environment, so 'which service' and 'in which environment' are one question in practice.
- Licensing and entitlement gate what appears in the console - a missing service is often an entitlement issue, not a bug.
POE-001.1.02 Determine the correct method to incorporate identity verification into a use case.
What to know:- PingOne Verify performs document capture plus liveness/selfie comparison to prove a real person matches a real document.
- Verification is invoked from a DaVinci flow or via API, and returns a verification status the flow branches on.
- Common placements: onboarding/registration, high-risk recovery, and step-up before a sensitive transaction.
- Decide what happens on failure and on manual review before designing the happy path.
POE-001.1.03 Determine the correct method to manage PingOne Credentials.
What to know:- Credentials issues and manages digital verifiable credentials to a wallet; the lifecycle is issue, present, verify, revoke.
- Credential types define the schema of claims carried; issuance is typically driven from a flow after identity proofing.
- Revocation and expiry are first-class - a credential design without a revocation story is incomplete.
- Pairing with Verify is the canonical pattern: prove the identity once, then issue a reusable credential.
POE-001.1.04 Identify standards used by PingOne Credentials.
What to know:- The relevant families are W3C Verifiable Credentials and Decentralized Identifiers (DIDs), plus wallet presentation protocols.
- Know the roles in the model: issuer, holder, and verifier, and which PingOne piece plays each.
- Cryptographic signing by the issuer is what makes a credential verifiable without calling the issuer back.
- Selective disclosure is the privacy argument for the whole model - present the claim, not the document.
POE-001.1.05 Identify verification types and methods used by PingOne Verify.
What to know:- Government ID document capture, facial comparison with liveness, and supporting checks such as email or phone possession.
- Liveness detection defends against a photo of a photo; it is the difference between selfie matching and real proofing.
- Each method has a configuration policy controlling strictness and retries.
- Match the method to the risk: not every journey needs document proofing.
POE-001.1.06 Determine the correct method to manage the Directory attributes in PingOne.
What to know:- The PingOne Directory carries standard attributes plus custom attributes you define per environment.
- Attribute types, multivalued handling, and uniqueness constraints are the configuration decisions.
- Population membership and attribute-based filtering drive who sees what.
- Changes to schema ripple into flows, policies, and provisioning - plan the blast radius before editing.
Objective 2: Authentication
POE-001.2.01 Explain how to manage sessions in PingOne.
What to know:- Session lifetime, idle timeout, and whether a session is remembered across applications are policy settings.
- Signing out of an application is not necessarily signing out of PingOne - know the difference and how to force both.
- Session data is what SSO rests on; a broken SSO experience is usually a cookie or domain problem.
POE-001.2.02 Determine the correct method to configure policies in PingOne.
What to know:- Authentication policies are ordered steps: login, MFA, agreements, progressive profiling, and DaVinci flows can all be steps.
- Policies attach to applications, so the same tenant can present different journeys per app.
- Order matters: the first matching step that satisfies the requirement ends evaluation.
POE-001.2.03 Determine the correct method to configure applications.
What to know:- Application type drives the protocol and the grant: web app, single-page app, native, service, and worker.
- Redirect URIs, grant types, and token settings are the fields that break integrations when wrong.
- Assign an authentication policy and the resource scopes the application may request.
POE-001.2.04 Determine the correct method to configure integrations.
What to know:- The Application Catalog provides pre-built SAML/OIDC integrations for common SaaS targets.
- Provisioning integrations push users outward; SSO integrations only authenticate.
- Where no catalog entry exists, build a generic SAML or OIDC application manually.
POE-001.2.05 Determine the correct method to manage PingID in PingOne.
What to know:- PingID is the MFA service with its own device registration, policies, and pairing methods.
- Know the migration/coexistence story between PingID and PingOne MFA in a hybrid estate.
- Device management and administrative unpairing are routine support operations.
POE-001.2.06 Explain how to manage PingOne multi-factor authentication (MFA).
What to know:- Methods include TOTP authenticator apps, push, SMS/voice, email, FIDO2/WebAuthn security keys, and biometrics.
- MFA policies decide which methods are allowed and in what order they are offered.
- Device registration, device limits, and recovery paths are part of a complete design.
- Pairing MFA with risk (Protect) is how step-up becomes conditional rather than constant.
Objective 3: Authorization
POE-001.3.01 Determine the correct method to configure and write PingOne Authorize policies.
What to know:- Authorize is externalized, attribute-based authorization: policies, rules, and decision endpoints.
- Policies compose from conditions over attributes drawn from the request, the identity, and external data.
- Combining algorithms decide the outcome when multiple rules apply - permit-overrides versus deny-overrides.
- Test with the decision endpoint and read the decision trace; the trace explains why, not just what.
POE-001.3.02 Determine enforcement decisions for API gateways using PingOne Authorize.
What to know:- The gateway asks; Authorize decides. The gateway enforces the returned permit/deny and any obligations.
- Fine-grained API authorization goes beyond scopes into per-resource, per-attribute decisions.
- Latency budget matters: cache what is safely cacheable and keep the decision path short.
POE-001.3.03 Determine the correct application of PingOne roles.
What to know:- Administrative roles (Environment Admin, Identity Data Admin, Client Application Developer, Organization Admin) scope what an admin can do.
- Roles are granted at organization or environment scope - the scope is as important as the role.
- Least privilege applies to administrators too; the exam expects the narrowest role that accomplishes the task.
Objective 4: Orchestration
POE-001.4.01 Determine the proper utilization of PingOne DaVinci flows.
What to know:- DaVinci is the orchestration layer: registration, recovery, progressive profiling, and any journey the stock policy cannot express.
- Flows are composed of connectors and are versioned; a flow policy exposes a specific version to an application.
- Subflows keep large journeys maintainable and reusable.
POE-001.4.02 Determine the correct method to integrate DaVinci flows into PingOne policy.
What to know:- A DaVinci flow becomes a step inside a PingOne authentication policy, so the flow runs as part of login.
- The flow policy is the contract between PingOne and DaVinci - point the policy step at the right one.
- Returning the expected completion status is what lets PingOne continue the policy chain.
Objective 5: Threat Insights
POE-001.5.01 Identify use cases for PingOne Protect.
What to know:- Protect scores risk in real time so authentication can be adaptive rather than uniformly strict.
- Typical uses: suppress MFA for low-risk logins, step up on anomalies, and block credential stuffing or bot traffic.
- Risk is a signal into a policy or flow decision, never a decision by itself.
POE-001.5.02 Identify the capabilities of predictors.
What to know:- Predictors are the individual risk signals: IP reputation, impossible travel, anomalous velocity, bot detection, new device, and user-based models.
- Each predictor emits a score or level; the risk policy combines them into an overall result.
- Custom predictors let you feed organization-specific signals into the same model.
POE-001.5.03 Determine the correct method to configure risk policies.
What to know:- A risk policy weights predictors and maps the combined result to low, medium, or high risk levels.
- Thresholds are the tuning surface - move them based on observed distributions, not intuition.
- Policies bind to applications and flows, so different apps can tolerate different risk.
POE-001.5.04 Analyze and evaluate dashboard results to tune risk policies.
What to know:- The dashboard shows score distributions and predictor contributions over real traffic.
- Tuning is a loop: observe false positives and negatives, adjust weights or thresholds, re-observe.
- Beware of tuning on too short a window - weekly seasonality is real in login traffic.
Objective 6: Troubleshooting
POE-001.6.01 Given a scenario, determine the correct method to troubleshoot using audit logs and dashboards.
What to know:- Audit logs record authentication, administrative, and API events per environment.
- Filter by correlation ID to follow one user journey end to end rather than reading noise.
- Dashboards summarize; audit logs explain. Start broad, then narrow to the failing event.
- Export or stream logs to an external SIEM when the retention window is not enough.
POE-001.6.02 Given a scenario, determine what to look for in analytics to troubleshoot DaVinci.
What to know:- DaVinci analytics show flow executions, per-node outcomes, and where executions terminate.
- A flow that fails at a specific node points at that connector's configuration or its external dependency.
- Compare a successful execution against a failing one - the divergence point is the bug.
- Check flow version and which version the flow policy actually publishes; version drift is a classic false alarm.
Public sources, used in good faith
These guides are independent study aids built from publicly available material: published exam blueprints, official product documentation, and vendor training catalogues. Product names, exam codes, and trademarks belong to their owners and are used only to identify the subject being taught. This site is not affiliated with or endorsed by any vendor named here. If you hold rights in material published on this page and believe it should be removed or corrected, please send the exact URL and a short note on the issue through the contact page; requests are reviewed promptly and in good faith. Read the full disclaimer →