Ping Identity Certified Professional - PingAM PT-AM-CPE Exam Questions

Answer : B

The Tree Designer in PingAM 8.0.2 is a visual, drag-and-drop tool used to build sophisticated login journeys. While it is highly flexible, it follows specific structural rules to ensure the authentication engine can execute the logic predictably.

Analysis of the statements:

Statement A is true: Trees must terminate in an outcome. Success and Failure nodes are standard. Additionally, the Inner Tree Evaluator node allows one tree to hand off processing to another 'child' tree.

Statement C is true: The designer is extensible. Administrators can develop their own Java or Scripted nodes, and the Ping Identity Marketplace provides a wide range of third-party nodes (e.g., for biometric providers or specialized risk engines) that appear in the designer palette once installed.

Statement D is true: 'Inner trees' are a supported concept, allowing for modularity where common logic (like MFA) can be built once and called from multiple parent trees.

Statement B is the 'not true' statement. While the designer allows for complex logic and loops (e.g., looping back to a username prompt if a password is wrong), it does not support nesting nodes within a tree. In PingAM architecture, nodes are atomic components placed on a flat canvas. You cannot 'nest' a node inside another node's configuration in the visual designer. Complexity is achieved through the branching and linking of these atomic nodes. If logic needs to be 'nested' or grouped, it is done by creating a separate tree and calling it as an Inner Tree. Understanding this structural limitation is key for architects designing modular authentication frameworks.

Answer : C

Push authentication in PingAM 8.0.2 utilizes the ForgeRock/Ping Authenticator app to provide a seamless, out-of-band multi-factor authentication (MFA) experience.3 To understand the correct statements, we must look at the technical requirements and the authentication lifecycle defined in the 'MFA: Push Authentication' documentation.

Statement A is correct: For the initial setup, a device with a camera is required because the registration process involves scanning a QR code generated by PingAM. Additionally, the user must install the specific Authenticator app (available for iOS and Android) to handle the cryptographic exchange and receive push notifications.4

Statement D is correct: This accurately describes the runtime flow of a push journey. When a user reaches a Push Sender node, PingAM communicates with the Push Notification Service (Apple APNs or Google FCM).5 The user's device receives the notification, and PingAM enters a 'waiting' state (via the Push Result Verifier node) until the user either approves or denies the request within the app.6

Why other statements are incorrect:

Statement B is incorrect because registration and authentication are typically handled by separate trees. Best practice dictates a 'Device Registration' tree for the initial onboarding and a 'Login/MFA' tree for day-to-day access. Forcing them into the same tree would be inefficient and create a poor user experience.

Statement C is a common point of confusion; while the user scans a code, the documentation refers to it as a QR code, not a standard barcode. In technical certification contexts, this distinction is often strictly enforced.

Therefore, only statements A and D represent the verified facts of the Push implementation in version 8.0.2, making Option C the correct answer.

Answer : B

The OAuth2 May Act script type in PingAM 8.0.2 allows administrators to programmatically determine if a token exchange request (impersonation or delegation) should be allowed by adding a may_act claim to the token.

According to the 'Scripting' and 'Token Exchange Scripting API' documentation, when this script is executed, the AM engine provides a specific set of 'Bindings' or variables. These allow the script to inspect the context of the request before deciding to modify the token. The documented variables for the OAuth2 May Act script are:

clientProperties: A map of the OAuth2 client's configuration properties.

identity: The identity object for the user/subject.

logger: The logging object for debugging within the script.

requestProperties: Properties of the incoming HTTP request.

scopes: The set of scopes requested or associated with the token.

scriptName: The name of the script being executed.

session: The user's SSO session (if available).

requestedToken: This is the most important variable; it represents the token being issued. Methods like .addMayAct() or .setMayAct() are called on this specific object.

Why other options are incorrect:

Option B correctly lists the bindings.

Options A and D are incorrect because they use the variable name token. While token is a common variable name in other OAuth2 script types (like the Access Token Modification script), the Token Exchange script specifically uses requestedToken to distinguish the new token from the subject_token or actor_token provided in the request.

Option C uses scopeList, which is not the standard variable name for the scopes in this specific script context; the documentation defines it as scopes.

Answer : B

Auto-federation is a feature in PingAM 8.0.2 designed to simplify the user experience by automatically linking an IdP identity to an SP identity without manual intervention or a specialized 'linking' page.12

According to the PingAM documentation on 'Link Identities Automatically with Auto-Federation':

Linking Mechanism (Statement B): Auto-federation does not rely on the SAML NameID. Instead, it uses a common attribute value found in both the SAML assertion and the SP's local identity store. For example, if both systems share an 'Email' attribute, the SP can be configured to use the mail attribute from the incoming assertion to search its own datastore. If a match is found, the accounts are linked. This is significantly more flexible than relying on NameID formats (disproving Statement A).

