Section 5 of 14
This domain tests whether you can manage access to Azure. That means identities (who is logging in), authorization (what they can do), governance (what rules apply across the organization), and how the management hierarchy flows from tenant down to individual resources.
Entra ID is Microsoft's cloud-based identity provider. It is what trusts your Azure subscriptions for authentication and what apps like Microsoft 365 use to know who you are. It is not the same as on-premises Active Directory Domain Services - they speak different protocols and serve different purposes.
| Property | Entra ID | AD Domain Services |
|---|---|---|
| Location | Cloud-native | On-premises servers |
| Protocols | OAuth 2.0, OIDC, SAML, WS-Fed | Kerberos, LDAP, NTLM |
| Structure | Flat (no OUs) | OUs and hierarchical |
| Best for | SSO to cloud apps, M365, Azure | Domain-joined Windows machines |
| Communication | HTTPS over internet | Many private ports on LAN |
Hybrid identity means you have on-premises AD and want those same users in Entra. The sync ALWAYS flows from AD DS up to Entra. It never flows the other direction.
| Tool | Where the engine runs | When to use |
|---|---|---|
| Entra Connect Sync | On-premises server | Traditional choice, runs as a Windows app |
| Entra Connect Cloud Sync | In the cloud, light agents on-prem | Newer, simpler, multi-forest support |
**Hybrid attributes have a **'source of authority' For users synced from on-prem AD, attributes like Job Title, Contact Info, and Display Name are owned by AD DS. You CANNOT change them in Entra - you have to change them in on-prem AD and let the sync push them up. Exception: Usage Location is a cloud-only attribute. You CAN set it directly in Entra even for synced users, and you MUST set it before you can assign Microsoft 365 licenses.
Cloud accounts - created directly in Entra
Synced accounts (hybrid) - originated in on-prem AD, replicated up
Guest accounts (B2B) - external users from other tenants, Google, Microsoft Accounts, or one-time-passcode email
External users come with stub objects in your tenant; their actual identity lives in their home directory
| COMMON TRAP Bulk operations: To bulk add NEW internal users, use 'Bulk Create'. To bulk add EXTERNAL users as guests, use 'Bulk Invite'. Microsoft will trick you with this distinction. |
|---|
| License | Key features added |
|---|---|
| Free | Basic identity, sign-in, group management |
| P1 | Conditional Access, dynamic groups, group-based licensing, SSPR with writeback, HR provisioning |
| P2 | Identity Protection (risk-based CA), Privileged Identity Management (PIM), access reviews |
P2-only features that show up on the exam: Identity Protection (risk-based Conditional Access) and Privileged Identity Management (PIM). If a question mentions either of these, the answer requires a P2 license. SSPR and MFA are available in P1 (and even Free/M365 in some tiers).
Lets users reset their own password without calling the help desk
Authentication methods you can configure: email, phone call, SMS, mobile app notification, mobile app code, security questions
Hardware tokens and 'username and password re-entry' are NOT valid SSPR methods
Password writeback (P1 feature) syncs the new password back to on-prem AD
Groups are how you assign permissions, licenses, and access at scale. Never grant directly to users for anything you might forget to clean up later.
| Group type | What it does |
|---|---|
| Security | Grants permissions for apps and resources in Azure |
| Microsoft 365 | Collaboration - SharePoint, Teams, shared mailbox |
| Membership | How members join |
|---|---|
| Assigned | Admin manually adds and removes users |
| Dynamic User | Auto-populated based on user attributes (e.g. Department equals Marketing) |
| Dynamic Device | Auto-populated based on device attributes |
License assignment to nested groups is NOT inherited If you assign a P2 license to Group 1, and Group 2 is a member of Group 1, the users in Group 2 do NOT get the license. Only direct members of Group 1 get licensed. Plan your group structure accordingly.
| COMMON TRAP P2 license assignment to groups: only Security groups (security-enabled) and Microsoft 365 groups with security enabled can receive licenses. A standard M365 group with security disabled cannot. |
|---|
If a question asks how to automate access policies for a specific department or attribute (e.g. 'enable MFA for finance department only'), the answer is almost always Dynamic Groups + Conditional Access policies. Dynamic groups auto-populate based on attributes, and Conditional Access targets those groups.
Azure has a strict hierarchy. Things flow down. This is the single most important concept in Domain 1.
| Scope | Description | What inherits |
|---|---|---|
| Tenant Root Group | Top of the hierarchy | Everything below |
| Management Groups | Custom hierarchy for organizing subs | Roles, policies, budgets cascade down |
| Subscription | Billing and access boundary | Inherited by RGs and resources |
| Resource Group | Logical container for related resources | Inherited by resources within |
| Resource | Individual service (VM, storage, etc.) | Lowest scope |
Permissions ALWAYS flow downward If you grant Contributor at the Subscription level, that user has Contributor on every Resource Group and every Resource in the subscription. This is a trap in exam questions. Tags do NOT inherit by default. You can use Azure Policy to force tag inheritance if needed.
| Role | What they can do | What they cannot do |
|---|---|---|
| Owner | Full control INCLUDING assigning roles | Nothing - it is the most powerful |
| Contributor | Full management of resources | CANNOT assign roles or change permissions |
| Reader | View only | Cannot change anything |
| User Access Admin | Can manage access (assign roles) | Cannot manage resources themselves |
| Network Contributor | Manage networks | Cannot access them (cannot read data within) |
Owner = Contributor + the ability to assign roles. This is the most-tested distinction in the exam. If the question asks about least privilege for someone who 'needs to assign roles', it is Owner (or User Access Admin, even more granular).
A role assignment combines three things:
**Identity **- the user, group, or service principal getting the permission
**Role **- the set of Actions (control plane) and DataActions (data plane) the identity can perform
**Scope **- where the permission applies (management group, subscription, RG, or specific resource)
When the built-in roles do not fit (too broad or too narrow), you can create custom roles. They are defined in JSON with five sections:
**assignableScopes **- which scopes this role can be assigned at (e.g. limit to one subscription or one RG)
**actions **- control plane permissions (managing the resource itself)
**notActions **- exclude specific actions from the wildcards in actions
**dataActions **- data plane permissions (reading/writing data inside the resource)
**notDataActions **- exclude specific data actions
Common custom role permissions to remember Login to a VM as a regular user: Microsoft.Compute/virtualMachines/login/action (this is a dataAction, not an action) To restrict a role to a specific resource group, change assignableScopes to /subscriptions/{sub-id}/resourceGroups/{rg-name}
Conditions on RBAC role assignments (e.g. 'only let this user read blobs whose tags equal X') are currently supported ONLY for Blob Storage and Queue Storage data actions. Not files, not tables.
Deny assignments override Allow permissions. They are not something you create directly - they are applied by Azure Blueprints and Managed Apps. Just know they exist and that they win over any role assignment.
| Lock type | What it prevents | Overrides RBAC? |
|---|---|---|
| CanNotDelete | Deletion only - you can still modify the resource | Yes |
| ReadOnly | Both deletion AND modifications - cannot even start/stop a VM (state change counts as modification) | Yes |
Locks override RBAC - even Owner cannot delete a locked resource An Owner CAN remove the lock first, then delete the resource. The exam loves this distinction. If a question shows a delete operation failing, look for a lock before looking at permissions. Locks are inherited downward. A lock at the subscription level applies to every resource group and resource underneath.
ReadOnly on a storage account means you cannot list the account keys. This blocks data access even if your RBAC role would normally allow it.
A lock prevents you from changing the Azure resource itself (the metadata, the configuration). It does NOT prevent you from working with data inside the resource. A CanNotDelete lock on a storage account does not stop you from adding or deleting blobs in containers. A lock on a SQL database does not stop you from writing rows.
Administrative Units (AUs) restrict admin permissions to a specific subset of users, groups, or devices. They exist because Entra is flat - no OUs. AUs are how you delegate, for example, 'help desk admins can only manage users in the New York office'.
AU vs RBAC - the distinction Microsoft loves RBAC scopes WHAT a role can do. AUs scope WHICH objects the role applies to. If the question says 'delegate user management to a regional admin only for users in that region', the answer is Administrative Units, not just RBAC.
Adding a GROUP to an AU does NOT automatically give an admin permission over the USERS in that group. Users must be explicitly added to the AU too. Otherwise an AU admin could add themselves to a group to escalate, which Microsoft (correctly) prevents.
Azure Policy enforces governance rules. It checks resources for compliance and can audit, deny, or even auto-remediate. It is how organizations restrict things like allowed regions, required tags, allowed VM sizes, mandatory diagnostic settings.
**Policy **- a single rule with a condition (what to check) and an effect (what to do)
**Initiative **- a collection of policies grouped for a single compliance goal (e.g. 'ISO 27001 Baseline'). Easier to assign and track compliance for many policies at once.
**Assignment **- when a policy or initiative is applied to a specific scope (management group, subscription, or RG)
| Effect | What it does | When to use |
|---|---|---|
| Audit | Logs non-compliant resources without blocking | Start here - understand impact before enforcing |
| Deny | Blocks creation of non-compliant resources | Once you know the audit results are safe |
| DeployIfNotExists | Auto-deploys a remediation template | Install required agents, default configs |
| Append | Adds properties (like tags) to resources | Apply default tags automatically |
| Modify | Modifies properties of existing resources | Bulk-apply settings |
| Disabled | Policy exists but does nothing | Pause without deleting |
Policy does NOT retroactively delete non-compliant resources Existing resources that violate a new Deny policy are FLAGGED as non-compliant. They are not deleted or modified. Only NEW deployments are blocked. To fix existing non-compliance, you need a remediation task (for Modify or DeployIfNotExists policies) or manual cleanup.
Policies can be assigned at any level: management group, subscription, resource group, or even individual resource. Exclusions can be applied at any level EXCEPT the top assignment scope. You cannot exclude the same scope you assigned at.
On the exam you may see policy JSON and have to determine its effect. Read it in this order:
Scope - which level is it assigned at
Exclusions - which sub-scopes are exempt
Policy definition - what condition triggers the effect
Parameters - the specific values passed in
Effect - what the policy actually does
Resource Policy Contributor - can create, modify, and assign policy definitions. Cannot do most other Azure actions.
Owner - full rights including policy
Contributor - can trigger remediation but cannot create or update definitions or assignments
User Access Admin - needed to grant the managed identity used by DeployIfNotExists and Modify policies
Common exam scenario User 1 must create initiative definitions, User 2 must assign initiatives to a resource group. Answer: Resource Policy Contributor for User 1 at the SUBSCRIPTION level (because creating definitions requires sub-level scope), and Resource Policy Contributor for User 2 at the RG level (more granular for assignment).
Tags are key-value pairs attached to resources for organization and billing. They are simple but the exam tests their edges.
Apply to: subscriptions, resource groups, individual resources
Max 50 tags per resource
Tags are NOT inherited by default - a tag on a RG does not automatically appear on resources within
Use Azure Policy to force tag inheritance if needed
Tags are used by Azure Cost Management for billing rollup by department, project, owner, etc.
Tags vs Resource Groups for billing rollup When the question is 'how to roll up billing by department', the answer is RESOURCE TAGGING, not Resource Groups. Resource Groups are organizational containers tied to lifecycle, but a single RG often spans multiple departments. Tags can attach to any resource regardless of which RG it lives in.
When a policy with 'append a tag' is assigned, by default it only affects NEW resources created after the assignment. Existing resources keep their original tags unchanged. You would need a remediation task (Modify policy effect) to apply the tag to existing resources.
When a resource moves to a new RG, it loses the old RG's tags and applies whatever the new RG's policy says. The resource's LOCATION does not change - only its parent RG. Moving a West Europe web app from RG1 to RG2 (in North Europe) keeps the web app in West Europe.
A subscription is a billing and access boundary. It trusts exactly one Entra tenant.
To create a new Azure subscription, you need an identity in an Entra tenant (or a trusted directory). External guests cannot create subscriptions by default.
Management groups give you a hierarchy ABOVE subscriptions for inheriting roles, policies, and budgets.
The Tenant Root Group is the top of the management group tree. You cannot delete it or move out from under it.
| Task | Required role |
|---|---|
| Bulk create internal users | User Administrator OR Global Administrator |
| Bulk invite external/guest users | Guest Inviter or User Administrator |
| Manage role assignments across all subscriptions | User Access Administrator at Tenant Root (least privilege over Owner) |
| Receive email alerts about service outages for a sub | Account Admin / Service Admin set on the subscription properties |
| Assign a policy to the tenant root management group | Global Administrator (must enable Access Management for Azure Resources first) |
Budgets can be set at management group, subscription, or RG levels
Budgets are NOT enforcement - they trigger alerts, they do not stop spend
Alerts fire based on actual spend or forecasted spend
Budgets reset based on their configured period (monthly, quarterly, etc.)
Action groups handle the response: email, SMS, webhook, Function, Logic App, runbook
Budget alerts trigger notifications only. They never stop, throttle, or shut down resources. Even if you hit 100% of your budget, the VMs keep running. If a question implies the budget will stop the VMs, the answer is NO.
| Channel | Rate limit |
|---|---|
| Max 100 per hour | |
| SMS | Max 1 every 5 minutes (max 12/hour) |
| Voice call | Max 1 every 5 minutes |
| Tool | What it does |
|---|---|
| Azure Advisor | Personalized recommendations for cost, security, reliability, performance, operational excellence |
| Azure Cost Management | Track spend, set budgets, view forecasts, analyze costs by tag/RG/service |
| Azure Pricing Calculator | Estimate costs before deploying |
| Azure TCO Calculator | Compare on-prem vs cloud costs for migrations |
If a question asks 'how to identify idle or underutilized VMs to save money', the answer is Azure Advisor (the Cost tab specifically). Azure Monitor watches health and metrics. Azure Cost Management tracks spend. Azure Advisor recommends improvements.