Line edits

Author: lootle1

learn-pr/azure/deploy-resources-scopes-bicep/8-knowledge-check.yml

@@ -68,4 +68,3 @@ quiz:
         You can use Bicep files that have a `targetScope` of `managementGroup`, but you need to explicitly set the `scope` to `tenant()`.
         Also, the hierarchy of management groups doesn't depend on how they're deployed.
         You set a management group's parent as one of its properties.
-

learn-pr/azure/deploy-resources-scopes-bicep/includes/1-introduction.md

@@ -1,10 +1,10 @@
-Some Azure resources are deployed outside resource groups, and are instead deployed at various _scopes_: a subscription, a management group, or even your whole tenant. By using Bicep, you can create and configure Azure resources at each of these scopes, and you'll gain the benefits of using infrastructure as code across your full portfolio of Azure resources.
+Some Azure resources are deployed outside resource groups and are instead deployed at various _scopes_: a subscription, a management group, or even your whole tenant. By using Bicep, you can create and configure Azure resources at each of these scopes, and you'll gain the benefits of using infrastructure as code across your full portfolio of Azure resources.
 
 ## Example scenario
 
 Suppose you're responsible for deploying and configuring Azure infrastructure at a toy company. Your R&D team is designing a new toy as part of a top-secret project called Project Teddybear. The team has asked you to create a dedicated Azure subscription to help prevent the project information from accidentally being exposed to the rest of the company.
 
-The R&D team plans to use virtual machines within the subscription, but to save money, the team has asked for your help to ensure that only certain virtual machine SKUs can be created within that subscription. The team also needs your assistance to create a virtual network in the subscription, because that network will eventually need to connect to the main corporate network, which you help to manage.
+The R&D team plans to use virtual machines within the subscription, but to save money, the team has asked for your help to ensure that only certain virtual machine SKUs can be created within that subscription. The team also needs your assistance to create a virtual network in the subscription because that network will eventually need to connect to the main corporate network, which you help to manage.
 
 Here's a diagram that shows how these components fit within their Azure subscription:
 

learn-pr/azure/deploy-resources-scopes-bicep/includes/2-understand-deployment-scopes.md

@@ -10,17 +10,17 @@ Azure has a hierarchical resource structure with multiple levels of management.
 
 :::image type="icon" source="../media/callout-01.png"::: Your *tenant* corresponds to your Microsoft Entra instance. An organization ordinarily has only one Microsoft Entra instance. This instance acts as the root of the resource hierarchy.
 
-:::image type="icon" source="../media/callout-02.png"::: *Management groups* provide a way to organize Azure subscriptions. Each tenant has a single root management group, and you can establish your own hierarchy of management groups under it. You might create separate management groups for the various parts of your organization, or for subscriptions that have their own security or governance requirements. You can apply policy and access-control restrictions to management groups, and all subscriptions below that management group in the hierarchy inherit these restrictions. Management groups aren't deployed to regions, and they have no impact on your resources' locations.
+:::image type="icon" source="../media/callout-02.png"::: *Management groups* provide a way to organize Azure subscriptions. Each tenant has a single root management group, and you can establish your own hierarchy of management groups under it. You might create separate management groups for the various parts of your organization or for subscriptions that have their own security or governance requirements. You can apply policy and access-control restrictions to management groups, and then all subscriptions below that management group in the hierarchy inherit these restrictions. Management groups aren't deployed to regions, and they have no impact on your resources' locations.
 
 :::image type="icon" source="../media/callout-03.png"::: *Subscriptions* act as billing accounts, and they contain resource groups and resources. Like management groups, subscriptions have no location and don't restrict where your resources are deployed.
 
 :::image type="icon" source="../media/callout-04.png"::: *Resource groups* are logical containers for your resources. With resource groups, you can manage and control related resources as a single unit. Resources such as virtual machines, Azure App Service plans, storage accounts, and virtual networks must be put into a resource group. Resource groups are created in a location so that Azure can track the metadata for the resources in the group, but resources inside the group can be deployed to other locations.
 
