Service: Azure Database for MySQL Flexible Server | Issue: CMK / Inaccessible server

Hi Devops,

It sounds like your MySQL Flexible Server is stuck in an Inaccessible state because the customer-managed key (CMK) failed its revalidation check (CMKRevalidateCheckKeyFailed). This usually means the server’s managed identity lost access to the Key Vault or the CMK settings need to be reapplied. Here’s what you can try:

1. Double-check your managed identity and Key Vault configuration: • Verify the user-assigned or system-assigned managed identity on your MySQL server has a Key Vault access policy with at least Get, WrapKey and UnwrapKey permissions on the key.
   • Make sure the Key Vault firewall (if enabled) allows access from your server’s network or service tag.
2. Reapply or update the CMK on the Flexible Server:
   • In the Azure portal: – Navigate to your MySQL Flexible Server > Encryption (under Settings) > Customer-managed key. – Click “Update” or “Change key,” reselect the Key Vault and key version, and save.
   • Via Azure CLI (example):

      az mysql flexible-server encryption update \
        --resource-group MyResourceGroup \
        --name MyServerName \
        --cmk-uri https://MyVault.vault.azure.net/keys/MyKeyName/KeyVersion
   

   This forces the service to reattach and revalidate the CMK. https://dori-uw-1.kuma-moon.com/en-us/azure/mysql/flexible-server/security-customer-managed-key#recommendations-for-configuring-data-encryption
   https://dori-uw-1.kuma-moon.com/en-us/azure/mysql/flexible-server/overview#enterprise-grade-security-compliance-and-privacy Please do let me know if it works. If not, share the details in private message for further troubleshooting.

For an Azure Database for MySQL Flexible Server that is in Inaccessible state due to CMK issues (such as CMKRevalidateCheckKeyFailed), the platform requires continuous access to the customer-managed key in Key Vault. Once access is correctly restored, the server must successfully revalidate the CMK before it can return to Available.

Based on the documented behavior:

1. Confirm that the key and vault are healthy and accessible:
   • Ensure the Key Vault still exists and is in the same region as the MySQL flexible server.
   • Ensure the CMK itself exists (not deleted) and is enabled.
   • Verify that the user-assigned managed identity (UAMI) or identity used for encryption still exists and has the required permissions (get, list, wrapKey, unwrapKey) on the key.
   • Confirm Key Vault firewall/network rules allow access from the MySQL flexible server.
2. If the key vault or key was deleted and has been recovered:
   • If the key vault was deleted and then recovered, follow:
     1. Recover the key vault.
     2. Revalidate data encryption on the MySQL flexible server so it can re-check the CMK and move back to Available.
   • If the key in the vault was deleted and then recovered, follow:
     1. Recover the key.
     2. Revalidate data encryption on the MySQL flexible server.
   The documented steps for making an Inaccessible server Available after key or vault deletion are:
   • Recover the key vault or key.
   • Revalidate the data encryption in the server’s data encryption settings.
3. Revalidate CMK in the portal:
   • Go to the Azure Database for MySQL flexible server in the Azure portal.
   • Open the data encryption / CMK configuration blade.
   • Use the Revalidate or equivalent action to validate the CMK and identity permissions. This is also required after restore or replica creation and applies similarly when recovering from an inaccessible CMK condition.
4. If the server remains stuck in Inaccessible after CMK and identity are correct:
   • The platform documentation does not expose a direct “backend revalidation” operation to customers beyond the above revalidation step.
   • For production-down scenarios where the server does not transition back to Available after key recovery and CMK revalidation, open an Azure Support ticket so the service team can perform backend repair. Use the highest severity available for production impact.
5. Preventive measures once recovered:
   • Apply a resource lock on the Key Vault to prevent accidental deletion.
   • Enable auditing/logging on Key Vault to monitor key access and configure Activity Log alerts and Action Groups for failures accessing the CMK.
   • Keep a backup/escrow copy of the CMK and create a Key Vault key backup before first use.

These steps align with the documented “Inaccessible customer-managed key condition” behavior for Azure Database for MySQL Flexible Server and the need to revalidate encryption after restoring key or vault access.

References:

• Data encryption with customer managed keys for Azure Database for MySQL