Fixing grammar, typos and organization.

Author: LuizMacedo

Instructions/Labs/AZ400_M01_Agile_Planning_and_Portfolio_Management_with_Azure_Boards.md

@@ -16,7 +16,7 @@ lab:
 
 ## Lab overview
 
-In this lab, you will learn about the agile planning and portfolio management tools and processes provided by Azure Boards and how they can help you quickly plan, manage, and track work across your entire team. You will explore the product backlog, sprint backlog, and task boards which can be used to track the flow of work during the course of an iteration. We will also take a look at how the tools have been enhanced in this release to scale for larger teams and organizations.
+In this lab, you'll learn about the agile planning and portfolio management tools and processes provided by Azure Boards and how they can help you quickly plan, manage, and track work across your entire team. You'll explore the product backlog, sprint backlog, and task boards that can track the flow of work during an iteration. We'll also look at the enhanced tools in this release to scale for larger teams and organizations.
 
 ## Objectives
 

Instructions/Labs/AZ400_M01_Version_Controlling_with_Git_in_Azure_Repos.md

@@ -20,24 +20,24 @@ lab:
 
 ## Lab overview
 
-Azure DevOps supports two types of version control, Git and Team Foundation Version Control (TFVC). Here is a quick overview of the two version control systems:
+Azure DevOps supports two types of version control, Git and Team Foundation Version Control (TFVC). Here's a quick overview of the two version control systems:
 
 - **Team Foundation Version Control (TFVC)**: TFVC is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server.
 
