AZ-104: Identities & Governance
Microsoft Entra ID (formerly Azure Active Directory)
What it is
Microsoft Entra ID is the cloud identity service that provides authentication (who are you?) and the directory that grants authorization authority for users, groups, and applications accessing Azure and Microsoft 365. It’s the modern rebrand of Azure Active Directory (Azure AD).
Why it exists
On-premises you had Active Directory Domain Services (AD DS) in a domain you control. Azure is a multi-tenant cloud you don’t fully control, so you need a tenant-scoped, managed directory that stores identities and decides access — without you running a domain controller.
Key ideas
- Tenant — an isolated dedicated instance of Entra ID representing one org. Every Azure subscription is trusted by a tenant.
- Directory objects — users, groups, service principals (the “identity” of apps/services), managed identities, devices.
- SSO — one sign-in works across Azure, M365, and third-party SaaS apps that trust the tenant.
- Behind the scenes — it is not AD DS: no Kerberos, no GPOs, no domain join. It’s a REST-based IDaaS.
Components relevant to AZ-104
- Users & groups
- Service principals & managed identities (how apps authenticate)
- MFA, SSPR, Conditional Access
- Microsoft Entra roles
- App registrations / Enterprise apps
Relationship to RBAC
RBAC authorizes resource access in Azure; Entra ID authorizes identity operations. They work together: Entra ID says who you are, RBAC says what you may do to this resource.
Diagram
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity/entra-overview
Exam notes
- Entra ID = identity/authN layer. RBAC = resource authZ layer.
- Rebranded from Azure AD in 2023; the exam may still reference “Azure AD” — same thing.
- A tenant = the container for identities; a subscription = a container for resources that trusts a tenant.
Related
rbac · user-account · service-principal · mfa · conditional-access · tenant
📘 Source: Microsoft Learn — Entraid
Microsoft Entra tenant
What it is
A tenant is a dedicated, isolated instance of Microsoft Entra ID representing a single organization. It is the security boundary/container for that org’s identities (users, groups, apps) and its own configuration.
Why it exists
Because Azure is shared infrastructure, each org needs an isolated directory where its identities live and are managed. The tenant defines the trust and isolation boundary — identities, data and settings in one tenant are isolated from others.
Key ideas
- Tenant relationship — every Azure subscription is associated with (trusted by) one tenant; the tenant controls who can admin the subscription.
- Tenant vs subscription — the tenant is the identity/directory container; a subscription is the resource container (billing + RBAC). A single tenant can own many subscriptions.
- Multi-tenant — tenants can collaborate via B2B/B2C and cross-tenant access, but remain isolated by default.
- Accessed as a domain like
contoso.onmicrosoft.comor a custom domain you verify.
How it fits (diagram)
Exam notes
- One tenant, many subscriptions is the classic AZ-104 organizational model (e.g. a management group tree under one tenant).
- Distinct tenants can be treated as isolation boundaries when segments/trades need separation.
- Rebranded Azure AD → Microsoft Entra ID; “tenant” means the same directory.
Related
entraid · subscription · user-account · management-groups
📘 Source: Microsoft Learn — Tenant
User account
What it is
A user account is the identity record in Microsoft Entra ID that represents a person (or service account) and what they’re permitted to sign in as. Each user belongs to a tenant.
Why it exists
Users are the primary principals whose access administrators manage. Entra ID authenticates them (password, MFA) and they’re granted access either directly or through group membership.
Key ideas
- Properties — display name, user principal name (UPN, e.g.
[email protected]), sign-in status, job title, department, and usage-location. - Types — cloud-only users vs synchronized users (from on-prem AD via Entra Connect / cloud sync).
- Directory roles — a user can hold Entra roles (directory-level) and be subject to RBAC assignments.
- Guest users (B2B) — external collaborators invited into the tenant; governed by external collaboration settings.
How it fits (diagram)
Exam notes
- UPN vs sign-in name; Usage location is required for licensing/MFA in some cases.
- Creating/bulk-creating users, assigning licenses, and resetting credentials are common AZ-104 admin tasks.
- Understand guest vs member and how guest access is scoped (B2B).
Related
entraid · groups · tenant · service-principal · mfa
📘 Source: Microsoft Learn — User Account
Microsoft Entra groups
What it is
A group is a container in Microsoft Entra ID that holds multiple members (users, devices, other groups) so you can assign permissions or policies to many principals at once.
Why it exists
Assigning access per-user doesn’t scale. Groups are the best practice for RBAC and Entra-role assignment: give the group the role, add members to the group, and membership changes propagate automatically.
Key ideas
- Types — Assigned (static, you pick members) vs Dynamic (membership computed from rules on user/device attributes, e.g. “all users in the Accounting department”).
- Nesting — groups can contain other groups, but some role assignments don’t support transitive membership.
- Group roles — a central Entra admin can manage group lifecycle; options control who can create groups (self-service).
How it fits (diagram)
Exam notes
- Assign RBAC + Entra roles to groups, not individuals (most defensible design).
- Dynamic groups are a recurring AZ-104 concept — membership updates automatically based on attributes.
- Know the difference between Assigned and Dynamic membership types.
Related
entraid · user-account · rbac · role-assignment
📘 Source: Microsoft Learn — Groups
Service principal (app identity)
What it is
A service principal is the identity Entra ID gives to an application or service (as opposed to a human user). It’s “who the app is” when it authenticates to Azure resources. A managed identity is an automatically managed service principal.
Why it exists
Apps and automation need to authenticate and be authorized without human credentials. A service principal carries its own identity and secret/certificate, so CI/CD (Pipelines/github-actions), scripts, and services can access resources via RBAC.
Key ideas
- Forms — (1) Application registration + its service principal, (2) managed identity (system-assigned or user-assigned) — the administrative-friendly kind, (3) a legacy service principal.
- Credentials — client secret, certificate, or federated credentials.
- Managed identities — Azure automatically creates/rotates credentials; ideal for VMs, Functions, and App Service to reach Key Vault/Azure SQL without storing secrets.
- Scoped via RBAC assignments just like users.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity-platform/app-objects-and-service-principals
Exam notes
- Managed identities are the recommended way to give Azure workloads access to Azure resources.
- System-assigned (tied to one resource) vs user-assigned (shared across resources) — know the difference.
- Service principals need the right role (e.g. Contributor, or a custom role) — least privilege.
Related
entraid · rbac · user-account · azure-pipelines
📘 Source: Microsoft Learn — Service Principal
Multifactor authentication (MFA)
What it is
MFA is a sign-in requirement that asks for two or more proofs of identity — typically something you know (password), plus something you have (phone/app) or are (biometric) — before granting access.
Why it exists
Passwords alone are weak (reused, phished, leaked). MFA dramatically reduces account-takeover risk by adding a second factor an attacker won’t have, even if they steal the password.
Key ideas
- Factors — knowledge, possession (Authenticator app, SMS/phone call, hardware key), and inherence (biometrics).
- Per-user vs Conditional Access — the legacy per-user MFA forcing is being superseded by Conditional Access policies that require MFA for specific sign-in risk/contexts (the modern, recommended approach).
- MFA registration — users register via combined security-info registration (sign-in + MFA).
- Security defaults — a tenant setting that enforces MFA for all users; a common starting point.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity/authentication/concept-mfa-howitworks
Exam notes
- Prefer Conditional Access to per-user MFA forcing for least-disruption, context-aware protection.
- Understand the survivable token / registration process and how administrators can temporarily bypass or validate registration.
- MFA is enforced by policy, not a setting on the account itself in modern tenants.
Related
conditional-access · entraid · password-reset
📘 Source: Microsoft Learn — Mfa
Self-service password reset (SSPR)
What it is
SSPR lets users reset their own password without calling IT, using registered security methods (authenticator app, phone, email, security questions) to prove who they are.
Why it exists
Password resets are a huge share of help-desk tickets. SSPR reduces that load while keeping security via registration + verification so only the real owner can reset, not an impersonator.
Key ideas
- Requirements — the tenant must have a license (Essentials/premium) and SSPR must be enabled for a chosen scope (selected users or
All). - Registration — users must first register security-info; admins can require registration at sign-in (combined security info).
- Verification — must pass a required number of methods (e.g. 2) before resetting.
- Admin accounts — Azure has one break-glass permanent Global Administrator account whose password cannot be reset via SSPR (a hard rule).
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity/authentication/concept-sspr-howitworks
Exam notes
- SSPR scope:
None/Selected/All— and how admin accounts are exempt by default. - Requires registration; push users to register at sign-in.
- Combined registration of MFA + SSPR security info is the modern flow.
Related
entraid · mfa · user-account · conditional-access
📘 Source: Microsoft Learn — Password Reset
Conditional Access
What it is
Conditional Access (CA) is Entra ID’s policy engine that evaluates signals (who, where, what device, what app, sign-in risk) against policies and grants the right controls (require MFA, block, require compliant/hybrid-joined device, force password change).
Why it exists
A one-size-fits-all “always require MFA” is heavy-handed. Conditional Access applies context-aware rules — e.g. “require MFA only for risky sign-ins from outside the corporate network,” or “block legacy protocols.” It’s the modern replacement for per-user MFA forcing.
Key ideas
- Policy components — Assignments (users/groups, cloud apps/actions, conditions like location/device/risk) → Access controls (grant or session control) + Enable policy.
- Grant controls — require MFA, require device to be compliant/hybrid Azure AD joined, require approved client app, require password change.
- Session controls — app-enforced restrictions, sign-in frequency (per-session), persistent browser session.
- Report-only mode / What-If tool — test policies safely before enforcement.
- Best practice — assign to groups, exclude break-glass admin accounts, and enable policies in phases.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity/conditional-access/overview
Exam notes
- CA is per policy, evaluated at sign-in, with conditions and controls.
- Break-glass account exclusion is a known best practice + exam point.
- Used heavily in AZ-400 for pipeline/service-account protection too.
Related
entraid · mfa · user-account · azure-ad-roles
📘 Source: Microsoft Learn — Conditional Access
Microsoft Entra roles
What it is
Microsoft Entra (formerly Azure AD) roles govern permissions on the identity/directory plane — managing users, groups, apps, tenants, and directory-wide settings. They are distinct from RBAC roles, which govern the Azure resource plane.
Why it exists
Operating a tenant requires delegating directory-level administration (create users, reset passwords, manage groups, configure SSPR/MFA) without handing out Global Administrator to everyone. Entra built-in roles scope that delegation.
Key ideas
- Examples — Global Administrator, Application Administrator, User Administrator, Password Administrator, Group Administrator, and [more built-in roles].
- Scope — roles apply at directory level (whole tenant) or, with [administrative units][scopeable roles], to a subset.
- Distinct from RBAC — granting Entra User Administrator does not grant rights to Azure resources (VMs, storage); those need RBAC. The two planes are separate.
- Least privilege — use the most specific role (e.g. Password Administrator vs Global Administrator).
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity/role-based-access-control/rbac-and-directory-admin-roles
Exam notes
- This is a classic AZ-104 differentiator: Entra roles authorize the direct / M365/identity plane; RBAC authorizes Azure resources.
- Know the purpose of common roles and that Global Administrator is the equivalent of Entra “owner.”
- Assign to groups, exclude break-glass accounts from Conditional Access.
Related
entraid · rbac · user-account · conditional-access
📘 Source: Microsoft Learn — Azure Ad Roles
Role-Based Access Control (RBAC)
What it is
RBAC is Azure’s authorization model: it controls what an identity may do to a resource. It answers “can this user stop this VM / read this storage account / create a resource here?”
Why it exists
To enforce the least-privilege principle at scale: give each user/service exactly the permissions they need, no more, and manage that centrally rather than per-resource.
The three pieces (memorize!)
- Security principal — who (a user, group, service principal, or managed identity).
- Role definition — what they may do (a set of permissions; e.g.
Reader,Contributor,Owner,Storage Blob Data Reader). - Scope — where it applies (management group → subscription → resource group → resource). Permissions are inherited down the scope hierarchy.
security principal + role + scope = assignment
Identity vs RBAC
- Entra ID = authentication (who you are).
- RBAC = authorization (what you can do). RBAC does not authenticate; it authorizes after identity is known.
Key exam facts
- Owner > Contributor > Reader, plus classic User Access Administrator.
- Assign roles to groups, not individual users, for easy management.
- Custom roles can be defined when built-in roles don’t fit.
- Scope precedence: deny at a parent does NOT override allow at a child unless a Deny assignment exists. (More specific/efficient assignments win; see docs on the exact rules.)
- RBAC is allow-by-default within assignment — a user with no assignment has no access (except subscription-level Owner).
Diagram
Diagrams courtesy of Microsoft Learn / Azure docs: role-based-access-control/overview
Related
entraid · role-definition · role-assignment · scope · subscription · resource-group
📘 Source: Microsoft Learn — Rbac
Role definition (RBAC)
What it is
A role definition is the “what you can do” part of RBAC. It’s a named collection of permissions (actions) written as allowed/denied operations on Azure resource types — e.g. Microsoft.Compute/virtualMachines/start/action.
Why it exists
Roles let you express permissions as a reusable, named unit (Reader, Contributor, Owner) instead of raw action lists, so assignments are readable and auditable.
Key ideas
- Built-in roles — Azure ships many, most importantly for AZ-104:
- Owner — full control incl. role assignments.
- Contributor — full management, except role assignments (can’t grant access).
- Reader — can view, cannot change.
- User Access Administrator — manage role assignments.
- Data-plane roles — e.g.
Storage Blob Data Reader,SQL DB Contributor.
- Custom roles — you define when built-ins don’t fit, by listing specific
actions/notActionsscoped to a management group, subscription, or resource group. - Action list —
*= all; data actions vs management actions.
How it fits (diagram)
Exam notes
- Contributor vs Owner: the defining difference is the ability to assign roles.
- Built-in roles are the default answer; custom roles are the exception.
- Data-plane roles (storage/SQL) are distinct from control-plane roles.
Related
rbac · role-assignment · scope · service-principal
📘 Source: Microsoft Learn — Role Definition
Role assignment (RBAC)
What it is
A role assignment is the act of binding all three RBAC elements together:
Security principal (who) + role definition (what they can do) + scope (where) = an assignment.
It’s the only thing that actually grants access — a role definition alone grants nothing.
Why it exists
Access is a relationship, not a property. Assignments make “who can do what, where” explicit, auditable, and scoped, which is how least-privilege gets implemented and governed.
Key ideas
- Security principal — user, group, service principal/managed identity, or managed identity.
- Scope hierarchy — management group → subscription → resource group → resource; assignments inherit down.
- Best practice — assign roles to groups (not individuals) at the highest scope that still gives least privilege.
- Owners can assign; Contributors cannot (see role-definition).
- Assigning roles requires the
Microsoft.Authorization/roleAssignmentspermission (blocked by default Contributor).
How it fits (diagram)
Exam notes
- Know the scope hierarchy + inheritance — the most-tested RBAC concept.
- Assign to groups, use least privilege, remember inheritance.
- You must be Owner/User Access Administrator yourself to grant roles.
Related
rbac · role-definition · scope · groups · service-principal
📘 Source: Microsoft Learn — Role Assignment
Scope
What it is
Scope is the level/hierarchy at which a control or assignment applies. In Azure governance there is a single hierarchy:
Management group → Subscription → Resource group → Resource
Why it exists
Scoping lets you delegate permissions and apply policies once, high in the hierarchy, and have them inherit down. It avoids repeating the same rule/allowance for every resource and gives administrators flexible, least-privilege control.
Key ideas
- RBAC scope — a role assignment made at a higher scope (e.g. subscription) applies to everything below it, unless overridden closer to the resource.
- Policy scope — an Azure Policy initiative applied to a management group affects all child subscriptions/resources.
- More-specific wins — an assignment/deny closer to the resource generally takes precedence over a broader one.
- Inheritance is the crucial mental model for both RBAC and Policy.
How it fits (diagram)
Exam notes
- Always consider scope when evaluating an RBAC or Policy scenario — the exam loves “which assignment applies here?”-type questions.
- Assign privileges at the highest scope that still grants least privilege, usually a resource group or subscription.
Related
management-groups · subscription · resource-group · role-assignment · azure-policy
📘 Source: Microsoft Learn — Scope
Azure Policy
What it is
Azure Policy is a governance service that creates, assigns, and enforces rules for Azure resources to ensure they stay compliant — e.g. “only allow VMs in approved regions” or “require tagging.” It evaluates existing resources and governs new deployments.
Why it exists
People make mistakes. Policy lets an org codify governance so non-compliant resources are automatically flagged (and optionally prevented/denied) at scale across subscriptions — regardless of who creates them.
Key ideas
- Defined vs assigned — policy definitions are written once (built-in or custom); an assignment applies them to a scope and enforces.
- Initiative — a group of policy definitions treated as one unit for enforcement/reporting (e.g. regulatory compliance initiatives).
- Effects —
Audit,Deny,DeployIfNotExists(+Modifyfor remediation), etc. Deny blocks non-compliant creation. - Exemptions/exclusions — carve out specific resources/subgroups.
- Not RBAC — Policy enforces rules; RBAC controls permissions. You can have both. Policy also doesn’t limit compute/identity permission — it limits configuration.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-policy/overview
Exam notes
- Distinguish Azure Policy (rules/compliance) from RBAC (access): a classic AZ-104 contrast.
- Know how to assign a built-in policy or initiative and read compliance state.
- Deny vs Audit effect mental model is heavily tested.
Related
management-groups · scope · rbac · resource-tags
📘 Source: Microsoft Learn — Azure Policy
Tags
What it is
Tags are name/value metadata you attach to resources (and resource groups) — e.g. environment=production, costcenter=finance, owner=platform. They are free-form and unlimited in count.
Why it exists
Tags let you organize, classify, and query resources for cost reporting, resource management/filtering, and automation — Azure Cost Management and many dashboards group by tag. They support policy-driven tagging standards (e.g. require a costcenter tag via Policy).
Key ideas
- Apply to many resource types, not all; inherit at resource group level optionally.
- Not a permission control — tags are metadata, not RBAC. (Policy / role assignment governs access.)
- Policy tagging standards — use
DeployIfNotExists/ModifywithinheritFromResourceGroupto auto-apply tags. - View/filter by tag in the portal, CLI (
az resource list --tag), and Cost Management.
How it fits (diagram)
Exam notes
- Tagging is metadata, separate from names; name/location are not tags.
- Tag inheritance (portal applies on create; policy
inheritFromResourceGroupfor ongoing). - Differentiate tags (metadata) from RBAC and Policy (rules).
Related
resource-group · azure-policy · azure-cost-management
📘 Source: Microsoft Learn — Resource Tags
Azure Cost Management
What it is
Azure Cost Management + Billing is the toolset for viewing, analyzing, and controlling Azure spend: Cost analysis, budgets, cost alerts, and export to build chargeback/finOps reports.
Why it exists
Cloud spend can sprawl. Cost Management gives administrators and finance teams visibility and governance — the “how much are we spending and where” answer that tags and scope make meaningful.
Key ideas
- Cost analysis — interactive, filterable view of costs by subscription/resource group/resource/tag; supports forecasts.
- Budgets — set a threshold (by amount, resource group, service) at daily/monthly scope with alert actions (email/automation/function) when exceeded.
- Cost alerts — budget-specific notification alerts (predefined templates like “budget threshold reached”).
- Costs are cumulative: costs roll up resource → resource group → subscription → management group.
How it fits (diagram)
Exam notes
- Spend analysis + budget alerts are the tested AZ-104 cost features.
- Tags enable meaningful cost grouping; without them, cost reporting is less useful.
- Exports to a storage account enable FinOps/chargeback automation.
Related
subscription · resource-tags · management-groups
📘 Source: Microsoft Learn — Azure Cost Management