The recommended procedure for a PingAM upgrade using a replicated PingDS backend is to create an isolated environment to ensure a rollback path. This involves stopping replication between the two PingDS servers and shutting down one instance. This offline instance serves as a clean, pre-upgrade backup. The upgrade is then performed against the single active instance. If the upgrade fails, the modified instance can be discarded, and the untouched, shutdown instance can be brought back online to restore the previous state, effectively rolling back the changes.

A. Upgrading against both active instances simultaneously provides no rollback path, as both would be modified. The uninstall.sh script removes the product, it does not roll back data.

B. This is incorrect; a rollback path is a critical feature of enterprise software upgrade procedures and is supported.

C. This option is incomplete. Simply starting the shutdown instance is not the full rollback procedure; the failed instance must be taken out of service.

1. Ping Identity Documentation, PingAM > Installation > Upgrading AM > Preparing for an upgrade. The documentation explicitly states: "To provide a backout plan, you can break replication between two configuration stores before you upgrade. Upgrade one of the servers, and if the upgrade is successful, re-enable replication. If the upgrade fails, you can revert to the server that you did not upgrade."