Manage Azure Identities and Governance - Q&A

This document contains comprehensive questions and answers for the Manage Azure Identities and Governance domain of the AZ-104 exam (20-25% weight).

📚 Reference Links

Section 1: Microsoft Entra ID Users and Groups

Q1.1: What is Microsoft Entra ID and how does it differ from Active Directory Domain Services (AD DS)?

Answer: Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud-based identity and access management service. It differs from AD DS in several key ways:

Microsoft Entra ID:

Cloud-based identity service
Uses HTTP/HTTPS protocols (REST APIs, OAuth, SAML, OpenID Connect)
Flat structure (no OUs, forests, or domains)
Designed for internet-scale applications
Supports modern authentication (MFA, Conditional Access)
No Group Policy support
Manages cloud and SaaS applications

Active Directory Domain Services:

On-premises directory service
Uses LDAP, Kerberos, NTLM protocols
Hierarchical structure (OUs, forests, domains, trusts)
Designed for on-premises network authentication
Group Policy for device management
Manages on-premises resources

Key Point: Entra ID is NOT a cloud version of AD DS - they serve different purposes and can work together through hybrid configurations.

Documentation Links:

Q1.2: What are the different types of user accounts in Microsoft Entra ID?

Answer: Microsoft Entra ID supports three types of user identities:

1. Cloud Identities:

Created and managed entirely in Entra ID
User principal name format: user@domain.onmicrosoft.com or custom domain
Best for cloud-only organizations

2. Directory-Synchronized Identities:

Synced from on-premises AD DS using Entra Connect
Password hash sync, pass-through authentication, or federation
User manages password on-premises

3. Guest Users (B2B):

External users invited to collaborate
Use their own identity provider (Microsoft, Google, etc.)
Limited access based on invitation scope
Appear as user_domain.com#EXT#@yourtenant.onmicrosoft.com

Creating Users via Azure CLI:

bash

# Create cloud user
az ad user create \
  --display-name "John Doe" \
  --user-principal-name "john@contoso.onmicrosoft.com" \
  --password "SecureP@ss123!" \
  --force-change-password-next-sign-in true

# Invite guest user
az ad user create \
  --display-name "External Partner" \
  --user-principal-name "partner_external.com#EXT#@contoso.onmicrosoft.com" \
  --user-type Guest

Documentation Links:

Q1.3: What are the different types of groups in Microsoft Entra ID?

Answer: Microsoft Entra ID supports two group types with two membership types:

Group Types:

1. Security Groups:

Used to manage access to shared resources
Can be assigned RBAC roles
Can be used in Conditional Access policies
Cannot have email addresses

2. Microsoft 365 Groups:

Collaboration groups with shared mailbox, calendar, files
Automatically creates SharePoint site, Teams team, etc.
Has an email address
Cannot be used for RBAC assignments directly

Membership Types:

1. Assigned:

Members manually added/removed by administrators
Static membership

2. Dynamic User:

Membership based on user attribute rules
Automatically adds/removes users based on criteria
Requires Entra ID P1 or P2 license

3. Dynamic Device:

Membership based on device attribute rules
Only for security groups
Requires Entra ID P1 or P2 license

Dynamic Group Rule Example:

(user.department -eq "Sales") and (user.country -eq "US")

Creating Groups via Azure CLI:

bash

# Create security group
az ad group create \
  --display-name "IT-Admins" \
  --mail-nickname "itadmins"

# Add member to group
az ad group member add \
  --group "IT-Admins" \
  --member-id "<user-object-id>"

Documentation Links:

Q1.4: How do you configure Self-Service Password Reset (SSPR)?

Answer: Self-Service Password Reset allows users to reset their passwords without administrator intervention.

Configuration Steps:

Enable SSPR:
- Navigate to Entra ID → Password reset
- Choose: None, Selected (specific groups), or All
Configure Authentication Methods:
- Mobile phone (SMS or call)
- Email (alternate email address)
- Security questions
- Mobile app notification/code
- Office phone
Set Required Methods:
- Number of methods required to reset (1 or 2)
- More methods = more secure
Configure Registration:
- Require users to register when signing in
- Days before users are asked to re-confirm
Configure Notifications:
- Notify users on password reset
- Notify admins when other admins reset passwords

SSPR Requirements:

Users must be registered with authentication methods
Users must have appropriate license (included in most Entra ID licenses)
Password writeback requires Entra Connect (for hybrid scenarios)

Important Considerations:

SSPR for admins always requires two authentication methods
Admin SSPR cannot use security questions
Password writeback needed to sync reset passwords to on-premises AD

Documentation Links:

Q1.5: What is Multi-Factor Authentication (MFA) and how is it configured?

Answer: Multi-Factor Authentication requires users to provide two or more verification methods from different categories:

Authentication Factors:

Something you know: Password, PIN
Something you have: Phone, hardware token, authenticator app
Something you are: Biometrics (fingerprint, face)

MFA Methods in Entra ID:

Microsoft Authenticator app (push notification or code)
OATH hardware/software tokens
SMS verification
Voice call
FIDO2 security keys
Windows Hello for Business

Configuration Options:

1. Per-User MFA (Legacy):

Enable/disable MFA for individual users
Three states: Disabled, Enabled, Enforced
Not recommended for new deployments

2. Conditional Access (Recommended):

Policy-based MFA requirements
Granular control based on conditions
Requires Entra ID P1 or P2

3. Security Defaults:

Free baseline security for all tenants
Requires MFA for all users
Blocks legacy authentication

Conditional Access MFA Example:

IF: User is in "All Users" group
AND: Accessing "Microsoft Azure Management"
AND: From any location
THEN: Require MFA

Best Practices:

Use Conditional Access over per-user MFA
Prefer passwordless methods (Authenticator, FIDO2)
Configure trusted locations for reduced friction
Use number matching for push notifications

Documentation Links:

Section 2: Role-Based Access Control (RBAC)

Q2.1: What is Azure RBAC and how does it work?

Answer: Azure Role-Based Access Control (RBAC) is an authorization system that provides fine-grained access management for Azure resources.

RBAC Components:

1. Security Principal (Who):

User
Group
Service principal
Managed identity

2. Role Definition (What):

Collection of permissions
Actions (allowed operations)
NotActions (excluded operations)
DataActions (data plane operations)
NotDataActions (excluded data operations)

3. Scope (Where):

Management group
Subscription
Resource group
Individual resource

Role Assignment Formula:

Security Principal + Role Definition + Scope = Role Assignment

How RBAC Works:

User attempts an action on a resource
Azure checks all role assignments for the user
Permissions are additive (union of all roles)
Deny assignments take precedence
Access granted if any role allows the action

Key Concepts:

Permissions are inherited down the scope hierarchy
Multiple role assignments can apply to a user
Deny assignments override allow permissions
RBAC is an allow model (no implicit deny)

Documentation Links:

Q2.2: What are the key built-in RBAC roles?

Answer: Azure provides 100+ built-in roles. The most important ones are:

Fundamental Roles:

Role	Description	Key Permissions
Owner	Full access + can delegate	All actions + role assignments
Contributor	Full access, no delegation	All actions except role assignments
Reader	View only	Read all resources
User Access Administrator	Manage access only	Manage role assignments

Common Service Roles:

Role	Description
Virtual Machine Contributor	Manage VMs, not VNet or storage
Storage Account Contributor	Manage storage accounts
Storage Blob Data Contributor	Read/write blob data
Network Contributor	Manage networking resources
SQL DB Contributor	Manage SQL databases
Key Vault Administrator	Manage Key Vault and secrets

Important Distinctions:

Contributor vs Owner:

Owner can assign roles to others
Contributor cannot manage access

Storage Account Contributor vs Storage Blob Data Contributor:

Account Contributor: Manage the storage account (control plane)
Data Contributor: Read/write blob data (data plane)

Viewing Role Definitions:

bash

# List all built-in roles
az role definition list --output table

# View specific role
az role definition list --name "Contributor" --output json

Documentation Links:

Q2.3: How do you create custom RBAC roles?

Answer: Custom roles are created when built-in roles don't meet your needs.

Custom Role Structure:

json

{
  "Name": "Custom VM Operator",
  "Description": "Can start, stop, and restart VMs",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>"
  ]
}

Creating Custom Role via CLI:

bash

# Create from JSON file
az role definition create --role-definition custom-role.json

# Create inline
az role definition create --role-definition '{
  "Name": "VM Operator",
  "Description": "Can manage VM power state",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "AssignableScopes": ["/subscriptions/<sub-id>"]
}'

Creating Custom Role via PowerShell:

powershell

$role = Get-AzRoleDefinition "Virtual Machine Contributor"
$role.Id = $null
$role.Name = "VM Operator"
$role.Description = "Can manage VM power state"
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Compute/virtualMachines/start/action")
$role.Actions.Add("Microsoft.Compute/virtualMachines/powerOff/action")
$role.Actions.Add("Microsoft.Compute/virtualMachines/restart/action")
$role.Actions.Add("Microsoft.Compute/virtualMachines/read")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/<subscription-id>")
New-AzRoleDefinition -Role $role

Custom Role Limits:

Maximum 5,000 custom roles per tenant
Role name must be unique within tenant
AssignableScopes limited to 2,000 scopes

Best Practices:

Start with a built-in role and modify
Use least privilege principle
Document the purpose of custom roles
Test thoroughly before production use

Documentation Links:

Q2.4: What is the difference between Azure RBAC and Microsoft Entra roles?

Answer: Azure RBAC and Microsoft Entra roles serve different purposes and manage different resources.

Azure RBAC:

Manages access to Azure resources
Scope: Management groups, subscriptions, resource groups, resources
Examples: Owner, Contributor, Reader, VM Contributor
Assigned in Azure portal → Access control (IAM)
Controls: VMs, storage, networking, etc.

Microsoft Entra Roles:

Manages access to Entra ID resources
Scope: Tenant-wide (directory level)
Examples: Global Administrator, User Administrator, Application Administrator
Assigned in Entra ID portal → Roles and administrators
Controls: Users, groups, applications, directory settings

Key Differences:

Aspect	Azure RBAC	Entra Roles
Manages	Azure resources	Directory objects
Scope	Hierarchical (MG→Sub→RG→Resource)	Tenant-wide
Assignment location	IAM blade	Entra ID roles
Custom roles	Yes	Yes (P1/P2 required)

Overlap - Global Administrator:

Entra Global Admin can elevate to Azure Owner
Must explicitly enable "Access management for Azure resources"
One-way elevation (Entra → Azure)

Common Entra Roles:

Role	Permissions
Global Administrator	Full access to all Entra features
User Administrator	Manage users and groups
Application Administrator	Manage app registrations
Privileged Role Administrator	Manage role assignments
Security Administrator	Manage security features

Documentation Links:

Section 3: Azure Subscriptions and Governance

Q3.1: What is the Azure resource hierarchy?

Answer: Azure uses a hierarchical structure for organizing and managing resources:

Root Management Group
    └── Management Groups (optional, up to 6 levels)
        └── Subscriptions
            └── Resource Groups
                └── Resources

Components:

1. Management Groups:

Container for subscriptions
Apply governance at scale
Up to 6 levels of nesting
10,000 management groups per tenant
Inherit policies and RBAC from parent

2. Subscriptions:

Billing boundary
Access control boundary
Logical container for resources
Linked to one Entra ID tenant
Has quotas and limits

3. Resource Groups:

Logical container for resources
Resources can only be in one resource group
Can span regions
Lifecycle management unit
Apply tags, locks, policies

4. Resources:

Individual Azure services
VMs, storage accounts, databases, etc.
Exist within a resource group

Inheritance Flow:

RBAC assignments inherit downward
Azure Policies inherit downward
Tags do NOT inherit (must be applied at each level)

Best Practices:

Use management groups for enterprise governance
Organize subscriptions by environment or business unit
Use resource groups for lifecycle management
Apply policies at highest appropriate level

Documentation Links:

Q3.2: What is Azure Policy and how does it work?

Answer: Azure Policy is a service for creating, assigning, and managing policies that enforce rules and effects on resources.

Policy Components:

1. Policy Definition:

JSON document defining the rule
Conditions and effects
Built-in or custom

2. Policy Initiative (Policy Set):

Collection of policy definitions
Group related policies together
Assign as a unit

3. Policy Assignment:

Applies policy/initiative to a scope
Can include parameters
Can exclude specific resources

Policy Effects:

Effect	Description
Deny	Prevents non-compliant resource creation/update
Audit	Creates warning event, allows resource
Append	Adds fields to resource during creation
Modify	Adds, updates, or removes tags
DeployIfNotExists	Deploys related resource if missing
AuditIfNotExists	Audits if related resource missing
Disabled	Policy not evaluated

Policy Definition Example:

json

{
  "mode": "All",
  "policyRule": {
    "if": {
      "field": "type",
      "equals": "Microsoft.Storage/storageAccounts"
    },
    "then": {
      "effect": "deny",
      "details": {
        "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
        "equals": false
      }
    }
  }
}

Assigning Policy via CLI:

bash

# Assign built-in policy
az policy assignment create \
  --name "require-tag" \
  --display-name "Require Department Tag" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b590-94f262ecfa99" \
  --scope "/subscriptions/<subscription-id>" \
  --params '{"tagName": {"value": "Department"}}'

Documentation Links:

Q3.3: What are resource locks and when should you use them?

Answer: Resource locks prevent accidental deletion or modification of critical resources.

Lock Types:

1. CanNotDelete (Delete Lock):

Authorized users can read and modify
Cannot delete the resource
Useful for production resources

2. ReadOnly (Read-Only Lock):

Authorized users can only read
Cannot modify or delete
Similar to Reader role
Useful for compliance scenarios

Lock Inheritance:

Locks inherit from parent scope
Lock on resource group applies to all resources
Most restrictive lock wins

Creating Locks via CLI:

bash

# Create delete lock on resource group
az lock create \
  --name "CannotDelete" \
  --lock-type CanNotDelete \
  --resource-group "Production-RG"

# Create read-only lock on specific resource
az lock create \
  --name "ReadOnlyLock" \
  --lock-type ReadOnly \
  --resource-group "Production-RG" \
  --resource-name "critical-storage" \
  --resource-type "Microsoft.Storage/storageAccounts"

# List locks
az lock list --resource-group "Production-RG" --output table

# Delete lock
az lock delete --name "CannotDelete" --resource-group "Production-RG"

Important Considerations:

ReadOnly Lock Side Effects:

Cannot add/remove role assignments
Cannot modify tags
Some operations that seem read-only may fail
Example: Cannot list storage account keys (considered a write operation)

Who Can Manage Locks:

Owner role
User Access Administrator role
Custom role with Microsoft.Authorization/locks/* permission

Best Practices:

Use CanNotDelete for production resources
Document why locks are applied
Test lock impact before applying to production
Consider using Azure Policy for enforcement at scale

Documentation Links:

Q3.4: How do you manage costs in Azure?

Answer: Azure provides several tools and strategies for cost management:

Cost Management Tools:

1. Azure Cost Management + Billing:

View and analyze costs
Create budgets and alerts
Export cost data
Cost recommendations

2. Azure Advisor:

Cost optimization recommendations
Right-sizing VMs
Reserved instance recommendations
Unused resources

3. Azure Pricing Calculator:

Estimate costs before deployment
Compare pricing options
Plan budgets

Cost Management Strategies:

1. Budgets:

bash

# Create budget with alert
az consumption budget create \
  --budget-name "Monthly-Budget" \
  --amount 1000 \
  --time-grain Monthly \
  --start-date "2025-01-01" \
  --end-date "2025-12-31" \
  --resource-group "Production-RG"

2. Tags for Cost Allocation:

bash

# Tag resources for cost tracking
az resource tag \
  --tags Department=IT CostCenter=12345 Environment=Production \
  --ids "<resource-id>"

3. Reserved Instances:

1-year or 3-year commitment
Up to 72% savings vs pay-as-you-go
Best for predictable workloads

4. Azure Hybrid Benefit:

Use existing Windows Server/SQL licenses
Significant savings on VMs

5. Spot VMs:

Up to 90% discount
Can be evicted with 30-second notice
Good for fault-tolerant workloads

6. Auto-shutdown:

Schedule VM shutdown
Reduce costs for dev/test environments

Cost Visibility Best Practices:

Use consistent tagging strategy
Create cost views by department/project
Set up budget alerts at 50%, 75%, 90%, 100%
Review Azure Advisor recommendations weekly

Documentation Links:

Section 4: Administrative Units and Privileged Identity Management

Q4.1: What are Administrative Units?

Answer: Administrative Units (AUs) are containers in Entra ID that restrict administrative scope to a portion of the organization.

Use Cases:

Large organizations with regional IT teams
Universities with departmental admins
Companies with business unit autonomy

How Administrative Units Work:

Create an AU and add users/groups/devices
Assign Entra roles scoped to the AU
Admins can only manage objects within their AU

Supported Roles for AU Scope:

User Administrator
Groups Administrator
Password Administrator
Authentication Administrator
Helpdesk Administrator
License Administrator

Creating Administrative Units:

powershell

# Create AU
New-AzureADMSAdministrativeUnit -DisplayName "Sales Department"

# Add user to AU
Add-AzureADMSAdministrativeUnitMember -Id "<AU-id>" -RefObjectId "<user-id>"

# Assign scoped role
$roleDefinition = Get-AzureADMSRoleDefinition -Filter "displayName eq 'User Administrator'"
New-AzureADMSRoleAssignment -DirectoryScopeId "/administrativeUnits/<AU-id>" -RoleDefinitionId $roleDefinition.Id -PrincipalId "<admin-user-id>"

Limitations:

Requires Entra ID P1 or P2
Not all roles support AU scoping
Nested AUs not supported
Maximum 30 AUs per user

Documentation Links:

Administrative units

Q4.2: What is Privileged Identity Management (PIM)?

Answer: Privileged Identity Management (PIM) provides just-in-time privileged access to reduce the risks of excessive permissions.

Key Features:

1. Just-in-Time Access:

Activate roles only when needed
Time-limited activation (1-24 hours)
Reduces standing privileged access

2. Approval Workflow:

Require approval for role activation
Multiple approvers supported
Justification required

3. Access Reviews:

Periodic review of role assignments
Automated recommendations
Remove stale assignments

4. Audit History:

Track all PIM activities
Who activated what role and when
Compliance reporting

PIM for Azure Roles:

Eligible vs Active assignments
Activate roles when needed
Supports all Azure RBAC roles

PIM for Entra Roles:

Same concepts for directory roles
Global Administrator, User Administrator, etc.

Configuration Example:

Make user "eligible" for Owner role
User requests activation when needed
Approver reviews and approves
User has Owner access for limited time
Access automatically revoked after time expires

Requirements:

Entra ID P2 license
Global Administrator or Privileged Role Administrator to configure

Best Practices:

Use eligible assignments instead of permanent
Require justification for activations
Set up alerts for suspicious activations
Conduct regular access reviews

Documentation Links:

Practice Questions

Question 1

You need to allow a developer to manage VMs in a resource group but prevent them from creating new VMs. Which approach should you use?

A. Assign the Virtual Machine Contributor role
B. Create a custom role with specific VM actions
C. Assign the Contributor role with a deny assignment
D. Use Azure Policy to deny VM creation

Answer: B

Create a custom role that includes VM management actions (start, stop, restart, read) but excludes Microsoft.Compute/virtualMachines/write. Virtual Machine Contributor would allow creating VMs.

Question 2

A user reports they cannot delete a storage account despite having the Contributor role. What is the most likely cause?

A. The user's session has expired
B. A resource lock is applied
C. Azure Policy is blocking the deletion
D. The storage account has blobs

Answer: B

A CanNotDelete or ReadOnly resource lock would prevent deletion even with Contributor role. Locks override RBAC permissions for delete operations.

Question 3

You need to ensure all resources in a subscription have a "CostCenter" tag. Resources without the tag should not be created. Which Azure Policy effect should you use?

A. Audit
B. Deny
C. Append
D. Modify

Answer: B

Deny effect prevents resource creation/modification if the policy conditions aren't met. Audit would only log non-compliance without preventing creation.

Question 4

What is the maximum number of management group levels supported in Azure?

A. 4
B. 5
C. 6
D. 10

Answer: C

Azure supports up to 6 levels of management group depth (not including the root level or subscription level).

Question 5

You want to grant a user the ability to assign RBAC roles but not manage any other resources. Which built-in role should you assign?

A. Owner
B. Contributor
C. User Access Administrator
D. Security Administrator

Answer: C

User Access Administrator can manage user access to Azure resources (role assignments) but cannot manage the resources themselves. Owner has full access including role assignments.

Summary

Key topics for the Identity and Governance domain:

Microsoft Entra ID: User types, groups, SSPR, MFA
Azure RBAC: Built-in roles, custom roles, role assignments, scope
Azure vs Entra Roles: Different purposes, different scopes
Governance: Management groups, subscriptions, resource groups
Azure Policy: Definitions, initiatives, assignments, effects
Resource Locks: CanNotDelete, ReadOnly, inheritance
Cost Management: Budgets, tags, recommendations
PIM: Just-in-time access, eligible assignments, access reviews

Manage Azure Identities and Governance - Q&A ​

📚 Reference Links ​

Section 1: Microsoft Entra ID Users and Groups ​

Q1.1: What is Microsoft Entra ID and how does it differ from Active Directory Domain Services (AD DS)? ​

Q1.2: What are the different types of user accounts in Microsoft Entra ID? ​

Q1.3: What are the different types of groups in Microsoft Entra ID? ​

Q1.4: How do you configure Self-Service Password Reset (SSPR)? ​

Q1.5: What is Multi-Factor Authentication (MFA) and how is it configured? ​

Section 2: Role-Based Access Control (RBAC) ​

Q2.1: What is Azure RBAC and how does it work? ​

Q2.2: What are the key built-in RBAC roles? ​

Q2.3: How do you create custom RBAC roles? ​

Q2.4: What is the difference between Azure RBAC and Microsoft Entra roles? ​

Section 3: Azure Subscriptions and Governance ​

Q3.1: What is the Azure resource hierarchy? ​

Q3.2: What is Azure Policy and how does it work? ​

Q3.3: What are resource locks and when should you use them? ​

Q3.4: How do you manage costs in Azure? ​

Section 4: Administrative Units and Privileged Identity Management ​

Q4.1: What are Administrative Units? ​

Q4.2: What is Privileged Identity Management (PIM)? ​

Practice Questions ​

Question 1 ​

Question 2 ​

Question 3 ​

Question 4 ​

Question 5 ​

Summary ​

Manage Azure Identities and Governance - Q&A

📚 Reference Links

Section 1: Microsoft Entra ID Users and Groups

Q1.1: What is Microsoft Entra ID and how does it differ from Active Directory Domain Services (AD DS)?

Q1.2: What are the different types of user accounts in Microsoft Entra ID?

Q1.3: What are the different types of groups in Microsoft Entra ID?

Q1.4: How do you configure Self-Service Password Reset (SSPR)?

Q1.5: What is Multi-Factor Authentication (MFA) and how is it configured?

Section 2: Role-Based Access Control (RBAC)

Q2.1: What is Azure RBAC and how does it work?

Q2.2: What are the key built-in RBAC roles?

Q2.3: How do you create custom RBAC roles?

Q2.4: What is the difference between Azure RBAC and Microsoft Entra roles?

Section 3: Azure Subscriptions and Governance

Q3.1: What is the Azure resource hierarchy?

Q3.2: What is Azure Policy and how does it work?

Q3.3: What are resource locks and when should you use them?

Q3.4: How do you manage costs in Azure?

Section 4: Administrative Units and Privileged Identity Management

Q4.1: What are Administrative Units?

Q4.2: What is Privileged Identity Management (PIM)?

Practice Questions

Question 1

Question 2

Question 3

Question 4

Question 5

Summary