-The previously illustrated example is a fairly basic scenario that shows how you can use management groups. Your organization might also consider implementing a _landing zone_, which is a set of Azure resources and configuration you need to get started with a production Azure environment. The _enterprise-scale landing zone_ is a proven approach to using management groups and subscriptions to effectively manage your Azure resources:
+The previously illustrated example is a fairly basic scenario that shows how you can use management groups. Your organization might also consider implementing a *landing zone*, which is a set of Azure resources and configuration you need to get started with a production Azure environment. The *enterprise-scale landing zone* is a proven approach to using management groups and subscriptions to effectively manage your Azure resources:
 
 :::image type="content" source="../media/2-hierarchy-eslz.png" alt-text="Diagram of an enterprise-scale landing-zone architecture, with four management groups and four subscriptions." border="false":::
 
-Whichever model you follow, by understanding the various levels of the hierarchy, you can start to apply flexible controls on how your Azure environment is used and managed. By using Bicep, you can manage these controls with all the benefits of infrastructure as code.
+Whichever model you follow, by understanding the various levels of the hierarchy you can start to apply flexible controls on how your Azure environment is used and managed. By using Bicep, you can manage these controls with all the benefits of infrastructure as code.
 
 > [!NOTE]
 > There are also some other resources that are deployed at specific scopes. *Extension resources* are deployed at the scope of another Azure resource. For example, a resource lock is an extension resource, which is deployed to a resource such as a storage account.
@@ -42,7 +42,7 @@ You might deploy resources to a management group when:
 - You need to grant access to all the resources within any subscriptions that fall under the management group hierarchy. For example, your cloud operations team might require access to every subscription in your organization. You can create a role assignment at your root management group, which grants your cloud operations team access to everything in Azure.
 
   > [!CAUTION]
-  > Be extremely careful when you grant access to resources by using management groups, and especially the root management group. Remember that every resource under the management group in the hierarchy inherits the role assignment. Make sure that your organization follows best practices for identity management and authentication, and that it follows the principle of least privilege; that is, don't grant any access that isn't required.
+  > Be extremely careful when you grant access to resources by using management groups, and especially the root management group. Remember that every resource under the management group in the hierarchy inherits the role assignment. Make sure that your organization follows best practices for identity management and authentication, and that it follows the principle of least privilege. That is, don't grant any access that isn't required.
 
 - You need to apply policies across your entire organization. For example, your organization might have a policy that resources can't be created in certain geographic regions, under any circumstances. You might apply a policy to your root management group that will block the creation of resources in that region.
 
@@ -58,7 +58,7 @@ You might deploy resources to your tenant when:
   > [!NOTE]
   > Not all Azure customers can create subscriptions by using infrastructure as code. Depending on your billing relationship with Microsoft, this might not be possible. For more information, see [Create Azure subscriptions programmatically](/azure/cost-management-billing/manage/programmatically-create-subscription).
 
