updates

Author: JulianePadrao

.openpublishing.redirection.json

@@ -187,6 +187,10 @@
       "source_path_from_root": "/learn-pr/wwl/monitor-fabric-items/8-summary.yml",
       "redirect_url": "/training/modules/monitor-fabric-items/7-summary"
     },
+    {
+      "source_path_from_root": "/learn-pr/wwl-data-ai/configure-database-authentication-authorization/2-describe-active-directory.yml",
+      "redirect_url": "/training/modules/configure-database-authentication-authorization/"
+    },
     {
       "source_path_from_root": "/learn-pr/wwl-data-ai/query-data-warehouse-microsoft-fabric/2-use-sql-query-editor.yml",
       "redirect_url": "/training/modules/query-data-warehouse-microsoft-fabric/"

learn-pr/wwl-data-ai/configure-database-authentication-authorization/8-knowledge-check.yml

@@ -22,55 +22,55 @@ quiz:
     choices:
     - content: "Kerberos"
       isCorrect: false
-      explanation: "That's incorrect. Microsoft Entra ID uses HTTPS protocols like SAML and OpenID Connect for authentication and uses OAuth for authorization."
+      explanation: "Incorrect. Microsoft Entra ID uses HTTPS protocols like SAML and OpenID Connect for authentication and uses OAuth for authorization."
     - content: "LDAP"
       isCorrect: false
-      explanation: "That's incorrect. Microsoft Entra ID uses HTTPS protocols like SAML and OpenID Connect for authentication and uses OAuth for authorization."
+      explanation: "Incorrect. Microsoft Entra ID uses HTTPS protocols like SAML and OpenID Connect for authentication and uses OAuth for authorization."
     - content: "OAuth"
       isCorrect: true
-      explanation: "That's correct. Microsoft Entra ID uses HTTPS protocols like SAML and OpenID Connect for authentication and uses OAuth for authorization."
+      explanation: "Correct. Microsoft Entra ID uses HTTPS protocols like SAML and OpenID Connect for authentication and uses OAuth for authorization."
   - content: "Which database stores the information about logins in SQL Server?"
     choices:
     - content: "master"
       isCorrect: true
-      explanation: "That's correct. Logins are stored in the master database."
+      explanation: "Correct. Logins are stored in the master database."
     - content: "model"
       isCorrect: false
-      explanation: "That's incorrect. The model database doesn't store any user or job information."
+      explanation: "Incorrect. The `model` database doesn't store any user or job information."
     - content: "msdb"
       isCorrect: false
-      explanation: "That's incorrect. The MSDB database stores data related to the SQL Server Agent."
+      explanation: "Incorrect. The `msdb` database stores data related to the SQL Server Agent."
   - content: "Which role allows users to create users within a database?"
     choices:
     - content: "db_datareader"
       isCorrect: false
-      explanation: "That's incorrect. This role only allows users to read all of the data in a given database, but not write any data."
+      explanation: "Incorrect. This role only allows users to read all of the data in a given database, but not write any data."
     - content: "db_accessadmin"
       isCorrect: true
-      explanation: "That's correct. Access admin can add users to the database and create them."
+      explanation: "Correct. Access admin can add users to the database and create them."
     - content: "db_securityadmin"
       isCorrect: false
-      explanation: "That's incorrect. The security admin role is privileged, but can't create logins and users."
+      explanation: "Incorrect. The security admin role is privileged, but can't create logins and users."
   - content: "Which permission allows the user to perform any option against a database object?"
     choices:
     - content: "Control"
       isCorrect: true
-      explanation: "That's correct. Control allows the user to drop or modify an object."
+      explanation: "Correct. Control allows the user to drop or modify an object."
     - content: "Delete"
       isCorrect: false
-      explanation: "That's incorrect. The delete permission only allows for deletion of data in a table."
+      explanation: "Incorrect. The `DELETE` permission only allows for deletion of data in a table."
     - content: "View Definition"
       isCorrect: false
-      explanation: "That's incorrect. View definition only allows the user to see the DDL for the object."
+      explanation: "Incorrect. View definition only allows the user to see the DDL for the object."
   - content: "What feature allows a user to execute a stored procedure without having permission to access the tables referenced in the stored procedure?"
     choices:
     - content: "Ownership chaining"
       isCorrect: true
-      explanation: "That's correct. Ownership chaining effectively gives the user temporary access to the objects called by the procedure."
+      explanation: "Correct. Ownership chaining effectively gives the user temporary access to the objects called by the procedure."
     - content: "Principle of least privilege"
       isCorrect: false
-      explanation: "That's incorrect. The principle of least privilege is a concept and not a functional action."
+      explanation: "Incorrect. The principle of least privilege is a concept and not a functional action."
     - content: "Granular security"
       isCorrect: false
-      explanation: "That's incorrect. Granular security would involve granting access to the procedure, but not actual manage the privileges."
+      explanation: "Incorrect. Granular security would involve granting access to the procedure, but not actual manage the privileges."
 

learn-pr/wwl-data-ai/configure-database-authentication-authorization/includes/1-introduction.md

@@ -1,10 +1,10 @@
 Azure SQL offerings provide several authentication and authorization options that differ from those in SQL Server. This is because Azure SQL Database and Azure SQL Managed Instance rely on Microsoft Entra ID instead of Windows Server Active Directory.
 
-This module explores best practices for granting permissions and the various permissions available within a database. It also delves into the concept of *least privilege*. While built-in roles in SQL Server and other database engines offer broad security privileges, many applications require more granular security on database objects.
+You'll explore the best practices for granting permissions and the various permissions available within a database. It also delves into the concept of *least privilege*. While built-in roles in SQL Server and other database engines offer broad security privileges, many applications require more granular security on database objects.
 
 ## Learning objectives
 
-In this module you will learn about:
+In this module you'll learn about:
 
 - Explain authentication options for Azure SQL offerings
 - Describe security principals

learn-pr/wwl-data-ai/configure-database-authentication-authorization/includes/3-describe-authentication-identities.md

@@ -4,15 +4,15 @@ Microsoft Entra ID authentication is more secure and simplifies user management.
 
 Azure SQL Database also supports SQL Server authentication and Microsoft Entra authentication. Microsoft Entra authentication uses the same credentials for other resources like the Azure portal or Microsoft 365.
 
-Microsoft Entra ID can sync with on-premises Active Directory, providing consistent credentials for both environments. It also supports multi-factor authentication (MFA) for added security. MFA options include push notifications via the Microsoft Authenticator app, text messages, or access codes. Users with MFA must use the Universal Authentication with MFA option in SQL Server Management Studio.
+Microsoft Entra ID can sync with on-premises Active Directory, providing consistent credentials for both environments. It also supports multifactor authentication (MFA) for added security. MFA options include push notifications via the Microsoft Authenticator app, text messages, or access codes. Users with MFA must use the Universal Authentication with MFA option in SQL Server Management Studio.
 
 You can set SQL admin permissions on an Azure SQL Database using the Azure portal.
 
 :::image type="content" source="../media/module-33-security-final-02.png" alt-text="Screenshot showing how to set admin permissions on a SQL Database.":::
 
-It is a best practice to make this account a Microsoft Entra group, so access is not dependent on a single login. The Microsoft Entra admin account grants special permissions and allows the account or group that holds that permission to have `sysadmin` like access to the server and all of the databases within the server. The admin account is only set using Azure Resource Manager and not at the database level. In order to change the account or group, you have to use the Azure portal, PowerShell, or Azure CLI.
+It's a best practice to make this account a Microsoft Entra group, so access isn't dependent on a single login. The Microsoft Entra admin account grants special permissions and allows the account or group that holds that permission to have `sysadmin` like access to the server and all of the databases within the server. The admin account is only set using Azure Resource Manager and not at the database level. In order to change the account or group, you have to use the Azure portal, PowerShell, or Azure CLI.
 
-## Role-based access control
+## Role-based access control (RBAC)
 
 All Azure types of operations for Azure SQL Database are controlled through role-based access control (RBAC). RBAC is currently decoupled from Azure SQL security, but you can think of it as security rights outside of your database in SQL Database, with a scope that includes subscription, resource group, and resource. The rights apply to operations in the Azure portal, the Azure CLI, and Azure PowerShell. RBAC allows for separation of duties between deployment, management, and usage.
 

learn-pr/wwl-data-ai/configure-database-authentication-authorization/includes/4-describe-security-principals.md

@@ -1,31 +1,29 @@
 Security principals are entities that can request SQL Server resources and to which you can (usually) grant permissions. There are several sets of security principals in SQL Server. Security principals exist at either the server level or the database level and can be either individuals or collections. Some sets have a membership controlled by the SQL Server administrators, and some have a fixed membership.
 
-At the database level, we’ll look at users, database roles, application roles.
-
  > [!NOTE]
- >New logins can be added by administrators on Azure SQL Database, but new server roles cannot be created.
+ >New logins can be added by administrators on Azure SQL Database, but new server roles can't be created.
 
 ## Schemas and securables
 
 Before we look at the details of security principals, we need to understand the concepts of securables and schemas. SQL Server and Azure SQL Database have three scopes for securables. Securables are the resources within the database to which the authorization system manages access. For example, a table is a securable. To simplify access control, SQL Server contains securables in nested hierarchies called scopes. The three securable scopes are the server, the database, and the schema. A schema is a collection of objects within your database, which allows objects to be grouped into separate namespaces.
 
-Every user has a default schema. If a user tries to access an object without specifying a schema name, as in: `SELECT name FROM customers`, it's assumed the object is in the user’s default schema. If there's no such object in the default schema, SQL Server will check to see if the object is in the pre-defined dbo schema. If there's no object of the specified name in either the user’s default schema, or in the dbo schema, the user will receive an error message. It's considered best practice to always specify the schema name when accessing objects, so the previous select would be something like:
+Every user has a default schema. If a user tries to access an object without specifying a schema name, as in: `SELECT name FROM customers`, it's assumed the object is in the user’s default schema. If there's no such object in the default schema, SQL Server checks to see if the object is in the predefined dbo schema. If there's no object of the specified name in either the user’s default schema, or in the dbo schema, the user receives an error message. It's a best practice to specify the schema name when accessing objects, so the previous select would be something like:
 `SELECT name FROM SalesSchema.customers`. If a user hasn't been given a default schema, their default schema is set to dbo.
 
-By default, if no schema is specified when a user creates an object, SQL Server will attempt to create it in the user’s default schema. If the user hasn't been granted permission to create objects in their default schema, the object can't be created.
+By default, if no schema is specified when a user creates an object, SQL Server attempts to create it in the user’s default schema. If the user hasn't been granted permission to create objects in their default schema, the object can't be created.
 
 ## Logins and users
 
-No matter the mode of authentication that is used, a login name used to access your SQL database is set up as a login within the instance. Those logins are set up at the instance level of SQL Server and stored in the master database. However, you can configure contained users, which are added at the database level. These users can be configured as SQL Server Authentication users as well as either Windows Authentication users or Microsoft Entra users (depending on which platform you're using). In order to create these users, the database must be configured for partial containment, which is configured by default in Azure SQL Database, and optionally configurable in SQL Server.
+No matter the mode of authentication that is used, a login name used to access your SQL database is set up as a login within the instance. Those logins are set up at the instance level of SQL Server and stored in the master database. However, you can configure contained users, which are added at the database level. These users can be configured as SQL Server Authentication users and either Windows Authentication users or Microsoft Entra users (depending on which platform you're using). In order to create these users, the database must be configured for partial containment, which is configured by default in Azure SQL Database, and optionally configurable in SQL Server.
 
-These users only have access to the database that the user is set up with. For the purposes of Azure SQL Database, it's considered a best practice to create users at the scope of the user database, and not in the master database as shown below.
+These users only have access to the database that the user is set up with. For the purposes of Azure SQL Database, it's a best practice to create users at the scope of the user database, and not in the master database.
 
 ```sql
 CREATE USER [dba@contoso.com] FROM EXTERNAL PROVIDER;
 GO
 ```
 
-The `CREATE USER` statement is executed in the context of the user database. In the example above, the user is a Microsoft Entra user as indicated with the `FROM EXTERNAL PROVIDER` syntax.
+The `CREATE USER` statement is executed in the context of the user database. In the example, the user is a Microsoft Entra user as indicated with the `FROM EXTERNAL PROVIDER` syntax.
 
 If logins are created at the instance level in SQL Server, a user should then be created within the database, which maps the user to the server-based login as shown in the following example.
 
@@ -53,7 +51,7 @@ As you can imagine, database security can get complicated for applications with
 
 SQL Server and Azure SQL Database both include built-in roles that are defined by Microsoft, and also provide the option to create custom roles. Custom roles can be created at the server or database level. However, server roles can't be granted access to objects within a database directly. Server roles are only available in SQL Server and Azure SQL Managed Instance, not in Azure SQL Database.
 
-Within a database, permissions can be granted to the users that exist within the database. If multiple users all need the same permissions, you can create a database role within the database and grant the needed permissions to this role. Users can be added as members of the database role. The members of the database role will inherit the permissions of the database role.
+Within a database, permissions can be granted to the users that exist within the database. If multiple users all need the same permissions, you can create a database role within the database and grant the needed permissions to this role. Users can be added as members of the database role. The member of the database role inherits the permissions of the database role.
 
 ```sql
 CREATE USER [DP300User1] WITH PASSWORD = 'Pa55.w.rd'
@@ -79,11 +77,11 @@ In the above example, you can see that two users are created, and then a role ca
 
 ## Application roles
 
-Application roles can also be created within a SQL Server database or Azure SQL Database. Unlike database roles, users aren't made members of an application role. An application role is activated by the user, by supplying the pre-configured password for the application role. Once the role is activated the permissions that are applied to the application role are applied to the user until that role is deactivated.
+Application roles can also be created within a SQL Server database or Azure SQL Database. Unlike database roles, users aren't made members of an application role. An application role is activated by the user, by supplying the preconfigured password for the application role. Once the role is activated the permissions that are applied to the application role are applied to the user until that role is deactivated.
 
 ## Built-in database roles
 
-Microsoft SQL Server contains several fixed database roles within each database for which the permissions are predefined. Users can be added as members of one or more roles. These roles give their members a pre-defined set of permissions. These roles work the same within Azure SQL Database and SQL Server.
+Microsoft SQL Server contains several fixed database roles within each database for which the permissions are predefined. Users can be added as members of one or more roles. These roles give their members a predefined set of permissions. These roles work the same within Azure SQL Database and SQL Server.
 
 | Database role | Definition |
 |------------|-------------|