PAME-101
Certified Expert - PingAM
Part of Certified Expert - PingAM
Proctored hands-on exam (3.5 hours). Each voucher code is valid for a single exam attempt only; once redeemed it cannot be reused. Exam covers PingAM version 8 or later.
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.
Section 1: Federation
PAME-101.1.01 Delegate authentication using SAML v2.0 (SAML2)
What to know:- PingAM as hosted IdP or SP: circle of trust, entity providers, and the metadata exchange that bootstraps both sides.
- Delegated authentication means PingAM sends the user to a remote IdP and consumes the assertion; know which side owns the session.
- Assertion signing and encryption keys come from the secret stores configured in Section 4 - a federation failure is often a secret-store failure.
- Attribute mapping decides what the SP actually receives; NameID format choices (persistent, transient, email) drive account linking.
- Auto-federation and dynamic profile creation are the two answers to 'the user does not exist locally yet'.
PAME-101.1.02 Configure OAuth 2.0 (OAuth2)/OpenID Connect (OIDC) integration
What to know:- PingAM as authorization server: clients (confidential vs public), grant types allowed per client, and scope-to-claim mapping.
- OIDC adds the ID token; know the claims script hook for customizing claims beyond the defaults.
- Authorization code with PKCE is the expected answer for browser and native clients; implicit and ROPC are retired.
- Token lifetimes, refresh-token rotation, and where the token store lives (CTS) are exam-relevant operational knobs.
- Consent handling and the OAuth2 provider service settings are configured at the realm level.
PAME-101.1.03 Configure Secret Token Service integration
What to know:- Security Token Service (STS) bridges token formats: SAML assertion in, OIDC/JWT out, and the reverse - REST STS and SOAP STS instances.
- Token transformation is the core use case: a legacy SAML-speaking application fronting a modern OAuth API, or vice versa.
- Each STS instance declares its issuer, supported token types, and the credential it uses to sign issued tokens.
- Validate the trust chain on both input and output tokens; a transformation is only as trustworthy as its weakest validation step.
Section 2: Authorization
PAME-101.2.01 Integrate with a preconfigured PingGateway instance
What to know:- PingGateway (formerly IG) enforces at the edge; PingAM decides. Know the agent/gateway split of responsibilities.
- The route configuration determines which requests are protected, and the PingAM policy set determines the decision.
- Single sign-on between gateway and PingAM relies on the session cookie domain and the configured AM URL.
- Common failure: gateway cannot reach the AM policy endpoint, or the agent profile credentials are wrong - check both before touching policy logic.
PAME-101.2.02 Configure policies
What to know:- Policy sets contain policies; each policy names resources, actions, subjects, and environment conditions.
- Resource types define the actions available (GET/POST for URLs); policy evaluation returns allowed actions plus advice and response attributes.
- Subject conditions (authenticated users, groups, OAuth2 scope) and environment conditions (IP, time, authentication level) compose the decision.
- Advice is how a deny becomes a step-up prompt - the mechanism that ties authorization back into an authentication journey.
- Test with the policy evaluation REST endpoint before blaming the enforcement point.
PAME-101.2.03 Demonstrate how to check for risk continuously
What to know:- Continuous risk means the session is re-evaluated after login, not just at the door - transactional authorization and session property changes.
- Policy advice can force step-up mid-session; combine with authentication level to gate sensitive actions.
- Signals can come from PingOne Protect or comparable risk sources feeding a decision node in the tree.
- The exam framing is scenario-based: given a risk signal, produce the configuration that re-challenges without ending the session.
Section 3: Authentication Trees
PAME-101.3.01 Demonstrate how to modify a user's authentication experience based on context
What to know:- Trees are node graphs with outcomes; context comes from nodes that inspect device, IP, risk, or user attributes.
- Scripted decision nodes are the general-purpose escape hatch when no stock node fits.
- Inner trees allow reuse of a subflow across multiple journeys - the DRY principle applied to authentication.
- Shared state carries values between nodes; know which state (shared vs secure vs transient) is appropriate for secrets.
PAME-101.3.02 Configure social authentication
What to know:- Social identity provider nodes (Google, Facebook, Apple, generic OIDC) federate the login and return a profile.
- Provisioning the local account is a separate decision: create, link to existing by email, or reject.
- Client ID and secret for each provider live in the social IdP service configuration; secrets belong in a secret store.
- Watch redirect URI registration on the provider side - the most common cause of a broken social flow.
PAME-101.3.03 Implement single sign-on (SSO)
What to know:- SSO within a realm rests on the AM session cookie; cross-domain SSO (CDSSO) handles the different-domain case.
- Session upgrade preserves the session while raising the authentication level after a step-up.
- Know the difference between the AM session, the OIDC session, and the application session - three lifetimes that must be reasoned about separately.
- Logout must be considered end to end: local, federated, and back-channel where supported.
PAME-101.3.04 Given a scenario, configure mutli-factor authentication (MFA
What to know:- Stock nodes cover OATH (TOTP/HOTP), push notification, WebAuthn/FIDO2, and recovery codes.
- Registration and authentication are distinct node paths; a complete tree handles the not-yet-registered user.
- Device profile and device match nodes let you skip MFA on a known device - the usual 'remember this device' requirement.
- Recovery codes and an administrative reset path are part of a correct design, not an afterthought.
Section 4: Core implementation tasks
PAME-101.4.01 Configure secret stores
What to know:- Secret stores abstract where key material lives: keystore file, filesystem, HSM/KMS, or environment variables.
- Secret IDs are mapped to purposes (signing OIDC tokens, SAML assertions, TLS) - the mapping is the configuration.
- Rotation is supported by listing multiple secrets against one ID with different valid-from times.
- A misconfigured secret store surfaces as a federation or token-signing failure, so check it early in troubleshooting.
PAME-101.4.02 Demonstrate proper system tuning
What to know:- JVM heap sizing, garbage collector choice, and thread pools are the first-order knobs.
- CTS (Core Token Service) sizing drives session and token throughput; monitor its LDAP backend.
- Connection pools to the identity store and CTS are common bottlenecks under load.
- Cache settings (session, policy, config) trade memory for latency; measure before and after.
PAME-101.4.03 Troubleshoot common issues
What to know:- Read the logs in order: audit logs for what happened, debug logs for why, and the container log for startup failures.
- Increase debug level per component rather than globally to avoid drowning in output.
- Isolate the layer: browser (cookies, redirects), gateway/agent, AM, then the identity store.
- Reproduce with a REST call where possible - it removes the browser from the equation.
PAME-101.4.04 Demonstrate proper security hardening
What to know:- Change all default administrative credentials and restrict the admin console to trusted networks.
- Disable unused authentication modules, services, and endpoints - reduce the reachable surface.
- Enforce TLS everywhere, set secure and httpOnly on cookies, and configure the cookie domain no broader than necessary.
- Follow the vendor hardening guide for the version deployed; hardening is version-specific and changes between releases.
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 →