Updating data encryption docs

Author: kummanish

articles/mysql/concepts-data-encryption-mysql.md

@@ -66,7 +66,7 @@ The following are requirements for configuring Key Vault:
 
 The following are requirements for configuring the customer-managed key:
 
-* The customer-managed key to be used for encrypting the DEK can be only asymmetric, RSA 2028.
+* The customer-managed key to be used for encrypting the DEK can be only asymmetric, RSA 2048.
 * The key activation date (if set) must be a date and time in the past. The expiration date (if set) must be a future date and time.
 * The key must be in the *Enabled* state.
 * If you're importing an existing key into the key vault, make sure to provide it in the supported file formats (`.pfx`, `.byok`, `.backup`).
@@ -88,7 +88,13 @@ Here are recommendations for configuring a customer-managed key:
 
 ## Inaccessible customer-managed key condition
 
-When you configure data encryption with a customer-managed key in Key Vault, continuous access to this key is required for the server to stay online. If the server loses access to the customer-managed key in Key Vault, the server begins denying all connections within 10 minutes. The server issues a corresponding error message, and changes the server state to *Inaccessible*. The only action allowed on a database in this state is deleting it.
+When you configure data encryption with a customer-managed key in Key Vault, continuous access to this key is required for the server to stay online. If the server loses access to the customer-managed key in Key Vault, the server begins denying all connections within 10 minutes. The server issues a corresponding error message, and changes the server state to *Inaccessible*. Some of the reason why the server can reach this state are:
+
+* If we create a Point In Time Restore server for your Azure Database for MySQL which has data encryption enabled, the newly created server will be in *Inaccessible* state. You can fix this through [Azure portal](howto-data-encryption-portal.md#using-data-encryption-for-restore-or-replica-servers) or [CLI](howto-data-encryption-cli.md#using-data-encryption-for-restore-or-replica-servers).
+* If we create a read replica for your Azure Database for MySQL which has data encryption enabled, the newly replica server will be in *Inaccessible* state. You can fix this through [Azure portal](howto-data-encryption-portal.md#using-data-encryption-for-restore-or-replica-servers) or [CLI](howto-data-encryption-cli.md#using-data-encryption-for-restore-or-replica-servers).
+* If you delete the KeyVault, the Azure Database for MySQL will be unable to access the key and will move to *Inaccessible* state. Recover the [Key Vault](../key-vault/general/soft-delete-cli.md#deleting-and-purging-key-vault-objects) and re-validate the data encryption to make the server *Available*.
+* If we delete the key from the KeyVault, the Azure Database for MySQL will be unable to access the key and will move to *Inaccessible* state. Recover the [Key](../key-vault/general/soft-delete-cli.md#deleting-and-purging-key-vault-objects) and re-validate the data encryption to make the server *Available*.
+* If the key stored in the Azure KeyVault expires, the key will become invalid and the Azure Database for MySQL will transition into *Inaccessible* state. Extend the key expiry date using [CLI](https://docs.microsoft.com/cli/azure/keyvault/key?view=azure-cli-latest#az-keyvault-key-set-attributes) and then re-validate the data encryption to make the server *Available*.
 
 ### Accidental key access revocation from Key Vault
 
@@ -98,7 +104,6 @@ It might happen that someone with sufficient access rights to Key Vault accident
 * Deleting the key.
 * Deleting the key vault.
 * Changing the key vault's firewall rules.
-
 * Deleting the managed identity of the server in Azure AD.
 
 ## Monitor the customer-managed key in Key Vault

articles/postgresql/concepts-data-encryption-postgresql.md

@@ -65,7 +65,7 @@ The following are requirements for configuring Key Vault:
 
 The following are requirements for configuring the customer-managed key:
 
-* The customer-managed key to be used for encrypting the DEK can be only asymmetric, RSA 2028.
+* The customer-managed key to be used for encrypting the DEK can be only asymmetric, RSA 2048.
 * The key activation date (if set) must be a date and time in the past. The expiration date (if set) must be a future date and time.
 * The key must be in the *Enabled* state.
 * If you're importing an existing key into the key vault, make sure to provide it in the supported file formats (`.pfx`, `.byok`, `.backup`).
@@ -87,7 +87,13 @@ Here are recommendations for configuring a customer-managed key:
 
 ## Inaccessible customer-managed key condition
 
-When you configure data encryption with a customer-managed key in Key Vault, continuous access to this key is required for the server to stay online. If the server loses access to the customer-managed key in Key Vault, the server begins denying all connections within 10 minutes. The server issues a corresponding error message, and changes the server state to *Inaccessible*. The only action allowed on a database in this state is deleting it.
+When you configure data encryption with a customer-managed key in Key Vault, continuous access to this key is required for the server to stay online. If the server loses access to the customer-managed key in Key Vault, the server begins denying all connections within 10 minutes. The server issues a corresponding error message, and changes the server state to *Inaccessible*. Some of the reason why the server can reach this state are:
+
+* If we create a Point In Time Restore server for your Azure Database for PostgreSQL Single server which has data encryption enabled, the newly created server will be in *Inaccessible* state. You can fix this through [Azure portal](howto-data-encryption-portal.md#using-data-encryption-for-restore-or-replica-servers) or [CLI](howto-data-encryption-cli.md#using-data-encryption-for-restore-or-replica-servers).
+* If we create a read replica for your Azure Database for PostgreSQL Single server which has data encryption enabled, the newly replica server will be in *Inaccessible* state. You can fix this through [Azure portal](howto-data-encryption-portal.md#using-data-encryption-for-restore-or-replica-servers) or [CLI](howto-data-encryption-cli.md#using-data-encryption-for-restore-or-replica-servers).
+* If you delete the KeyVault, the Azure Database for PostgreSQL Single server will be unable to access the key and will move to *Inaccessible* state. Recover the [Key Vault](../key-vault/general/soft-delete-cli.md#deleting-and-purging-key-vault-objects) and re-validate the data encryption to make the server *Available*.
+* If we delete the key from the KeyVault, the Azure Database for PostgreSQL Single server will be unable to access the key and will move to *Inaccessible* state. Recover the [Key](../key-vault/general/soft-delete-cli.md#deleting-and-purging-key-vault-objects) and re-validate the data encryption to make the server *Available*.
+* If the key stored in the Azure KeyVault expires, the key will become invalid and the Azure Database for PostgreSQL Single server will transition into *Inaccessible* state. Extend the key expiry date using [CLI](https://docs.microsoft.com/cli/azure/keyvault/key?view=azure-cli-latest#az-keyvault-key-set-attributes) and then re-validate the data encryption to make the server *Available*.
 
 ### Accidental key access revocation from Key Vault