-- **Git**: Git is a distributed version control system. Git repositories can live locally (such as on a developer's machine). Each developer has a copy of the source repository on their dev machine. Developers can commit each set of changes on their dev machine and perform version control operations such as history and compare without a network connection.
+- **Git**: Git is a distributed version control system. Git repositories can live locally (on a developer's machine). Each developer has a copy of the source repository on their dev machine. Developers can commit each set of changes on their dev machine and perform version control operations such as history and compare without a network connection.
 
-Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC.
+Git is the default version control provider for new projects. You should use Git for version control in your projects unless you need centralized version control features in TFVC.
 
-In this lab, you will learn how to establish a local Git repository, which can easily be synchronized with a centralized Git repository in Azure DevOps. In addition, you will learn about Git branching and merging support. You will use Visual Studio Code, but the same processes apply for using any Git-compatible client.
+In this lab, you'll learn to establish a local Git repository, which can easily be synchronized with a centralized Git repository in Azure DevOps. In addition, you'll learn about Git branching and merging support. You'll use Visual Studio Code, but the same processes apply to using any Git-compatible client.
 
 ## Objectives
 
 After you complete this lab, you will be able to:
 
-- Clone an existing repository
-- Save work with commits
-- Review history of changes
-- Work with branches by using Visual Studio Code
+- Clone an existing repository.
+- Save work with commits.
+- Review history of changes.
+- Work with branches by using Visual Studio Code.
 
 ## Estimated timing: 50 minutes
 

Instructions/Labs/AZ400_M02_Version_Controlling_with_Git_in_Azure_Repos.md

@@ -20,22 +20,22 @@ lab:
 
 ## Lab overview
 
-Azure DevOps supports two types of version control, Git and Team Foundation Version Control (TFVC). Here is a quick overview of the two version control systems:
+Azure DevOps supports two types of version control, Git and Team Foundation Version Control (TFVC). Here's a quick overview of the two version control systems:
 
 - **Team Foundation Version Control (TFVC)**: TFVC is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server.
 
-- **Git**: Git is a distributed version control system. Git repositories can live locally (such as on a developer's machine). Each developer has a copy of the source repository on their dev machine. Developers can commit each set of changes on their dev machine and perform version control operations such as history and compare without a network connection.
+- **Git**: Git is a distributed version control system. Git repositories can live locally (on a developer's machine). Each developer has a copy of the source repository on their dev machine. Developers can commit each set of changes on their dev machine and perform version control operations such as history and compare without a network connection.
 
-Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC.
+Git is the default version control provider for new projects. You should use Git for version control in your projects unless you need centralized version control features in TFVC.
 
-In this lab, you will learn how to work with branches and repositories in Azure DevOps.
+You'll learn how to work with branches and repositories in Azure DevOps in this lab.
 
 ## Objectives
 
 After you complete this lab, you will be able to:
 
-- Work with branches in Azure Repos
-- Work with repositories in Azure Repos
+- Work with branches in Azure Repos.
+- Work with repositories in Azure Repos.
 
 ## Estimated timing: 30 minutes
 

Instructions/Labs/AZ400_M03_Configuring_Agent_Pools_and_Understanding_Pipeline_Styles.md

@@ -30,8 +30,8 @@ In this lab, you'll step through converting a classic pipeline into a YAML-based
 
 After you complete this lab, you will be able to:
 
-- Implement YAML-based pipelines
-- Implement self-hosted agents
+- Implement YAML-based pipelines.
+- Implement self-hosted agents.
 
 ## Estimated timing: 45 minutes
 

Instructions/Labs/AZ400_M03_Deploying_Docker_containers_to_Azure_App_Service_web_apps.md

@@ -26,9 +26,9 @@ In this lab, you will learn how to use an Azure DevOps CI/CD pipeline to build a
 
 After you complete this lab, you will be able to:
 
-- Build a custom Docker image by using an Microsoft hosted Linux agent
-- Push an image to Azure Container Registry
-- Deploy a Docker image as a container to Azure App Service by using Azure DevOps
+- Build a custom Docker image by using an Microsoft hosted Linux agent.
+- Push an image to Azure Container Registry.
+- Deploy a Docker image as a container to Azure App Service by using Azure DevOps.
 
 ## Estimated timing: 60 minutes
 
@@ -129,7 +129,7 @@ In this task, you will use Azure Cloud Shell to create Azure resources required
 
     >**Note**: Record the values of **Registry name** and **Login server** (the registry names and the admin user name should match). You will need them later in this lab.
 
-### Exercise 2: Deploy a Docker container to Azure App Service web app by using Azure DevOps
+### Exercise 2: Deploy a Docker container to Azure App Service web app using Azure DevOps
 
 In this exercise, you will deploy a Docker container to Azure App Service web app by using Azure DevOps.
 

Instructions/Labs/AZ400_M03_Enabling_Continuous_Integration_with_Azure_Pipelines.md

@@ -16,15 +16,15 @@ lab:
 
 ## Lab overview
 
-In this lab, you will learn how to configure continuous integration (CI) and continuous deployment (CD) for your applications using Build and Release in Azure Pipelines. This scriptable CI/CD system is both web-based and cross-platform, while also providing a modern interface for visualizing sophisticated workflows. Although we won’t demonstrate all of the cross-platform possibilities in this lab, it is important to point out that you can also build for iOS, Android, Java (using Ant, Maven, or Gradle) and Linux.
+This lab will teach you how to configure continuous integration (CI) and continuous deployment (CD) for your applications using Build and Release in Azure Pipelines. This scriptable CI/CD system is web-based and cross-platform while also providing a modern interface for visualizing sophisticated workflows. Although we won’t demonstrate all of the cross-platform possibilities in this lab, it's essential to point out that you can also build for iOS, Android, Java (using Ant, Maven, or Gradle), and Linux.
 
 ## Objectives
 
 After you complete this lab, you will be able to:
 
-- Create a basic build pipeline from a template
-- Track and review a build
-- Invoke a continuous integration build
+- Create a basic build pipeline from a template.
+- Track and review a build.
+- Invoke a continuous integration build.
 
 ## Estimated timing: 45 minutes
 

Instructions/Labs/AZ400_M03_Implementing_GitHub_Actions_by_using_DevOps_Starter.md

@@ -20,20 +20,20 @@ lab:
 
 ## Lab overview
 
-In this lab, you will learn how to implement a GitHub Action workflow that deploys an Azure web app by using DevOps Starter.
+In this lab, you'll learn how to implement a GitHub Action workflow that deploys an Azure web app using DevOps Starter.
 
 ## Objectives
 
 After you complete this lab, you will be able to:
 
-- Implement a GitHub Action workflow by using DevOps Starter
-- Explain the basic characteristics of GitHub Action workflows
+- Implement a GitHub Action workflow by using DevOps Starter.
+- Explain the basic characteristics of GitHub Action workflows.
 
 ## Estimated timing: 30 minutes
 
 ## Instructions
 
-### Exercise 1 : Create a DevOps Starter project
+### Exercise 1: Create a DevOps Starter project
 
 In this exercise, you will use DevOps Starter to facilitate provisioning of a number of resources, including:
 

Instructions/Labs/AZ400_M03_Integrating_External_Source_Control_with_Azure_Pipelines.md

@@ -14,22 +14,22 @@ lab:
 
 - **Set up an Azure DevOps organization:** If you don't already have an Azure DevOps organization that you can use for this lab, create one by following the instructions available at [Create an organization or project collection](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/create-organization?view=azure-devops).
 
-- If you don't already have a GitHub account that you can use for this lab, follow instructions available at [Signing up for a new GitHub account](https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/signing-up-for-a-new-github-account).
+- If you don't already have a GitHub account that you can use for this lab, follow instructions available at [Signing up for a new GitHub account](https://docs.github.com/get-started/signing-up-for-github/signing-up-for-a-new-github-account).
 
 ## Lab overview
 
-With the introduction of Azure DevOps, Microsoft is offering developers a new continuous integration/continuous delivery (CI/CD) service called Azure Pipelines that enables you to continuously build, test, and deploy to any platform or cloud. It has cloud-hosted agents for Linux, macOS, and Windows; powerful workflows with native container support; and flexible deployments to Kubernetes, VMs, and serverless environments.
+With the introduction of Azure DevOps, Microsoft offers developers a new continuous integration/continuous delivery (CI/CD) service called Azure Pipelines that enables you to build continuously, test, and deploy to any platform or cloud. It has cloud-hosted agents for Linux, macOS, and Windows; powerful workflows with native container support; and flexible deployments to Kubernetes, VMs, and serverless environments.
 
-Azure Pipelines provides unlimited CI/CD minutes and 10 parallel jobs to every GitHub open source project for free. All open source projects run on the same infrastructure that our paying customers use. That means you’ll have the same fast performance and high quality of service. Many of the top open source projects are already using Azure Pipelines for CI/CD, such as Atom, CPython, Pipenv, Tox, Visual Studio Code, and TypeScript-and the list is growing every day.
+Azure Pipelines provides unlimited CI/CD minutes and 10 parallel jobs to every GitHub open source project for free. All open source projects run on the same infrastructure that our paying customers to use. That means you’ll have the same fast performance and high quality of service. Many of the top open source projects are already using Azure Pipelines for CI/CD, such as Atom, CPython, Pipenv, Tox, Visual Studio Code, and TypeScript-and the list is growing every day.
 
-In this lab, you’ll see how easy it is to set up Azure Pipelines with your GitHub projects and how you can start seeing benefits immediately.
+In this lab, you’ll see how easy it's to set up Azure Pipelines with your GitHub projects and how you can start seeing benefits immediately.
 
 ## Objectives
 
 After you complete this lab, you will be able to:
 
 - Install Azure Pipelines from the GitHub Marketplace.
-- Integrate a GitHub project with an Azure DevOps pipeline.
+- Integrate a GitHub project with an Azure Pipeline.
 - Track pull requests through the pipeline.
 
 ## Estimated timing: 60 minutes

Instructions/Labs/AZ400_M04_Controlling_Deployments_using_Release_Gates.md

@@ -20,33 +20,33 @@ lab:
 
 ## Lab overview
 
-This lab covers the configuration of the deployment gates and details how to use them to control execution of Azure pipelines. To illustrate their implementation, you will configure a release definition with two environments for an Azure Web App. You will deploy to the Canary environment only when there are no blocking bugs for the app and mark the Canary environment complete only when there are no active alerts in Application Insights of Azure Monitor.
+This lab covers the configuration of the deployment gates and details how to use them to control the execution of Azure Pipelines. To illustrate their implementation, you'll configure a release definition with two environments for an Azure Web App. You'll deploy to the Canary environment only when there are no blocking bugs for the app and mark the Canary environment complete only when there are no active alerts in Application Insights of Azure Monitor.
 
-A release pipeline specifies the end-to-end release process for an application to be deployed across a range of environments. Deployments to each environment are fully automated by using jobs and tasks. Ideally, you do not want new updates to the applications to be exposed to all the users at the same time. It is a best practice to expose updates in a phased manner i.e. expose to a subset of users, monitor their usage and expose to other users based on the experience of the initial set of users.
+A release pipeline specifies the end-to-end release process for an application to be deployed across various environments. Deployments to each environment are fully automated by using jobs and tasks. Ideally, you don't want new updates to the applications to be simultaneously exposed to all the users. It's a best practice to expose updates in a phased manner, that is, expose them to a subset of users, monitor their usage, and expose them to other users based on the experience of the initial set of users.
 
-Approvals and gates enable you to take control over the start and completion of the deployments in a release. With approvals, you can wait for users to manually approve or reject deployments. Using release gates, you can specify application health criteria that must be met before release is promoted to the next environment. Prior to or after any environment deployment, all the specified gates are automatically evaluated until they all pass or until they reach your defined timeout period and fail.
+Approvals and gates enable you to take control over the start and completion of the deployments in a release. You can wait for users to approve or reject deployments with approvals manually. Using release gates, you can specify application health criteria to be met before the release is promoted to the following environment. Before or after any environment deployment, all the specified gates are automatically evaluated until they pass or reach your defined timeout period and fail.
 
 Gates can be added to an environment in the release definition from the pre-deployment conditions or the post-deployment conditions panel. Multiple gates can be added to the environment conditions to ensure all the inputs are successful for the release.
 
 As an example:
 
-- Pre-deployment gates ensure there are no active issues in the work item or problem management system before deploying a build to an environment.
-- Post-deployment gates ensure there are no incidents from the monitoring or incident management system for the app after it’s been deployed, before promoting the release to the next environment.
+- Pre-deployment gates ensure no active issues in the work item or problem management system before deploying a build to an environment.
+- Post-deployment gates ensure no incidents from the app's monitoring or incident management system after being deployed before promoting the release to the following environment.
 
 There are 4 types of gates included by default in every account.
 
-- Invoke Azure Function: Triggers execution of an Azure Function and ensures a successful completion.
-- Query Azure Monitor alerts: Observes the configured Azure Monitor alert rules for active alerts.
-- Invoke REST API: Makes a call to a REST API and continues if it returns a successful response.
-- Query work items: Ensures the number of matching work items returned from a query is within a threshold.
+- Invoke Azure Function: Trigger the execution of an Azure Function and ensures a successful completion.
+- Query Azure Monitor alerts: Observe the configured Azure Monitor alert rules for active alerts.
+- Invoke REST API: Make a call to a REST API and continues if it returns a successful response.
+- Query work items: Ensure the number of matching work items returned from a query is within a threshold.
 
 ## Objectives
 
 After you complete this lab, you will be able to:
 
-- Configure release pipelines
-- Configure release gates
-- Test release gates
+- Configure release pipelines.
+- Configure release gates.
+- Test release gates.
 
 ## Estimated timing: 75 minutes
 
@@ -164,7 +164,7 @@ In this task, you will create two Azure web apps representing the **Canary** and
 
     > **Note**: You can create multiple alert rules on different metrics such as availability < 99 percent, server response time > 5 Seconds, or server exceptions > 0
 
-### Exercise 1: Configure release pipeline
+### Exercise 1: Configure the release pipeline
 
 In this exercise, you will configure a release pipeline.
 

Instructions/Labs/AZ400_M04_Creating_a_Release_Dashboard.md

@@ -20,16 +20,16 @@ lab:
 
 ## Lab overview
 
-In this lab, you will step through creation of a release dashboard and the use of REST API to retrieve Azure DevOps release data, which you can make this way available to your custom applications or dashboards.
+In this lab, you'll step through creating a release dashboard and using REST API to retrieve Azure DevOps release data, which you can make available to your custom applications or dashboards.
 
-The lab leverages the Azure DevOps Starter resource, which automatically creates an Azure DevOps project that builds and deploys an application into Azure.
+The lab uses the Azure DevOps Starter resource, which automatically creates an Azure DevOps project that builds and deploys an application into Azure.
 
 ## Objectives
 
 After you complete this lab, you will be able to:
 
-- create a release dashboard
-- use REST API to query release information
+- Create a release dashboard.
+- Use REST API to query release information.
 
 ## Estimated timing: 45 minutes