Update how-to-use-azure-policy.md

Addressing PR review comments from content engineering team

Author: Nagarjuna-Vipparthi

articles/load-testing/how-to-use-azure-policy.md

@@ -12,75 +12,89 @@ ms.topic: how-to
 
 # Secure your Azure Load Testing resources with Azure Policy
 
-[Azure Policy](../governance/policy/overview.md) is a governance tool that gives users the ability to audit and manage their Azure environment at scale. Azure Policy helps you place guardrails on Azure resources to ensure they are compliant with assigned policy rules. It allows users to perform audit, real-time enforcement, and remediation of their Azure environment. The results of audits that are performed by policy are available to users in a compliance dashboard. In the compliance dashboard, you can see a drill down of the resources and components that are compliant and noncompliant. For more information, see the [Overview of the Azure Policy service](../governance/policy/overview.md).
+[Azure Policy](../governance/policy/overview.md) is a governance tool that allows you to enforce organizational standards and to assess compliance at-scale. The policies allow you to perform audits, real-time enforcement, and remediation of your Azure environment. Audit results are available in your compliance dashboard. In the dashboard, you can review which resources and components are compliant and noncompliant, and take remediation actions. For more information, see the [Overview of the Azure Policy service](../governance/policy/overview.md). 
 
-Example Usage Scenarios:
+Use Azure policy to manage your load testing resources in scenarios like:
 
-- Azure Load Testing service creates Azure resources like virtual machines, Network Security Group (NSG), Azure load balancer in your subscription to run a load test. You want to ensure that these resources get created only in a set of virtual networks in your subscription. 
-- You want to ensure that load tests in Azure Load Testing can be created only in private test traffic mode. 
-- You want to use customer-managed keys(CMK) to manage the encryption at rest for your Azure Load Testing resource. 
+- **Private tests**
+  - When you want to ensure that load tests in Azure Load Testing can be created only in private test traffic mode. 
+  - When you want to ensure that the resources like virtual machines, Network Security Group (NSG), Azure load balancer and public IP created by the Azure Load Testing service get created only in a set of virtual networks in your subscription. 
+- **Customer-managed keys**
+  - You want to use customer-managed keys(CMK) to manage the encryption at rest for your Azure Load Testing resource. 
 
 ## Types of policy effects and guidance
 
