Line edits2

Author: lootle1

learn-pr/azure/secure-your-azure-sql-database/6-knowledge-check.yml

@@ -24,7 +24,7 @@ quiz:
       isCorrect: false
     - content: A server-level virtual network rule
       isCorrect: true
-      explanation: A server-level virtual network rule will allow you to allow connectivity from specific Azure VNet subnets, and will block access from the internet. This is the most efficient manner to secure this configuration.
+      explanation: A server-level virtual network rule will allow you to allow connectivity from specific Azure VNet subnets and will block access from the internet. This is the most efficient manner to secure this configuration.
     - content: A database-level IP address rule
       isCorrect: false
 

learn-pr/azure/secure-your-azure-sql-database/includes/1-create-database.md

@@ -51,7 +51,7 @@ In this unit, you set up the resources that you use throughout this module. Envi
 
 ## Create and configure a Linux virtual machine
 
-Create the Linux VM that to use through some examples.
+Create the Linux VM to use through some examples.
 
 1. Run the following command to create the VM. This command might take several minutes to complete.
 

learn-pr/azure/secure-your-azure-sql-database/includes/2-restrict-network-access.md

@@ -14,7 +14,7 @@ Firewall rules are configured at the server or database level. The rules specifi
   - IP address rules
 
 > [!NOTE]
-> SQL Data Warehouse only supports server-level IP firewall rules, and not database-level IP firewall rules.
+> SQL Data Warehouse only supports server-level IP firewall rules and not database-level IP firewall rules.
 
 Take a closer look at how these rules work.
 
@@ -47,19 +47,19 @@ For server-level rules, all of these rules can be created and manipulated throug
 
 ### Database-level firewall rules
 
-These rules allow access to an individual database on a logical server and are stored in the database itself. For database-level rules, you can configure only **IP address rules**. They function the same as when applied at the server-level, but are scoped to the database only.
+These rules allow access to an individual database on a logical server and are stored in the database itself. For database-level rules, you can configure only **IP address rules**. They function the same as when applied at the server-level but are scoped to the database only.
 
 :::image type="content" source="../media/2-db-ip-rule-1.png" alt-text="Diagram represents a database IP address network rule.":::
 
-The benefits of database-level rules are their portability. When you replicate a database to another server, the database-level rules are replicated, since they're stored in the database itself.
+The benefits of database-level rules are their portability. When you replicate a database to another server, the database-level rules are replicated since they're stored in the database itself.
 
 The downside to database-level rules is that you can only use IP address rules. These rules might limit the flexibility you have and can increase administrative overhead.
 
 Database-level firewall rules can be created and manipulated only through T-SQL.
 
 ## Restrict network access in practice
 
-As a best practice, use database-level IP firewall rules to enhance security and to make your database more portable. Use server-level IP firewall rules for administrators and when you have several databases with the same access requirements so that you don't want to spend time configuring each database individually.
+As a best practice, use database-level IP firewall rules to enhance security and to make your database more portable. Use server-level IP firewall rules for administrators and when you have several databases with the same access requirements. This way you don't spend time configuring each database individually.
 
 Take a look at how these rules work in practice, and how you can secure network access to only allow what is necessary. Recall that you created an Azure SQL Database logical server, a database, and the _appServer_ Linux VM that acts as an application server. This scenario is often seen when a database has been migrated to Azure SQL Database and resources inside of a virtual network need to access it. The firewall feature of Azure SQL Database can be used in many scenarios, but this example has practical applicability and demonstrates how each of the rules functions.
 
@@ -97,7 +97,7 @@ Because your VM has outbound internet access, you can use the **Allow access to
 
 1. In the **Search resources, services, and docs** box at the top, search for your database server name, `server-name`. Select the SQL server.
 
-1. In the SQL server pane, in the left menu pane, under **Security**, select **Networking**.
+1. In the SQL server pane, in the left menu pane under **Security**, select **Networking**.
 
 1. Scroll down to **Exceptions**, select the checkbox for **Allow Azure services and resources to access this server**, and then select **Save**. Wait until the system acknowledges this change.
 
