edits

Author: v-albemi

learn-pr/azure/test-bicep-code-using-azure-pipelines/includes/1-introduction.md

@@ -2,7 +2,7 @@ When you automate your Bicep deployments by using Azure Pipelines, you create a
 
 In this module, you'll learn how to extend your pipeline to add validation, checks, and tests. By implementing verifications, you build confidence that your deployments meet your quality standards.
 
-## Example scenario
+## Module scenario
 
 Suppose you're the Azure administrator at a toy company. You're working with your website team to create a Bicep template that deploys and configures the Azure resources for your company's main website. You're also creating a pipeline to deploy the Bicep file automatically.
 

learn-pr/azure/test-bicep-code-using-azure-pipelines/includes/2-understand-pipeline-stages.md

@@ -6,13 +6,13 @@ _Stages_ help you to divide your pipeline into multiple logical blocks. Each sta
 
 :::image type="content" source="../media/2-stages.png" alt-text="Diagram that shows a pipeline with a stage containing one job. The job contains four steps." border="false":::
 
-You can use stages in your pipeline to mark a separation of concerns. For example, when you work with Bicep code, _validating_ the code is a separate concern from _deploying_ your Bicep file. When you use an automated pipeline, building and testing your code are often called _continuous integration_ (CI). Deploying code in an automated pipeline is often called _continuous deployment_ (CD).
+You can use stages in your pipeline to mark a separation of concerns. For example, when you work with Bicep code, validating the code is a separate concern from deploying your Bicep file. When you use an automated pipeline, building and testing your code are often called _continuous integration_ (CI). Deploying code in an automated pipeline is often called _continuous deployment_ (CD).
 
 During CI stages, you check the validity of the changes that have been made to your code. CI stages provide quality assurance. You can run them without affecting your live production environment.
 
 In many programming languages, code needs to be _built_ before someone can run it. When a Bicep file is deployed, it's converted, or _transpiled_, from Bicep to JSON. The tooling performs this process automatically. In most situations, you don't need to manually build Bicep code to JSON templates in your pipeline. We still use the term _continuous integration_ when we talk about Bicep code, though, because the other parts of CI still apply, such as validating your code.
 
-After your CI stages run successfully, you should have increased your confidence that the changes you made will also deploy successfully. During CD stages, you deploy your code to each of your environments. You usually start with test and other nonproduction environments and move through to production environments. In this module, you'll deploy to a single environment. In a future module, you'll learn how to extend your deployment pipeline to deploy to multiple environments, such as nonproduction and production environments.
+After your CI stages run successfully, you should have increased your confidence that the changes you made will also deploy successfully. During CD stages, you deploy your code to each of your environments. You usually start with test and other nonproduction environments and then continue to production environments. In this module, you'll deploy to a single environment. In a future module, you'll learn how to extend your deployment pipeline to deploy to multiple environments, such as nonproduction and production environments.
 
 Stages run in a sequence. You can control how and when each stage runs. For example, you can configure your CD stages to run only after your CI stages run successfully. Or you might have multiple CI stages that need to run in sequence, for example, to build your code and then test it. You might also include a _rollback_ stage that runs only if previous deployment stages fail.
 

learn-pr/azure/test-bicep-code-using-azure-pipelines/includes/3-lint-validate-bicep-code.md

@@ -2,7 +2,7 @@ Now that you know what pipeline stages are for, let's consider the first set of
 
 ## What's a valid Bicep file?
 
-A valid Bicep file is one that doesn't contain any syntax errors. Also, the definitions for the Azure resources that you plan to deploy must be valid. And when the resources defined in the file are deployed, they stay within the quotas and limits that exist in your Azure subscription.
+A valid Bicep file is one that doesn't contain any syntax errors. Also, the definitions for the Azure resources that you plan to deploy must be valid. And when the resources defined in the file are deployed, they must stay within the quotas and limits that exist in your Azure subscription.
 
 Some of the checks are performed on your Bicep file in isolation, like the checks for syntax errors, for valid Azure resource definitions, and for code quality. These steps are part of a process called _linting_. To check for other problems, you need to request that the Azure Resource Manager service validates your template and takes your Azure environment into account.
 
