Understanding Azure Permissions: A Practical Guide
A clear and actionable breakdown of Azure RBAC roles, scopes, and the permissions required for real-world cloud operations.
Introduction.
Understanding who can do what in Azure is one of the most common pain points for businesses adopting or scaling their cloud infrastructure. Assigning permissions might appear straightforward—until a user with “Contributor” access cannot assign a role, deploy a service, or view cost data.
These types of roadblocks are especially common when developers, DevOps engineers, or IT support teams are expected to build or manage infrastructure but lack the necessary access.
This guide was written to remove the guesswork. It covers the fundamentals of Azure Role-Based Access Control (RBAC), explains the purpose and limitations of common built-in roles, and maps those roles to specific operational tasks.
Whether you're managing SQL resources, deploying Function Apps, configuring managed identities, or setting policies, this article will help you understand the exact permissions needed—and the best way to assign them securely.
By the end of this guide, you should be able to:
Confidently determine which Azure role is required for a given task
Avoid the pitfalls of over- or under-provisioning access
Support technical users with the correct access model from the outset
This article is ideal for IT service providers, internal support teams, and cloud engineers who want to align autonomy with governance in Azure.
Azure RBAC Explained.
Azure Role-Based Access Control (RBAC) is Microsoft’s native system for managing access to Azure resources. It allows organisations to grant users only the permissions they need to perform specific tasks, and nothing more—supporting the principle of least privilege.
Each role assignment in Azure consists of three parts:
Security Principal: The user, group, or service principal being granted access.
Role Definition: A predefined or custom set of permissions (e.g. Reader, Contributor, Owner).
Scope: The level at which the permissions apply—this can be a subscription, resource group, or specific resource.
Understanding this model is essential to managing Azure securely and effectively. A user might have the right role but at the wrong scope, leading to frustrating permission errors.
Key Built-in Roles (and What They Actually Do).
Microsoft Azure includes a long list of built-in roles, but for most practical cases, the following are the most relevant:
| Role | What it allows | Can assign roles? |
| Reader | View resources only | No |
| Contributor | Create and manage resources (excluding IAM) | No |
| Owner | Full access to all resources, including IAM | Yes |
| User Access Administrator | Assign RBAC roles to others | Yes |
| Key Vault Administrator | Managed secrets, keys, certificates, and policies | No |
| Application Administrator | Manage app registrations and enterprise apps | No |
| Managed Identity Contributor | Create and assign managed identities to resources | No |
| Cost Management Contributor | View and manage budget and cost alerts | No |
| Policy Contributor | Create and assign Azure Policies | No |
Note: Assigning a role at a higher scope (e.g. subscription) gives access to everything underneath it (e.g. all resource groups and resources).
Common Microsoft Azure Tasks & The Roles Required.
The following sections explain what roles are needed for common Azure administration tasks, including those frequently encountered in service desk escalations and infrastructure deployments.
1.1 Creating and managing resource groups.
| Task | Required role | Scope |
| Create, rename, or delete resource groups | Contributor | Subscription |
| Deploy resources into a group | Contributor | Resource Group |
| Assign permissions within a group | Contributor + User Access Administrator or Owner | Resource Group |
A common mistake is assuming Contributor alone allows IAM changes. It does not.
1.2 Creating and managing Azure subscriptions.
Azure subscription management takes place largely outside the Azure portal, often via the Microsoft 365 admin centre or Azure EA/partner portals.
| Task | Required role | Where Set |
| Create or rename a subscription | Global Administrator or Billing Administrator | Microsoft 365 Admin Portal |
| View and manage resources inside a subscription | Contributor or Owner | Azure Portal |
| Assign roles within the subscription | Owner or User Access Admin | Azure Portal |
You cannot create new Azure subscriptions directly from the Azure portal without billing permissions in Microsoft 365.
1.3 Budget and Cost Monitoring
| Task | Required role | Scope |
| View cost reports | Reader or Cost Management Reader | Subscription |
| Create budgets and alerts | Cost Management Contributor | Subscription |
| Manage cost recommendations and advisor settings | Cost Management Contributor | Subscription |
The Contributor role alone does not allow access to cost tools unless explicitly granted.
1.4 Managing App Registrations and Service Principals
Azure Active Directory (Entra ID) governs identity-related actions. Roles assigned in the Azure portal alone are insufficient for app registration control.
| Task | Required role | Scope |
| Create and manage app registrations | Application Administrator | Entra ID |
| Grant permissions to apps | Application Administrator | Entra ID |
| Manage Enterprise Applications | Application Administrator | Entra ID |
| Assign roles to service principals in Azure | User Access Administrator or Owner | Azure Resource Scope |
1.5 Deploying Secure Workloads with Managed Identities
Managed Identities allow services to authenticate securely without passwords or connection strings.
| Task | Required role | Scope |
| Enable managed identity on resources | Contributor | Resource |
| Assign roles to managed identities | User Access Administrator | Target resource |
| Allow function apps or VMs to use managed identity | Contributor | Function App or VM |
| Create or manage identity role bindings (e.g. Key Vault) | Managed Identity Contributor | Vault or resource |
1.6 Azure SQL Servers and Databases
Azure SQL requires both RBAC and SQL-specific permissions. Some access must be configured within SQL itself.
| Task | Required role | Scope |
| Deploy SQL servers and DBs | Contributor | Resource Group |
| Configure networking, firewall rules | Contributor | SQL Server |
| Enable Azure AD authentication | SQL Active Directory Admin | SQL Server |
| Grant database access via Entra ID | SQL Admin (internal) + Entra roles | SQL Server / Entra ID |
1.7 Key Vaults and Secrets
Key Vault is highly secured. Access must be explicitly granted, regardless of Contributor rights.
| Task | Required role | Scope |
| Create and delete Key Vaults | Contributor | Resource Group |
| View or modify secrets | Key Vault Reader or Key Vault Administrator | Key Vault |
| Assign access to identities | Key Vault Administrator | Key Vault |
| Link Vaults with apps securely | Contributor (on app) + Role assignment on Vault | App and Key Vault |
1.8 Azure Function Apps and Automation Workloads
| Task | Required role | Scope |
| Create or delete Function Apps | Contributor | Resource Group |
| Assign identity for automation | Contributor | Function App |
| Connect app to Key Vault securely | Contributor + User Access Admin (on Vault) | App + Vault |
| Deploy from GitHub using managed identity | Application Admin (Entra) + Contributor | Azure and Entra |
1.9 Creating and Applying Azure Policy
Policy allows organisations to enforce compliance controls across resources.
| Task | Required role | Scope |
| Create custom policies | Policy Contributor | Subscription or Management Group |
| Assign initiatives (policy sets) | Policy Contributor or Owner | Subscription |
| View policy compliance | Reader or Policy Reader | Subscription or below |
A Contributor cannot create or assign policies unless explicitly granted the Policy Contributor role.
Summary: Suggested Role Set For A Cloud Engineer.
For someone building and managing Azure infrastructure autonomously (e.g. a DevOps or Lead Software Engineer), the following roles should be considered:
| Scope | Recommended roles |
| Subscription | Owner or Contributor + User Access Administrator |
| Entra ID | Application Administrator |
| Key Vaults | Key Vault Administrator |
| Budgets & Costs | Cost Management Contributor |
| SQL Servers | Contributor + SQL AD Admin (set in SQL) |
| Function Apps | Contributor |
| Automation & Identity | Managed Identity Contributor |
| Policy Management | Policy Contributor |
If autonomy must be balanced with oversight, use Privileged Identity Management (PIM) to grant time-limited access to elevated roles.
Custom Roles & Security Groups In Azure.
In some scenarios, the built-in roles provided by Microsoft do not precisely match the requirements of your organisation. For example, you may want to grant a user the ability to manage storage accounts but not virtual networks, or allow access to Cost Management tools without exposing billing settings.
1.1 Custom Roles.
Custom roles allow you to define a permission set tailored to your organisation’s needs. They are created using Azure Resource Manager and consist of a list of allowed actions, denied actions, and the scope to which they apply.
| Use case | Example |
| A developer needs to manage Function Apps but not delete them | Create a custom role without Microsoft.Web/sites/delete |
| An auditor needs read-only access to all resources plus cost data | Base the role on Reader + add Microsoft.CostManagement/*/read |
| A third party should manage storage but not modify networking or IAM | Grant storage actions only, and deny network/IAM actions |
Custom roles require planning and testing but can significantly reduce over-permissioning.
Learn more: Create or update Azure custom roles
1.2 Security Groups for Role Assignments.
Rather than assigning roles directly to individuals, it is best practice to assign RBAC roles to Microsoft Entra security groups. This offers several advantages:
Scalability: Assign a role once to the group, and it applies to all members.
Audibility: Easily see who inherits access via group membership.
Lifecycle management: Use Entra dynamic groups or HR-connected provisioning to manage group population.
| Group type | Use case |
| Static security group | “Cloud Engineers - UK” with direct membership |
| Dynamic group | “All users with job title = ‘Software Engineer’” |
| Nested group | For complex structures (e.g. team leads, contractors) |
Security groups can be used both in Azure RBAC and Entra roles (e.g. Application Administrator), making them a key part of scalable access control.
Tip: Assigning roles to groups makes permissions easier to audit and rotate when staff change roles.
Final Thoughts.
Azure permissions are powerful, but when misconfigured, either by selecting the wrong role or applying it at the wrong scope, they can introduce serious barriers to progress.
Poorly assigned access can delay deployments, create security gaps, undermine governance, and prevent critical infrastructure from being managed effectively.
Avoid defaulting to "Contributor" or "Owner" for all users. Instead, use targeted combinations of roles like Contributor + User Access Administrator, Application Administrator, and Key Vault Administrator to provide operational access without compromising governance.
As teams scale, consider formalising a permissions baseline per role (e.g. Developer, DevOps, Analyst), and use Azure PIM to support just-in-time access for high-risk actions.
