Chapter 1
Manage Azure Identities and Governance
Identity is the foundation of everything in Azure. Before you deploy a single virtual machine or storage account, you need to know who can sign in, what they are allowed to do, and how your subscriptions stay organized and compliant. This domain carries 20–25% of the AZ-104 exam — the single largest slice — and it is also the area where real administrators make the costliest mistakes. This chapter covers Microsoft Entra ID, self-service password reset, Azure RBAC, Azure Policy, resource locks and tags, management groups, and cost management.
Managing Microsoft Entra ID

Microsoft Entra ID (formerly Azure Active Directory) is the identity service for Azure. Every user who signs in to the Azure portal, every service principal that runs an automation script, and every guest from a partner company passes through Entra ID. As an Azure administrator, you manage users, groups, licenses, and external identities here — not in the Azure portal's subscription blades, but in the Microsoft Entra admin center.
Users
You can create users one at a time in the portal, but in practice you will create them in bulk. Entra ID supports bulk user creation through a CSV file upload: you download the template, fill in one row per user (user principal name, display name, password), and upload it. Each row creates one cloud-only user account. You can also create users with PowerShell (New-MgUser) or the Azure CLI (az ad user create), which is the right approach when user creation is part of an automated onboarding script.
Every user has a user principal name (UPN), which looks like an email address (for example, fatima@contoso.com) and is what the user types at sign-in. Two properties deserve special attention because the exam loves them: usage location and account status. Usage location is a two-letter country code on the user profile, and it is required before you can assign licenses — license assignment fails without it, because Microsoft uses it to determine which services are legally available in that country. Account status lets you block sign-in, which immediately prevents the user from authenticating while preserving the account and its group memberships. Blocking sign-in is the correct first step when an employee leaves or an account is suspected of compromise; deleting the account comes later, after you have reviewed what it owned.
License assignment fails if the user has no usage location set. If a question describes a license assignment error, check usage location first.
By default, regular member users in Entra ID have a set of default permissions: they can register applications, create security groups, and read other users' basic profile information. You can restrict these in User settings ("Users can register applications" and "Restrict access to Microsoft Entra administration portal" are common hardening choices), but know the defaults for the exam.
Groups
Groups are how you assign access at scale. Never assign a role to 300 individual users when you can assign it to one group. Entra ID has several group types, and confusing them is a classic exam trap:
- Security groups are used to manage access to resources — assigning RBAC roles, granting app access. They can be mail-enabled or not.
- Microsoft 365 groups provide a shared mailbox, calendar, SharePoint site, and Teams team in addition to membership. They are collaboration groups first.
- Distribution groups (and mail-enabled security groups) exist for email distribution and cannot be used for resource access assignments.
Membership can be assigned (an administrator adds members manually) or dynamic (a rule query automatically adds users based on attributes, such as department -eq "Finance"). Dynamic membership requires Microsoft Entra ID P1 or P2 licenses for the members. Dynamic groups are powerful for onboarding automation — a new hire in Finance lands in the right groups the moment their department attribute is set — but the licensing requirement catches people out.
Nesting rules matter: security groups can be nested (a security group can be a member of another security group), but Microsoft 365 groups cannot be nested, and you cannot add a Microsoft 365 group to a security group. Mail-enabled groups cannot be nested either.
Dynamic group membership requires Entra ID P1 or P2. If a question says dynamic membership isn't working and the tenant only has Free licenses, that's the answer.
Security groups can be nested; Microsoft 365 groups cannot. A question asking you to nest a Microsoft 365 group inside another group has no valid solution — the answer is that it isn't supported.
Licenses
Most Entra ID and Microsoft 365 features beyond the basics require licenses: Entra ID P1 or P2, or Microsoft 365 E3/E5 (which include Entra ID P1/P2 respectively). The efficient way to assign them is group-based licensing: you assign the license to a group, and every member automatically receives it. When someone leaves the group, the license is automatically removed. Group-based licensing itself requires Entra ID P1 or P2 for the users receiving licenses through the group — another licensing prerequisite the exam tests.
Remember the usage location rule: a user without a usage location cannot receive a license, whether assigned directly or through a group. When group-based licensing shows errors for specific users, check their usage location and for conflicting service plans (for example, two plans that both include Exchange Online will conflict, and you must disable one).
External and guest (B2B) users
Business-to-business (B2B) collaboration lets you invite users from outside your organization as guest users. Guests sign in with their own identity provider (their company's Entra ID, a Microsoft account, or even a one-time email passcode) and get access to the specific resources you share — a Teams team, a SharePoint site, or an Azure subscription via RBAC.
You invite guests from the Entra admin center (one at a time or in bulk via CSV), from Teams/SharePoint, or programmatically. A guest's UPN takes a distinctive form: fatima_contoso.com#EXT#@fabrikam.onmicrosoft.com — the #EXT# marker identifies external users, which is useful when filtering or writing dynamic group rules (guests are typically excluded from employee dynamic groups with a rule like user.userType -eq "Member").
Control the blast radius of guest access in External collaboration settings: you can restrict who is allowed to invite guests (anyone in the organization, admins only, or specific roles), allow or block specific domains, and limit what guests can see (for example, hiding group memberships they don't belong to). For structured partner access, access packages in Entra ID Governance (P2) let you bundle resources with approval workflows and automatic expiration — the enterprise answer to "a partner needs access for 90 days."
Self-Service Password Reset (SSPR)

Password resets are the single most common helpdesk ticket in most organizations. Self-service password reset lets users reset their own passwords without calling the helpdesk, and on the exam it is a licensing minefield. Get the licensing rules right and half the SSPR questions answer themselves.
Enablement and registration
You enable SSPR in the Microsoft Entra admin center under Password reset, choosing Selected (a pilot group — the recommended rollout approach) or All. Users must register authentication methods before they can use SSPR; you drive registration with the setting "Require users to register when signing in," which prompts them at next sign-in. In modern tenants, SSPR registration is combined with multifactor authentication registration in one converged experience.
When a user resets, the password reset policy controls how many authentication methods they must provide: one or two. Requiring two methods is the stronger choice and is commonly mandated by security baselines.
Authentication methods
The methods an administrator can allow for SSPR include: the Microsoft Authenticator app (notification or code), email, mobile phone (text or call), office phone, and security questions. Here is the trap the exam sets repeatedly: administrators cannot use security questions — for admin accounts, only the stronger methods (Authenticator app, email, mobile phone) are permitted. If a question asks which SSPR method an administrator can register and one option is security questions, eliminate it.
You can also customize the SSPR experience — helpdesk link, custom email, and guidance text — so users see your company's support contact instead of Microsoft's defaults.
Password writeback
For cloud-only users, SSPR just works. For users synced from on-premises Active Directory via Microsoft Entra Connect Sync, there is a catch: without writeback, SSPR can only reset the cloud password, leaving the on-premises password unchanged — which means the user still can't sign in to on-premises systems. Password writeback solves this by writing the new password back to on-premises Active Directory, and it enforces the on-premises password policy too (a reset that violates the on-premises policy fails).
Password writeback has hard prerequisites: Microsoft Entra ID P1 or P2, and writeback enabled in Microsoft Entra Connect Sync. No P1/P2, no writeback — the exam states this as plainly as it gets.
Password writeback requires Entra ID P1 or P2 plus Microsoft Entra Connect Sync with writeback enabled. Without writeback, SSPR for a synced user resets only the cloud password.
The SSPR licensing matrix
Memorize this table — it directly answers a whole family of exam questions:
| Scenario | License required |
|---|---|
| SSPR for cloud-only users | Included with Entra ID Free |
| SSPR for on-premises synced users (without writeback) | Entra ID P1 or P2 |
| Password writeback | Entra ID P1 or P2 |
| SSPR for administrator accounts | Entra ID P1 or P2 |
The pattern: everything beyond basic cloud-user SSPR needs P1 or P2. If a question describes SSPR failing for an administrator or a synced user on a Free tenant, the answer is licensing.
SSPR for administrators requires P1 or P2, and admins cannot use security questions as a reset method. Both facts appear on the exam constantly.
Azure Role-Based Access Control (RBAC)

Azure RBAC controls who can do what to which Azure resources. It is the authorization system for the management plane — creating virtual machines, changing firewall rules, reading resource configurations. Every role assignment has three parts: a security principal (user, group, service principal, or managed identity), a role definition (what actions are allowed), and a scope (where it applies).
Scopes and inheritance
Scopes form a hierarchy: management group → subscription → resource group → resource. A role assignment at a higher scope is inherited by everything below it. Assign Contributor at the subscription scope and the assignee is a Contributor on every resource group and resource in that subscription. This is why you assign broad roles high and narrow roles low: give the database team Contributor on their resource group, not on the whole subscription.
The assignable scope is also where least privilege lives. Need someone to manage access but not resources? That is the User Access Administrator role, not Owner. Need someone to read everything for auditing? Reader. The exam constantly asks for the least-privilege role for a scenario — always choose the narrowest role and the narrowest scope that satisfies the requirement.
Built-in roles
Know these cold:
- Owner: full access to everything, including the right to delegate access to others. There should be very few Owners.
- Contributor: full access to manage resources, but cannot grant access to others (no
Microsoft.Authorization/roleAssignments/write). This is the single most tested distinction — Contributor cannot assign roles. - Reader: can view everything but cannot make any changes. Auditors and monitoring tools live here.
- User Access Administrator: can manage user access to resources (assign roles) but cannot manage the resources themselves. The least-privilege answer whenever someone needs to delegate access without touching resources.
Contributor cannot assign roles. If a user with Contributor tries to grant someone access and fails, the cause is the missing authorization permission — the fix is Owner or User Access Administrator, not a broader resource role.
Management plane vs. data plane
This is the most important RBAC concept on the exam, and the one most administrators get wrong in real life. Azure has two planes:
- The management plane is Azure Resource Manager: creating, deleting, and configuring resources. Contributor and Owner operate here.
- The data plane is the data inside the resource: blob contents in a storage account, secrets in a key vault, messages in a queue. Management-plane roles do not grant data-plane access.
Concrete consequences: a user with Contributor on a storage account can rotate its keys and change its firewall, but cannot read a single blob — for that they need a data-plane role like Storage Blob Data Reader. A user with Contributor on a key vault can manage the vault's settings but cannot read secrets — that requires Key Vault Secrets User (or an access policy, in the older model). When a question says "the user can manage the resource but gets Access Denied reading its data," the answer is always a data-plane role.
Management-plane roles (Owner, Contributor, Reader) never grant data-plane access. Reading blob data needs Storage Blob Data Reader/Contributor; reading key vault secrets needs Key Vault Secrets User. This distinction is tested in multiple questions.
Custom roles
When no built-in role fits, you create a custom role defined in JSON. The key elements:
- Actions: the management-plane operations allowed (for example,
Microsoft.Storage/*/read). - NotActions: subtracted from Actions —
Actions: ["/read"]withNotActions: ["Microsoft.Storage//read"]means "read everything except storage." - DataActions / NotDataActions: the data-plane equivalents.
- AssignableScopes: where the role may be assigned — a custom role can only be assigned at or below its assignable scopes. A role scoped to one resource group cannot be assigned at the subscription level.
Creating or updating custom roles requires Microsoft.Authorization/roleDefinitions/write, which Owner and User Access Administrator hold. Clone a built-in role in the portal as your starting point rather than writing JSON from scratch.
Deny assignments
Deny assignments take precedence over all role assignments — including Owner. A deny assignment blocks specific actions for specific principals even if they hold Owner at the same scope. Deny assignments are created by the platform (for example, by Azure Blueprints-style guardrails and certain managed services), not directly by administrators, but you must know their effect: when access is denied despite an Owner assignment, look for a deny assignment. You can view effective permissions, including deny assignments, with Check access in the Access control (IAM) blade.
Deny beats everything, including Owner. "User is Owner but still gets Access Denied" always points to a deny assignment (or a resource lock — check both).
Azure Policy

If RBAC answers "who can do what," Azure Policy answers "what configurations are allowed to exist." Policy enforces organizational standards — every storage account must use private endpoints, no virtual machine may expose RDP to the internet, all resources must carry a cost-center tag — automatically and continuously.
How Policy works
You create a policy definition (a JSON rule describing a condition and an effect), then create a policy assignment that applies the definition to a scope (management group, subscription, or resource group), optionally with parameters to customize it per assignment (for example, the list of allowed VM SKUs). Policy evaluates resources at creation time and on a periodic compliance scan, reporting each resource as compliant or non-compliant in the compliance dashboard.
Policy effects
The effect determines what happens when a resource violates the rule:
- Deny: blocks the non-compliant deployment or configuration change outright. The strongest enforcement — use it for security non-negotiables.
- Audit: allows the resource but flags it as non-compliant. Use it when you want visibility before enforcement, or for rules you can't yet enforce.
- Append: adds the specified fields to a resource when it is created (commonly used to add tags).
- Modify: changes a resource's properties, including on existing resources — the only effect (along with DeployIfNotExists) that can remediate.
- DeployIfNotExists: deploys a related resource when a condition is met — the classic example is deploying the Log Analytics agent or a diagnostic setting to every VM. It uses a managed identity on the assignment to perform the deployment, and you pair it with a remediation task to fix resources that already exist.
Only Modify and DeployIfNotExists can change or add resources; Audit and Deny only block or flag. If a question asks which effect automatically fixes existing non-compliant resources, it's DeployIfNotExists (with a remediation task) or Modify.
Initiatives, exemptions, and compliance
An initiative (policy set definition) bundles multiple policy definitions into one assignable unit — for example, the "NIST SP 800-53" initiative contains dozens of individual policies. You assign the initiative once instead of managing dozens of assignments, and you can set parameter values per policy within it.
Exemptions carve out exceptions: a specific resource, resource group, or scope that should not be evaluated against a policy. Every exemption has a category: Waiver (the target was never compliant and won't be — a permanent, approved exception) or Mitigated (the target was non-compliant but the risk was addressed through other means). Exemptions can have an expiration date, so temporary exceptions automatically lapse — always set one for time-bound waivers.
The compliance dashboard shows per-assignment and per-resource compliance state. Non-compliant resources from DeployIfNotExists or Modify policies can be fixed in bulk with a remediation task, which re-runs the policy's deployment logic against them.
Resource Locks, Tags, and Organization

Resource locks
Locks protect resources from accidental deletion or modification. There are exactly two kinds:
- CanNotDelete: users can read and modify the resource but cannot delete it. Deleting the resource — or deleting its parent resource group — is blocked.
- ReadOnly: users can only read. No modifications, no deletions. ReadOnly is the stronger lock: it even blocks actions you might not expect, such as listing storage account keys (a write operation) or restarting a virtual machine.
Locks are inherited: a lock on a resource group applies to every resource inside it. When both lock types apply at different scopes, the most restrictive wins — a ReadOnly lock on the resource group overrides a CanNotDelete lock on the resource itself. To manage locks (create or delete them), you need Microsoft.Authorization/locks/*, held by Owner and User Access Administrator — Contributors cannot remove locks, which is precisely the point.
ReadOnly is stronger than CanNotDelete, locks inherit from parent scopes, and the most restrictive lock wins. A VM that can't be restarted despite no lock on the VM itself has an inherited ReadOnly lock above it.
Tags
Tags are name-value pairs (for example, CostCenter: Finance, Environment: Production) used for organization, cost reporting, and automation. The limits are fixed and testable: 50 tags per resource or resource group, tag names up to 512 characters, values up to 256 characters. Key facts:
- Tags do not inherit — a resource group tagged
Environment: Productiondoes not pass that tag to the resources inside it. (Use an Azure Policy with the Append or Modify effect to push tags down.) - Tags travel with a resource when it moves to another resource group.
- There is no rename operation for a tag — you must add the new tag and remove the old one.
- Tags never grant or restrict access; they are metadata, not security.
Resource groups and subscriptions
A resource group is a logical container for resources that share a lifecycle — deploy them together, manage access together, delete them together. Practical rules: a resource group can hold resources from multiple regions (the resource group's own location only determines where its metadata is stored); a subscription holds up to 980 resource groups; and Azure retains up to 800 deployments in a resource group's deployment history.
Resources can be moved between resource groups and between subscriptions, but only within the same Microsoft Entra tenant, and both the source and destination must not be locked. Some resource types don't support moves at all — always check the move-support documentation for the specific resource type before promising a migration.
Subscriptions are billing and access boundaries: each subscription has its own invoice, its own administrators, and its own quota. Organize subscriptions by purpose (production vs. development), by department, or by billing owner — and then manage them at scale with management groups.
Management Groups

When you have dozens of subscriptions, managing policy and access one subscription at a time doesn't scale. Management groups create a hierarchy above subscriptions so a single policy assignment or RBAC assignment applies to everything underneath.
The hierarchy has strict rules:
- Every directory has a single root management group (the tenant root). It cannot be moved or deleted, and every subscription sits under it by default.
- Maximum 10,000 management groups in a single directory.
- Maximum 6 levels deep, excluding the root — plan your hierarchy (for example: root → regions → business units → environments) within that depth.
- Each management group and subscription has exactly one parent — it's a tree, not a graph.
- Policy assignments and RBAC assignments on a management group are inherited by all child management groups, subscriptions, resource groups, and resources.
Design guidance: keep the hierarchy shallow and aligned to how the business is actually organized and billed. A common pattern is root → platform/landing-zone vs. workloads → business unit → environment (production/non-production). Put guardrail policies (allowed regions, required tags, deny public storage) at the highest level that makes sense, and let individual teams manage their own subscriptions below.
Management groups: 10,000 per directory, 6 levels deep (excluding root), single parent each, and policy/RBAC inherit downward. A question asking for one policy across 50 subscriptions is always answered with a management group assignment.
Moving a subscription between management groups requires RBAC permission on both the subscription and the target management group, and the move re-evaluates inherited policies — a subscription landing under a "deny public IPs" policy will immediately flag its non-compliant resources.
Cost Management

Administrators don't just keep Azure running — they keep it affordable. This objective covers budgets, alerts, and the tools that find wasted spend.
Budgets and alerts
A budget sets a spending threshold for a scope (management group, subscription, or resource group) over a period (monthly, quarterly, annually). You configure alerts at percentage thresholds of the budget — for example, email the finance team at 50%, 80%, 90%, and 100% of the monthly budget. Budgets support two alert types: actual (based on spend so far) and forecast (based on projected spend, which fires before you actually overshoot). Forecast alerts are the early-warning system — an 80% forecast alert tells you you're on track to exceed the budget, while there's still time to act.
Budget alerts use action groups for notification, so the same alert can email people, trigger a webhook, or run an automation runbook that shuts down dev VMs.
Azure Advisor cost recommendations
Azure Advisor continuously analyzes your usage and produces recommendations, including a dedicated Cost category: right-size or shut down underutilized virtual machines, delete unattached managed disks (you pay for provisioned disk storage whether it's attached or not), and similar findings. Advisor recommendations are advisory, not automatic — you decide what to apply. On the exam, "identify wasted spend" scenarios point to Advisor; "enforce" scenarios point to Policy.
Reservations, savings plans, and Spot
Pay-as-you-go is the most expensive way to run steady workloads. The discounts, in increasing commitment order:
- Spot VMs: spare Azure capacity at up to ~90% discount, but Azure can evict your VM with 30 seconds' notice when capacity is needed. Only for fault-tolerant, interruptible workloads (batch jobs, rendering, dev/test).
- Reserved instances: commit to 1 or 3 years of a specific VM family/region (or database) for a large discount — typically up to ~70% off pay-as-you-go. Best for predictable, always-on production workloads.
- Azure savings plans for compute: commit to a fixed hourly spend for 1 or 3 years, applied flexibly across VM families and regions — the middle ground between rigid reservations and pay-as-you-go.
Match the discount to the workload: Spot = interruptible batch work (eviction risk); Reservations = steady, predictable production (1/3-year commitment); pay-as-you-go = variable or short-lived. Advisor finds the waste; budgets warn you about it.
Worked Examples

Example 1: Least-privilege access for a partner team
Scenario: Contoso's partner Fabrikam needs to deploy and manage resources in the fabrikam-partner resource group for 90 days. A Contoso administrator, Amara, must set this up but should not grant more access than necessary. The partner's lead, Jonas, needs to manage resources in the resource group and invite his own team members to it.
Reasoning:
- Identity first. Jonas is external, so Amara invites him as a B2B guest user. She checks external collaboration settings to confirm guest invitations are allowed, and notes the 90-day requirement — an access package with expiration would be the enterprise answer, but a direct RBAC assignment with a calendar reminder to revoke works for the exam scenario.
- Resource access. Jonas needs to manage resources in one resource group: Contributor at the resource-group scope. Not Owner (he doesn't need to manage access... except he does — he needs to invite his team).
- Delegation. Jonas must grant access to his team members. Contributor cannot assign roles, so Jonas also needs User Access Administrator at the resource-group scope. The least-privilege combination is Contributor + User Access Administrator scoped to
fabrikam-partner— never Owner, never subscription scope. - Data plane check. If the partner's app reads blobs, Contributor isn't enough — Jonas's team would also need Storage Blob Data Reader on the storage account.
Answer: Invite Jonas as a B2B guest; assign Contributor + User Access Administrator at the resource-group scope (add Storage Blob Data Reader if blob data access is needed).
Example 2: Enforcing standards across 40 subscriptions
Scenario: Contoso has 40 subscriptions across three business units. Security requires: (1) no storage account may allow public blob access, (2) every resource must carry a CostCenter tag, (3) all activity must be audited before enforcement begins.
Reasoning:
- Scale mechanism. One assignment covering 40 subscriptions means a management group. Create a management-group hierarchy (root → business units), move the subscriptions under it, and assign at the management-group level — policy and RBAC inherit downward.
- No public blob access. Assign a built-in policy with Deny effect (security non-negotiable). But requirement 3 says audit before enforcement — so first assign with Audit effect to measure the blast radius, review compliance, then switch to Deny.
- Required tag. A Modify policy (or Append) that adds the
CostCentertag. Since tags don't inherit, policy is the mechanism that pushes them to resources. Pair it with a remediation task to tag the resources that already exist. - Exemptions. The legacy archive subscription gets a Waiver exemption (it will never comply); the subscription mid-migration gets a Mitigated exemption with an expiration date.
Answer: Management-group-scoped assignments; Audit first then Deny for the storage rule; Modify + remediation task for tags; Waiver and time-bound Mitigated exemptions where justified.
Example 3: The mysterious undeletable VM
Scenario: An administrator with the Owner role tries to delete a virtual machine and gets an error. The VM has no lock on it. The resource group has a ReadOnly lock.
Reasoning:
- Owner should be able to delete anything — unless something outranks the role assignment. Two candidates: a deny assignment or a resource lock.
- There is a ReadOnly lock on the resource group. Locks inherit to all child resources, and ReadOnly is the most restrictive lock — it blocks deletion (and modification) of everything beneath it, including this VM.
- The fix: someone with
Microsoft.Authorization/locks/delete(Owner or User Access Administrator — which this admin has) removes the ReadOnly lock from the resource group, then deletes the VM. Note the trap: a CanNotDelete lock would also block deletion, but ReadOnly blocks even more.
Answer: The inherited ReadOnly lock on the resource group blocks the deletion. Remove the lock, then delete the VM.
End-of-Chapter Test
1. You need to create 200 user accounts in Microsoft Entra ID for new hires. What is the most efficient method? A) Create each user manually in the Entra admin center B) Upload a CSV file using the bulk create operation C) Email the list to Microsoft support D) Create a dynamic group and add the users to it
2. A user has only a Microsoft Entra ID Free license and is a cloud-only account. They need to use self-service password reset. What is required? A) Upgrade the user to Entra ID P1 B) Enable password writeback in Microsoft Entra Connect Sync C) Nothing extra — SSPR for cloud users is included with Free D) Assign the user the Global Administrator role
3. Your organization syncs users from on-premises Active Directory. A synced user resets their password via SSPR, but password writeback is not configured. What happens? A) Both the cloud and on-premises passwords are reset B) Only the cloud password is reset; the on-premises password is unchanged C) The reset fails entirely D) The user is converted to a cloud-only account
4. A user with the Contributor role on a subscription tries to assign the Reader role to a colleague. The assignment fails. Why? A) The colleague must be in the same resource group first B) Contributor does not include permission to assign roles C) Role assignments can only be made at the management group scope D) The subscription has too many role assignments
5. A user has Contributor access on a storage account and tries to read a blob's contents. Access is denied. What is the least-privilege fix? A) Assign the Owner role on the storage account B) Assign the Storage Blob Data Reader role on the storage account C) Assign the Contributor role at the subscription scope D) Regenerate the storage account keys
6. You create a custom RBAC role with assignableScopes set to a single resource group. You then try to assign it at the subscription scope. What happens? A) The assignment succeeds and applies to the whole subscription B) The assignment fails because the scope is outside the role's assignableScopes C) The assignment succeeds but only applies to the resource group D) The role is automatically promoted to subscription scope
7. A user holds the Owner role on a resource group but is denied when trying to delete a resource. There are no resource locks. What is the most likely cause? A) The user needs the Contributor role instead B) A deny assignment is blocking the action C) The resource group is in a different region D) Owner cannot delete resources, only manage them
8. You need an Azure Policy that blocks any virtual machine deployment exposing RDP to the internet. Which policy effect should you use? A) Audit B) Append C) Deny D) Modify
9. You want existing non-compliant virtual machines to automatically receive a required CostCenter tag. Which policy effect, combined with a remediation task, accomplishes this? A) Audit B) Deny C) Append D) Modify
10. A resource group has a CanNotDelete lock, and a virtual machine inside it has a ReadOnly lock. An administrator tries to restart the VM. What happens? A) The restart succeeds because CanNotDelete is weaker B) The restart is blocked by the ReadOnly lock on the VM C) The restart succeeds because locks only block deletion D) The restart is blocked by the CanNotDelete lock on the resource group
11. Your company has 60 subscriptions and you need to apply the same set of Azure Policy definitions to all of them with a single assignment. What should you do? A) Create 60 separate policy assignments, one per subscription B) Assign the policies at the management group level above the subscriptions C) Assign the policies to each resource group individually D) Use Azure Blueprints to deploy the policies
12. A production virtual machine runs 24/7 with predictable utilization. Which purchasing option gives the largest discount? A) Pay-as-you-go B) Spot VM C) 3-year reserved instance D) Azure Hybrid Benefit alone
Answer Key
1. B — Bulk create via CSV is the designed method for mass user creation; manual creation doesn't scale and groups don't create users.
2. C — SSPR for cloud-only users is included with Entra ID Free. P1/P2 is only needed for synced users, writeback, or admin SSPR.
3. B — Without password writeback, SSPR resets only the cloud password; the on-premises AD password is untouched.
4. B — Contributor lacks Microsoft.Authorization/roleAssignments/write. Assigning roles requires Owner or User Access Administrator.
5. B — Blob data is the data plane. Storage Blob Data Reader grants exactly the needed read access; Contributor is management-plane only.
6. B — A custom role can only be assigned at or below its assignableScopes. Subscription scope is outside a resource-group-scoped role.
7. B — Deny assignments take precedence over all role assignments, including Owner. With no locks present, a deny assignment is the cause.
8. C — Deny blocks non-compliant deployments outright, which is what "blocks" requires. Audit would only flag it.
9. D — Modify changes resource properties on existing resources; paired with a remediation task it tags what's already deployed. (DeployIfNotExists is for deploying related resources, not editing tags.)
10. B — ReadOnly is the most restrictive lock and blocks all modifications including restarts. The most restrictive lock wins regardless of scope.
11. B — A single policy assignment at the management group scope inherits down to all subscriptions beneath it.
12. C — A 3-year reservation gives the deepest discount for steady 24/7 workloads. Spot is cheaper per hour but the VM can be evicted, making it unsuitable for production.
Answer key
Want the full Microsoft Azure Administrator (AZ-104) package?
This guide is free to read. Get the downloadable PDF guidebook plus the full 730-question AZ-104 practice exam with 3 months of online access.
Get AZ-104 Full Access — $10