@@ -20,9 +20,7 @@ A linter contains a predefined set of rules for each of these categories. Exampl
 - **String interpolation**. The linter checks if your file uses the `concat()` function instead of Bicep string interpolation. String interpolation makes your Bicep files more readable.
 - **Default values for secure parameters**. The linter warns you if you set default values for parameters that are marked with the `@secure()` decorator. A default value for a secure parameter is a bad practice because it gives the secure parameter a human-readable value, and people might not change it before deployment.
 
-The Bicep linter runs automatically when you use the Bicep tooling. Every time you build a Bicep file, the linter checks it against its best practices. Linting happens automatically when you deploy a Bicep file to Azure.
-
-But in a pipeline, you typically want to run the validation and linting steps before you deploy the file. You can configure Bicep to verify your file by manually building the Bicep file via the Bicep CLI:
+The Bicep linter runs automatically when you use the Bicep tooling. Every time you build a Bicep file, the linter checks it against its best practices. Linting happens automatically when you deploy a Bicep file to Azure. But in a pipeline, you typically want to run the validation and linting steps before you deploy the file. You can configure Bicep to verify your file by manually building the Bicep file via the Bicep CLI:
 
 ::: zone pivot="cli"
 
@@ -53,7 +51,7 @@ You can express this addition in your pipeline YAML file like this:
 
 ### Linter warnings and errors
 
-By default, the linter emits a warning when it discovers that a Bicep file has violated a rule. Warnings that the Bicep linter emits aren't treated as an error, so they won't stop the pipeline run or stop subsequent stages from running.
+By default, the linter emits a warning when it discovers that a Bicep file has violated a rule. Warnings that the Bicep linter emits aren't treated as errors, so they won't stop the pipeline run or stop subsequent stages from running.
 
 You can change this behavior by configuring Bicep to treat the linter rule violations as errors instead of warnings. You do this configuration by adding a _bicepconfig.json_ file to the folder that contains your Bicep file. You can decide which linter issues should be treated as errors and which should remain as warnings. You'll see how to update linter rules later in this module.
 

learn-pr/azure/test-bicep-code-using-azure-pipelines/includes/4-exercise-set-up-environment.md

@@ -23,7 +23,7 @@ The modules in this learning path are part of a progression. Each module has an
 
 Run a template that sets up your Azure DevOps organization.
 
