diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md
index f54759836..e426edd65 100644
--- a/src/pentesting-cloud/azure-security/az-basic-information/README.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md
@@ -212,38 +212,31 @@ Example:
- Grant the "User Administrator" role to regional IT staff, scoped to their region's AU.
- Outcome: Regional IT admins can manage user accounts within their region without affecting other regions.
-### Entra ID Roles
+### Entra ID Roles & Permissions
- In order to manage Entra ID there are some **built-in roles** that can be assigned to Entra ID principals to manage Entra ID
- Check the roles in [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
+ - Roles marked as **`PRIVILEGED`** by EntraID should be assigned with caution because as Microsoft explains [in the docs](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): Privileged role assignments can lead to elevation of privilege if not used in a secure and intended manner.
- The most privileged role is **Global Administrator**
-- In the Description of the role it’s possible to see its **granular permissions**
+- Roles group **granular permissions** and they ca be found in their descriptions.
+- It's possible to **create custom roles** with the desired permissions. Although for some reason not all the granular permissions are available for admins to create custom roles.
+- Roles in Entra ID are completely **independent** from roles in Azure. The only relation is that principals with the role **Global Administrator** in Entra ID can elevate to the **User Access Administrator** role in Azure.
+- It's **not possible to use wildcards** in Entra ID roles.
-## Roles & Permissions
+## Azure Roles & Permissions
-**Roles** are **assigned** to **principals** on a **scope**: `principal -[HAS ROLE]->(scope)`
-
-**Roles** assigned to **groups** are **inherited** by all the **members** of the group.
-
-Depending on the scope the role was assigned to, the **role** cold be **inherited** to **other resources** inside the scope container. For example, if a user A has a **role on the subscription**, he will have that **role on all the resource groups** inside the subscription and on **all the resources** inside the resource group.
-
-### Classic Roles
-| **Role** | Permissions/Capabilities | All resource types | Resource Scope |
-| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
-| **Owner** |
- Full access to all resources
- Can manage access for other users
| All resource types |
-| **Contributor** | - Full access to all resources
- Cannot manage access
| All resource types |
-| **Reader** | • View all resources | All resource types |
-| **User Access Administrator** | - View all resources
- Can manage access for other users
| All resource types |
+- **Roles** are **assigned** to **principals** on a **scope**: `principal -[HAS ROLE]->(scope)`
+- **Roles** assigned to **groups** are **inherited** by all the **members** of the group.
+- Depending on the scope the role was assigned to, the **role** cold be **inherited** to **other resources** inside the scope container. For example, if a user A has a **role on the subscription**, he will have that **role on all the resource groups** inside the subscription and on **all the resources** inside the resource group.
### Built-In roles
-[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) has several Azure **built-in roles** that you can **assign** to **users, groups, service principals, and managed identities**. Role assignments are the way you control **access to Azure resources**. If the built-in roles don't meet the specific needs of your organization, you can create your own [**Azure custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
+[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) has several Azure **built-in roles** that you can **assign** to **users, groups, service principals, and managed identities**. Role assignments are the way you control **access to Azure resources**. If the built-in roles don't meet the specific needs of your organization, you can create your own [**Azure custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles).
**Built-In** roles apply only to the **resources** they are **meant** to, for example check this 2 examples of **Built-In roles over Compute** resources:
-| Role | Description | Role Identifier |
-| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Provides permission to backup vault to perform disk backup. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
+| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
| [Virtual Machine User Login](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | View Virtual Machines in the portal and login as a regular user. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
This roles can **also be assigned over logic containers** (such as management groups, subscriptions and resource groups) and the principals affected will have them **over the resources inside those containers**.