-When enforcing a policy, you can determine its effect over the resulting evaluation. Each policy definition allows you to choose one of multiple effects. Therefore, policy enforcement may behave differently depending on the type of operation you are evaluating. In general, the effects for policies that integrate with Azure Load Testing include:
+When enforcing a policy, you can determine its [effect](../governance/policy/policy-glossary.md#effect) over the resulting evaluation. Each policy definition allows you to choose one of multiple [effects](../governance/policy/concepts/effect-basics.md). Therefore, policy enforcement may behave differently depending on the type of operation you are evaluating. In general, the effects for policies that integrate with Azure Load Testing include:
 
-- [**Audit**](../governance/policy/concepts/effects.md#audit): when the effect of a policy is set to `Audit`, the policy doesn't cause any breaking changes to your environment. It only alerts you to Azure Load Testing resources that don't comply with the policy definitions within a specified scope, by marking these components as noncompliant in the policy compliance dashboard. Audit is default if no policy effect is selected.
+- [**Audit**](../governance/policy/concepts/effects.md#audit): When the effect of a policy is set to `Audit`, the policy doesn't cause any breaking changes to your environment. The policy alerts you to Azure Load Testing resources that don't comply with the policy definitions within a specified scope. Components are marked as noncompliant in the policy compliance dashboard. The `Audit` value is default if no policy effect is selected.
 
-- [**Deny**](../governance/policy/concepts/effects.md#deny): when the effect of a policy is set to `Deny`, the policy blocks the creation of a new resource or new test runs that don't comply with the policy definition. Existing noncompliant test runs are not affected. The 'audit' capabilities continue to operate.
+- [**Deny**](../governance/policy/concepts/effects.md#deny): When the effect of a policy is set to `Deny`, the policy blocks the creation of a new test run that doesn't comply with the policy definition. Existing noncompliant test runs and resources are not affected. The 'Audit' capabilities continue to operate.
 
-- [**Disabled**](../governance/policy/concepts/effects.md#disabled): when the effect of a policy is set to `Disabled`, the policy gets evaluated but enforcement doesn't take effect, thus being compliant for the condition with `Disabled` effect. This effect is useful to disable the policy for a specific condition as opposed to all conditions.
+- [**Disabled**](../governance/policy/concepts/effects.md#disabled): When the effect of a policy is set to `Disabled`, the policy gets evaluated but enforcement doesn't take effect. This effect is useful to disable the policy for a specific condition as opposed to all conditions.
 
-## Available Built-In Policy Definitions
+## Built-in policy definitions
 
-Predetermined policies, referred to as 'built-ins', facilitate governance over your load testing resources so you don't have to write custom policies in JSON format to enforce commonly used rules associated with best security practices. Even though built-ins are predetermined, certain policies require you to define parameters. For example, by defining the effect of the policy, you can audit the load testing resource before enforcing a deny operation to prevent outages. See [built-in policies for Azure Load Testing](../governance/policy/samples/built-in-policies#azure-load-testing) to view the current built-in policies available for Azure Load Testing. 
+Predetermined policies, referred to as 'built-ins', allow governance over your load testing resources so you don't have to write custom policies in JSON format to enforce commonly used rules associated with best security practices. Even though built-ins are predetermined, certain policies require you to define parameters. For example, by defining the effect of the policy, you can audit the load testing resource before enforcing a deny operation to prevent outages. See [built-in policies for Azure Load Testing](../governance/policy/samples/built-in-policies#azure-load-testing) to view the current built-in policies available for Azure Load Testing. 
 
-## Enabling and managing a load testing policy through the Azure portal
+## Enable and manage a load testing policy
 
 ### Select a Policy Definition
 
 1. Log in to the Azure portal.
-1. Search "Policy" in the Search Bar and Select **Policy**.
+1.Search **Policy** in the search bar and select **Policy**.
 
     ![Screenshot that shows the Search Bar.](media/how-to-use-azure-policy/search-policy.png)
 
-1. In the Policy window, select **Definitions**.
+1. In the **Policy** window, select **Definitions**.
 
     ![Screenshot that highlights the Definitions option.](media/how-to-use-azure-policy/select-definitions.png)
 
-1. In the Category Filter, unselect **Select All** and select **Azure Load Testing**. 
+1. In the *Category* filter, unselect **Select All** and select **Azure Load Testing**.
 
     ![Screenshot that shows the Category Filter and the selected Azure Load Testing category.](media/how-to-use-azure-policy/select-category.png)
 
 1. Now you should be able to see all the policies available for Azure Load Testing. Make sure you read and understand the [policy guidance](#types-of-policy-effects-and-guidance) and select a policy you want to assign to a scope.  
 
     ![Screenshot that shows the available policies.](media/how-to-use-azure-policy/search-policy.png)
 
-### Assign a Policy to a Scope 
+### Assign a policy to a scope
 
-1. Select a policy you wish to apply. In this example, the **Load tests using Azure Load Testing should be run only against private endpoints from within a virtual network** policy is shown. Click the assign button in the top-left corner.
+1. Select a policy to apply. In this example, the **Load tests using Azure Load Testing should be run only against private endpoints from within a virtual network** policy is shown. Click the **Assign** button in the top-left corner.
 
     ![Screenshot that shows the Load tests using Azure Load Testing should be run only against private endpoints from within a virtual network policy.](media/how-to-use-azure-policy/select-policy.png)
 
-1. Select the subscription where you want the policy to be applied. You can choose to restrict the scope to only a single resource group within a subscription. If you want to apply the policy to the entire subscription and exclude some resource groups, you can also configure an exclusion list. Set the policy enforcement selector to **Enabled** if you want the effect of the policy (audit or deny) to occur or **Disabled** to turn the effect (audit or deny) off. 
+1. Select the subscription where you want the policy to be applied.
+   
+	    You can choose to restrict the scope to only a single resource group within a subscription.
+	    
+	    If you want to apply the policy to the entire subscription and exclude some resource groups, you can also configure an exclusion list.
+	    
+	    Set the policy enforcement selector to **Enabled** if you want the effect of the policy (audit or deny) to occur or **Disabled** to turn the effect (audit or deny) off. 
 
     ![Screenshot that shows where you can choose to restrict the scope to only a single resource group within a subscription.](media/how-to-use-azure-policy/select-policy-scope.png)
 
-1. To specify the policy effect, click on the parameters tab at the top of the screen. Uncheck 'Only show parameters that need input or review' option. Select **Audit** or **Deny** or **Disabled** for the effect of the policy following the [policy guidance](#types-of-policy-effects-and-guidance). Then select the review + create button. 
+1. To specify the policy effect, select the parameters tab at the top of the screen.
+	
+	1. Uncheck the *Only show parameters that need input or review* option.
+	
+	1. Select **Audit** or **Deny** or **Disabled** for the effect of the policy following the [policy guidance](#types-of-policy-effects-and-guidance).
+	
+	1. Select the **Review + create** button. 
 
     ![Screenshot that shows the Parameters tab where you can specify the policy effect.](media/how-to-use-azure-policy/select-policy-effect.png)
 
 ## Feature Limitations
 
-Assigning a policy with a "deny" effect may take up to 30 mins (average case) and 1 hour (worst case) to start denying the creation of non-compliant resources. The delay refers to following scenarios -
+Assigning a policy with a "deny" effect may take from 30 mins (on average) or up to one hour to start denying the creation of non-compliant resources. The delay refers to following scenarios:
 1. A new policy is assigned.
 2. An existing policy assignment is modified.
 3. A new Azure Load Testing resource is created in a scope with existing policies.
 
-The policy evaluation of existing components in an Azure Load Testing resource may take up to 1 hour (average case) and 2 hours (worst case) before compliance results are viewable in the portal UI.
+The policy evaluation of existing components in an Azure Load Testing resource may take up to one hour (one averagee) or up to two hours before compliance results are viewable in the portal.
 
 If the compliance results show up as "Not Started" it may be due to the following reasons:
 
-- The policy evaluation is not completed. Initial evaluation latency can take up to 2 hours in the worst-case scenario.
+- The policy evaluation is not completed. Initial evaluation latency can take up to two hours.
 - There are no Azure Load Testing resources in the scope of the policy assignment.
 
 ## Next Steps