Identity and Governance

Explained with real-life analogies so even beginners can understand Entra ID, RBAC, and Azure Policy. This is a core domain covering 20–25% of the AZ-104 exam.

The Identity/Governance domain accounts for 20–25% of the AZ-104 exam. It might sound dry at first, but it's really about managing "who can access what" and "are we operating by the rules." Entra ID management, RBAC, and Azure Policy are the key topics.

---

 

Entra ID Users and Groups

Entra ID (formerly Azure Active Directory) is like an access control system for a company building. Just as you need an employee badge to enter the building and different badges grant access to different floors, Entra ID determines "who can log in to Azure" and "which resources they can access."

User Management

There are several ways to create users. For a small team, you can add them one by one through the Azure Portal, but if you need to register hundreds of employees at once, bulk creation with a CSV file is much more convenient. You can also automate this with scripts using PowerShell or Azure CLI.

User creation: Choose from Portal (web UI), PowerShell, CLI (command line), or bulk creation (CSV file upload) based on the situation. Guest users (B2B collaboration): Used when external partners or contractors need access to your Azure resources. For example, if an outsourced development firm needs access to your test environment, you can invite their employees as "guests." Guests sign in with their own company account (or personal email), so there's no need to create new accounts for them. SSPR (Self-Service Password Reset): Allows employees to reset forgotten passwords on their own, without calling the IT help desk. Employees get a fast and convenient experience, while the IT team is freed from repetitive password reset requests. Administrative Units: Used in large organizations to delegate management authority by region or department. For example, a "Seoul branch administrator" can be restricted to managing only Seoul branch users.

Group Types

Grouping users makes permission management much easier. Instead of granting permissions to 100 people individually, you can grant permissions to a "Marketing Team" group, and all group members automatically inherit that permission.

| Type | Membership Method | Primary Use | |------|-------------------|-------------| | Security Group | Assigned or dynamic | Managing access permissions for Azure resources | | Microsoft 365 Group | Assigned or dynamic | Collaboration tools like Teams, shared mailboxes, SharePoint |

Security groups are used to bundle access permissions — "this team can access this resource." Microsoft 365 groups go beyond simple permissions to automatically connect shared inboxes, Teams channels, and SharePoint sites, making them collaboration-focused groups.

There are also two types of membership. Direct assignment means an admin manually adds members one by one. Dynamic membership lets you set rules like "anyone whose department is Marketing is automatically included," so users are automatically added or removed when they meet or no longer meet the conditions. Dynamic groups are extremely useful in organizations with frequent onboarding, offboarding, or department transfers.

---

 

Azure RBAC

RBAC (Role-Based Access Control) is a system that gives different keys based on job titles. Just as a new employee can only open their own desk drawer, a team lead can also open the meeting room, and a facilities manager can manage the entire building — Azure uses "roles" to precisely control what each user is allowed to do.

Built-in Roles

Azure provides pre-built roles for common needs. Understanding these four roles is enough to get started.

| Role | What they can do | What they cannot do | |------|-----------------|---------------------| | Owner | Everything + assign roles to others | Nothing | | Contributor | Create, modify, and delete resources | Assign roles to others | | Reader | View and inspect resources | Create, modify, or delete | | User Access Administrator | Manage role assignments | Modify resources directly |

Thinking in real-world terms: give developers Contributor so they can deploy and manage infrastructure, but prevent them from touching others' permissions. Give the audit team Reader so they can see the current state but cannot change anything.

Role Assignment Scope

One of RBAC's powerful features is being able to choose at which level to assign a role. Azure has the following four-level hierarchy:

Roles assigned at a higher level are automatically inherited by lower levels. For example, if you give someone Reader at the "subscription" level, they automatically get read access to all resource groups and resources within that subscription. Conversely, if you want to grant access to only a single specific resource, you assign the role at the "resource" level.

!RBAC role assignment scope hierarchy

Custom Roles