User Experience (Statement C): One of the primary benefits of auto-federation is that it supports a 'Just-in-Time' experience. The user only needs to log in to the Identity Provider (IdP). When they are redirected to the SP, the SP performs the attribute-based lookup and creates the session immediately. The user is never prompted to log in at the SP side just to 'prove' who they are for the linking process (disproving Statement D).

Because auto-federation relies on matching attributes and only requires a single login at the IdP, the correct statements are B and C. This makes Option B the correct choice. This feature is particularly useful in Large-Scale B2B or B2C scenarios where pre-mapping thousands of users manually would be impossible.

Answer : A

The ForceAuth=true parameter is a standard directive used in various authentication protocols (specifically SAML2 and OIDC) and is natively supported by the PingAM 8.0.2 XUI (the modern End-User User Interface).

According to the 'Authentication and SSO' documentation:

Normally, if a user has an active, valid session cookie (iPlanetDirectoryPro), and they navigate to the AM login URL, PingAM will recognize the session and automatically redirect the user to their destination (the 'Success URL') without prompting for credentials. This is the core benefit of Single Sign-On.

However, when the ForceAuth=true parameter is appended to the query string, it instructs the PingAM authentication engine to bypass the session check for the purpose of re-authentication. The engine will:

Ignore the existing valid session cookie.

Force the user back to the login page (rendering the initial nodes of the configured authentication tree).

Require the user to provide their credentials again.

This is a critical security feature for high-value transactions. For instance, if a user is already logged in but attempts to change their bank transfer details, the application can redirect them to AM with ForceAuth=true to ensure the person sitting at the computer is indeed the authorized user. Option B is incorrect because ForceAuth only forces a re-authentication; whether that includes MFA depends on the tree configuration, not the parameter itself. Option C is incorrect as PingAM explicitly processes this parameter. Therefore, the primary outcome is the redirection to the login page regardless of the current session state.

Answer : A

In PingAM 8.0.2, Multi-Factor Authentication (MFA) using the OATH standard supports two primary algorithms: TOTP (Time-based One-Time Password) and HOTP (HMAC-based One-Time Password).14 For an authentication journey to function correctly, the 'Registration' phase (where the user's device and AM agree on a secret and algorithm) and the 'Verification' phase (where AM checks the submitted code) must be perfectly synchronized.

According to the 'Authentication Node Reference' for the OATH Token Verifier node and OATH Registration node:

Both nodes contain a configuration property named OATH Algorithm.15 This property determines how the six- or eight-digit code is generated and validated. If the OATH Registration node is configured to set up a user for TOTP, it will generate a QR code containing the TOTP parameters for the user's authenticator app.

When that user later attempts to log in, the OATH Token Verifier node (Option A) must also be set to TOTP.16 If the verifier is accidentally set to HOTP (which uses a counter rather than a time step), the validation will consistently fail because the server will be looking for a counter-based value while the app is providing a time-based value.

Other nodes like the Recovery Code Collector Decision node (Option B) or OATH Device Storage node (Option D) handle subsequent or separate tasks (like account recovery or writing the final profile to LDAP) and do not directly participate in the real-time OATH mathematical validation logic. Thus, the OATH Token Verifier is the mandatory counterpart that must match the registration's algorithm setting.

Answer : B

This error message is directly related to the User Profile configuration within a specific realm in PingAM 8.0.2. In the 'Core Authentication Attributes' of a realm, PingAM defines how it should handle user identities after they have successfully provided valid credentials through an authentication tree or chain.

There are primarily four modes for the User Profile setting:

Required: This is often the default. It specifies that after a user successfully authenticates, PingAM must be able to locate a corresponding user entry in the configured Identity Store. If the user exists in the datastore, the session is created. If the user does not exist, authentication fails with the error message 'user requires profile to login' (or a similar profile-related exception in the logs).

Ignored: In this mode, PingAM issues an SSO session token immediately upon successful credential validation, regardless of whether a user profile exists in the back-end repository. This is useful for temporary or guest access where no permanent record is needed.

Dynamic: AM attempts to find the user; if the user is not found, it automatically creates a new profile in the identity store.

Dynamic with User Alias: Similar to dynamic creation but supports aliasing.

If an administrator sees the 'user requires profile to login' error, it confirms that the credentials themselves were technically correct (the user passed the authentication nodes), but the realm is currently in Required mode (it has not been set to Ignore or Dynamic) and no matching entry exists in the identity store. This frequently happens in migration scenarios or when using external identity providers (like Social IDPs) where the 'Link' or 'Provisioning' step has not been properly configured in the authentication journey. To resolve this, the administrator must either pre-provision the user, set the mode to Ignore, or implement a Create Object node within the authentication tree to handle dynamic provisioning.