@@ -168,7 +168,7 @@ Use a server-level IP rule to restrict the systems that can connect.
 
     After the command completes, enter `exit` to exit sqlcmd. Remain connected over SSH.
 
-1. Back in the Azure portal, on the **Networking** pane for your SQL server, under **Firewall rules**, select **add a firewall rule**. Name the rule **Allow appServer**, enter the public IP address of the _appServer_ VM for the **Start IP** and **End IP**, and then select **OK**.
+1. Back in the Azure portal, on the **Networking** pane for your SQL server under **Firewall rules**, select **Add a firewall rule**. Name the rule **Allow appServer**, enter the public IP address of the _appServer_ VM for the **Start IP** and **End IP**, and then select **OK**.
 
 1. Select **Save**.
 
@@ -207,7 +207,7 @@ In this case, because your VM is running in Azure, you can use a server-level vi
     | **Virtual network**              | appServerVNET                            |
     | **Subnet name / Address prefix** | appServerSubnet / 10.0.0.0/24            |
 
-1. Select **Enable** to enable the service endpoint on the subnet, then select **OK** after the endpoint is enabled to create the rule.
+1. Select **Enable** to enable the service endpoint on the subnet, and then select **OK** after the endpoint is enabled to create the rule.
 
 1. Remove the IP address rule. Select the **...** next to your **Allow appServer** rule, select **Delete**, and then select **Save**.
 

learn-pr/azure/secure-your-azure-sql-database/includes/3-manage-authentication.md

@@ -1,18 +1,18 @@
-Even though you might be able to connect to the database over the network that doesn't mean you can actually gain access to the data itself. Following a layered approach, you want to ensure that only users who need access to the data can actually access it. This access is where authentication and authorization come in to play.
+Even though you might be able to connect to the database over the network, that doesn't mean you can actually gain access to the data itself. Following a layered approach, you want to ensure that only users who need access to the data can actually access it. This access is where authentication and authorization come in to play.
 
 ## Authentication
 
-Authentication is the process of verifying an identity. This identity could be a user, a service that runs on a system, or a system itself, such as a virtual machine. Through the process of authentication, you ensure that the person or system is who they claim to be. SQL Database supports two types of authentication: _SQL authentication_ and _Microsoft Entra authentication_.
+Authentication is the process of verifying an identity. This identity could be a user, a service that runs on a system, or a system itself like a virtual machine. Through the process of authentication, you ensure that the person or system is who they claim to be. SQL Database supports two types of authentication: _SQL authentication_ and _Microsoft Entra authentication_.
 
 ### SQL authentication
 
-The SQL authentication method uses a username and password. User accounts can be created in the main database and can be granted permissions in all databases on the server. You can also create users in the database itself, called contained users, and give them access to only that database. When you created the logical server for your database, you specified a _server admin_ sign-in with a username and password. Using these credentials, you can authenticate to any database on that server as the database owner, or _dbo_.
+The SQL authentication method uses a username and password. User accounts can be created in the main database and can be granted permissions in all databases on the server. You can also create users in the database itself, called contained users, and give them access to only that database. When you created the logical server for your database, you specified a _server admin_ sign-in with a username and password. Using these credentials, you can authenticate to any database on that server as the database owner or _dbo_.
 
 <a name='azure-active-directory-authentication'></a>
 
 ### Microsoft Entra authentication
 
-This authentication method uses identities managed by Microsoft Entra ID and is supported for managed and integrated domains. Use Microsoft Entra authentication (integrated security) whenever possible. With Microsoft Entra authentication, you can manage the identities of database users and other Microsoft services in one central location. Central ID management provides a single place to manage database users and simplifies permission management. If you want to use Microsoft Entra authentication, you must create another server administrator called the *Microsoft Entra admin*, which is allowed to administer Microsoft Entra users and groups. This admin can also perform all operations that a regular server admin can.
+This authentication method uses identities managed by Microsoft Entra ID and is supported for managed and integrated domains. Use Microsoft Entra authentication (integrated security) whenever possible. With Microsoft Entra authentication, you can manage the identities of database users and other Microsoft services in one central location. Central ID management provides a single place to manage database users and simplifies permission management. If you want to use Microsoft Entra authentication, you must create another server administrator called the _Microsoft Entra admin_, which is allowed to administer Microsoft Entra users and groups. This admin can also perform all operations that a regular server admin can.
 
 ## Authorization
 
