Microsoft Entra ID Users, Groups and Administrative Units
Every AZ-104 identity question starts with where the account came from. A user is either cloud only, created directly in the tenant, synchronised from an on-premises Active Directory by Microsoft Entra Connect, or invited as a guest from another tenant or an email address. The source matters because a synchronised user's attributes are mastered on-premises and cannot be edited in the portal, and because a guest signs in against their home directory rather than yours. Groups come in two flavours: a security group, which is what you assign RBAC roles and licences to, and a Microsoft 365 group, which also creates a mailbox, a SharePoint site and a Teams team. Membership is either assigned, where you pick the members by hand, or dynamic, where a membership rule is evaluated against user or device attributes and Microsoft Entra ID adds and removes members for you. Dynamic membership needs a Microsoft Entra ID P1 licence for every member of the group. An administrative unit is a container that scopes a Microsoft Entra role to a subset of users, groups or devices, which is how you let a regional helpdesk reset passwords for their own region only without making them a tenant-wide User Administrator.
Exam tip. When a scenario says a user was created on-premises and an attribute cannot be changed in the Azure portal, the answer is almost always to change it in on-premises Active Directory and let Entra Connect synchronise it. When a scenario asks for helpdesk staff to manage only one office or region, the answer is an administrative unit, not a new custom role.
Azure RBAC: Scope, Inheritance and Custom Roles
Azure role-based access control answers three questions: who (a security principal, meaning a user, group, service principal or managed identity), what (a role definition, which is a list of allowed and denied operations), and where (a scope). The four scopes are management group, subscription, resource group and individual resource, and an assignment made at one level is inherited by everything beneath it. Permissions are additive and there is no ordinary deny: if a user holds Reader at the subscription and Contributor on one resource group, they are a Contributor in that resource group and a Reader everywhere else. The only thing that overrides an allow is a deny assignment, which Azure creates itself through Azure Blueprints or a managed application and which you cannot author directly in the portal. The three built-in roles you must be able to separate are Owner (full access including granting access to others), Contributor (full management access but cannot grant access), and User Access Administrator (can grant access but cannot manage resources). A custom role is defined by its Actions, NotActions, DataActions, NotDataActions and AssignableScopes, and it is worth remembering that NotActions is not a deny rule: it simply subtracts operations from the Actions list in that same definition, so a second role assignment can still grant them.
Exam tip. Read the scope before the role name. Most wrong answers in RBAC questions pick the right role at the wrong scope, or pick Owner where the requirement says the person must not be able to grant access to others.
Azure Policy, Initiatives and Effects
Azure RBAC controls who can act; Azure Policy controls what may exist. A policy definition is a rule with an effect, and the effects are the whole point of the topic. Deny blocks a non-compliant deployment outright. Audit lets it through but flags it as non-compliant. Append adds a field such as a tag to the request. Modify changes or removes tags on new and existing resources. DeployIfNotExists deploys a related resource, such as a diagnostic setting, when the target resource is missing one. AuditIfNotExists reports on the same condition without fixing it. Disabled turns a single assignment off without deleting it. Both Modify and DeployIfNotExists change resources, so both need a managed identity on the assignment with enough rights, and both apply to existing resources only when you run a remediation task. An initiative, also called a policy set, groups related definitions so they can be assigned and reported on together, which is how the built-in regulatory compliance packs are shipped. Policies are assigned at management group, subscription or resource group scope and inherit downward, with exclusions available for individual child scopes and exemptions available for a defined period.
Exam tip. If the requirement is prevent, the effect is Deny. If it is report on, it is Audit. If it is fix automatically, it is Modify for tags and DeployIfNotExists for related resources, and both of those need a managed identity plus a remediation task to touch anything that already exists.
Management Groups, Tags, Locks and Cost Control
The Azure hierarchy runs tenant root management group, management groups, subscriptions, resource groups, resources, and it is the reason a single policy or role assignment can cover an entire estate. Every subscription belongs to exactly one management group, the hierarchy supports up to six levels below the root, and the root group cannot be moved or deleted. Tags are name and value pairs used to slice cost and to target automation. They are not inherited by default: a resource does not pick up its resource group's tags, which is exactly the gap the Inherit a tag from the resource group policy with a Modify effect exists to close. Resource locks come in two kinds. CanNotDelete allows changes but blocks deletion, and ReadOnly blocks both changes and deletion, which can break operations you would not expect, such as listing storage account keys, because that call is a write operation. Locks inherit downward and the most restrictive lock in the chain wins. On the money side, a Cost Management budget is an alerting tool rather than a brake: crossing it raises an alert and can trigger an action group, but nothing stops spending unless you build that yourself.
Exam tip. ReadOnly locks are the classic trap. If a scenario says an operation started failing after a lock was applied and the operation is something like retrieving storage account keys or restarting a service, the answer is that ReadOnly blocks it and CanNotDelete would not have.