1.1 — Foundation

Microsoft Entra ID

The cloud-native identity and access management backbone of Azure. Every user, app, or service that touches Azure resources must authenticate through Entra ID. Every subscription trusts exactly one tenant.

Let's talk about Microsoft Entra ID, and I want to start with why this exists before we define what it is. Imagine running a company in 2024. Your team uses Microsoft 365, Azure, Salesforce, GitHub, and twenty other tools. Without a central identity system, each tool has its own username and password. When someone leaves the company, IT has to manually deactivate accounts across all 20 systems. Miss one, and that ex-employee still has access to your customer data. That is the problem Entra ID solves. It is a cloud-based identity and access management service. One central place where you manage who people are and what they are allowed to do, across every application your organisation uses. Entra ID is NOT the cloud version of your on-premises Active Directory. They are completely different systems. On-premises AD uses Kerberos and NTLM, old protocols built for internal networks. Entra ID uses OAuth2, OIDC, and SAML, protocols built for the internet. You do not install Entra ID on a server. Microsoft runs it for you. When your organisation signs up for Azure, Azure creates a Tenant, your organisation's private isolated directory in the cloud. Everything lives inside your tenant. Other organisations cannot see into it. Entra ID enables three key things. First, Single Sign-On. Sign in once and you are into Microsoft 365, Azure Portal, Salesforce, GitHub, all of it. Second, Conditional Access. Write policies like: block access from unknown countries, but allow access from corporate devices on the office network. This requires P1 licence. The free tier does not have it. Third, Multi-Factor Authentication. Require a second factor before granting access. This is the single most effective control against password attacks.. For Kube context: your Okta instance federates into Entra ID. When you log in through Okta, Okta sends a SAML assertion to Entra ID saying I have verified this user. Entra ID trusts Okta and grants access to Azure resources without you needing a separate password.. Exam critical: Free tier has no Conditional Access and no PIM. P1 adds Conditional Access. P2 adds Privileged Identity Management for time-limited elevated access.. Remember: Entra ID is cloud-native identity, not cloud AD DS. Tenant is your isolated directory. Conditional Access needs P1. PIM needs P2.

📖 Microsoft Entra ID — Complete Explanation

Microsoft Entra ID (formerly Azure Active Directory) is a cloud-native Identity and Access Management (IAM) service — fundamentally different from on-premises Active Directory Domain Services.

Tenant: When your organisation signs up for any Microsoft cloud service, Azure creates a dedicated tenant — an isolated directory instance. Think of it as your organisation's private phonebook in the cloud. Every user, group, application, and device lives in this tenant. Your tenant gets a unique domain like yourcompany.onmicrosoft.com.

Why not just use AD DS? AD DS was built for on-premises networks using Kerberos/NTLM. It requires line-of-sight to domain controllers and manages computers joined to a domain. Entra ID uses HTTPS/OAuth2/OIDC/SAML — protocols designed for the internet. No domain controller needed. Works from any browser, anywhere.

Kube context: Your Okta instance federates into Entra ID. When Kiran logs in via Okta, Okta sends a SAML assertion to Entra ID. Entra ID trusts Okta as a federated identity provider and grants access to Azure resources — without Kiran needing a separate Entra ID password.

🏢

The Metaphor

Think of Entra ID as your company's HR department. It issues ID cards (identities), verifies who you are, and decides which buildings (subscriptions) you're allowed to enter. Without HR clearing you, no door opens — no matter what you try.

Architecture — Entra ID Tenant Structure

Entra ID vs On-Premises AD DS

🔑

The Metaphor

AD DS is like a physical key locker room inside your office — your morning badge gets you Kerberos tickets that open internal doors. Step outside and those keys are useless.

Entra ID is a digital ID on your phone — works anywhere in the world over internet, verifiable by any trusted app, no physical office required.

Feature	AD DS (On-Premises)	Entra ID (Cloud)
Location	Your servers (Domain Controllers)	Microsoft cloud
Protocol	Kerberos / NTLM	OAuth 2.0 / OIDC / SAML
Manages	Windows PCs, domain, on-prem resources	Cloud apps, Azure, SaaS
Group Policy	✓ Yes	✗ No (uses Intune instead)
Azure RBAC	✗ No	✓ Yes
MFA built-in	✗ No	✓ Yes
Remote access	VPN required	Works from anywhere
Managed by	Your IT team	Microsoft

