AZ-104 Deep Dive: Master Identities and Governance in Azure

Welcome to the definitive guide for mastering the Manage Identities and Governance domain of the AZ-104 Azure Administrator certification exam. This section, representing a significant portion of the exam (15-20%), is arguably the most critical. Why? Because identity is the new control plane. Misconfigurations here don’t just cause errors; they lead to security breaches. As an experienced Azure architect and instructor, I’ve seen firsthand how a solid foundation in Microsoft Entra ID, governance, and RBAC separates a competent admin from a truly exceptional one.

This deep dive is engineered for IT professionals who aren’t just looking to pass an exam but to gain architecture-level understanding. We’ll move beyond simple definitions and into real-world scenarios, best practices, and the “why” behind the “how.” You will learn to think like a senior Azure administrator, making strategic decisions that ensure your cloud environment is secure, compliant, and efficiently managed. If you’re just starting your journey, check out our complete AZ-104 Study Plan or compare it with other certifications like AZ-104 vs AZ-204 and AZ-104 vs AZ-305.

Part 1: Mastering Microsoft Entra ID (The Foundation of Identity)

Microsoft Entra ID (formerly Azure Active Directory or Azure AD) is the heart of identity and access management in the Microsoft cloud. It is a cloud-based identity and access management service that helps your employees sign in and access resources in external resources, like Microsoft 365, the Azure portal, and thousands of other SaaS applications, as well as internal resources like apps on your corporate network and intranet.

Users and Groups

At its core, Entra ID is about managing principals (identities) and controlling their access.

User Objects

A user object is the primary representation of a person within Entra ID.

• Cloud-only identities: Created and exist only in Microsoft Entra ID.
• Directory-synchronized identities: Sourced from an on-premises Active Directory and synchronized to Entra ID using Microsoft Entra Connect. These are the most common in enterprise environments.
• Guest identities: Used for external collaboration (B2B), allowing you to invite users from other tenants or with public email addresses to access your resources.

Group Objects

Groups are containers for users, other groups, or service principals, used to assign access to resources efficiently.

• Security Groups: The most common type, used for granting access rights to resources. This is the primary group type you’ll work with for resource management.
• Microsoft 365 Groups: Provides collaboration opportunities by giving group members access to a shared mailbox, calendar, files, SharePoint site, and more. While important, they are less central to core Azure resource management than security groups.

Membership Types:

• Assigned: You manually add and remove members. Simple and direct.
• Dynamic User/Device: Membership is automatically updated based on user or device attributes (e.g., a “Sales Department” group for all users whose department attribute is “Sales”). This is managed via Dynamic Groups.

Microsoft Entra ID manages user identities through cloud-only, synchronized, or guest accounts. It uses security groups with assigned or dynamic membership to grant permissions to Azure resources efficiently.

Real-World Scenario: Onboarding a New Development Team

Imagine a new team of five developers is joining your company, “Contoso.” They need access to specific development resources in Azure.

1. Create Users: You create five new synchronized user objects in your on-premises Active Directory, which are then synced to Microsoft Entra ID.
2. Create a Group: Instead of assigning permissions one by one, you create a security group in Entra ID named sg-dev-team-alpha.
3. Assign Membership: You add the five new developer user objects to this group.
4. Grant Access: Later, when we discuss RBAC, you will assign the necessary roles (e.g., “Contributor”) to this single group on the appropriate resources. When a developer leaves, you simply remove them from the group, instantly revoking all their access. This is the principle of efficient identity management.

Microsoft Entra ID Roles vs. Azure RBAC Roles

This is a critical point of confusion for many students. They are not the same.

Exam Tip: If a question asks about giving someone permission to reset user passwords or manage application registrations, the answer is a Microsoft Entra ID Role. If it’s about managing a virtual network or a storage account, it’s an Azure RBAC Role. To see how this domain fits into the bigger certification landscape, explore AZ-900 vs AZ-104 and AZ-900 vs MS-900.

Part 2: Architecting Azure Governance (The Rules of the Road)

Governance in Azure is about establishing policies, processes, and controls to manage your resources at scale. It ensures your organization complies with corporate standards and regulatory requirements, controls costs, and maintains security.

The Governance Hierarchy: Management Groups and Subscriptions

Think of the Azure governance structure as a hierarchy.

1. Root Management Group: The top-level container for your entire organization. Policies applied here are inherited by everything below.
2. Management Groups (MGs): These are containers for subscriptions. You create a hierarchy of MGs that mirrors your organization’s structure (e.g., by department, geography, or environment like Prod/Dev). This allows you to apply policies and RBAC assignments to entire groups of subscriptions at once.
3. Subscriptions: A subscription is a logical container for your resources and a billing boundary. An organization can have many subscriptions.
4. Resource Groups (RGs): A container within a subscription that holds related resources for an Azure solution. Every Azure resource must exist in one (and only one) resource group.
5. Resources: The individual services you deploy, like VMs, databases, and web apps. For a complete overview of certification costs and career benefits, check our guide on AZ-104 Certification Cost, Salary, and Jobs and Is AZ-104 Certification Worth It?.”