-- You're creating or configuring management groups. Azure creates single root management group when you enable management groups for your tenant, and you can create multiple levels of management groups under it. You can use Bicep to define your whole management group hierarchy. You can also assign subscriptions to management groups.
+- You're creating or configuring management groups. Azure creates a single root management group when you enable management groups for your tenant, and you can create multiple levels of management groups under it. You can use Bicep to define your whole management group hierarchy. You can also assign subscriptions to management groups.
 
     With Bicep, you can submit deployments to the tenant scope. [Tenant-scoped deployments require special permission](/azure/azure-resource-manager/templates/deploy-to-tenant#required-access). However, in practice, you don't need to submit tenant-scoped deployments. It's simpler to instead deploy tenant-scoped resources by using a template at a different scope. You'll see how to do that later in this module.
 

learn-pr/azure/deploy-resources-scopes-bicep/includes/5-deploy-multiple-scopes.md

@@ -1,7 +1,7 @@
 Sometimes you need to deploy resources across multiple levels of your hierarchy from within one deployment. Here are some situations where you might want to do this:
 
 - You need to deploy resources across two different resource groups. For example, you might want to create a network security group in a shared resource group and also deploy a network interface for a virtual machine in a resource group for your application.
-- You're using a template to create a resource group, which is a subscription-scoped resource, and then want to deploy a storage account and other Azure resources to that resource group by using a resource group-scoped deployment.
+- You're using a template to create a resource group, which is a subscription-scoped resource. Then, you want to deploy a storage account and other Azure resources to that resource group by using a resource group-scoped deployment.
 - You're deploying a management group hierarchy and also want to deploy some subscriptions, which are tenant-scoped resources.
 
 With Bicep, you can create a deployment that works across a range of scopes by using the `scope` keyword.
@@ -10,7 +10,7 @@ With Bicep, you can create a deployment that works across a range of scopes by u
 
 ## Specify the scope for a module
 
-You can use Bicep modules to deploy a set of resources at a scope that's different from the `targetScope` specified in the file. Here's an example Bicep file that's deployed with a `targetScope` of a `subscription`, but uses a module to deploy some resources to a resource group:
+You can use Bicep modules to deploy a set of resources at a scope that's different from the `targetScope` specified in the file. Here's an example Bicep file that's deployed with a `targetScope` of a `subscription`, but it uses a module to deploy some resources to a resource group:
 
 :::code language="bicep" source="code/5-sub-scope-rg-module.bicep" highlight="1,4" :::
 
@@ -26,7 +26,7 @@ Notice that the `scope` property uses a Bicep function to help identify the scop
 
 A common use of scopes is to deploy resources across multiple resource groups. Although you can't set the `scope` property on most Azure resources, you can use modules to tell Bicep that a set of resources should be deployed to a different resource group.
 
-For example, you might want to create a single set of Bicep files that deploys a virtual network and its associated resources to a shared resource group named *ToyNetworking*, and then deploy a network interface to a different resource group. Here's what the Bicep file looks like:
+For example, you might want to create a single set of Bicep files that deploys a virtual network and its associated resources to a shared resource group named *ToyNetworking*. Then, you deploy a network interface to a different resource group. Here's what the Bicep file looks like:
 
 :::code language="bicep" source="code/5-multiple-rgs.bicep" highlight="2, 15" :::
 
@@ -73,7 +73,7 @@ Notice that this example uses `targetScope = 'managementGroup'` in the template
 
 ## Create a management group and subscription hierarchy
 
-Now you know how to deploy many different resources at a variety of scopes, and you know how to use Bicep modules and the `scope` keyword to deploy combinations of resources. Let's apply all this new knowledge to extending the management group hierarchy in the preceding example. Now, the hierarchy will also include a _subscription alias_, which is a tenant-scoped resource that creates a new Azure subscription:
+Now you know how to deploy many different resources at a variety of scopes, and you know how to use Bicep modules and the `scope` keyword to deploy combinations of resources. Let's apply all this new knowledge to extending the management group hierarchy in the preceding example. Now, the hierarchy will also include a *subscription alia*s, which is a tenant-scoped resource that creates a new Azure subscription:
 
 :::code language="bicep" source="code/5-create-mg-hierarchy.bicep" range="27-33" :::
 

learn-pr/azure/deploy-resources-scopes-bicep/includes/6-exercise-deploy-multiple-scopes-modules.md

@@ -1,9 +1,9 @@
 > [!NOTE]
 > This exercise requires an Azure subscription. If you don't already have one, you can get a [free subscription](https://azure.microsoft.com/free/?azure-portal=true).
 
-The R&D team has asked for your help to create a virtual network in the Project Teddybear subscription. You know you'll be helping the team with more subscriptions in the future, so you decide to extend your reusable Bicep template to deploy a virtual network for the team members to use. 
+The R&D team has asked for your help to create a virtual network in the Project Teddybear subscription. You know you'll be helping the team with more subscriptions in the future, so you decide to extend your reusable Bicep template to deploy a virtual network for the team members to use.
 
-In this exercise, you'll update the template that you started to build in the last exercise. 
+In this exercise, you'll update the template that you started to build in the last exercise.
 
 During the process, you'll: