Domain 1: Manage Azure Identities and Governance

Exam weight: 15–20%

This domain tests whether you can manage who has access to what in Azure and enforce organization-wide rules on resources. It contains the single most common exam trap: Entra ID roles vs Azure RBAC roles — they are completely separate systems.


1.1 Microsoft Entra ID (formerly Azure AD)

Entra ID is Azure's cloud-based identity directory. Every Azure subscription is associated with exactly one Entra ID tenant. The tenant is the trust boundary for all identities.

Tenant vs Subscription

ConceptWhat it is
TenantThe Entra ID directory (identity store)
SubscriptionA billing and resource container
RelationshipOne tenant → many subscriptions possible

A subscription belongs to exactly one tenant. A tenant can own many subscriptions.

User Types

TypeCreated howDefault access
MemberCreated inside this tenantCan read most directory objects
GuestInvited from another org (B2B)Restricted — sees only what they're explicitly given

Group Types

TypePurpose
Security groupUsed for Azure RBAC and app access
Microsoft 365 groupCollaboration (Teams, SharePoint, Exchange mailbox)

Group Membership

Membership typeHow members are addedLicense required
AssignedManually by adminNone
Dynamic UserAuto, based on user attribute rules (department eq "Finance")Entra ID P1
Dynamic DeviceAuto, based on device attributesEntra ID P1

Exam trap: Dynamic groups require Entra ID P1 license. Any question that says "automatically add users based on attributes with no manual effort" implies dynamic groups and P1 licensing.

Managed Identities

A managed identity is a service principal automatically managed by Azure — no credentials to store or rotate.

TypeLifecycleShared across resources?
System-assignedTied to the resource — deleted when the resource is deletedNo — one resource only
User-assignedStandalone resource — persists independentlyYes — attach to multiple resources

Exam trap: If a question asks "the VM is recreated and must retain its existing role assignments," the answer is user-assigned managed identity because system-assigned gets a new Object ID on recreation.


1.2 Azure RBAC

Azure Role-Based Access Control governs what Azure actions a principal can perform on Azure resources. It is completely separate from Entra ID roles.

RBAC Answers Three Questions

  1. Who? — Security principal (user, group, service principal, managed identity)
  2. What? — Role definition (a named set of permitted Actions)
  3. Where? — Scope

Scope Hierarchy

Root Management Group (tenant root)
 └─ Management Group
     └─ Subscription
         └─ Resource Group
             └─ Resource
  • RBAC assignments are inherited downward.
  • Assignments are additive — a user gets the union of all role assignments at all scopes.
  • There is no implicit deny — only explicit role assignments or deny assignments block access.

Key Built-in Roles

RoleCan doCannot do
OwnerEverything, including manage access
ContributorCreate and manage all resourcesAssign roles, manage locks
ReaderView all resourcesAny write or delete action
User Access AdministratorManage RBAC assignments at this scopeCreate or manage resources

Exam trap: A Contributor cannot assign roles. If a question asks who can grant the Contributor role to another user, the answer is Owner or User Access Administrator — not Contributor.

Exam trap: A Contributor cannot create or delete resource locks. Managing locks requires Microsoft.Authorization/locks/*, which Contributor explicitly excludes.

Deny Assignments

  • Cannot be created manually by users.
  • Created by Azure Blueprints and Managed Applications.
  • Take precedence over role assignments — they block even Owners.

Custom Roles

  • Define Actions, NotActions, DataActions, NotDataActions.
  • Scope is set per-subscription or per-management-group.
  • The NotActions field removes actions from what Actions allows — it is not a deny, just a subtraction.

1.3 Entra Roles vs Azure RBAC Roles — The #1 Exam Trap

These are two completely separate systems that just happen to live in the same Azure portal.

AttributeEntra ID RolesAzure RBAC Roles
ControlsThe Entra directory (users, groups, apps, devices)Azure resources (VMs, storage, networks, etc.)
ExamplesGlobal Administrator, User Administrator, Billing ReaderOwner, Contributor, Reader, Storage Blob Data Contributor
Assigned inEntra ID admin centerAzure portal / ARM / CLI / RBAC blade
ScopeTenant-wide (or specific Entra objects)Management group → Subscription → RG → Resource

Global Admin can elevate to Azure: In Entra settings, a Global Administrator can grant themselves the User Access Administrator Azure RBAC role on all subscriptions (one-time toggle). This is not automatic — it must be explicitly done.

Exam scenario: "A user is the Global Administrator in Entra ID. They try to create a VM. It fails." → Reason: Global Admin has no Azure RBAC permissions unless explicitly granted. They need at minimum Contributor on the target scope.


1.4 Management Groups

Hierarchy

Root Management Group (auto-created, represents the tenant)
 ├─ Management Group: Corp
 │   ├─ Subscription: Prod
 │   └─ Subscription: Dev
 └─ Management Group: External
     └─ Subscription: Partner
  • Up to 6 levels of nesting (not counting root).
  • A subscription can be in only one management group at a time.
  • RBAC and Policy assignments inherit to all child subscriptions and resources.
  • Moving a subscription between management groups transfers the inherited assignments.

Moving Resources Between Subscriptions

  • Most resources can be moved with az resource move.
  • Restrictions: target subscription must be in the same Entra tenant.
  • Resource IDs change after a move — update automation scripts and monitoring rules.
  • Some resources cannot be moved: Azure AD Domain Services, ExpressRoute circuits with VNet links.

1.5 Azure Policy

Azure Policy enforces organizational standards on resources independently of RBAC. A user with Contributor can be blocked by a Policy.

Effect Types — Must Know All

EffectWhat it doesWhen it runs
DenyBlocks the non-compliant operationAt creation or modification
AuditLogs non-compliance — allows itAt creation or modification
AppendAdds properties/tags to the requestAt creation or modification
ModifyAdds, replaces, or removes tags/propertiesAt creation or modification
DeployIfNotExistsDeploys a related resource if it doesn't existAfter the resource is created
AuditIfNotExistsAudits if a related resource is missingAfter the resource is created
DisabledPolicy is off — no evaluation

Exam trap — DeployIfNotExists: It runs after resource creation for new resources, but for existing non-compliant resources you must manually trigger a Remediation Task. It does not retroactively fix existing resources automatically.

Exam trap — Append vs Modify: Use Append to add new properties (like tags). Use Modify to change or remove existing properties. In practice, Modify is replacing Append for tag scenarios.

Initiatives (Policy Sets)

An initiative (policy set) bundles multiple policies into one assignable unit. Example: the "Enable Microsoft Defender for Cloud" initiative bundles 20+ individual policies.

Policy vs RBAC — How They Interact

  1. Request arrives → RBAC is evaluated first.
  2. If RBAC allows it → Policy is evaluated.
  3. If Policy says Deny → request is rejected, even for Owners.

1.6 Resource Locks

Locks prevent accidental deletion or modification. Applied at resource, resource group, or subscription — inherited downward.

Lock typeBlocksAllows
CanNotDeleteDeleteRead + all modifications
ReadOnlyDelete + all modificationsRead only

ReadOnly Gotchas

ReadOnly sounds simple but it blocks any ARM write action on the management plane, including:

  • Listing storage account access keys (listKeys is classified as a write)
  • Starting or stopping a VM (start/deallocate are write operations)
  • Scaling an App Service plan

Exam trap: A ReadOnly lock on a storage account prevents listing access keys, even for an Owner. This is one of the most common exam questions.

Who Can Manage Locks

Requires Microsoft.Authorization/locks/* — included in Owner and User Access Administrator only. Contributor cannot create or delete locks.


Section Takeaways

TopicKey Point
Tenant vs SubscriptionOne tenant owns many subscriptions; one subscription belongs to one tenant
Dynamic groupsRequire Entra ID P1 license
RBAC scopeAdditive, inherited downward, no implicit deny
Contributor limitsCannot assign roles, cannot manage locks
Entra roles vs Azure RBACCompletely separate — biggest exam trap in Domain 1
Global AdminHas no Azure resource access unless explicitly granted via RBAC
Policy vs RBACPolicy can block even an Owner; evaluated after RBAC
DeployIfNotExistsNeeds manual Remediation Task for existing resources
ReadOnly lockBlocks listKeys on storage, blocks VM start/stop
User-assigned MIPersists across resource recreation; system-assigned does not

Confusing Points — Clarified

Q: Does assigning Owner at a Management Group make the user Owner of all subscriptions under it? A: Yes. RBAC inherits downward through the full hierarchy — management group → subscription → resource group → resource.

Q: Can Azure Policy block a Global Administrator from creating a resource? A: From an Azure resource perspective, yes — if the Policy has a Deny effect. The Global Admin has no special bypass for Azure Policy. (They could remove the policy assignment if they also have the right Azure RBAC, but that's a different action.)

Q: What's the difference between NotActions and a Deny assignment? A: NotActions in a custom role is subtraction from Actions — it removes permissions from the allow list. A Deny assignment is an explicit block that overrides all role assignments, even Owner.

Q: Can a Contributor delete a resource that has a CanNotDelete lock? A: No. The lock blocks deletion regardless of RBAC role. The Contributor also cannot remove the lock (requires Owner/UAA). Both vectors are blocked.