Azure Policy

Azure Policy is a service in Azure that you use to create, assign, and manage policies that enforce different rules and effects over your resources. These policies ensure that resources stay compliant with your corporate standards and service level agreements. You can also explore the full Azure Certification Path to understand where governance skills align across Microsoft certifications.

How it Works:

• Policy Definition: A rule written in JSON. For example, a definition could be “Allowed locations” which specifies a list of Azure regions where resources can be deployed.
• Policy Assignment: You apply a policy definition to a specific scope (Management Group, Subscription, or RG).
• Initiative (Policy Set): A collection of related policy definitions grouped together. For example, you could have a “HIPAA Compliance” initiative that includes policies for enabling encryption, restricting public IPs, and more.

Common Policy Effects:

• Append: Adds required fields to a resource during creation (e.g., adding a specific tag).
• Audit: Creates a warning event in the activity log if a resource is non-compliant but doesn’t stop the action.
• Deny: Blocks the creation or modification of a resource if it violates the policy. This is the most powerful effect for enforcement.
• DeployIfNotExists: Deploys a related resource if it’s missing (e.g., deploying a Log Analytics agent on all new VMs).

Resource Locks

Resource Locks are a simple but powerful governance tool used to prevent accidental deletion or modification of critical Azure resources. They are your safety net.

• CanNotDelete (Delete Lock): Authorized users can still read and modify a resource, but they can’t delete it.
• ReadOnly: Authorized users can only read a resource; they cannot delete or update it. This is the most restrictive lock.

Key Point: Locks apply to everyone, including Global Administrators. To modify or delete a locked resource, the lock must first be removed by a user with the necessary permissions (e.g., Owner or User Access Administrator).

Real-World Scenario: Enforcing Corporate Standards

Contoso Corp has the following requirements:

1. All resources must be deployed in either “East US” or “West Europe.”
2. All resources must be tagged with a “CostCenter” tag.
3. The production VNet must not be accidentally deleted.

Solution Architecture:

1. Management Group Structure: Create MGs for “Production” and “Development.”
2. Policy for Locations: Create a policy definition for “Allowed locations” and assign it to the root management group with the Deny effect. This single policy now protects the entire organization.
3. Policy for Tagging: Create a policy definition for “Require a tag on resources” and assign it to the root MG with the Append or Deny effect. Append is user-friendly as it can add a default tag if missing, while Deny is stricter.
4. Resource Lock: Apply a CanNotDelete lock directly on the production VNet resource.

This multi-layered governance strategy ensures compliance and security with minimal administrative overhead.

Part 3: Implementing Role-Based Access Control (Granting the Keys)

While Entra ID manages who the users are and Governance sets the rules, Role-Based Access Control (RBAC) determines what those users can do with specific Azure resources. It is the core of Azure’s security model and is built on the principle of least privilege.

The Core Components of an RBAC Assignment

An RBAC assignment consists of three parts. A helpful mnemonic is Who, What, Where.

1. Security Principal (Who): The identity being granted access. This can be a User, a Group, a Service Principal (for applications), or a Managed Identity (for Azure resources).
   • Best Practice: Always assign roles to groups, not individual users. This simplifies management dramatically.
2. Role Definition (What): A collection of permissions. It defines what actions the principal can perform, such as Microsoft.Compute/virtualMachines/start/action.
   • Built-in Roles: Azure provides hundreds of pre-defined roles like Owner, Contributor, Reader, and Virtual Machine Contributor.
   • Custom Roles: If a built-in role is too permissive, you can create your own custom roles with a specific set of permissions.
3. Scope (Where): The level in the Azure hierarchy where the access is applied. This can be a Management Group, Subscription, Resource Group, or a single Resource.

Inheritance is Key: Permissions granted at a higher scope are inherited by lower scopes. If you grant a group the “Reader” role on a Subscription, that group can read all resources in all resource groups within that subscription.

Real-World Scenario: Giving a Developer Limited Access

Let’s revisit our “Contoso” developers. They need to manage web apps within the rg-webapp-prod resource group but must not have access to the SQL databases in the same RG. If you’re practicing for hands-on labs, our detailed guide on AZ-104 Deploying and Managing Azure Resources will complement this section.

1. Identify the Principal: The group sg-dev-team-alpha.
2. Identify the Scope: The resource group rg-webapp-prod.
3. Identify the Role: The “Contributor” role is too broad because it would give them access to the SQL databases. The “Web Plan Contributor” or “Website Contributor” roles are better, as they are scoped to only App Service resources.
4. The Assignment: You assign the Website Contributor role to the sg-dev-team-alpha group at the scope of the rg-webapp-prod resource group.

Result: The developers can now fully manage the web apps but cannot even see, let alone modify, the SQL databases, even though they are in the same resource group. This is a perfect example of applying the principle of least privilege using RBAC.

Frequently Asked Questions (FAQ)

I’m preparing for the AZ-104 exam. Can you explain the difference between Microsoft Entra ID roles and Azure RBAC roles in simple terms?

Microsoft Entra ID roles are for managing permissions inside Entra ID itself, like resetting passwords or managing users. Azure RBAC roles are for managing access to Azure resources, like virtual machines, storage accounts, and networks.

Think of it like a company. An Entra ID “User Administrator” is like an HR manager who can hire, fire, and manage employee records (user identities). An Azure RBAC “Virtual Machine Contributor” is like a mechanic who has been given the keys to work on specific company cars (VMs) but can’t access employee records. They are two separate permission systems for two different purposes.

What’s the best way to structure Management Groups? I’m not sure where to start.

The best practice is to start with a simple structure that mirrors your organization’s operational needs and expand as necessary. A great starting point is a top-level MG for your company, with child MGs for “Production,” “Development,” and “Sandbox” environments.

This allows you to apply strict policies (like limiting expensive SKUs) to the Development environment and even stricter security policies (like requiring MFA) to the Production environment, all through inheritance. You can further subdivide by business unit or application if your organization is large. The key is to use MGs to apply policy and access controls at scale, reducing redundant configurations on individual subscriptions.

Why am I getting an error saying I’m not authorized to perform an action, even though I’m a Global Administrator?

This is a classic issue that stems from the separation between Entra ID and Azure RBAC. A Global Administrator has the highest permissions within Microsoft Entra ID but, by default, has no access to Azure resources. You are an admin of the directory, not the resources within it.

To fix this, a Global Administrator must elevate their access. You can do this in the Properties of Microsoft Entra ID by enabling the setting “Access management for Azure resources.” This grants you the User Access Administrator role at the root scope (/), allowing you to then assign yourself the Owner role on any subscription you need to manage. This elevated access should be used sparingly and disabled after use.

When should I create a custom RBAC role instead of just using the built-in ones?

You should create a custom RBAC role when a built-in role is too permissive and violates the principle of least privilege. The built-in roles are great, but sometimes they grant more permissions than a user needs.

For example, the built-in “Virtual Machine Contributor” role allows a user to create, manage, and delete VMs. But what if you want to allow a junior admin to only start and stop existing VMs without giving them the power to delete them? There’s no built-in role for that. This is the perfect scenario to create a custom role. You would clone the “Reader” role and add only the specific actions: Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/restart/action.

I’m confused about Resource Locks. If I put a ReadOnly lock on a resource group, what happens?

A ReadOnly lock on a resource group makes all resources within that group read-only. This means no one, not even an Owner, can modify or delete any resource inside that RG or the RG itself. They also cannot add new resources to it.

This is an extremely powerful protective measure. For example, you might apply a ReadOnly lock on a resource group containing resources for a just-completed project to “freeze” it in its final state for archival or auditing purposes. Remember, to make any changes, an authorized user must first remove the lock.

What are Administrative Units in Entra ID and do I need to know them for the exam?

Answer: Yes, Administrative Units (AUs) are an important concept. An Administrative Unit is an Entra ID resource that can be a container for other Entra ID resources, such as users and groups. It allows you to delegate administrative permissions over a specific subset of your directory.

For instance, you could create an AU for “Europe” and put all European users and groups inside it. You could then assign someone the User Administrator role scoped only to the “Europe” AU. This person could then reset passwords and manage users for European employees, but they would have no administrative permissions over users in the “North America” AU. It’s a way to achieve delegated administration within Entra ID.

Can you explain dynamic groups in a practical way?

Dynamic groups automatically manage their membership based on rules you define, saving you from manual work. Think of it as a smart, self-updating list.

A classic real-world example is for licensing. Let’s say every user in your Sales department needs a Power BI Pro license. Instead of manually adding every new salesperson to a licensed group, you create a dynamic group with a rule like (user.department -eq “Sales”). Now, any time a new user is created or an existing user’s department is set to “Sales” in Entra ID, they are automatically added to this group. If someone leaves the Sales department, they are automatically removed. You can then assign the Power BI license to this one group and let Entra ID handle the rest.

What mistakes should I absolutely avoid with Azure Policy?

The biggest mistake is applying a Deny policy to a high-level scope without proper testing. Imagine assigning a policy that denies the creation of storage accounts without geo-redundancy to your root management group. You could instantly break automated deployment scripts and prevent legitimate business operations from proceeding.

Pro Tip: Always test new policies by first using the Audit effect. This will log non-compliant actions without blocking them. Review the audit logs to see what would have been impacted. Once you are confident the policy is correct and won’t cause unintended consequences, you can change the effect to Deny.