When built-in roles don't precisely match your organization's requirements, you can create your own roles. For example, if you need fine-grained control like "can read Blobs in a specific storage account but cannot access Queues," you can define a custom role using a JSON file. This is a more advanced feature, but the exam does ask questions like "what do you do when built-in roles can't meet the requirements?"

---

 

Governance

Governance, simply put, is a system that ensures operations follow the rules. Even the best system, operated without rules, can result in exploding costs, security gaps, or compliance violations. Azure's governance tools prevent these problems proactively.

Azure Policy

Azure Policy is a system that automatically enforces your organization's rules. For example, if you set a policy stating "all resources must only be created in the Korea Central region," it will automatically block anyone who tries to create a server in a US region.

There are four main things you can do with Policy:

Deny: Prevents the creation of resources that violate the rule. This is the most powerful effect. Audit: Does not block rule violations but records the violation. It's common to first run in Audit mode when introducing a new rule, to understand the scope of impact. DeployIfNotExists: When a resource is created, if a certain condition is missing, it automatically triggers an additional deployment. For example, you can configure it so that a monitoring agent is automatically installed whenever a virtual machine is created. Modify: Automatically corrects non-compliant settings to the correct values.

Initiative is a feature that manages multiple policies as a single bundle. For example, if you bundle an encryption policy, a network policy, and a tagging policy under a "Security Hardening" initiative, assigning just that one initiative to a subscription applies all the policies at once.

The compliance dashboard lets you see at a glance which resources are violating which policies. You can also view violation percentages (%), making it easy to assess your organization's overall compliance status.

Resource Locks

You can lock important resources to prevent accidental deletion or modification. It's good practice to apply locks to production databases and critical network configurations.

There are two types of locks:

Delete lock: Only prevents deletion of the resource. You can still modify settings or add data. Suitable for resources that "must not be deleted." ReadOnly lock: Allows only read access, as the name suggests. Neither modification nor deletion is possible. Suitable for stable environments where no changes should occur, but it can be overly restrictive and may unexpectedly block some operations.

Locks operate independently of RBAC. Even a person with Owner permissions cannot delete a locked resource. To delete it, you must first remove the lock itself.

Tags

Tags are like sticking memo notes onto resources. For example, you can attach key-value pairs like , , or to any resource.

Why are tags important? When you're running hundreds of resources in Azure, it can be hard to immediately answer "how much did the Marketing team spend this month?" But if all resources have a tag, you can filter costs by that tag to get the answer.

There is one important characteristic: tags are not inherited. Adding a tag to a resource group does not automatically apply it to the resources inside. If you want to enforce tags on all resources, you can use the Modify effect in Azure Policy.

---

 

Key Exam Points

The exam frequently presents scenarios and asks you to choose the most appropriate Azure feature. Remembering the key points below in connection with their scenarios will be helpful.

Users and Groups "I want to automatically manage group members based on attributes like department or job title" → Use dynamic groups. No manual adding or removing needed. "I want to invite external partners or contractors to my Azure environment" → Use guest users (B2B collaboration). The other party signs in with their own account. "I want employees to reset forgotten passwords on their own without IT team help" → Enable SSPR (Self-Service Password Reset).

RBAC Roles "I need all permissions and the ability to assign roles to others" → That's Owner. "I need to create and manage resources but must not be able to manage permissions" → That's Contributor. "How are RBAC roles propagated?" → Inherited from higher to lower levels. Applied automatically in the order: Management Group → Subscription → Resource Group → Resource.

Governance "I want to enforce rules to allow only certain resource types or regions" → Use Azure Policy. "I'm worried an important resource might be accidentally deleted" → Apply a Delete lock. Modification is still possible. "I want to create an environment where nothing can be changed" → Use a ReadOnly lock. Both modification and deletion are blocked. "I want to attach labels to resources for cost tracking" → Use Tags. Note that tags are not automatically inherited by child resources, so use Policy together if you need to apply them in bulk.

The most effective approach to this domain is not memorization but

Back to blog list