💡

Hybrid Identity

Most enterprises run BOTH. Microsoft Entra Connect syncs users from on-prem AD DS to Entra ID automatically. Same username works on your laptop login (Kerberos) AND Azure Portal (OIDC). Your Regal Rexnord laptops are almost certainly using Hybrid Identity.

License Tiers: Free → P1 → P2

🏗️

The Metaphor

Free = basic lock and key. Gets the job done.
P1 = smart locks with rules — "only let people in during business hours, only if on company laptop".
P2 = full surveillance + just-in-time access + risk intelligence.

Feature	Free	P1	P2
Users, Groups, Basic RBAC	✓	✓	✓
Basic MFA	✓	✓	✓
SSPR (cloud-only)	✓	✓	✓
SSPR (on-prem writeback)	✗	✓	✓
Conditional Access	✗	✓ P1	✓
Dynamic Groups	✗	✓ P1	✓
Group-based licensing	✗	✓ P1	✓
PIM (just-in-time)	✗	✗	✓ P2
Identity Protection	✗	✗	✓ P2
Access Reviews	✗	✗	✓ P2

⚠️

Most Common Exam Trap — License Tiers

Conditional Access = P1 (NOT P2). Most people guess P2. PIM = P2. Identity Protection = P2. Remember: P1 = smart access rules. P2 = risk intelligence + just-in-time.

1.2 — Identity Types

Managed Identities, Service Principals & WIF

Azure has multiple identity types for non-human authentication. Choosing the right one eliminates secrets, rotation overhead, and security risk.

Identity Types — When to Use What

Managed Identity

🏷️

The Metaphor

A Managed Identity is like a staff ID card that Azure prints and manages automatically for a resource. The Function App carries this card to get into other Azure buildings (Key Vault, Storage, Service Bus). No password. No expiry. Azure renews it silently.

System-Assigned

Tied to Resource Lifecycle

Created automatically when you enable it on a resource. Deleted when the resource is deleted. Good for single-use scenarios. If the VM dies, the identity dies too.

User-Assigned

Independent, Reusable

Created separately as an Azure resource. Can be attached to multiple resources simultaneously. Survives resource deletion. Best practice for production — if Function App crashes, identity still exists, re-attach and everything works.

⚠️

Real Production Failure — Managed Identity Deleted

Function App has system-assigned MI. Someone deletes the MI from Entra. App still runs. But every call to Key Vault/Storage/Service Bus fails with 401/403. App looks healthy in metrics but is operationally dead. Fix: re-enable system-assigned MI (new object ID) and reassign roles.

Workload Identity Federation (WIF) — ADO Best Practice

🔐

The Metaphor

Old way (SP + Secret): ADO shows up at Azure's door with a password written on a piece of paper. If someone steals that paper, they get in forever.

WIF: ADO shows up and says "I am ADO pipeline #XYZ from org Kube, running job #42." Azure calls Microsoft's identity system to verify the claim live. No password involved. Like showing a government-issued digital ID that gets verified in real time.

WIF Authentication Flow

ADO — Create WIF Service Connection

# In Azure DevOps:
Project Settings → Service Connections → New Service Connection
→ Azure Resource Manager
→ Workload Identity Federation (automatic)
→ Select Subscription → Done

# ADO auto-creates:
# 1. App Registration in Entra ID
# 2. Federated Credential on App Registration
# 3. Contributor role on selected subscription/RG

# Verify in Azure CLI:
az ad app list --display-name "your-ado-org-project" --query "[].{Name:displayName,AppId:appId}"

1.3 — Access Control

Role-Based Access Control

MS Docs

RBAC controls what identities can DO and WHERE. Every assignment = WHO + WHAT ROLE + WHERE (SCOPE). Permissions flow DOWN the hierarchy, never up.

Role-Based Access Control, RBAC, answers one question: who is allowed to do what, and where. Every RBAC assignment has exactly three components. The Who, which is a user, group, service principal, or managed identity. The What, which is a Role, a collection of permissions. And the Where, which is a Scope. The scope hierarchy has four levels: Management Group at the top, then Subscription, then Resource Group, then individual Resource. The critical rule: permissions flow downward. Assign Contributor at the Subscription level, and that user automatically has Contributor access to every Resource Group and Resource inside that subscription. One assignment at the top, coverage everywhere below. Built-in roles you must know: Owner has full control including assigning roles to others. Contributor can create and manage everything except assign roles. Reader can view everything but change nothing. And specific roles like Virtual Machine Contributor cover only VM operations. The gotcha that catches everyone: Owner at the management plane does NOT mean access to data inside resources. If you are Owner of a Key Vault, you can manage the vault resource itself, but you cannot read the secrets stored inside it. For that you need the Key Vault Secrets User role, a data plane role. Management plane and data plane are completely separate. This distinction is tested heavily on AZ-104. RBAC is additive. Reader from one group plus Contributor from another group means you get Contributor. The only way to explicitly block something is a Deny assignment, which overrides everything. Best practice: assign roles to groups, not individual users. New person joins DevOps team, add them to the group. They inherit all RBAC assignments automatically. Someone leaves, remove from group. One action, access revoked everywhere. Always use Least Privilege. Need to read storage blobs, use Storage Blob Data Reader, not Contributor.. Remember: WHO does WHAT WHERE. Permissions flow down. Management plane and data plane are separate. Assign to groups. Least privilege always.

🚪

The Metaphor

Entra ID is the HR department that issues ID cards. RBAC is the access rules on every door in the building. Your badge (identity) gets you through the front door. RBAC decides: can you enter Floor 3 (Subscription)? Can you enter Room 12 (Resource Group)? Can you open the filing cabinet (Resource)? Can you READ files, or also EDIT and DELETE?

RBAC Scope Hierarchy — Permissions Flow Down

Animated — Permission inheritance: assign once at top, flows to everything below

Core Built-in Roles

Role	Create/Modify	Delete	Manage RBAC	Read	Common Use
Owner	✓	✓	✓ Can assign roles	✓	Team leads, pipeline SPs needing RBAC
Contributor	✓	✓	✗ Cannot assign roles	✓	Developers, pipeline service connections
Reader	✗	✗	✗	✓	Auditors, stakeholders, monitoring
User Access Admin	✗	✗	✓ RBAC only	✓	Assign roles without full Owner

⚠️

Management Plane vs Data Plane — Most Missed Concept

Contributor on Key Vault ≠ can read secrets.
Reader on Storage Account ≠ can read blobs.

Management plane (RBAC) controls: create/delete the resource, change settings.
Data plane controls: read/write the actual data inside the resource.

To read KV secrets → need Key Vault Secrets User role.
To read blobs → need Storage Blob Data Reader role.
These are separate, additional role assignments.

Custom Roles

JSON — Custom Role Definition

{
  "Name": "Kube-FunctionApp-Deployer",
  "Description": "Can deploy and restart Function Apps only",
  "Actions": [
    "Microsoft.Web/sites/read",
    "Microsoft.Web/sites/write",
    "Microsoft.Web/sites/restart/action",
    "Microsoft.Web/sites/publishxml/action"
  ],
  "NotActions": [
    "Microsoft.Web/sites/delete"    // explicitly excluded (not a Deny)
  ],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>"
  ]
}

# Create custom role
az role definition create --role-definition custom-role.json

# Assign it
az role assignment create \
  --assignee kiran@kube.com \
  --role "Kube-FunctionApp-Deployer" \
  --scope /subscriptions/<id>/resourceGroups/RG-Prod/providers/Microsoft.Web/sites/kube-func-prod

1.4 — Governance

Azure Policy

MS Docs

RBAC controls what people can DO. Azure Policy controls what resources can BE. Even Owner-level users are blocked by Deny policies. Policy governs resource properties — RBAC governs user actions.

🏙️

The Metaphor

RBAC is your office keycard system. Azure Policy is the city building code. Even if you own the building and have all the keys, you cannot build without windows, you cannot use illegal materials, and every floor must have a fire exit. The building inspector (Policy) doesn't care who you are — they only care if the resource meets the rules.

Effect	Blocks Creation?	Fixes Existing?	Real Use Case
Deny	✓ Yes	✗ No	No resources outside East US — hard block
Audit	✗ No	✗ No	Flag untagged resources — visibility only
Modify	✗ No	✓ Via remediation	Auto-add/fix tags on new AND existing resources
Append	✗ No	✗ No	Add fields at creation time only (no existing)
DeployIfNotExists	✗ No	✓ Via remediation	Auto-deploy Log Analytics agent to every VM
AuditIfNotExists	✗ No	✗ No	Check if related resource exists (e.g. VM has backup)
Disabled	✗ No	✗ No	Policy turned off

⚠️

Append vs Modify — Most Missed Difference

Append: adds at creation ONLY — cannot fix existing resources.
Modify: adds/replaces AND can remediate existing resources via remediation task.
If the question says "fix existing" → always Modify, never Append.

💡

Remediation Task Requirement

Modify and DeployIfNotExists effects need a Managed Identity on the policy assignment to make changes on your behalf. Azure auto-creates this during remediation task setup. The MI needs Contributor or Tag Contributor on the target scope.

1.5 — Protection

Resource Locks

MS Docs

Locks are the last line of defense against human error. Even Owner cannot bypass a lock — it must be explicitly removed first.

🔒

The Metaphor

RBAC is the key to the medicine cabinet. Azure Policy is the prescription rules. Resource Lock is the childproof safety cap on the bottle itself. Even if you have the key and the medicine is allowed — that safety cap makes you stop and think. Some caps you simply cannot remove without specific authority.

CanNotDelete

Delete Protected

Users CAN read the resource. Users CAN modify it. Users CANNOT delete it.

Use: production databases, Key Vaults, critical VNets. "You can change config but you cannot destroy it."

ReadOnly

Full Protection

Users CAN read the resource. Users CANNOT modify it. Users CANNOT delete it.

⚠️ Much more destructive than it sounds — see traps below.

⚠️

ReadOnly Breaks Unexpected Things

ReadOnly on a Storage Account breaks: listing keys, creating SAS tokens, autoscale writing to VMSS, ADO pipeline deployments, Azure Backup creating recovery points.

"Read" in ReadOnly means literal reads only — even operations that feel like reads but are technically writes will fail.

Never put ReadOnly on an entire subscription — it will silently break pipelines, autoscale, monitoring agents, and backups.

          
          Azure CLI — Resource Locks
        
# Apply CanNotDelete lock on Resource Group
az lock create \
  --name "prod-rg-lock" \
  --resource-group RG-Kube-Prod \
  --lock-type CanNotDelete \
  --notes "Production RG — deletion locked"

# List all locks on a resource group
az lock list \
  --resource-group RG-Kube-Prod \
  --output table

# Delete lock (must do this before deleting the resource)
az lock delete \
  --name "prod-rg-lock" \
  --resource-group RG-Kube-Prod

1.6 — Structure

Subscriptions & Management Groups

🏢

The Metaphor

Management Group = the property management company overseeing multiple buildings. Sets rules that apply to ALL buildings under it.
Subscription = an individual office building with its own address and bill.
Resource Group = a floor or department inside the building.

Kube platform — Recommended Management Group Structure

1.7 — Users & Groups

User Types, Groups & SSPR

Understanding user types and group mechanics is essential — they are the foundation for dynamic access control at scale.

Groups — Static vs Dynamic

👥

The Metaphor

Static group = a club with a doorman checking a printed invite list. Admin adds/removes members manually.

Dynamic group = an automatic filter — "anyone with the job title 'DevOps Engineer' is automatically a member." HR changes your title → you're in or out instantly. No admin action needed.

Type	Members Added By	License	Best For
Assigned (Static)	Admin manually	Free	Small teams, ad-hoc groups
Dynamic User	Attribute rule (dept, title, email suffix)	P1 required	Auto-access for new hires by department
Dynamic Device	Device attribute rule (OS, model)	P1 required	Conditional Access based on device type

Azure CLI — Create Dynamic Group

# Create dynamic group — all DevOps users auto-join
az ad group create \
  --display-name "Kube-DevOps-Team" \
  --mail-nickname "kube-devops" \
  --description "Auto-populated by department attribute"

# Set dynamic membership rule (done in portal or Graph API)
# Rule: (user.department -eq "DevOps")
# OR multi-condition:
# (user.department -eq "DevOps") -or (user.department -eq "Platform")

# Assign RBAC to group (not individual users)
az role assignment create \
  --assignee "<group-object-id>" \
  --role "Contributor" \
  --scope "/subscriptions/<sub-id>/resourceGroups/RG-Dev"

💡

Dynamic Group Processing Delay

Dynamic group membership can take up to 24 hours to propagate after an attribute change. For immediate access requirements, manually add the user to an assigned group as a temporary measure.

Self-Service Password Reset (SSPR)

🔑

The Metaphor

Without SSPR: user forgets password → calls helpdesk → helpdesk resets → 30 min delay. Multiply by 500 users per year = massive cost.

With SSPR: user proves identity (phone OTP, authenticator, email code) → resets own password instantly. Helpdesk call avoided entirely.

Scenario	License	Notes
Cloud-only user SSPR	Free (limited), P1 full	User resets their Entra ID password
SSPR with on-prem writeback	P1 required	Password syncs back to on-prem AD DS via Entra Connect
Admin account SSPR	Built-in	Always requires 2 auth methods (hardcoded by Microsoft)

📋

SSPR Authentication Methods

Methods available: Authenticator App (code or notification), SMS, Email (external), Security Questions, OATH hardware tokens. Admin accounts always need 2 methods regardless of policy — Microsoft enforces this and you cannot override it.

Bulk User Operations

Bulk Create / Invite / Delete

CSV-Based Bulk Operations

Portal: Entra ID → Users → Bulk operations → Download CSV template → Fill → Upload.

Available operations: Bulk create (new users), Bulk invite (guest B2B), Bulk delete.

CLI equivalent: PowerShell New-AzureADUser in a loop, or Graph API PATCH requests.

Exam note: Large-scale user provisioning = System for Cross-domain Identity Management (SCIM) via Enterprise Applications.

1.8 — Devices

Device Management

MS Docs

Conditional Access policies often make decisions based on device state. Understanding join types is critical for those policies to work correctly.

Device Join Types — Where Devices Are Registered

📋

Exam Angle — Device Compliance

Conditional Access "Require compliant device" only works for Entra Joined or Hybrid Entra Joined devices managed by Intune. Entra Registered BYOD devices can be marked compliant only if Intune manages them. A personal phone not enrolled in Intune cannot be "compliant" regardless of registration.

1.9 — Governance

Tags & Cost Management

Resource Tags

Metadata for Governance

Tags = key-value pairs on any Azure resource.
Max 50 tags per resource.
Tags do NOT inherit to child resources automatically — must apply explicitly or use Policy (Modify effect).

Common tags at Kube:
Environment: Production
CostCenter: IoT-Platform
Owner: Kiran
Project: AIP3-TTI4

Cost Management

Budgets & Alerts

Azure Cost Management allows setting budgets with alerts at subscription, resource group, or tag level.

Budget alert types:
Cost alert: fires when actual spend reaches % of budget
Forecast alert: fires when projected spend will exceed budget

Action: email notification OR trigger Action Group (run Logic App, Function, Webhook)

          
          Azure CLI — Tags & Budget
        
# Apply tags to Resource Group
az tag create \
  --resource-id "/subscriptions/<id>/resourceGroups/RG-Kube-Prod" \
  --tags Environment=Production CostCenter=IoT-Platform Owner=Kiran

# List resources by tag
az resource list \
  --tag "Environment=Production" \
  --output table

# Create budget with alert at 80% of $500/month
az consumption budget create \
  --budget-name "Kube-Prod-Monthly" \
  --amount 500 \
  --time-grain Monthly \
  --start-date "2026-01-01" \
  --end-date   "2027-01-01" \
  --threshold 80 \
  --contact-emails kiran@kube.com

⚠️

Tags Do NOT Inherit — Common Governance Failure

Adding a CostCenter tag to a Resource Group does NOT tag the VMs, storage accounts, or databases inside it. Each resource needs its own tag. Fix: use Azure Policy with Modify effect to inherit parent RG tags to child resources automatically via remediation task.

1.10 — Governance

Azure Blueprints

MS Docs

📐

The Metaphor

Imagine you're opening 10 new office branches. Instead of setting up each one manually (installing the same locks, same furniture, same security cameras), you use a master blueprint that defines everything. Apply the blueprint → new branch is fully configured and compliant instantly. Modify the blueprint → all branches update.

What Blueprints Package Together

One Assignment = Complete Environment

A Blueprint combines: Resource Groups + ARM Templates + RBAC assignments + Azure Policies into a single versioned artifact.

Use case: every new project subscription needs — Dev/QA/Prod resource groups, tagging policy, budget alert, Contributor role for dev team, Log Analytics workspace ARM template. Assign the Blueprint = all of this created in one action.

Blueprint Lock: unlike normal resource locks, Blueprint-applied locks cannot be removed even by Owner — only by unassigning the Blueprint itself. This is the strongest protection available.

📋

Blueprints vs ARM Templates vs Policy

ARM Template: deploys resources. No RBAC, no Policy bundled.
Azure Policy: governs resource properties. No deployment.
Blueprint: packages ARM + Policy + RBAC + RGs together. Versioned. Audited. Lock cannot be removed by Owner.

Note: Microsoft is migrating Blueprints functionality to Template Specs + Azure Policy. Blueprints still tested on AZ-104.

Exam Prep

Phase 1 — Exam Q&A

Click any question to reveal the answer. These are exam-style questions based on actual AZ-104 patterns from the last 2-3 years.

Q A company wants to ensure users can only access the Azure portal from managed devices. What is required?

ANSWER

Entra ID P1 license + Conditional Access Policy.

Conditional Access is a P1 feature. The policy would be: IF signing into Azure Portal AND device is NOT compliant or NOT Entra Joined → THEN block access or require MFA.

⚠️ Trap: Many choose P2. Conditional Access = P1. PIM = P2.

Q After transferring a subscription to a new Entra tenant, admins cannot access resources. What is the most likely cause?

ANSWER

All RBAC role assignments are deleted during tenant transfer.

Resources remain intact. Managed identities are deleted. Service principals are deleted. All role assignments are permanently deleted. Must reassign after transfer.

⚠️ Billing transfer (same tenant) = RBAC stays. Tenant transfer = RBAC deleted. Know the difference.

Q A contributor on a Key Vault reports they cannot read secrets despite having full access to the resource. What is missing?

ANSWER

Contributor is a management plane role. Reading secrets requires the Key Vault Secrets User data plane role.

Assign "Key Vault Secrets User" role on the Key Vault resource. If using the old Access Policies model (not RBAC), add Get/List permissions in the Access Policies tab instead.

Q A company wants all new DevOps hires to automatically get access to DevOps tools the moment HR sets their department. What do you configure?

ANSWER

Dynamic Security Group (requires P1) + RBAC assigned to the group.

1. Create Dynamic Security Group with rule: (user.department -eq "DevOps")
2. Assign Contributor role to the group on the DevOps resource group.
3. HR sets department=DevOps → user auto-joins group → inherits all access.

Zero admin action needed for each new hire.

Q A policy is assigned with Modify effect to auto-add CostCenter tags. A VM was created but the tag is missing. Three possible causes?

ANSWER

1. Policy assignment Managed Identity has insufficient permissions (most likely) — MI needs Tag Contributor role on scope.

2. VM created outside policy scope — VM in a different RG not covered by assignment.

3. Policy evaluation delay — New policies take up to 30 minutes to evaluate new resources.

Q An admin cannot delete a Recovery Services Vault. What are the two most likely reasons?

ANSWER

1. Vault contains active backup items — must stop backup + delete backup data first.

2. Vault has soft-deleted items — items in 14-day soft delete retention. Must disable soft delete → delete items → wait → then delete vault.

Order: disable replication (ASR) → stop backup + delete data → clear soft-deleted items → delete vault.

Q What is the difference between Append and Modify policy effects?

ANSWER

Append: Adds fields/tags DURING resource creation only. Cannot overwrite existing values. Cannot remediate existing non-compliant resources.

Modify: Adds OR replaces tags/properties. Supports remediation tasks to fix existing resources. Needs Managed Identity on policy assignment. More powerful in every way.

⚠️ "Fix existing resources" = always Modify. "Add at creation only" = Append.

Phase 1 — Cheat Sheet

Conditional Access needs which license?P1 (NOT P2)

PIM / Just-in-time access?P2

SSPR on-premises writeback?P1 + Azure AD Connect

Pipeline → Azure with no secrets?WIF (Workload Identity Federation)

Azure resource → Azure resource?Managed Identity

Tenant transfer → what happens to RBAC?ALL RBAC deleted

Contributor on Key Vault reads secrets?No — need KV Secrets User (data plane)

Auto-access for new dept hires?Dynamic Group (P1) + RBAC on group

Fix existing untagged resources?Modify effect + Remediation Task

Which NSG rule priority fires first?Lowest number (100 before 200)

Max MG depth below root?6 levels

User-assigned MI vs System-assigned?User-assigned survives resource deletion, reusable