How Should Administrators Plan Azure Resource Access for Developers and Operations Teams?

One of the most important Azure administration concepts is understanding that access should be designed around responsibility, scope and least privilege—not convenience. A common beginner mistake is giving developers or operations teams broad Contributor or Owner access at the subscription level simply because it makes development easier. Microsoft recommends granting only the access required to perform the job and limiting both roles and scopes. Think about access as three dimensions: WHO → WHAT → WHERE Who: Developer, operations engineer, security team, application identity, deployment pipeline. What: Read resources, deploy applications, manage configuration, restart services, manage networking, assign roles, etc. Where: Management group → Subscription → Resource Group → Resource. For example: Team Possible requirement Appropriate design consideration Developer Deploy application Limit deployment permissions to relevant resources/resource group Developer View logs Reader/monitoring permissions may be sufficient Operations Manage App Services Scope access to required resource groups Security/Admin Manage role assignments Privileged RBAC capability should be tightly controlled CI/CD pipeline Deploy application Use an appropriate service connection/identity rather than personal credentials The important lesson is that Contributor does not automatically mean “everything.” Azure RBAC permissions are evaluated at scopes, and permissions can be inherited from broader scopes. For example, a Contributor assignment at resource-group scope can allow management of resources within that resource group. A better enterprise model Imagine a company has: Development Subscription → Developers have broader access for experimentation. Test Subscription → Developers have controlled deployment access. Production Subscription → Developers generally don't receive unrestricted administrative access. Operations Team → Has operational permissions required for production management. Security Team → Controls privileged access and reviews role assignments. For production, you should also consider Microsoft Entra Privileged Identity Management (PIM) for privileged roles, and Microsoft specifically recommends limiting privileged administrator assignments and using PIM where appropriate. Another important practice is assigning roles to groups rather than individual users wherever practical. This makes access easier to manage when people join teams, change responsibilities or leave the organisation. Interview question to practise “Why shouldn't we simply give every developer Contributor access to the subscription?” A strong answer: “Because access should follow least privilege. Subscription-level Contributor is broader than many developers require and increases the potential blast radius of an accidental or compromised account. I would define access based on role, resource scope and responsibilities, and use more privileged access only where the job requires it.” That's the difference between knowing Azure RBAC and understanding Azure security architecture.