Line edits3

Author: lootle1

learn-pr/azure/authenticate-azure-deployment-pipeline-service-principals/7-knowledge-check.yml

@@ -31,7 +31,7 @@ quiz:
       explanation: Although this will work, it's not a good practice to use a single service principal for all of your environments. Additionally, granting access to your tenant root management group will allow the service principal to modify resources anywhere in your Azure environment, which is unnecessarily permissive.
     - content: Create a single service principal and grant it access to each of the resource groups in the three subscriptions.
       isCorrect: false
-      explanation: Although this will work, it's not good practice to use a single service principal for all of your environments. At the very least, you should separate production and non-production environments by using two service principals, but a dedicated service principal for each environment is preferred.
+      explanation: Although this will work, it's not good practice to use a single service principal for all of your environments. At the very least, you should separate production and nonproduction environments by using two service principals, but a dedicated service principal for each environment is preferred.
     - content: Create three service principals, one per environment, and grant each access to a single resource group in the relevant subscription.
       isCorrect: true
       explanation: When you work with multiple environments, it's best to use dedicated service principals for each environment so that your pipeline can't accidentally change anything in another environment.

learn-pr/azure/authenticate-azure-deployment-pipeline-service-principals/includes/2-understand-service-principals.md

@@ -31,7 +31,7 @@ Microsoft Entra ID is the service that manages identities for Azure. Microsoft E
 
 A service principal is a type of account. It can sign in to Microsoft Entra ID, but there's no human to sign in and interact with the authentication process. Service principals don't have MFA or similar protections, because those require a person to do something to prove their identity.
 
-In Microsoft Entra ID, a service principal is identified by an _application ID_ and a credential. The application ID is a globally unique ID (GUID). For pipelines, the credential is usually a strong password called a _key_. Alternatively, you can use a _certificate_ as a credential.
+In Microsoft Entra ID, an _application ID_ and a credential identifies a service principal. The application ID is a globally unique ID (GUID). For pipelines, the credential is usually a strong password called a _key_. Alternatively, you can use a _certificate_ as a credential.
 
 ### Managed identities
 
@@ -68,7 +68,7 @@ You might see a few different terms in use when you work with service principals
 
 Service principals are a feature of Microsoft Entra ID. Microsoft Entra ID is a global identity service. Many companies use Microsoft Entra ID, and each company is called a _tenant_.
 
-Microsoft Entra ID has a concept of an _application_, which represents a system, piece of software, process, or some other non-human agent. You can think of a deployment pipeline as an application.
+Microsoft Entra ID has a concept of an _application_, which represents a system, piece of software, process, or some other nonhuman agent. You can think of a deployment pipeline as an application.
 
 In Microsoft Entra ID, applications can do many things that are beyond the scope of authentication and pipeline deployments. When you create an application and tell Microsoft Entra ID about it, you create an object called an _application registration_. An application registration represents the application in Microsoft Entra ID.
 

learn-pr/azure/authenticate-azure-deployment-pipeline-service-principals/includes/3-create-service-principal-key.md

@@ -39,7 +39,7 @@ When you create a service principal, you generally ask Azure to create a key at
 > [!NOTE]
 > Remember our earlier discussion about how service principals work? Keys are stored as part of the application registration object. If you open the Azure portal, look within the Microsoft Entra configuration, and then go to the application registrations. You can create and delete keys there too.
 
-Azure shows you the key when you create the service principal. This is the only time that Azure will ever show you the key. After that, you can't retrieve it anymore. It's important that you securely copy the key so you can use it when you configure your pipeline. Don't share the key by email or another non-secure means. If you lose a key, you must delete it and create a new one.
+Azure shows you the key when you create the service principal. This is the only time that Azure will ever show you the key. After that, you can't retrieve it anymore. It's important that you securely copy the key so you can use it when you configure your pipeline. Don't share the key by email or another nonsecure means. If you lose a key, you must delete it and create a new one.
 
 ## Manage service principals for Azure Pipelines
 
@@ -167,4 +167,4 @@ It's a good practice to document your service principals in a place that you and
 > - The permissions that it needs, and a clear justification for why it needs them.
 > - What its expected lifetime is.
 
-You should regularly audit your service principals to ensure that they're still being used and that the permissions they've been assigned are still correct.
+You should regularly audit your service principals to ensure that they're still in use and that the permissions they've been assigned are still correct.

learn-pr/azure/authenticate-azure-deployment-pipeline-service-principals/includes/5-grant-service-principal-access-azure.md

@@ -9,7 +9,7 @@ Until now, you've focused on what service principals are and how they can be use
 After Microsoft Entra ID has authenticated a service principal, the next question becomes: what can this service principal do? This is the concept of _authorization_. It's the responsibility of the Azure role-based access control (RBAC) system, sometimes called identity and access management (IAM). By using Azure RBAC, you can grant a service principal access to a specific resource group, subscription, or management group.
 
 > [!NOTE]
-> Everything you're doing here is using the Azure RBAC system to grant access to create and manage Azure resources, like your storage accounts, App Service plan, and virtual networks. Microsoft Entra ID also has its own role system, which is sometimes called _directory roles_. You use these roles to grant permissions for service principals to manage Microsoft Entra ID. This module doesn't discuss this subject in depth, but be aware that the term _role_ can be used for both situations in some documentation.
+> Here, everything you're doing is using the Azure RBAC system to grant access to create and manage Azure resources, like your storage accounts, App Service plan, and virtual networks. Microsoft Entra ID also has its own role system, which is sometimes called _directory roles_. You use these roles to grant permissions for service principals to manage Microsoft Entra ID. This module doesn't discuss this subject in depth, but be aware that the term _role_ can be used for both situations in some documentation.
 
 ## Select the right role assignment for your pipeline
 
@@ -65,7 +65,7 @@ You can create multiple role assignments that provide different permissions at d
 
 You likely work with multiple environments, like development, test, and production environments for your applications. The resources for each environment should be deployed to different resource groups or subscriptions.
 
-You should create separate service principals for each environment, and grant each service principal the minimum set of permissions that it needs for its deployments. Be especially careful to avoid mixing permissions for production deployments with those for deployments to non-production environments.
+You should create separate service principals for each environment, and grant each service principal the minimum set of permissions that it needs for its deployments. Be especially careful to avoid mixing permissions for production deployments with those for deployments to nonproduction environments.
 
 ## Create a role assignment for a service principal
 
@@ -135,7 +135,7 @@ You can also create a role assignment at the same time that you create a service
 
 ## Grant access using Bicep
 
-Role assignments are Azure resources. This means that you can create a role assignment by using Bicep. You might do this if you initialize your resource groups using Bicep, and then deploy the resources into the resource group using a service principal. Here's an example Bicep definition for the role assignment above:
+Role assignments are Azure resources. This means that you can create a role assignment by using Bicep. You might do this if you initialize your resource groups using Bicep, and then deploy the resources into the resource group using a service principal. Here's an example Bicep definition for the role assignment discussed:
 
 ```bicep
 resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {