Practice Free PT-AM-CPE Exam Online Questions
Question #1
Which of the following is an incorrect statement about session upgrade outcomes?
- A . In a server-side session configuration, when using the ForceAuth parameter and an authentication tree, PingAM issues a new session token to a user who reauthenticates, even if the current session already meets the security requirements
- B . In a server-side or client-side session configuration, PingAM issues a new session token to a user who reauthenticates, only when the current session does not meet the security requirements
- C . In a server-side session configuration, when using advices, PingAM copies the session properties to a new session and replaces the client’s original session token with a new session token
- D . In a client-side session configuration, PingAM replaces the client’s original session token with a new session token
Correct Answer: B
B
Explanation:
In PingAM 8.0.2, a Session Upgrade occurs when a user is required to authenticate at a higher security level (Auth Level). The outcomes of these upgrades depend on the session storage (server-side vs. client-side) and the parameters used.
Statement B is incorrect because it claims that a new token is issued only when the current session does not meet requirements. In reality, if a request explicitly includes a parameter like ForceAuth=true or prompt=login, PingAM will force a re-authentication and issue a new session token regardless of the current session’s state.
According to the "Session Upgrade" and "Step-up Authentication" documentation:
Statement A is correct: When ForceAuth=true is used, the AM engine ignores the existing session’s Auth Level and forces the user through the tree. A new session/token is generated upon success. Statement C is correct: This describes the standard "Advice" flow (e.g., from a policy). AM creates a new session, copies existing properties from the old one, and replaces the token.
Statement D is correct: In client-side sessions, since the state is in a JWT cookie, any change (like an
Auth Level increase) requires the issuance of a brand-new signed JWT to replace the old one.
Therefore, because PingAM allows for forced re-authentication even when requirements are met, the restrictive "only when" condition in Statement B makes it the incorrect (and thus the target) answer. This behavior is key for security scenarios where a fresh proof of presence is required regardless of previous activity.
B
Explanation:
In PingAM 8.0.2, a Session Upgrade occurs when a user is required to authenticate at a higher security level (Auth Level). The outcomes of these upgrades depend on the session storage (server-side vs. client-side) and the parameters used.
Statement B is incorrect because it claims that a new token is issued only when the current session does not meet requirements. In reality, if a request explicitly includes a parameter like ForceAuth=true or prompt=login, PingAM will force a re-authentication and issue a new session token regardless of the current session’s state.
According to the "Session Upgrade" and "Step-up Authentication" documentation:
Statement A is correct: When ForceAuth=true is used, the AM engine ignores the existing session’s Auth Level and forces the user through the tree. A new session/token is generated upon success. Statement C is correct: This describes the standard "Advice" flow (e.g., from a policy). AM creates a new session, copies existing properties from the old one, and replaces the token.
Statement D is correct: In client-side sessions, since the state is in a JWT cookie, any change (like an
Auth Level increase) requires the issuance of a brand-new signed JWT to replace the old one.
Therefore, because PingAM allows for forced re-authentication even when requirements are met, the restrictive "only when" condition in Statement B makes it the incorrect (and thus the target) answer. This behavior is key for security scenarios where a fresh proof of presence is required regardless of previous activity.
Question #2
Examine the following JWT client assertion in JSON format. From the subset of claims listed below, which claim can be optional?
JSON
JSON
{
"iss": "myClient",
"sub": "myClient",
"aud": "https://am.example.com/login/oauth2/access_token",
"jti": "id012345",
"exp": 1633363568,
"iat": 1633356368
}
- A . jti
- B . aud
- C . iss
- D . sub
Correct Answer: A
A
Explanation:
When an OAuth2 client uses Private Key JWT or Client Secret JWT for authentication at the PingAM 8.0.2 token endpoint, it must present a JWT (JSON Web Token) containing specific claims that identify and authorize the client. This is governed by the OIDC and OAuth2 JWT Profile specifications (RFC 7523).
According to the PingAM documentation on "OAuth 2.0 Client Authentication" and the "JWT Profile for Client Authentication":
iss (Issuer): Mandatory. This must be the client_id of the OAuth2 client.
sub (Subject): Mandatory. This must also be the client_id of the OAuth2 client (as the client is the subject of the authentication).
aud (Audience): Mandatory. This must be the URL of the PingAM OAuth2 service (the token endpoint) or the issuer URL.
exp (Expiration Time): Mandatory. This protects against the long-term use of intercepted assertions. The jti (JWT ID) (Option A) provides a unique identifier for the token. In the context of standard JWT validation, jti is used to prevent replay attacks by ensuring that a specific token is only processed once. While highly recommended for security hardening, the PingAM 8.0.2 technical reference for OAuth2 client assertions marks jti as optional unless the server is explicitly configured to require it for replay detection. Without a jti, PingAM will still validate the iss, sub, aud, and exp claims to authenticate the client. Therefore, among the choices provided, jti is the claim that can be omitted without inherently violating the base OAuth2 JWT authentication request requirements.
A
Explanation:
When an OAuth2 client uses Private Key JWT or Client Secret JWT for authentication at the PingAM 8.0.2 token endpoint, it must present a JWT (JSON Web Token) containing specific claims that identify and authorize the client. This is governed by the OIDC and OAuth2 JWT Profile specifications (RFC 7523).
According to the PingAM documentation on "OAuth 2.0 Client Authentication" and the "JWT Profile for Client Authentication":
iss (Issuer): Mandatory. This must be the client_id of the OAuth2 client.
sub (Subject): Mandatory. This must also be the client_id of the OAuth2 client (as the client is the subject of the authentication).
aud (Audience): Mandatory. This must be the URL of the PingAM OAuth2 service (the token endpoint) or the issuer URL.
exp (Expiration Time): Mandatory. This protects against the long-term use of intercepted assertions. The jti (JWT ID) (Option A) provides a unique identifier for the token. In the context of standard JWT validation, jti is used to prevent replay attacks by ensuring that a specific token is only processed once. While highly recommended for security hardening, the PingAM 8.0.2 technical reference for OAuth2 client assertions marks jti as optional unless the server is explicitly configured to require it for replay detection. Without a jti, PingAM will still validate the iss, sub, aud, and exp claims to authenticate the client. Therefore, among the choices provided, jti is the claim that can be omitted without inherently violating the base OAuth2 JWT authentication request requirements.
Question #3
Which of the following are existing script types in PingAM?
A) Decision node script for authentication trees
B) End User user interface theme script
C) OpenID Connect claims script
D) Policy condition script
- A . A, B and C
- B . A, B and D
- C . B, C and D
- D . A, C and D
Correct Answer: D
D
Explanation:
PingAM 8.0.2 is highly extensible through its Scripting Engine, which supports Groovy and JavaScript. However, scripts can only be applied to specific "hooks" or "extension points" defined by the platform.
According to the "Scripting" and "Script Types" reference in the PingAM 8.0.2 documentation, the standard supported script types are:
Decision node script (A): Used within Authentication Trees via the "Scripted Decision Node." These scripts allow for complex logic, such as checking user attributes, calling external APIs, or evaluating risk before deciding which path a user should take in their journey.
OpenID Connect claims script (C): This script type is used to customize the claims returned in OIDC ID Tokens or at the UserInfo endpoint. It allows administrators to transform internal LDAP attributes into the specific JSON format required by OIDC clients.
Policy condition script (D): Used within Authorization Policies. These scripts define custom logic for granting or denying access (e.g., "Allow access only if the user is connecting from a specific IP range and it is between 9 AM and 5 PM").
Why Statement B is incorrect: There is no such thing as an "End User user interface theme script" in the PingAM scripting engine. UI customization (Themeing) in PingAM 8.0.2 is handled through the XUI framework using CSS, HTML templates, and configuration JSON files, or by building a custom UI using the Ping SDKs. It does not use the server-side Groovy/JavaScript scripting engine that governs authentication and authorization logic. Therefore, the valid script types are A, C, and D, making
Option D the correct choice.
D
Explanation:
PingAM 8.0.2 is highly extensible through its Scripting Engine, which supports Groovy and JavaScript. However, scripts can only be applied to specific "hooks" or "extension points" defined by the platform.
According to the "Scripting" and "Script Types" reference in the PingAM 8.0.2 documentation, the standard supported script types are:
Decision node script (A): Used within Authentication Trees via the "Scripted Decision Node." These scripts allow for complex logic, such as checking user attributes, calling external APIs, or evaluating risk before deciding which path a user should take in their journey.
OpenID Connect claims script (C): This script type is used to customize the claims returned in OIDC ID Tokens or at the UserInfo endpoint. It allows administrators to transform internal LDAP attributes into the specific JSON format required by OIDC clients.
Policy condition script (D): Used within Authorization Policies. These scripts define custom logic for granting or denying access (e.g., "Allow access only if the user is connecting from a specific IP range and it is between 9 AM and 5 PM").
Why Statement B is incorrect: There is no such thing as an "End User user interface theme script" in the PingAM scripting engine. UI customization (Themeing) in PingAM 8.0.2 is handled through the XUI framework using CSS, HTML templates, and configuration JSON files, or by building a custom UI using the Ping SDKs. It does not use the server-side Groovy/JavaScript scripting engine that governs authentication and authorization logic. Therefore, the valid script types are A, C, and D, making
Option D the correct choice.
Question #4
What scope is required to be included in a client’s request if you wish to utilize the OpenID Connect capabilities of PingAM’s OAuth2 implementation?
- A . profile
- B . openid+connect
- C . openid
- D . id
Correct Answer: C
C
Explanation:
PingAM 8.0.2 implements OpenID Connect (OIDC) 1.0 as an identity layer on top of the OAuth 2.0 protocol. While OAuth 2.0 is designed for authorization (accessing resources), OIDC is designed for authentication (verifying who the user is).
According to the "OpenID Connect 1.0" documentation in PingAM, the presence of a specific scope in the Authorization Request is what signals to the AM server that the request should be treated as an OIDC flow rather than a standard OAuth2 flow. This mandatory scope is openid.
When PingAM receives an /oauth2/authorize request containing the scope=openid parameter:
It triggers the OIDC processing logic.
It ensures that an ID Token (a signed JWT containing user identity information) is generated alongside (or instead of) the Access Token.
It allows the client to later access the UserInfo Endpoint to retrieve further claims about the authenticated user.
Other scopes like profile (Option A), email, or address are optional OIDC scopes used to request specific sets of user claims, but they do not "activate" OIDC on their own. openid+connect and id (Options B and D) are not recognized standard scopes in the OIDC specification. Therefore, openid is the fundamental requirement for any OIDC interaction in PingAM 8.0.2.
C
Explanation:
PingAM 8.0.2 implements OpenID Connect (OIDC) 1.0 as an identity layer on top of the OAuth 2.0 protocol. While OAuth 2.0 is designed for authorization (accessing resources), OIDC is designed for authentication (verifying who the user is).
According to the "OpenID Connect 1.0" documentation in PingAM, the presence of a specific scope in the Authorization Request is what signals to the AM server that the request should be treated as an OIDC flow rather than a standard OAuth2 flow. This mandatory scope is openid.
When PingAM receives an /oauth2/authorize request containing the scope=openid parameter:
It triggers the OIDC processing logic.
It ensures that an ID Token (a signed JWT containing user identity information) is generated alongside (or instead of) the Access Token.
It allows the client to later access the UserInfo Endpoint to retrieve further claims about the authenticated user.
Other scopes like profile (Option A), email, or address are optional OIDC scopes used to request specific sets of user claims, but they do not "activate" OIDC on their own. openid+connect and id (Options B and D) are not recognized standard scopes in the OIDC specification. Therefore, openid is the fundamental requirement for any OIDC interaction in PingAM 8.0.2.
Question #5
In the default Cloud Developer Kit (CDK) deployment of the forgeops repository, which pods provide the user interface functionality?
- A . admin-ui, end-user-ui, login-ui
- B . amadmin-ui, idmadmin-ui, login-ui
- C . am-ui, idm-ui, login-ui
- D . am-ui, idm-ui, end-user-ui
Correct Answer: A
A
Explanation:
The Cloud Developer Kit (CDK), part of the forgeops repository, represents the modern approach to deploying the Ping Identity Platform (including PingAM 8.0.2) in a containerized, Kubernetes-native environment. According to the PingAM deployment and ForgeOps documentation, the platform has transitioned from a monolithic architecture―where the user interface was embedded within the AM web application―to a decoupled, microservices-aligned architecture. In a standard CDK deployment, the user interface components are separated into their own distinct pods to allow for independent scaling, updates, and management.
The three specific pods that provide user interface functionality in a default CDK environment are: admin-ui: This pod hosts the administrative console. It is the centralized interface that administrators use to configure realms, manage identity stores, define authentication trees, and oversee the general health of both PingAM and PingIDM. By separating the administrative UI from the core engine, the platform reduces the attack surface and allows for more granular resource allocation. end-user-ui: This pod serves the self-service portal for end-users. It is responsible for providing the interface where users can manage their own profiles, update passwords, register Multi-Factor Authentication (MFA) devices, and manage their consent for OAuth2/UMA applications. This UI interacts with the back-end via REST APIs to ensure a seamless and responsive user experience. login-ui: This is a specialized pod dedicated to the authentication journey. When a user interacts with an "Intelligent Access" tree, the login-ui pod renders the callbacks (such as username prompts, password fields, or MFA challenges). This pod ensures that the presentation layer of the authentication process is modernized and distinct from the heavy processing logic of the PingAM core.
Collectively, these three pods ensure that the "User Interface" layer of the deployment is modular. This architecture is a prerequisite for high-availability deployments and is the standard configuration verified in the ForgeOps documentation for version 8.0.2 deployments.
A
Explanation:
The Cloud Developer Kit (CDK), part of the forgeops repository, represents the modern approach to deploying the Ping Identity Platform (including PingAM 8.0.2) in a containerized, Kubernetes-native environment. According to the PingAM deployment and ForgeOps documentation, the platform has transitioned from a monolithic architecture―where the user interface was embedded within the AM web application―to a decoupled, microservices-aligned architecture. In a standard CDK deployment, the user interface components are separated into their own distinct pods to allow for independent scaling, updates, and management.
The three specific pods that provide user interface functionality in a default CDK environment are: admin-ui: This pod hosts the administrative console. It is the centralized interface that administrators use to configure realms, manage identity stores, define authentication trees, and oversee the general health of both PingAM and PingIDM. By separating the administrative UI from the core engine, the platform reduces the attack surface and allows for more granular resource allocation. end-user-ui: This pod serves the self-service portal for end-users. It is responsible for providing the interface where users can manage their own profiles, update passwords, register Multi-Factor Authentication (MFA) devices, and manage their consent for OAuth2/UMA applications. This UI interacts with the back-end via REST APIs to ensure a seamless and responsive user experience. login-ui: This is a specialized pod dedicated to the authentication journey. When a user interacts with an "Intelligent Access" tree, the login-ui pod renders the callbacks (such as username prompts, password fields, or MFA challenges). This pod ensures that the presentation layer of the authentication process is modernized and distinct from the heavy processing logic of the PingAM core.
Collectively, these three pods ensure that the "User Interface" layer of the deployment is modular. This architecture is a prerequisite for high-availability deployments and is the standard configuration verified in the ForgeOps documentation for version 8.0.2 deployments.
Question #5
In the default Cloud Developer Kit (CDK) deployment of the forgeops repository, which pods provide the user interface functionality?
- A . admin-ui, end-user-ui, login-ui
- B . amadmin-ui, idmadmin-ui, login-ui
- C . am-ui, idm-ui, login-ui
- D . am-ui, idm-ui, end-user-ui
Correct Answer: A
A
Explanation:
The Cloud Developer Kit (CDK), part of the forgeops repository, represents the modern approach to deploying the Ping Identity Platform (including PingAM 8.0.2) in a containerized, Kubernetes-native environment. According to the PingAM deployment and ForgeOps documentation, the platform has transitioned from a monolithic architecture―where the user interface was embedded within the AM web application―to a decoupled, microservices-aligned architecture. In a standard CDK deployment, the user interface components are separated into their own distinct pods to allow for independent scaling, updates, and management.
The three specific pods that provide user interface functionality in a default CDK environment are: admin-ui: This pod hosts the administrative console. It is the centralized interface that administrators use to configure realms, manage identity stores, define authentication trees, and oversee the general health of both PingAM and PingIDM. By separating the administrative UI from the core engine, the platform reduces the attack surface and allows for more granular resource allocation. end-user-ui: This pod serves the self-service portal for end-users. It is responsible for providing the interface where users can manage their own profiles, update passwords, register Multi-Factor Authentication (MFA) devices, and manage their consent for OAuth2/UMA applications. This UI interacts with the back-end via REST APIs to ensure a seamless and responsive user experience. login-ui: This is a specialized pod dedicated to the authentication journey. When a user interacts with an "Intelligent Access" tree, the login-ui pod renders the callbacks (such as username prompts, password fields, or MFA challenges). This pod ensures that the presentation layer of the authentication process is modernized and distinct from the heavy processing logic of the PingAM core.
Collectively, these three pods ensure that the "User Interface" layer of the deployment is modular. This architecture is a prerequisite for high-availability deployments and is the standard configuration verified in the ForgeOps documentation for version 8.0.2 deployments.
A
Explanation:
The Cloud Developer Kit (CDK), part of the forgeops repository, represents the modern approach to deploying the Ping Identity Platform (including PingAM 8.0.2) in a containerized, Kubernetes-native environment. According to the PingAM deployment and ForgeOps documentation, the platform has transitioned from a monolithic architecture―where the user interface was embedded within the AM web application―to a decoupled, microservices-aligned architecture. In a standard CDK deployment, the user interface components are separated into their own distinct pods to allow for independent scaling, updates, and management.
The three specific pods that provide user interface functionality in a default CDK environment are: admin-ui: This pod hosts the administrative console. It is the centralized interface that administrators use to configure realms, manage identity stores, define authentication trees, and oversee the general health of both PingAM and PingIDM. By separating the administrative UI from the core engine, the platform reduces the attack surface and allows for more granular resource allocation. end-user-ui: This pod serves the self-service portal for end-users. It is responsible for providing the interface where users can manage their own profiles, update passwords, register Multi-Factor Authentication (MFA) devices, and manage their consent for OAuth2/UMA applications. This UI interacts with the back-end via REST APIs to ensure a seamless and responsive user experience. login-ui: This is a specialized pod dedicated to the authentication journey. When a user interacts with an "Intelligent Access" tree, the login-ui pod renders the callbacks (such as username prompts, password fields, or MFA challenges). This pod ensures that the presentation layer of the authentication process is modernized and distinct from the heavy processing logic of the PingAM core.
Collectively, these three pods ensure that the "User Interface" layer of the deployment is modular. This architecture is a prerequisite for high-availability deployments and is the standard configuration verified in the ForgeOps documentation for version 8.0.2 deployments.
Question #7
To protect against cross-site request forgery attacks, a default PingAM installation requires that some requests, such as POST requests, include:
- A . X-OpenAM-Password header
- B . If-Match: _rev header
- C . X-Requested-With or Accept-API-Version header
- D . X-OpenAM-Username header
Correct Answer: C
C
Explanation:
Cross-Site Request Forgery (CSRF) is an attack where a malicious site sends a request to PingAM using the victim’s authenticated browser session. Because standard HTML forms and cross-site requests cannot easily set custom HTTP headers, requiring a specific header is an effective defense for REST APIs.
According to the PingAM "Security" documentation and the "REST API" reference:
By default, PingAM 8.0.2 enforces a CSRF filter on its REST endpoints (such as /json/authenticate or /json/users). For any "state-changing" request (like a POST, PUT, or DELETE), the client must prove the request is intentional and not a forged browser-driven request. This is achieved by requiring at
least one of the following headers:
X-Requested-With: Commonly used by AJAX libraries like jQuery. Its presence indicates the request was made via a script, which is generally not possible for a standard cross-site CSRF attack.
Accept-API-Version: This header serves two purposes. First, it ensures the client is targeting a specific version of the PingAM REST API (e.g., resource=2.0, protocol=1.0). Second, since custom headers cannot be set in simple cross-site <form> submissions, it acts as a CSRF token.
If a POST request is sent to the REST API without one of these headers, PingAM will reject the request with a 403 Forbidden error, even if the user has a valid session cookie.
Option B (If-Match: _rev) is used for concurrency control (preventing "lost updates" in IDM or AM configuration), but it is not the primary CSRF defense.
Options A and D are headers sometimes used for "Zero-Page Login" or legacy authentication, but they do not provide protection against CSRF for the general REST API. Therefore, the combination of X-Requested-With or Accept-API-Version is the correct answer for default CSRF protection in PingAM 8.0.2.
C
Explanation:
Cross-Site Request Forgery (CSRF) is an attack where a malicious site sends a request to PingAM using the victim’s authenticated browser session. Because standard HTML forms and cross-site requests cannot easily set custom HTTP headers, requiring a specific header is an effective defense for REST APIs.
According to the PingAM "Security" documentation and the "REST API" reference:
By default, PingAM 8.0.2 enforces a CSRF filter on its REST endpoints (such as /json/authenticate or /json/users). For any "state-changing" request (like a POST, PUT, or DELETE), the client must prove the request is intentional and not a forged browser-driven request. This is achieved by requiring at
least one of the following headers:
X-Requested-With: Commonly used by AJAX libraries like jQuery. Its presence indicates the request was made via a script, which is generally not possible for a standard cross-site CSRF attack.
Accept-API-Version: This header serves two purposes. First, it ensures the client is targeting a specific version of the PingAM REST API (e.g., resource=2.0, protocol=1.0). Second, since custom headers cannot be set in simple cross-site <form> submissions, it acts as a CSRF token.
If a POST request is sent to the REST API without one of these headers, PingAM will reject the request with a 403 Forbidden error, even if the user has a valid session cookie.
Option B (If-Match: _rev) is used for concurrency control (preventing "lost updates" in IDM or AM configuration), but it is not the primary CSRF defense.
Options A and D are headers sometimes used for "Zero-Page Login" or legacy authentication, but they do not provide protection against CSRF for the general REST API. Therefore, the combination of X-Requested-With or Accept-API-Version is the correct answer for default CSRF protection in PingAM 8.0.2.
Question #8
To ensure the user’s full name is displayed on the consent screen for an OpenID Connect application, which string should be added into the Support Claims property on the OpenID Connect tab page of the OAuth2 Provider service in PingAM?
- A . name|en|Full name
- B . Full name|en|name
- C . full_name|Full name
- D . name|en|given_name+’ ‘+family_name
Correct Answer: A
A
Explanation:
When a client requests an OpenID Connect (OIDC) scope (like profile), PingAM 8.0.2 may present a Consent Screen to the user, asking permission to share specific claims. To make this screen user-friendly, PingAM allows administrators to map technical claim names to human-readable labels and specify localizations.
According to the PingAM documentation on "Supported Claims" in the OAuth2/OIDC Provider settings:
The format for the Supported Claims property entry is:
ClaimName|Locale|DisplayName
In this syntax:
ClaimName: The technical OIDC claim (e.g., name, email, given_name).
Locale: The ISO language code (e.g., en, fr).
DisplayName: The text that will actually appear on the UI (the "Full name" label).
Therefore, the string name|en|Full name (Option A) is the correct configuration.
Option B is incorrect because it reverses the technical name and the display name.
Option C is incorrect as it lacks the required locale component and uses full_name (which is not the standard OIDC claim name; the standard is name).
Option D attempts to perform a logic operation (+) within a configuration field where only static mapping strings are allowed. Claim composition (concatenating first and last names) is handled by
the OIDC Claims Script, not by the Supported Claims UI property.
A
Explanation:
When a client requests an OpenID Connect (OIDC) scope (like profile), PingAM 8.0.2 may present a Consent Screen to the user, asking permission to share specific claims. To make this screen user-friendly, PingAM allows administrators to map technical claim names to human-readable labels and specify localizations.
According to the PingAM documentation on "Supported Claims" in the OAuth2/OIDC Provider settings:
The format for the Supported Claims property entry is:
ClaimName|Locale|DisplayName
In this syntax:
ClaimName: The technical OIDC claim (e.g., name, email, given_name).
Locale: The ISO language code (e.g., en, fr).
DisplayName: The text that will actually appear on the UI (the "Full name" label).
Therefore, the string name|en|Full name (Option A) is the correct configuration.
Option B is incorrect because it reverses the technical name and the display name.
Option C is incorrect as it lacks the required locale component and uses full_name (which is not the standard OIDC claim name; the standard is name).
Option D attempts to perform a logic operation (+) within a configuration field where only static mapping strings are allowed. Claim composition (concatenating first and last names) is handled by
the OIDC Claims Script, not by the Supported Claims UI property.
Question #9
Which statements are correct about push notification authentication implemented with PingAM?
A) The user must have a device with a camera and install the Authenticator app.
B) The registration and authentication steps must be part of the same authentication tree.
C) To register a device the user scans a barcode with the Authenticator installed on their device.1
D) During subsequent authentication processes, PingAM instructs the push server to send a notification to the registered device, and waits for the user to use the Authenticator app to approve the request.2
- A . A, B, and C only
- B . B, C, and D only
- C . A and D only
- D . A and B only
Correct Answer: C
C
Explanation:
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.
C
Explanation:
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.
Question #10
Which of the following statements are correct regarding session upgrades in PingAM?
A) An authenticated user is required to authenticate again either to the same or a different authentication service.
B) The user must not change for the session upgrade to succeed.
C) The only PingAM mechanism to do a session upgrade is the ForceAuth=true request parameter.
D) A session upgrade is PingAM’s mechanism to perform what is called step-up authentication.
- A . A, C, and D
- B . B, C, and D
- C . A, B, and D
- D . A, B, and C
Correct Answer: C
C
Explanation:
In PingAM 8.0.2, Session Upgrade (often referred to as Step-up Authentication) is the process of increasing the "Authentication Level" (Auth Level) associated with a user’s session.2 This is common when a user has logged in with a basic method (like username/password) but attempts to access a resource that requires a stronger method (like MFA). Regarding the statements:
Statement A is correct: To upgrade a session, PingAM requires the user to satisfy the requirements of an authentication tree or module that has a higher Auth Level than the current session.3 This technically involves a "re-authentication" event specifically for the higher-level requirement. Statement B is correct: Crucially, the identity authenticated during the upgrade must match the identity of the existing session. If a different user attempts to authenticate during an upgrade process, PingAM will reject the upgrade to prevent session hijacking or identity swapping.4 Statement D is correct: Session upgrade is indeed the technical implementation of the industry-standard "step-up authentication" concept.
Statement C is incorrect because ForceAuth=true is not the only mechanism for a session upgrade.
While ForceAuth=true (in SAML2 or OIDC) or the prompt=login parameter can force a fresh authentication, PingAM also supports upgrades via Policy Advice.5 When a policy engine determines that a resource requires a higher Auth Level, it sends an "advice" to the client, triggering a session upgrade journey.6 Additionally, authentication trees can be configured to perform upgrades natively using the Session Upgrade configuration in the realm settings. Therefore, since A, B, and D are technically accurate descriptions of the AM 8.0.2 lifecycle, Option C is the correct choice.
C
Explanation:
In PingAM 8.0.2, Session Upgrade (often referred to as Step-up Authentication) is the process of increasing the "Authentication Level" (Auth Level) associated with a user’s session.2 This is common when a user has logged in with a basic method (like username/password) but attempts to access a resource that requires a stronger method (like MFA). Regarding the statements:
Statement A is correct: To upgrade a session, PingAM requires the user to satisfy the requirements of an authentication tree or module that has a higher Auth Level than the current session.3 This technically involves a "re-authentication" event specifically for the higher-level requirement. Statement B is correct: Crucially, the identity authenticated during the upgrade must match the identity of the existing session. If a different user attempts to authenticate during an upgrade process, PingAM will reject the upgrade to prevent session hijacking or identity swapping.4 Statement D is correct: Session upgrade is indeed the technical implementation of the industry-standard "step-up authentication" concept.
Statement C is incorrect because ForceAuth=true is not the only mechanism for a session upgrade.
While ForceAuth=true (in SAML2 or OIDC) or the prompt=login parameter can force a fresh authentication, PingAM also supports upgrades via Policy Advice.5 When a policy engine determines that a resource requires a higher Auth Level, it sends an "advice" to the client, triggering a session upgrade journey.6 Additionally, authentication trees can be configured to perform upgrades natively using the Session Upgrade configuration in the realm settings. Therefore, since A, B, and D are technically accurate descriptions of the AM 8.0.2 lifecycle, Option C is the correct choice.