@@ -38,7 +38,7 @@ Create a new user that you can use to grant access to.
     sqlcmd -S tcp:[server-name].database.windows.net,1433 -d marketplaceDb -U '[username]' -P '[password]' -N -l 30
     ```
 
-1. Run the following command to create a new user. This user is a _contained user_ that has only allow access to the _marketplace_ database. Feel free to adjust the password as necessary, but be sure and note it because you need it for a future step.
+1. Run the following command to create a new user. This user is a _contained user_ that only has allow access to the _marketplace_ database. Feel free to adjust the password as necessary, but be sure and note it because you need it for a future step.
 
     ```sql
     CREATE USER ApplicationUser WITH PASSWORD = 'YourStrongPassword1';
@@ -66,11 +66,11 @@ Make the user a member of the `db_datareader` and `db_datawriter` roles, grantin
     GO
     ```
 
-Now sign in as that user and take a look at this configuration in action.
+Now sign in as that user, and take a look at this configuration in action.
 
 1. While still at the T-SQL prompt, enter `exit` to exit your session.
 
-1. Now sign back in to the database, but as the user you created.
+1. Now sign back in to the database but as the user you created.
 
     ```bash
     sqlcmd -S tcp:[server-name].database.windows.net,1433 -d marketplaceDb -U 'ApplicationUser' -P '[password]' -N -l 30

learn-pr/azure/secure-your-azure-sql-database/includes/4-data-security.md

@@ -16,7 +16,7 @@ Take a look in the Azure portal at where TDE is configured on your _marketplaceD
 
 1. In the search bar at the top of the Azure portal, search for **marketplaceDb**, then select the database.
 
-1. In the left menu pane, under **Security**, select **Data encryption**.
+1. In the left menu pane under **Security**, select **Data encryption**.
 
 1. In the data encryption option, verify that **Data encryption** is set to **On**. You should also see an encryption status of **Encrypted**.
 
@@ -31,13 +31,13 @@ You might notice that when you ran your query in the previous unit that some of
 
 Maybe you don't want your users to be able to see the full phone number or email address, but you still want to make a portion of the data available for customer service representatives to identify a customer. By using the dynamic data masking feature of Azure SQL Database, you can limit the data that is displayed to the user. Dynamic data masking is a policy-based security feature that hides the sensitive data in the result set of a query over designated database fields, while the data in the database isn't changed.
 
-Data masking rules consist of the column to apply the mask to, and how the data should be masked. You can create your own masking format, or use one of the standard masks, such as:
+Data masking rules consist of the column to apply the mask to and how the data should be masked. You can create your own masking format, or use one of the standard masks, such as:
 
-- Default value, which displays the default value for that data type instead.
-- Credit card value, which only shows the last four digits of the number, converting all other numbers to lower case x's.
-- Email, which hides the domain name and all but the first character of the email account name.
-- Number, which specifies a random number between a range of values. For example, on the credit card expiry month and year, you could select random months from 1 to 12 and set the year range from 2018 to 3000.
-- Custom string, which allows you to set the number of characters exposed from the start of the data, the number of characters exposed from the end of the data, and the characters to repeat for the remainder of the data.
+- **Default value**: Displays the default value for that data type instead.
+- **Credit card value**: Only shows the last four digits of the number, converting all other numbers to lower case x's.
+- **Email**: Hides the domain name and all but the first character of the email account name.
+- **Number**: Specifies a random number between a range of values. For example, on the credit card expiry month and year, you could select random months from 1 to 12 and set the year range from 2018 to 3000.
+- **Custom string**: Allows you to set the number of characters exposed from the start of the data, the number of characters exposed from the end of the data, and the characters to repeat for the remainder of the data.
 
 When database administrators query the columns, they still see the original values. Nonadministrators see the masked values. You can allow other users to see the nonmasked versions by adding them to the SQL users excluded from masking list.