An organization is configuring access permissions for its tier-1 IT support staff in Azure. The support staff must be able to view all resource configurations across an Azure subscription and open technical support tickets with Microsoft. However, corporate security policy dictates that the support staff must not have permissions to create, modify, or delete resources, nor manage user access assignments. The standard Azure built-in roles do not provide this exact combination of permissions. Which solution should the organization implement to meet these requirements while adhering to the principle of least privilege?

Create and assign an Azure RBAC custom role with read permissions and support ticket actions: ### What Azure Custom Roles Are An **Azure custom role** is a user-defined role definition in **Azure Role-Based Access Control (Azure RBAC)** that provides tailored access control when the pre-configured **Azure built-in roles** do not match organizational requirements. ### How It Meets the Requirements - **Meets visibility requirement**: Incorporates the `*/read` action, allowing support engineers to view all resource configurations across the subscription. - **Meets support ticket requirement**: Includes `Microsoft.Support/*` actions, granting the ability to create, update, and manage support tickets with Microsoft. - **Enforces security constraints**: Excludes write and delete actions on Azure infrastructure resources, ensuring staff cannot modify or delete assets. - **Maintains least privilege**: Prevents unauthorized role assignments and access governance changes. ### Key Advantages and Capabilities - **Granular permission control**: Specific allowed operations (`Actions`) and restricted operations (`NotActions`) can be precisely tailored. - **Flexible assignable scopes**: Can be assigned at the **management group**, **subscription**, or **resource group** level. - **Multi-tool deployment**: Can be created and maintained using the **Azure portal**, **Azure CLI**, **Azure PowerShell**, or **ARM templates** via JSON definitions. - **Security compliance**: Aligns with organizational compliance standards by eliminating unnecessary administrative privileges. ### Why This Is Optimal When no single built-in role (such as **Owner**, **Contributor**, or **Reader**) provides the exact balance of required operational actions without granting excess permissions, authoring an **Azure custom role** is the recommended and architecturally correct approach.