In the complex ecosystem of Microsoft Azure, governance and security are not merely optional features; they are the foundational requirements for any enterprise-scale deployment. For an organization such as Tailwind Traders, managing a vast array of resources—ranging from global virtual machine clusters to centralized databases—demands a disciplined approach to administration. This article provides a comprehensive, exam-aligned deep dive into Managing Azure Subscriptions and RBAC, designed specifically to help AZ-104 candidates master the structures and logic required to secure the cloud.
The ability to control who can do what, and where they can do it, is central to the role of an Azure Administrator. Improper configuration of these boundaries does not just lead to administrative clutter; it creates significant security risks and billing runaway. By understanding subscriptions as boundaries and Role-Based Access Control (RBAC) as the enforcement mechanism, you can implement a “Zero Trust” environment that scales with the business.
The Identity Provider: Microsoft Entra ID
Before managing access, an architect must understand where identities originate. Microsoft Entra ID (formerly Azure Active Directory) is the centralized identity provider for Azure. It serves as the tenant-level directory where users, groups, and applications are defined. However, a common point of confusion for those new to the platform is the relationship between the directory and the subscription.
While Entra ID manages identities, it does not automatically grant those identities permission to Azure resources. Permissions are granted through a trust relationship: an Azure subscription “trusts” an Entra ID tenant to verify the identity of the users trying to access its resources.
Authentication vs. Authorization
To master Azure IAM (Identity and Access Management), one must distinguish between these two fundamental processes:
- Authentication (AuthN): This is the act of proving identity. When a Tailwind Traders employee logs in using their corporate email and a Multi-Factor Authentication (MFA) prompt, they are performing authentication. Entra ID confirms they are indeed who they say they are.
- Authorization (AuthZ): Once authenticated, authorization determines what the user can do. Does this user have permission to restart a server? Can they delete a storage account? This is where RBAC is applied.
Entra ID Roles vs. Azure RBAC Roles
Another critical distinction is between Entra ID Roles and Azure RBAC Roles.
- Entra ID Roles (like Global Administrator or User Administrator) control access to the directory itself—managing users, resetting passwords, or configuring domain names.
- Azure RBAC Roles (like Owner, Contributor, or Reader) control access to Azure resources within a subscription.
Even a Global Administrator in Entra ID does not have access to the data inside a subscription’s virtual machines unless they specifically “Elevate Access” to manage Azure subscriptions, a practice that should be reserved for emergency “break-glass” scenarios.
Azure Subscriptions: The Governance Boundary
An Azure subscription is more than just a way to pay for services; it is a critical logical container that serves two primary purposes:
- Billing Boundary: Subscriptions allow organizations to generate separate billing reports and invoices. Tailwind Traders might use separate subscriptions for “Production,” “Development,” and “Testing” to ensure that the costs of experimental projects do not blend into the operational budget of the main business.
- Access Boundary: Subscriptions define the limit of administrative reach. By default, an administrator in the “Development” subscription has no visibility or control over the “Production” subscription. This isolation prevents cross-environment accidents and limits the “blast radius” if an account is compromised.
The Azure Scope Hierarchy and Inheritance
To manage access at scale, Azure uses a hierarchical structure. Permissions are additive and follow a top-down inheritance model.
The Four Levels of Scope
- Management Groups: These are containers that help you manage access, policy, and compliance for multiple subscriptions.
- Use Case: Tailwind Traders uses a “Production” Management Group to apply a policy that mandates all resources must be deployed in the “East US” region across five different subscriptions.
- Subscriptions: As discussed, these are the primary containers for resources and billing.
- Resource Groups: These are logical folders where you place resources that share a common lifecycle.
- Use Case: Grouping a Web App, its SQL Database, and its App Service Plan together so that when the project is finished, the entire group can be deleted at once.
- Resources: These are the individual service instances, such as a Storage Account or a Virtual Network.
The Power of Inheritance
The most vital rule to remember for the AZ-104 exam is that permissions are inherited. If you assign the “Reader” role to a user at the Subscription level, that user is a Reader for every Resource Group and every individual Resource within that subscription. Access cannot be “denied” further down the chain; it can only be granted. This is why scoping at the Resource Group level is considered a best practice for most administrative tasks.
Implementing Azure RBAC
Azure Role-Based Access Control (RBAC) is the system used to manage who has access to Azure resources. It is implemented using a simple formula:
Security Principal + Role Definition + Scope = Access
- Security Principal: The “Who.” This can be a User, a Group, a Service Principal (for apps), or a Managed Identity.
- Role Definition: The “What.” A collection of permissions (e.g., Read, Write, Delete).
- Scope: The “Where.” The level of the hierarchy where the access applies.
Tailwind Traders Real-World Example
The IT Director at Tailwind Traders needs a junior administrator to manage backups for the “Marketing” web servers but does not want them to be able to change network settings.
- Principal: The “Junior-Admins” Entra ID group.
- Role: Backup Operator.
- Scope: The marketing-web-rg Resource Group.
Result: The junior admin can perform backups within that group but cannot touch anything in the “Finance” resource group or modify the subscription’s billing settings.
Comparison of Built-in Roles
Azure provides hundreds of built-in roles, but for the AZ-104 exam, you must master the fundamental ones.
| Role Name | Scope of Power | Key Limitation | Best Use Case |
| Owner | Full access to all resources + ability to grant access to others. | High security risk if compromised. | The primary subscription administrator. |
| Contributor | Full access to manage resources (Create/Delete/Modify). | Cannot grant access to others via RBAC. | Lead developers or system engineers. |
| Reader | Can view all resources and metadata. | Cannot make any changes or see secrets. | Auditing, monitoring, or junior observers. |
| User Access Administrator | Can manage role assignments and access. | Cannot manage resources (VMs, DBs). | Security officers who only manage permissions. |
Identity Types: Service Principals vs. Managed Identities
When applications or automation scripts need to interact with Azure, we do not use standard user accounts. We use specialized identities.
Service Principals
A Service Principal is essentially a “service account” for an application. Administrators must create a client secret or certificate and rotate it periodically. If a developer hardcodes the secret into code and the code leaks, the entire identity becomes compromised.
Managed Identities (The “Gold Standard”)
Managed Identities are the modern, secure alternative. They provide an identity for the Azure service itself (like a Virtual Machine or an Azure Function).
- System-Assigned: Tied directly to a single resource. When you delete the resource, you also delete the identity.
- User-Assigned: You assign a standalone resource to multiple Azure services.
The primary advantage of Managed Identities is that Azure handles the credential rotation. There are no secrets for a developer to manage or leak, making this the most secure way to implement the “Shield” for your applications.
Monitoring and Troubleshooting RBAC
Assigning roles is only half of the job; an architect must also be able to verify and troubleshoot access. You can do this through the Access Control (IAM) blade found on every resource, resource group, and subscription.
Troubleshooting Tools
- Check Access: Within the IAM blade, you can use the “Check Access” feature to look up a specific user and see exactly what permissions they have and, crucially, where they inherit those permissions from.
- Activity Logs: If a resource is deleted, you can use the Activity Log to see who did it, as it provides a 90-day history of every “Write,” “Delete,” and “Action” performed.. It will show the identity that performed the action and whether it succeeded.
- Access Reviews: Entra ID P2 enables organizations to periodically review access to sensitive roles and automatically remove unnecessary access.
Common RBAC Mistakes
To maintain a healthy environment, avoid these frequent pitfalls:
- Assigning Roles to Individual Users: This is a massive administrative burden. If an employee leaves, you must find every individual assignment to remove it. Always assign roles to Groups.
- Over-Scoping (Violating Least Privilege): Don’t give “Contributor” access at the Subscription level just because it’s easier. If a user only manages a database, give them “SQL DB Contributor” at the Resource Group level.
- Confusing the Data Plane with the Control Plane: A “Reader” can see that a Storage Account exists (Control Plane), but they cannot see the files inside it (Data Plane) unless they also have a data-specific role like “Storage Blob Data Reader.”
Conclusion: The Architect’s Blueprint
Effective governance in Microsoft Azure is built on the rigorous application of Managing Azure Subscriptions and RBAC. By viewing subscriptions as clear billing and security boundaries and applying the principle of least privilege through scoped RBAC assignments, you create an environment that is both flexible for developers and impenetrable for unauthorized actors.
As you prepare for the AZ-104 exam, remember the hierarchy: Management Groups govern subscriptions, subscriptions govern resource groups, and resource groups govern resources. Master the flow of inheritance and understand the specific utility of built-in roles to confidently manage any enterprise cloud infrastructure. Focus on automation, leverage Managed Identities wherever possible, and always verify access through the IAM blade to ensure you implement your “As Above, So Below” logic perfectly in the cloud.