How is managing guest (B2B) users different from regular users?

Managing guest users involves inviting external collaborators into your tenant to access your resources. The key difference is their identity is managed by their home tenant or email provider, not yours. You don’t manage their passwords.

Your primary responsibility is controlling what they can access once they are in your tenant. By default, guests have limited directory permissions, but you can assign them to groups and grant them Azure RBAC roles on resources just like any other user. A common practice is to have strict review processes for guest access using Entra ID Access Reviews to ensure they don’t retain access longer than necessary.

Will a resource lock prevent a resource from being deleted by an Azure Policy?

Yes, it will. A resource lock takes precedence over most other actions, including automated ones from Azure Policy. For example, if you have a policy that is supposed to delete non-compliant resources and that resource has a CanNotDelete lock, the policy action will fail. Locks are the ultimate “are you sure?” prompt and are designed to protect against both accidental human actions and automated processes.

What’s the relationship between a resource group and a subscription?

A subscription is a billing and management boundary that contains multiple resource groups. A resource group is a container within a single subscription that holds related Azure resources. A resource must be in a resource group, and a resource group must be in a subscription. You cannot nest resource groups or have a resource group span multiple subscriptions.

For the AZ-104 exam, how deep do I need to know about creating custom RBAC roles with JSON?

You need to understand why and when you would create a custom role and what the main components of the JSON definition are. You should be able to look at a JSON snippet and identify the actions, notActions, and assignableScopes. You likely won’t be asked to write a complex JSON definition from scratch, but you should be able to interpret one or identify what needs to be changed to meet a specific requirement.

I’m trying to assign a role at a management group scope, but I can’t find it. What’s wrong?

The most likely reason is that you don’t have the necessary permissions. To assign roles to others at a specific scope, you must have a role that includes the Microsoft.Authorization/roleAssignments/write permission at that same scope (or higher). Typically, you need to be an Owner or User Access Administrator at the management group level to assign roles there. If you only have Owner on a subscription, you can’t assign roles at the parent management group.

Can a single user have multiple roles at the same time?

Absolutely. A user’s total permissions are the sum of all their role assignments. For example, a user could have the “Reader” role on an entire subscription, allowing them to see everything, but also have the “Virtual Machine Contributor” role on a specific resource group. In that RG, they can create and manage VMs, but in all other RGs in the subscription, they can only read resources. This additive model provides great flexibility.

What are Tags and how do they relate to governance?

Tags are metadata key-value pairs that you apply to Azure resources. They are a critical part of governance because they allow you to organize, manage, and report on resources in a way that makes sense for your business. For example, you can tag resources with their owner, environment (Prod/Dev), or cost center. You can then use Azure Policy to enforce that all resources must have certain tags, and you can use tools like Azure Cost Management to filter and report on costs based on those tags.

Key Takeaways

• Identity is the Perimeter: Microsoft Entra ID is the core of Azure security. Master users, groups (especially dynamic groups), and the critical difference between Entra ID Roles and Azure RBAC Roles.
• Govern from the Top Down: Use Management Groups to apply Azure Policy and RBAC assignments at scale. This is far more efficient than managing individual subscriptions.
• RBAC is about Least Privilege: Always use the Who, What, Where model. Assign roles to groups, choose the most specific role possible (create custom roles if needed), and apply it at the lowest possible scope.
• Policy Enforces Compliance: Use Azure Policy to enforce your corporate standards. Start with Audit to test, then move to Deny or DeployIfNotExists for enforcement.
• Locks are Your Safety Net: Use Resource Locks on critical infrastructure to prevent accidental deletion or modification.

Study Tips & Hands-On Labs

1. Practice in the Portal: Get a free Azure trial. Create users and groups. Create a management group hierarchy. Assign a policy like “Allowed locations” and see it block a deployment.
2. RBAC Scenarios: Give a user “Reader” at the subscription level. Then, try to create a VM in a resource group. Observe the failure. Now, grant that same user “Virtual Machine Contributor” on just that one RG and try again. Experiencing the permissions is the best way to learn.
3. Custom Role Creation: Find a built-in role like “Storage Account Contributor.” Review its permissions (in JSON). Then, try to create a custom role that only allows a user to read and list storage keys, but not delete the account.
4. Dynamic Groups: Create a dynamic group for all users whose “Usage location” is “United States.” Create a new user, set their location, and watch them automatically appear in the group.

Conclusion

Managing identities and governance in Azure isn’t just a set of tasks; it’s a strategic discipline. By mastering these foundational concepts, you are building the secure, compliant, and well-managed cloud environment that every business demands. The principles discussed here—centralized identity, top-down governance, and least-privilege access—are directly testable on the AZ-104 exam and are paramount to your success as an Azure Administrator.