Description of problem:
So via https://bugzilla.redhat.com/show_bug.cgi?id=1609022 we had a few reports around mysql failing when a password gets changed during a redeploy. That is an issue we need to look into. But the real question was "why did folks even hit that since they were not explicitely changing passwords".

This bug is meant to track these spurious password changes.

It seems to me that you can simply reproduce this behaviour if you specify a custom plan via -p during deploy. So I did a deployment like this:
...
-p derived.yaml
...

derived.yaml has the following:
version: 1.0

name: overcloud
description: >
  Default Deployment plan
template: overcloud.yaml
environments:
  - path: overcloud-resource-registry-puppet.yaml
workflow_parameters:
  tripleo.derive_params.v1.derive_parameters:
    ######### DPDK Parameters #########
    # Specifices the minimum number of CPU physical cores to be allocated for DPDK
    # PMD threads. The actual allocation will be based on network config, if
    # the a DPDK port is associated with a numa node, then this configuration
    # will be used, else 1.
    num_phy_cores_per_numa_node_for_pmd: 1
    # Amount of memory to be configured as huge pages in percentage. Ouf the
    # total available memory (excluding the NovaReservedHostMemory), the
    # specified percentage of the remaining is configured as huge pages.
    huge_page_allocation_percentage: 50
    ######### HCI Parameters #########
    hci_profile: nfv_default
    hci_profile_config:
      default:
        average_guest_memory_size_in_mb: 2048
        average_guest_cpu_utilization_percentage: 50
      many_small_vms:
        average_guest_memory_size_in_mb: 1024
        average_guest_cpu_utilization_percentage: 20
      few_large_vms:
        average_guest_memory_size_in_mb: 4096
        average_guest_cpu_utilization_percentage: 80
      nfv_default:
        average_guest_memory_size_in_mb: 8192
        average_guest_cpu_utilization_percentage: 90


I did a plan dump after the initial deploy and after the redeploy (which we know fails) and here are all the passwords we umprompted change under the hood:
(undercloud) [stack@undercloud-0 ~]$ diff -u before/plan-environment.yaml after/plan-environment.yaml |grep -i -e pass -e pwd -e key|grep -e '^-' -e '^+'
(undercloud) [stack@undercloud-0 ~]$ diff -u before/plan-environment.yaml after/plan-environment.yaml |grep -i -e pass -e pwd -e key -e cook |grep -e '^-' -e '^+'                                                                                                             
(undercloud) [stack@undercloud-0 ~]$ diff -u before/plan-environment.yaml after/plan-environment.yaml |grep -i -e pass -e pwd -e key -e cook -e secret |grep -e '^-' -e '^+'
-  HeatAuthEncryptionKey: qX6QNfufCF6k6DTZCK3Has7Udm6x6zdz
+  HeatAuthEncryptionKey: 51y1jUrU4hxfEwPkrvN0LoclEPu4CsAk
-  HorizonSecret: vnFPqWGZ4x
+  HorizonSecret: DQsYLPYCqg
-  MysqlRootPassword: NcHaHdAbjp
+  MysqlRootPassword: bVEgGn7TST
-  PcsdPassword: mG7jgT7HqZC6ajyD
-  RabbitCookie: gK4yepTpK9xJxdqCdQV2
+  PcsdPassword: ftNJSERu551wE0da
+  RabbitCookie: mFvYOjBgXAQW3qm6it3t

So it seems to me that the involved changed passwords here are all the ones contained in the default_password.yaml file.