Managing an Azure environment involves much more than creating virtual machines, storage accounts, and other cloud resources. Administrators also need to determine who can access those resources, what they are allowed to do, where their permissions apply, and which organizational rules resources must follow.
Azure provides several services to handle these responsibilities. Microsoft Entra ID manages identities, Azure role-based access control (RBAC) manages access to Azure resources, Azure Policy establishes governance rules, and the Azure resource hierarchy provides the structure through which these controls are applied.
Understanding how these components work together is particularly important for Azure administrators preparing for the AZ-104 certification.
Microsoft Entra ID and Azure Identity
Microsoft Entra ID is Microsoft’s cloud-based identity and access management service. It provides the identity layer used by Azure and other Microsoft cloud services.
An Entra ID tenant contains users, groups, applications, devices, and other identity-related objects. Users can have different origins depending on how an organization manages its identity infrastructure.
Common identity types include:
- Cloud-only identities: Created and managed directly in Microsoft Entra ID.
- Directory-synchronized identities: Originating from an on-premises Active Directory environment and synchronized to Entra ID.
- Guest identities: External users invited to collaborate within an organization’s tenant.
Microsoft Entra ID also supports groups, which are particularly useful for managing access at scale. Instead of assigning permissions individually to every user, administrators can place users into groups and assign the required access to the group.
For example, a development team can be represented by a security group. When a new developer joins the team, adding the user to the group can provide the access associated with that group. When the developer leaves the team, removing the user can revoke that group-based access.
Microsoft Entra Groups and Dynamic Membership
Groups provide a practical way to organize identities and manage permissions.
Two important group types are security groups and Microsoft 365 groups. Security groups are commonly used when controlling access to resources, while Microsoft 365 groups provide collaboration features such as shared files, mailboxes, calendars, and SharePoint resources.
Group membership can also be managed in different ways.
Assigned Membership
With assigned membership, an administrator manually adds or removes users and devices from a group.
This approach is straightforward when membership changes infrequently or when administrators need direct control.
Dynamic Membership
Dynamic groups automatically update their membership according to rules based on user or device attributes.
For example, an organization could create a group for users whose department is set to Sales. When a user’s relevant attribute changes, their group membership can be updated automatically.
This can also simplify license assignment and access management. Instead of manually maintaining a list of users who need a particular service, an organization can use a dynamic group and manage access through that group.
Understanding the Azure Resource Hierarchy
Azure resources are organized through a hierarchy that provides different levels at which access and governance can be applied.
A simplified structure is: Management Group → Subscription → Resource Group → Resource
Management Groups
Management groups sit above subscriptions and allow organizations to organize multiple subscriptions into a structure.
They are useful when an organization needs to apply governance or access controls across multiple subscriptions.
Subscriptions
A subscription provides a management and billing boundary for Azure resources. Organizations can use multiple subscriptions to separate environments, business units, applications, or other operational boundaries.
Resource Groups
A resource group is a logical container for related Azure resources within a subscription.
For example, an application might have a web app, database, storage account, and supporting resources organized within a resource group.
Resource groups also provide a useful scope for RBAC, policies, and resource management.
Resources
Resources are the individual Azure services deployed within the resource groups, such as virtual machines, storage accounts, virtual networks, databases, and web applications.
Understanding this hierarchy is important because Azure permissions and governance controls can be applied at different levels.
Azure RBAC: Controlling Who Can Access Azure Resources
Azure role-based access control determines what identities can do with Azure resources.
A useful way to understand an RBAC assignment is the Who, What, Where model:
- Who: The security principal receiving access.
- What: The role defining the permitted actions.
- Where: The scope at which the role is assigned.
The security principal can be a user, group, service principal, or managed identity.
The role definition specifies the operations that the principal can perform. Azure provides many built-in roles, including Owner, Contributor, Reader, and service-specific roles.
The scope determines where those permissions apply. Azure RBAC scopes can include:
- Management group
- Subscription
- Resource group
- Individual resource
For example, assigning the Reader role at the subscription level allows the principal to read resources throughout that subscription, subject to the applicable access model.
Permissions granted at a higher scope can also be inherited by lower scopes. This makes scope selection an important part of designing least-privilege access.
Built-In and Custom Roles
Built-in roles cover many common administrative requirements. However, there can be situations where a built-in role provides more access than a user actually needs.
Azure supports custom roles for more specific permission requirements.
A custom role can define permitted actions and restrictions using elements such as Actions, NotActions, and AssignableScopes. This allows administrators to create a permission set that more closely matches a particular operational responsibility.
The goal should be to provide the access required to perform a task without unnecessarily expanding the user’s permissions.
Microsoft Entra Roles vs Azure RBAC Roles
Microsoft Entra roles and Azure RBAC roles are separate permission systems, and understanding the distinction is important.
| Microsoft Entra roles | Azure RBAC roles |
| Manage resources within Microsoft Entra ID | Manage access to Azure resources |
| Used for directory administration | Used for Azure resource authorization |
| Examples include User Administrator | Examples include Reader and Contributor |
| Focus on identities and directory resources | Focus on Azure services and resources |
For example, managing users within Microsoft Entra ID is associated with Entra roles, while managing a virtual machine or storage account is handled through Azure RBAC.
A Global Administrator is highly privileged within Microsoft Entra ID, but that does not automatically mean the account has unrestricted access to Azure resources. The separation between directory administration and Azure resource authorization is an important concept for Azure administrators to understand.
For professionals preparing for the AZ-104 certification, understanding these distinctions is more useful than simply memorizing role names. Practicing scenario-based questions alongside hands-on Azure administration can help reinforce how identities, roles, and scopes work together. AZ 104 Dumps can be used as an additional study resource for reviewing these types of exam concepts.
Azure Policy and Governance
RBAC determines who can perform an action, while Azure Policy is used to establish rules that resources must follow.
Azure Policy can help organizations maintain standards across their Azure environment. Policies can be used to evaluate resources, identify non-compliance, and, depending on the configured effect, prevent or remediate certain deployments.
The main concepts include:
- Policy definition: Describes the rule or condition that should be evaluated.
- Policy assignment: Applies a policy definition to a particular scope.
- Initiative: Groups multiple related policy definitions into a single policy set.
- Compliance: Shows whether resources meet the requirements of assigned policies.
Several policy effects are commonly encountered:
- Audit: Identifies non-compliant resources without blocking the operation.
- Deny: Prevents an operation when it violates the policy.
- Append: Adds specified information to a resource during deployment.
- DeployIfNotExists: Deploys a related resource or configuration when a required item is missing.
For example, an organization might require resources to be deployed only in approved Azure regions. A policy can be assigned at an appropriate management group or subscription scope so the requirement applies consistently across the environment.
When introducing restrictive policies, testing is important. An organization can first use an auditing approach to identify the potential impact before applying stronger enforcement.
Tags and Resource Locks
Azure governance also includes tools for organizing resources and protecting important infrastructure.
Azure Tags
Tags are key-value metadata associated with Azure resources.
Common tags include:
- Environment: Production
- Owner: Development
- CostCenter: 1001
- Project: Website
Tags can help organizations organize resources, allocate costs, filter reports, and establish governance standards. Azure Policy can also be used to enforce tagging requirements.
Resource Locks
Resource locks provide another layer of protection against accidental changes.
Two important lock types are:
- CanNotDelete: Prevents deletion while still allowing authorized modifications.
- ReadOnly: Prevents modification and deletion while allowing read access.
For example, a critical production resource can have a CanNotDelete lock applied to reduce the risk of accidental deletion.
Locks should be used carefully because they can also affect legitimate administrative operations.
Practical Azure Identity and Governance Scenarios
The individual Azure services become easier to understand when considered together.
Scenario 1: A Development Team Needs Web Application Access
Suppose five developers need to manage web applications within a particular resource group, but they should not receive broad access to unrelated resources.
A practical design is to:
- Create or use a security group for the development team.
- Add the developers to the group.
- Select an appropriate application-specific RBAC role.
- Assign the role at the required resource-group scope.
This avoids giving the entire group unnecessarily broad Contributor permissions when a more specific role can meet the requirement.
Scenario 2: An External Contractor Needs Azure Access
An external contractor can be represented as a guest identity in Microsoft Entra ID.
The organization can then control the contractor’s access through groups and Azure RBAC. Because the contractor is external, access should be limited to the resources required for the engagement and reviewed periodically.
Scenario 3: Production Resources Need Additional Protection
Consider an organization that wants all resources to use approved regions, requires CostCenter tags, and wants to protect an important production network resource.
Different Azure governance tools can address each requirement:
- Azure Policy can restrict permitted locations.
- Azure Policy can enforce required tags.
- A resource lock can help prevent accidental deletion.
- RBAC can control which administrators can modify the resources.
This illustrates why Azure governance is not a single service. Identity, authorization, policy, resource organization, and protection mechanisms work together.
Common AZ-104 Identity and Governance Concepts to Review
Several concepts are particularly important when studying Azure identity and governance:
- Microsoft Entra ID manages identities and directory resources.
- Security groups can simplify resource access management.
- Dynamic groups can automate membership based on attributes.
- Azure RBAC determines what a security principal can do to Azure resources.
- RBAC permissions depend on both role and scope.
- Permissions can be inherited from higher scopes.
- Microsoft Entra roles and Azure RBAC roles serve different purposes.
- Azure Policy establishes governance requirements.
- Tags provide resource metadata that can support organization and cost management.
- Resource locks help protect important resources from deletion or modification.
- Management groups provide a way to organize and govern multiple subscriptions.
Quick Reference: Azure Identity and Governance
| Concept | Primary purpose |
| Microsoft Entra ID | Identity and access management |
| Microsoft Entra roles | Directory administration |
| Security principal | Identity receiving access |
| Azure RBAC | Azure resource authorization |
| Role definition | Defines permitted actions |
| Scope | Determines where access applies |
| Management Groups | Organize and govern subscriptions |
| Azure Policy | Enforce governance requirements |
| Tags | Organize and classify resources |
| Resource Locks | Protect resources from changes or deletion |
Conclusion
Managing identities and governance in Azure requires understanding how several services fit together. Microsoft Entra ID provides the identity layer, Azure RBAC controls resource permissions, and Azure Policy establishes governance requirements. Management groups, subscriptions, and resource groups provide the hierarchy through which these controls can be organized and applied.
The most useful way to approach the subject is to think about the relationship between identity, permissions, scope, and governance. Once those relationships are clear, concepts such as RBAC inheritance, dynamic groups, policy assignments, tags, and resource locks become much easier to apply to real Azure administration scenarios.
Source: FG Newswire