NW doc minor fixes

Author: Ankita Dutta

articles/network-watcher/connection-monitor.md

@@ -75,9 +75,9 @@ Complete the steps in [Create the first VM](#create-the-first-vm) again, with th
 
 |Step|Setting|Value|
 |---|---|---|
-| 1 | Select a version of **Ubuntu Server** |                                                                         |
+| 1 | Select a version of the **Ubuntu Server** |                                                                     |
 | 3 | Name                                  | myVm2                                                                   |
-| 3 | Authentication type                   | Paste your SSH public key or select **Password**, and enter a password. |
+| 3 | Authentication type                   | Paste your SSH public key or select **Password** and enter a password. |
 | 3 | Resource group                        | Select **Use existing** and select **myResourceGroup**.                 |
 | 6 | Extensions                            | **Network Watcher Agent for Linux**                                             |
 
@@ -128,14 +128,14 @@ Create a connection monitor to monitor communication over TCP port 22 from *myVm
 
 Alerts are created by alert rules in Azure Monitor and can automatically run saved queries or custom log searches at regular intervals. A generated alert can automatically run one or more actions, such as to notify someone or start another process. When setting an alert rule, the resource that you target determines the list of available metrics that you can use to generate alerts.
 
-1. In Azure portal, select the **Monitor** service, and then select **Alerts** > **New alert rule**.
-2. Click **Select target**, and then select the resources that you want to target. Select the **Subscription**, and set **Resource type** to filter down to the Connection Monitor that you want to use.
+1. In the Azure portal, select the **Monitor** service, and then select **Alerts** > **New alert rule**.
+2. Click **Select target**, and then select the resources that you want to target. Select the **Subscription**, and set the **Resource type** to filter down to the Connection Monitor that you want to use.
 
     ![alert screen with target selected](./media/connection-monitor/set-alert-rule.png)
-1. Once you have selected a resource to target, select **Add criteria**.The Network Watcher has [metrics on which you can create alerts](../azure-monitor/alerts/alerts-metric-near-real-time.md#metrics-and-dimensions-supported). Set **Available signals** to the metrics ProbesFailedPercent and AverageRoundtripMs:
+1. Once you have selected a resource to target, select **Add criteria**. The Network Watcher has [metrics on which you can create alerts](../azure-monitor/alerts/alerts-metric-near-real-time.md#metrics-and-dimensions-supported). Set **Available signals** to the metrics ProbesFailedPercent and AverageRoundtripMs:
 
     ![alert page with signals selected](./media/connection-monitor/set-alert-signals.png)
-1. Fill out the alert details like alert rule name, description and severity. You can also add an action group to the alert to automate and customize the alert response.
+1. Fill out the alert details like alert rule name, description, and severity. You can also add an action group to the alert to automate and customize the alert response.
 
 ## View a problem
 
@@ -156,7 +156,7 @@ By default, Azure allows communication over all ports between VMs in the same vi
     | Priority                | 100            |
     | Name                    | DenySshInbound |
 
-5. Since connection monitor probes at 60-second intervals, wait a few minutes and then on the left side of the portal, select **Network Watcher**, then **Connection monitor**, and then select the **myVm1-myVm2(22)** monitor again. The results are different now, as shown in the following picture:
+5. Since connection monitor probes at 60-second intervals, wait a few minutes, and then on the left side of the portal, select **Network Watcher**, then **Connection monitor**, and then select the **myVm1-myVm2(22)** monitor again. The results are different now, as shown in the following picture:
 
     ![Monitor details fault](./media/connection-monitor/vm-monitor-fault.png)
 

articles/network-watcher/diagnose-vm-network-routing-problem.md

@@ -40,8 +40,8 @@ Log in to the Azure portal at https://portal.azure.com.
 
 ## Create a VM
 
-1. Select **+ Create a resource** found on the upper, left corner of the Azure portal.
-2. Select **Compute**, and then select **Windows Server 2016 Datacenter** or **Ubuntu Server 17.10 VM**.
+1. Select **+ Create a resource** found on the upper-left corner of the Azure portal.
+2. Select **Compute** and then select **Windows Server 2016 Datacenter** or **Ubuntu Server 17.10 VM**.
 3. Enter, or select, the following information, accept the defaults for the remaining settings, and then select **OK**:
 
     |Setting|Value|
@@ -76,7 +76,7 @@ If you already have a network watcher enabled in at least one region, skip to [U
 
 Azure automatically creates routes to default destinations. You may create custom routes that override the default routes. Sometimes, custom routes can cause communication to fail. Use the next hop capability of Network Watcher to determine which route Azure is using to route traffic.
 
-1. In the Azure portal, select **Next hop**, under **Network Watcher**.
+1. In the Azure portal, select **Next hop** under **Network Watcher**.
 2. Select your subscription, enter or select the following values, and then select **Next hop**, as shown in the picture that follows:
 
     |Setting                  |Value                                                   |
@@ -89,9 +89,9 @@ Azure automatically creates routes to default destinations. You may create custo
 
     ![Next hop](./media/diagnose-vm-network-routing-problem/next-hop.png)
 
-    After a few seconds, the result informs you that the next hop type is **Internet**, and that the **Route table ID** is **System Route**. This result lets you know that there is a valid system route to the destination.
+    After a few seconds, the result informs you that the next hop type is **Internet** and that the **Route table ID** is **System Route**. This result lets you know that there is a valid system route to the destination.
 
-3. Change the **Destination IP address** to *172.31.0.100* and select **Next hop** again. The result returned informs you that **None** is the **Next hop type**, and that the **Route table ID** is also **System Route**. This result lets you know that, while there is a valid system route to the destination, there is no next hop to route the traffic to the destination.
+3. Change the **Destination IP address** to *172.31.0.100* and select **Next hop** again. The result returned informs you that **None** is the **Next hop type** and that the **Route table ID** is also **System Route**. This result lets you know that, while there is a valid system route to the destination, there is no next hop to route the traffic to the destination.
 
 ## View details of a route
 
@@ -100,9 +100,9 @@ Azure automatically creates routes to default destinations. You may create custo
 
     ![Effective routes](./media/diagnose-vm-network-routing-problem/effective-routes.png)
 
-    When you ran the test using 13.107.21.200 in [Use next hop](#use-next-hop), the route with the address prefix 0.0.0.0/0 was used to route traffic to the address, since no other route includes the address. By default, all addresses not specified within the address prefix of another route are routed to the internet.
+    When you ran the test using 13.107.21.200 in [Use next hop](#use-next-hop), the route with the address prefix 0.0.0.0/0 was used to route traffic to the address since no other route includes the address. By default, all addresses not specified within the address prefix of another route are routed to the internet.
 
-    When you ran the test using 172.31.0.100 however, the result informed you that there was no next hop type. As you can see in the previous picture, though there is a default route to the 172.16.0.0/12 prefix, which includes the 172.31.0.100 address, the **NEXT HOP TYPE** is **None**. Azure creates a default route to 172.16.0.0/12, but doesn't specify a next hop type until there is a reason to. If, for example, you added the 172.16.0.0/12 address range to the address space of the virtual network, Azure changes the **NEXT HOP TYPE** to **Virtual network** for the route. A check would then show **Virtual network** as the **NEXT HOP TYPE**.
+    When you ran the test using 172.31.0.100, however, the result informed you that there was no next hop type. As you can see in the previous picture, though there is a default route to the 172.16.0.0/12 prefix, which includes the 172.31.0.100 address, the **NEXT HOP TYPE** is **None**. Azure creates a default route to 172.16.0.0/12 but doesn't specify a next hop type until there is a reason to. If, for example, you added the 172.16.0.0/12 address range to the address space of the virtual network, Azure changes the **NEXT HOP TYPE** to **Virtual network** for the route. A check would then show the **Virtual network** as the **NEXT HOP TYPE**.
 
 ## Clean up resources
 

articles/network-watcher/quickstart-configure-network-security-group-flow-logs-from-arm-template.md

@@ -70,7 +70,7 @@ If there were issues with the deployment, see [Troubleshoot common Azure deploym
 
 ## Clean up resources
 
-You can delete Azure resources by using complete deployment mode. To delete a flow logs resource, specify a deployment in complete mode without including the resource you want to delete. Read more about [complete deployment mode](../azure-resource-manager/templates/deployment-modes.md#complete-mode).
+You can delete Azure resources by using complete deployment mode. To delete a flow logs resource, specify a deployment in the complete mode without including the resource you want to delete. Read more about [complete deployment mode](../azure-resource-manager/templates/deployment-modes.md#complete-mode).
 
 You also can disable an NSG flow log in the Azure portal:
 

articles/network-watcher/quickstart-configure-network-security-group-flow-logs-from-bicep.md

@@ -79,7 +79,7 @@ If there were issues with the deployment, see [Troubleshoot common Azure deploym
 
 ## Clean up resources
 
-You can delete Azure resources by using complete deployment mode. To delete a flow logs resource, specify a deployment in complete mode without including the resource you want to delete. Read more about [complete deployment mode](../azure-resource-manager/templates/deployment-modes.md#complete-mode).
+You can delete Azure resources by using complete deployment mode. To delete a flow logs resource, specify a deployment in the complete mode without including the resource you want to delete. Read more about [complete deployment mode](../azure-resource-manager/templates/deployment-modes.md#complete-mode).
 
 You also can disable an NSG flow log in the Azure portal:
 

includes/resource-manager-quickstart-bicep-introduction.md

@@ -6,4 +6,4 @@ ms.date: 09/27/2021
 ms.author: jgao
 ---
 
-[Bicep](../articles/azure-resource-manager/bicep/overview.md) is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. Bicep offers the best authoring experience for your infrastructure-as-code solutions in Azure.
+[Bicep](../articles/azure-resource-manager/bicep/overview.md) is a domain-specific language (DSL) that uses a declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. Bicep offers the best authoring experience for your infrastructure-as-code solutions in Azure.