edit

Author: dlepow

articles/container-registry/container-registry-geo-replication.md

@@ -89,7 +89,7 @@ ACR begins syncing images across the configured replicas. Once complete, the por
 * When you push or pull images from a geo-replicated registry, Azure Traffic Manager in the background sends the request to the registry located in the region that is closest to you in terms of network latency.
 * After you push an image or tag update to the closest region, it takes some time for Azure Container Registry to replicate the manifests and layers to the remaining regions you opted into. Larger images take longer to replicate than smaller ones. Images and tags are synchronized across the replication regions with an eventual consistency model.
 * To manage workflows that depend on push updates to a geo-replicated registry, we recommend that you configure [webhooks](container-registry-webhook.md) to respond to the push events. You can set up regional webhooks within a geo-replicated registry to track push events as they complete across the geo-replicated regions.
-* To serve blobs representing content layers, Azure Container Registy uses data endpoints. You can enable [dedicated data endpoints](container-registry-firewall-access-rules.md#enable-dedicated-data-endpoints-preview) for your registry in each of your registry's geo-replicated regions. These endpoints simplify configuration of firewall access rules.
+* To serve blobs representing content layers, Azure Container Registy uses data endpoints. You can enable [dedicated data endpoints](container-registry-firewall-access-rules.md#enable-dedicated-data-endpoints-preview) for your registry in each of your registry's geo-replicated regions. These endpoints allow configuration of tightly scoped firewall access rules.
 * If you configure a [private link](container-registry-private-link.md) for your registry using private endpoints in a virtual network, dedicated data endpoints in each of the geo-replicated regions are enabled by default. 
 
 ## Delete a replica