POE-001
Certified Expert - PingOne
Parte de 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.
Material de estudo independente, construído a partir do blueprint público da prova. Sem afiliação, autorização ou endosso da ping. Os objetivos são transcritos e mapeados à mão, então esta página pode conter erros ou estar defasada em relação ao material atual do fabricante: objetivos, versões, numeração e disponibilidade mudam sem aviso. Trate o portal de certificação da própria ping como a fonte da verdade e confira nele antes de agendar qualquer coisa.
Objective 1: Identification
POE-001.1.01 Determine services required for specific use cases.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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).
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
Fontes públicas, usadas de boa-fé
Estes guias são materiais de estudo independentes, montados a partir de conteúdo publicamente disponível: blueprints de exame publicados, documentação oficial de produto e catálogos de treinamento dos fabricantes. Nomes de produtos, códigos de exame e marcas pertencem a seus titulares e são usados apenas para identificar o assunto ensinado. Este site não é afiliado a nenhum fabricante aqui citado nem endossado por ele. Se você detém direitos sobre material publicado nesta página e entende que ele deve ser removido ou corrigido, envie a URL exata e uma breve nota sobre o problema pela página de contato; os pedidos são analisados com rapidez e boa-fé. Ler o aviso legal completo →