how do I rotate a secret (string)

Hello @Cody Nunn

If by rotate a secret you mean the PostgreSQL password stored as a string in Azure Key Vault, there are actually two separate rotations involved:

Change the real PostgreSQL administrator password.

Store the new connection string/password as a new version of the existing Key Vault secret.

Don't just change the Key Vault value—the database password must match it.

For Azure Database for PostgreSQL Flexible Server, Microsoft supports resetting the administrator password with:

az postgres flexible-server update \
  --resource-group <resource-group> \
  --name <server-name> \
  --admin-password "<new-password>"

The server must be in the Ready state and password authentication must be enabled.

Then update the existing Key Vault secret:

az keyvault secret set \
  --vault-name <key-vault-name> \
  --name billing-database-url \
  --value "<new-connection-string>"

You don't need to delete the old secret first. az keyvault secret set creates a new version of the secret while retaining the previous versions.

If your Container App references the Key Vault secret using a versionless URI, such as:

https://<vault>.vault.azure.net/secrets/billing-database-url

make sure the application eventually picks up the new version. If it's pinned to a specific secret-version URI, you'll need to update that reference/revision.

For your HP connectivity issue, that's separate from secret rotation. If the PostgreSQL Flexible Server uses public access, add only the required client public IP:

az postgres flexible-server firewall-rule create \
  --resource-group <resource-group> \
  --name <server-name> \
  --rule-name Allow-HP \
  --start-ip-address <public-IP> \
  --end-ip-address <public-IP>

Microsoft documents using the same start/end address to permit one public IPv4 address.

Then test from the HP:

Test-NetConnection <server>.postgres.database.azure.com -Port 5432

If that succeeds, test PostgreSQL authentication using the new credentials before running any schema changes.

One security note: the screenshot contains a public IP, server hostname, database name and administrator username. Since you also stated that the PostgreSQL password was exposed, I would rotate the password immediately and avoid posting the new connection string, Key Vault secret, subscription ID, or credentials publicly.

The safe sequence is:

Rotate PostgreSQL password → update Key Vault secret → verify/restart the consuming application if required → test connectivity → remove any obsolete firewall access.

Also, if the application supports it, consider moving away from a long-lived PostgreSQL password toward Microsoft Entra authentication/managed identity, which reduces the need to manage database passwords at all.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.