-1. [Get and run the ADOGenerator project](https://github.com/microsoft/AzDevOpsDemoGenerator/blob/main/docs/RunApplication.md) in Visual Studio or the IDE of your choice.
+1. [Get and run the ADOGenerator project](https://github.com/microsoft/AzDevOpsDemoGenerator/blob/main/docs/RunApplication.md) in Visual Studio or another IDE.
 
 1. When you're asked whether you want to create a new template or use the demo generator, enter **1** and then select **Enter**.
 
@@ -36,9 +36,9 @@ Run a template that sets up your Azure DevOps organization.
 
 1. Enter your Azure DevOps organization name, and then select **Enter**.
 
-1. If prompted, enter your Azure DevOps PAT, then select **Enter**.
+1. If prompted, enter your Azure DevOps PAT, and then select **Enter**.
 
-1. Enter a project name such as *toy-website-test*, then select **Enter**.
+1. Enter a project name, such as **toy-website-test**, and then select **Enter**.
 
 1. After your project is created, go to your Azure DevOps organization in your browser (at `https://dev.azure.com/<your-organization-name>/`) and select the project.
 1. In Azure DevOps, [Create a self-hosted agent](/azure/devops/pipelines/agents/windows-agent) in the Default pool.
@@ -51,7 +51,7 @@ If you haven't already, create a fork of the **mslearn-test-bicep-code-using-git
 
 1. Select **Fork** at the top-right of the screen.
 
-1. Choose your GitHub account as the **Owner**, then select **Create fork**.
+1. Choose your GitHub account as the **Owner**, and then select **Create fork**.
 
 ## Clone the repository
 

learn-pr/azure/test-bicep-code-using-azure-pipelines/includes/5-exercise-add-lint-validate-stages-pipeline.md

@@ -112,7 +112,7 @@ Now that you've identified the problem, you can fix it in your Bicep file.
 
 1. In Visual Studio Code, open the _main.bicep_ file in the _deploy_ folder.
 
-1. Notice that the Bicep linter has also detected that the `storageAccountNameParam` parameter isn't used. Visual Studio Code indicates the unused parameter with a wavy line. Normally, the line would be yellow to indicate a warning. But because you customized the _bicepconfig.json_ file, the linter treats the code as an error and displays the line in red. Here's the line:
+1. Notice that the Bicep linter has also detected that the `storageAccountNameParam` parameter isn't used. Visual Studio Code indicates the unused parameter with a wavy line. Normally, the line would be yellow to indicate a warning. But because you customized the _bicepconfig.json_ file, the linter treats the code as an error and displays the line in red. Here's the line of code:
 
    :::code language="bicep" source="code/5-template-1.bicep" range="15" :::
 
@@ -132,7 +132,7 @@ Now that you've identified the problem, you can fix it in your Bicep file.
 
 ## View the pipeline run again
 
-1. In your browser, go to your pipeline.
+1. In Azure DevOps, go to your pipeline.
 
 1. Select the most recent run.
 
@@ -182,7 +182,7 @@ You found another problem in the Bicep file. Here, you'll fix the problem.
 
 ## View the successful pipeline run
 
-1. In your browser, go to your pipeline.
+1. In Azure DevOps, go to your pipeline.
 
 1. Select the most recent run.
 

learn-pr/azure/test-bicep-code-using-azure-pipelines/includes/6-preview-approve-deployment.md

@@ -61,10 +61,10 @@ Checks and approvals are evaluated just before a pipeline stage begins. When Azu
 
 An approval is one type of check. When you configure an approval check, you assign one or more reviewers who need to approve the continuation of the pipeline.
 
-Azure Pipelines also provides other types of checks. For example, you can call an API to run custom logic, control the business hours during which a stage can run, and even query Azure Monitor to ensure that a deployment succeeded. Only approval checks are discussed in this module, but links are provided to more information about checks in the summary.
+Azure Pipelines also provides other types of checks. For example, you can call an API to run custom logic, control the business hours during which a stage can run, and even query Azure Monitor to ensure that a deployment succeeded. Only approval checks are discussed in this module, but the module summary includes links to more information about checks.
 
 > [!NOTE]
-> Agent pools and service connections can also have checks configured on them. You can also use a special step called a manual approval task. However, this module focuses on environments and the checks associated with them.
+> Agent pools and service connections can also have checks configured on them. You can also use a special step called a *manual approval task*. However, this module focuses on environments and the checks associated with them.
 
 After your pipeline begins and reaches a stage that requires an approval check, the pipeline run pauses. All reviewers who have been designated as approvers are sent a message in Azure DevOps and by email.
 

learn-pr/azure/test-bicep-code-using-azure-pipelines/includes/7-exercise-add-preview-stage-pipeline.md

@@ -23,7 +23,7 @@ First, you'll add a new stage to your pipeline that runs the what-if operation.
 
 ## Add an environment
 
-1. In your browser, go to **Pipelines** > **Environments**.
+1. In Azure DevOps, go to **Pipelines** > **Environments**.
 
    :::image type="content" source="../media/7-environments.png" alt-text="Screenshot of the Azure DevOps interface that shows the Environments item on the Pipelines menu.":::
 
@@ -33,7 +33,7 @@ First, you'll add a new stage to your pipeline that runs the what-if operation.
 
 1. Enter **Website** as the environment name.
 
-   Leave the description blank. For **Resource**, select **None**.
+   Leave the description blank. In the **Resource** section, select **None**.
 
    > [!NOTE]
    > In Azure Pipelines, environments are used to enable deployment features. Some of these features apply only when you're deploying to Kubernetes or to virtual machines. In this module, you won't use these features and you can ignore them.
@@ -52,7 +52,7 @@ First, you'll add a new stage to your pipeline that runs the what-if operation.
 
    :::image type="content" source="../media/7-add-check-approval.png" alt-text="Screenshot of the Azure DevOps interface that shows the page for adding a check. The Approvals item is highlighted.":::
 
-1. In the **Approvers** box, type your own name and select yourself.
+1. In the **Approvers** box, enter your own name and select yourself.
 
 1. Expand the **Advanced** section by selecting the down arrow.