Control Center does not reapply updated secrets/configuration values after deployment update without forcing reconfiguration or removing persisted state

The customer has identified an issue with IBM Connect:Direct Control Center running on Kubernetes/EKS.

During the initial deployment, configuration values such as database credentials, administrator passwords and other secrets are provided through Helm values and Kubernetes Secrets.

After the deployment is completed, if any of these values are changed and a new deployment pipeline is executed (Helm upgrade), the updated values are not reflected by Control Center. The application continues to operate using the previously configured values. 

As an example, when the database password was changed, the new password was correctly updated in the secret source, but Control Center continued trying to use the old credentials and was unable to authenticate successfully. The issue was only resolved after removing the previously persisted information.

The customer observed that restarting pods or executing standard deployment procedures does not cause the application to reload the updated configuration. According to discussions with IBM specialists, the configuration process appears to be executed only once, and a manual intervention is required to force the configcc process to run again.

Customer Concerns:

The current workaround requires manual actions inside the running environment, including modification of internal files and forcing configuration flags before running a Helm upgrade. 

This approach is not acceptable for the customer's production environment because:

• Direct access to pods is heavily restricted.
• Any manual intervention requires a privileged "break glass" process.
• Password and secret rotation must be fully automated through CI/CD pipelines.
• Operational procedures must not depend on manual edits inside containers. 

Expected Behavior

When Secrets or configuration values are updated and a new deployment (Helm upgrade) is executed, Control Center should provide a supported and fully automatable mechanism to reapply the updated values without requiring:

• manual pod access,
• modification of internal files,
• deletion of persisted application state,
• or destructive recreation procedures.