For Proof of Possession OAuth2 tokens, in addition to the access token, what must be presented to the authorization server?
Correct Answer: D
Proof of Possession (PoP) tokens, specifically Certificate-Bound Access Tokens as defined in RFC 8705 and supported by PingAM 8.0.2, are designed to prevent token misuse by binding the access token to a specific client's cryptographic material.9 According to the PingAM documentation on "Certificate-Bound Proof-of-Possession," when an OAuth2 client requests a token, PingAM retrieves the client's public key (either from a provided certificate or a JWK) and embeds a thumbprint (the cnf claim) of that material into the issued token. When the client subsequently presents this token to the Resource Server (or the Authorization Server's introspection endpoint), it must also provide "Proof" that it possesses the private key corresponding to that thumbprint. In the Mutual TLS (mTLS) approach, this proof is provided by the Client private certificate presented during the TLS handshake.10 The server verifies that the certificate used to establish the secure connection matches the one bound to the token. Without presenting the certificate (Option D), the token is considered "unbound" or invalid, even if the token itself is otherwise well-formed. This mechanism effectively "pins" the token to the client, ensuring that if the token is stolen, it cannot be used by any other entity that does not possess the matching private key. Nonce and State (Options A and C) are used during the initial authorization request for different security purposes (replay protection and CSRF), and while a JWK (Option B) can be used to define the public key, the actual presentation of proof during an mTLS transaction is the certificate.
Question 12
Which of the following would be a possible combination of fields in the JSON body when making a policy evaluation via REST?
Correct Answer: B
In PingAM 8.0.2, requesting policy decisions via the REST API involves sending a POST request to the policies endpoint with the _action=evaluate parameter. To receive an accurate decision, the request body must provide the context of the access attempt. According to the "Request policy decisions over REST" documentation, the JSON body typically includes the following core fields: resources: (Required) An array of strings representing the URIs the user is attempting to access. application: (Required) This field specifies the name of the Policy Set (formerly known as the application) that contains the relevant policies for the evaluation. subject: (Optional, but usually required for user-specific policies) This object identifies the user or entity requesting access. It can include the user's ssoToken or a set of claims if using JWT-based subjects. Why other options are incorrect: Advices (Options A and C) are not inputs for a policy evaluation request. Instead, advices are returned by PingAM in the response if a policy condition fails (e.g., an AuthLevelConditionAdvice requesting the user to provide MFA). A request cannot "evaluate" an advice; it triggers one. Option D is incorrect because the resources field is a mandatory requirement for any evaluation; without a target resource, the engine has nothing to compare against the defined policy rules. Therefore, the combination of resources, subject, and application represents the standard, valid structure for a policy decision request in PingAM 8.0.2.
Question 13
In order to support rollback in case of a failed PingAM upgrade in a two server PingDS environment, what PingDS safety measure can be configured?
Correct Answer: D
Upgrading PingAM 8.0.2 in an environment with multiple PingDS (Directory Server) instances requires a careful strategy to ensure data integrity and to allow for an immediate Rollback if the upgrade fails or introduces instability.6 According to the PingAM "Plan for Rollback" and "Upgrade in a Replicated Environment" documentation, the recommended safety measure involves isolating one of the data store nodes to act as a "time-capsule" of the pre-upgrade state. The process is as follows: Stop Replication: Before starting the upgrade, administrators should disable or stop replication between the PingDS nodes. This prevents any schema changes or data modifications performed during the AM upgrade from being propagated to the backup node. Isolate a Node: One PingDS instance is shut down or taken out of the load balancer rotation. This instance remains in its original, healthy state. Perform the Upgrade: The PingAM upgrade is performed against the remaining active PingDS instance. If the upgrade involves schema updates (which is common when moving to version 8.0.2), only the active node's data is modified. Rollback Path: If the upgrade fails, the administrator can simply shut down the "corrupted" upgraded environment and restart the isolated PingDS instance along with the original PingAM WAR file. Because replication was stopped, the isolated node still contains the original configuration and user data. Option D is the only answer that correctly identifies this "safety-net" architecture. Option A is risky because a failed upgrade would corrupt both instances. Option C is incomplete because simply "starting up" the shutdown instance after an upgrade doesn't account for how you handle the discrepancy between the upgraded and non-upgraded nodes. The goal is to keep the shutdown instance as a valid, un-touched recovery point.
Question 14
Which of the following components is used to return data to PingGateway or the agent to be included with the policy decision?
Correct Answer: C
When PingAM 8.0.2 evaluates an authorization policy, the primary output is a "Permit" or "Deny" decision. However, applications and Policy Enforcement Points (PEPs)-like PingGateway or a Web Agent-often require additional metadata about the user or the session to function correctly (e.g., the user's employee ID, department, or a specific preference). According to the PingAM documentation on "Policies" and "Requesting Decisions": The mechanism used to provide this extra information is Response Attributes. When defining a policy in the PingAM UI or via REST, an administrator can configure "Response Attributes" which map internal attributes (from the User Profile or the Session) to keys that are sent back in the policy decision payload. How it works: If a policy is configured with a response attribute mapping uid to User-ID, when PingGateway asks "Can user X access resource Y?", PingAM responds with "Permit" AND a map containing User-ID: X. Consumption: PingGateway or the Web Agent can then take these attributes and inject them into HTTP headers (e.g., X-User-ID) so the downstream application can consume them without having to query AM again. Subjects (Option A), Resources (Option B), and Actions (Option D) are all input components used to define the scope of a policy; they are not used to return data to the enforcer. Only Response Attributes serve the purpose of enriching the decision response with additional context.
Question 15
Which is the correct simplified TLS handshake sequence needed to authenticate clients using a mutual TLS exchange?
Correct Answer: D
Mutual TLS (mTLS) is a security enhancement where both the client and the server provide X.509 certificates to prove their identities.9 In PingAM 8.0.2, mTLS is frequently used for secure "Machine-to-Machine" (M2M) communication, such as between an OAuth2 client and the token endpoint, or between AM and a Directory Server (PingDS). According to the PingAM documentation on "Secure Network Communication" and "mTLS for OAuth2," the handshake sequence for mTLS follows these logical steps: Client Hello: The client initiates the request to the server.10 Server Hello & Certificate: The server responds by presenting its own certificate (verifying the server's identity to the client).11 In an mTLS scenario, the server also includes a CertificateRequest message.12 Client Certificate & Key Exchange: The client validates the server's certificate. If valid, the client then sends its own Client Certificate to the server, along with the encrypted pre-master secret or key exchange data. Verification and Establishment: The server validates the client's certificate against its truststore. If the certificate is trusted and the cryptographic signatures match, the mutually secure connection is established. Option D represents the most accurate "simplified" sequence. Option A is incorrect because the server presents its certificate before the client sends its own certificate. Option B and C are incorrect because the server always responds to the initial "Client Hello" with its own identity (Server Certificate) before the client proceeds with identity submission. This "handshake" ensures that no data is transmitted until both parties have cryptographically verified each other.
