Update how-to-data-owner-policies-storage.md

Author: inward-eye

articles/purview/how-to-data-owner-policies-storage.md

@@ -6,17 +6,17 @@ ms.author: vlrodrig
 ms.service: purview
 ms.subservice: purview-data-policies
 ms.topic: how-to
-ms.date: 04/08/2022
+ms.date: 04/15/2022
 ms.custom:
 ---
 
 # Access provisioning by data owner to Azure Storage datasets (preview)
 
 [!INCLUDE [feature-in-preview](includes/feature-in-preview.md)]
 
-[Policies](concept-data-owner-policies.md) in Azure Purview allow you to enable access to data sources that have been registered to a collection. 
+[Policies](concept-data-owner-policies.md) allow you to enable access to data sources that have been registered for *Data use governance* in Azure Purview.
 
-This article describes how a data owner can use Azure Purview to enable access to datasets in Azure Storage. Currently, these Azure Storage sources are supported:
+This article describes how a data owner can delegate in Azure Purview management of access to Azure Storage datasets. Currently, these two Azure Storage sources are supported:
 - Blob storage
 - Azure Data Lake Storage (ADLS) Gen2
 
@@ -29,21 +29,19 @@ This article describes how a data owner can use Azure Purview to enable access t
 [!INCLUDE [Access policies generic configuration](./includes/access-policies-configuration-generic.md)]
 
 ### Register the data sources in Azure Purview for Data use governance
-The Azure Storage resources need to be registered with Azure Purview to later define access policies.
+The Azure Storage resources need to be registered first with Azure Purview to later define access policies.
 
 To register your resources, follow the **Prerequisites** and **Register** sections of these guides:
 
 -   [Register and scan Azure Storage Blob - Azure Purview](register-scan-azure-blob-storage-source.md#prerequisites)
 
 -   [Register and scan Azure Data Lake Storage (ADLS) Gen2 - Azure Purview](register-scan-adls-gen2.md#prerequisites)
 
-After you've registered your resources, you'll need to enable data use governance. Data use governance affects the security of your data, as it allows your users to manage access to resources from within Azure Purview.
-
-To ensure you securely enable data use governance, and follow best practices, follow this guide to enable data use governance for your resource group or subscription:
+After you've registered your resources, you'll need to enable *Data use governance*. Data use governance can affect the security of your data, as it allows certain Azure Purview roles to manage access to data sources that have been registered. Secure practices related to *Data use governance* are described in this guide:
 
 - [How to enable data use governance](./how-to-enable-data-use-governance.md) 
 
-In the end, your resource will have the  **Data use governance** toggle to **Enabled**, as shown in the picture:
+The expected outcome is that your data source will have the  **Data use governance** toggle **Enabled**, as shown in the picture:
 
 :::image type="content" source="./media/how-to-data-owner-policies-storage/register-data-source-for-policy-storage.png" alt-text="Screenshot that shows how to register a data source for policy by toggling the enable tab in the resource editor.":::
 
@@ -58,7 +56,7 @@ Execute the steps in the [data-owner policy authoring tutorial](how-to-data-owne
 
 
 ## Additional information
-- Policy statements set below container level on a Storage account are supported. If no access has been provided at Storage account level or container level, then the App that requests the data must execute a direct access by providing a fully qualified name to the data object. If the App attempts to crawl down the hierarchy starting from the Storage account or Container, and there's no access at that level, the request will fail. The following documents show examples of how to do perform a direct access. See also blogs in the *Next steps* section of this tutorial.
+- Policy statements set below container level on a Storage account are supported. If no access has been provided at Storage account level or container level, then the App that requests the data must execute a direct access by providing a fully qualified name to the data object. If the App attempts to crawl down the hierarchy starting from the Storage account or Container (like Storage Explorer does), and there's no access at that level, the request will fail. The following documents show examples of how to perform a direct access. See also the blogs in the *Next steps* section of this how-to-guide.
   - [*abfs* for ADLS Gen2](../hdinsight/hdinsight-hadoop-use-data-lake-storage-gen2.md#access-files-from-the-cluster)
   - [*az storage blob download* for Blob Storage](../storage/blobs/storage-quickstart-blobs-cli.md#download-a-blob)
 - Creating a policy at Storage account level will enable the Subjects to access system containers, for example *$logs*.  If this is undesired, first scan the data source(s) and then create finer-grained policies for each (that is, at container or subcontainer level).
@@ -69,9 +67,8 @@ Execute the steps in the [data-owner policy authoring tutorial](how-to-data-owne
 
 ### Known issues
 
-> [!Warning]
-> **Known issues** related to Policy creation
-> - Do not create policy statements based on Azure Purview resource sets. Even if displayed in Azure Purview policy authoring UI, they are not yet enforced. Learn more about [resource sets](concept-resource-sets.md).
+**Known issues** related to Policy creation
+- Do not create policy statements based on Azure Purview resource sets. Even if displayed in Azure Purview policy authoring UI, they are not yet enforced. Learn more about [resource sets](concept-resource-sets.md).
 
 ### Policy action mapping