Merge pull request #290149 from v-thepet/patch-29

Update documentation-government-overview-wwps.md

Author: prmerger-automator[bot]

articles/azure-government/documentation-government-overview-wwps.md

@@ -80,7 +80,7 @@ Your data in an Azure Storage account is [always replicated](../storage/common/s
 
 Data in an Azure Storage account is always replicated three times in the primary region. Azure Storage provides LRS and ZRS redundancy options for replicating data in the primary region. For applications requiring high availability, you can choose geo-replication to a secondary region that is hundreds of kilometers away from the primary region. Azure Storage offers GRS and GZRS options for copying data to a secondary region. More options are available to you for configuring read access (RA) to the secondary region (RA-GRS and RA-GZRS), as explained in [Read access to data in the secondary region](../storage/common/storage-redundancy.md#read-access-to-data-in-the-secondary-region).
 
-Azure Storage redundancy options can have implications on data residency as Azure relies on [paired regions](../availability-zones/cross-region-replication-azure.md) to deliver [geo-redundant storage](../storage/common/storage-redundancy.md#geo-redundant-storage) (GRS). For example, if you're concerned about geo-replication across regions that span country boundaries, you may want to choose LRS or ZRS to keep Azure Storage data at rest within the geographic boundaries of the country in which the primary region is located. Similarly, [geo replication for Azure SQL Database](/azure/azure-sql/database/active-geo-replication-overview) can be obtained by configuring asynchronous replication of transactions to any region in the world, although it's recommended that paired regions be used for this purpose as well. If you need to keep relational data inside the geographic boundaries of your country/region, you shouldn't configure Azure SQL Database asynchronous replication to a region outside that country/region.
+Azure Storage redundancy options can have implications on data residency as Azure relies on [paired regions](../availability-zones/cross-region-replication-azure.md) to deliver [geo-redundant storage](../storage/common/storage-redundancy.md#geo-redundant-storage) (GRS). For example, if you're concerned about geo-replication across regions that span country/region boundaries, you may want to choose LRS or ZRS to keep Azure Storage data at rest within the geographic boundaries of the country/region in which the primary region is located. Similarly, [geo replication for Azure SQL Database](/azure/azure-sql/database/active-geo-replication-overview) can be obtained by configuring asynchronous replication of transactions to any region in the world, although it's recommended that paired regions be used for this purpose as well. If you need to keep relational data inside the geographic boundaries of your country/region, you shouldn't configure Azure SQL Database asynchronous replication to a region outside that country/region.
 
 As described on the [data location page](https://azure.microsoft.com/global-infrastructure/data-residency/), most Azure **regional** services honor the data at rest commitment to ensure that your data remains within the geographic boundary where the corresponding service is deployed. A handful of exceptions to this rule are noted on the data location page. You should review these exceptions to determine if the type of data stored outside your chosen deployment Geography meets your needs.