AZ-104 Manage Azure Identities and Governance Practice Question
A contractor pool changes every month. The operations team wants Azure role access to stay the same when people join or leave, without editing role assignments for each person. Which two actions should the administrator take? Select two.
⚠ Common exam trap
Watch out — candidates often confuse Microsoft 365 groups (used for collaboration and Entra ID join) with security groups (used for RBAC assignments), leading them to select Option C instead of A.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create a security group in Microsoft Entra ID for the contractor pool.
Creating a security group in Microsoft Entra ID (formerly Azure AD) allows the administrator to manage membership dynamically or manually as contractors join or leave. By assigning the Azure role to this security group (Option D), role assignments remain constant; only group membership changes, eliminating the need to edit individual role assignments. This approach leverages Azure RBAC's support for security groups as assignable principals, ensuring consistent access control.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a security group in Microsoft Entra ID for the contractor pool.
Why this is correct
A security group is the right identity container for changing membership. Contractors can be added or removed from the group without touching the Azure RBAC assignment itself, which keeps access administration simple and consistent over time.
- ✗
Assign the Azure role directly to each contractor account.
Why it's wrong here
Adding role assignments directly to each contractor account means every new contractor requires a new RBAC assignment and every departure requires a revocation, causing exactly the frequent change churn the operations team wants to avoid. This approach also leaves stale grants when removals are missed, increasing security risk, and makes entitlement reviews harder because the assignments themselves change with each contractor cycle. It is functionally correct but operationally inefficient compared to a group-based assignment.
When this WOULD be correct
This option would be correct in a scenario where the contractor pool is static (no turnover) and the administrator needs to grant specific, individual permissions that differ per contractor, with no requirement for automated group-based management.
- ✗
Create a Microsoft 365 group and use it for VM sign-in.
Why it's wrong here
Microsoft 365 groups are designed for collaboration scenarios such as Teams, SharePoint, and unified mailboxes, not as the primary container for delegating Azure resource permissions. Although they can technically hold security principals, Azure RBAC common practice strongly prefers Azure AD security groups for access control. Additionally, 'VM sign-in' is a data-plane concern that wouldn't be resolved by a group type choice; Azure RBAC governs the management plane, and VM login requires separate configuration like Azure AD-joined VMs.
When this WOULD be correct
This option would be correct in a question about enabling VM sign-in for a group of users using Microsoft Entra ID authentication, where a Microsoft 365 group can be used to grant access to VMs joined to Microsoft Entra ID.
- ✓
Assign the Azure role to the security group rather than to individual users.
Why this is correct
Assigning the Azure role to the security group rather than to individual users decouples the role assignment from membership churn. The single RBAC assignment to the group persists across monthly contractor changes, and only the group's membership list is updated. This minimizes administrative overhead, reduces the risk of orphaned permissions, and keeps access reviews aligned with the group.
- ✗
Use a user-assigned managed identity for each contractor.
Why it's wrong here
User-assigned managed identities are workload identities used by Azure resources to authenticate to services (e.g., a VM accessing Key Vault), and they cannot represent individual human contractors. Since they are service principals rather than user accounts, they do not support interactive sign-on, password resets, or per-person audit logs. Using one per contractor would conflate human access with workload access and break the monthly membership model entirely.
When this WOULD be correct
A question asks how to grant an Azure VM access to Key Vault secrets without storing credentials. The correct answer would be to assign a user-assigned managed identity to the VM and grant that identity the Key Vault Secrets User role.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Create a security group in Microsoft Entra ID for the contractor pool.Correct answer▾
Why this is correct
A security group is the right identity container for changing membership. Contractors can be added or removed from the group without touching the Azure RBAC assignment itself, which keeps access administration simple and consistent over time.
✗Assign the Azure role directly to each contractor account.Wrong answer — click to see why▾
Why this is wrong here
Assigning the Azure role directly to each contractor account requires manual updates when contractors join or leave, which contradicts the requirement to keep role access unchanged without editing assignments.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the contractor pool is static (no turnover) and the administrator needs to grant specific, individual permissions that differ per contractor, with no requirement for automated group-based management.
Why candidates choose this
Candidates may think direct assignment is simpler or more straightforward, not realizing it creates administrative overhead for a dynamic group like a monthly-changing contractor pool.
✗Create a Microsoft 365 group and use it for VM sign-in.Wrong answer — click to see why▾
Why this is wrong here
Creating a Microsoft 365 group does not help manage Azure role assignments for a contractor pool; it is designed for collaboration features like shared mailboxes and calendars, not for assigning Azure roles to users.
★ When this WOULD be the correct answer
This option would be correct in a question about enabling VM sign-in for a group of users using Microsoft Entra ID authentication, where a Microsoft 365 group can be used to grant access to VMs joined to Microsoft Entra ID.
Why candidates choose this
Candidates may confuse Microsoft 365 groups with security groups, thinking both can be used for Azure role assignments, or they may focus on the 'VM sign-in' aspect without considering the core requirement of managing role access for a changing contractor pool.
✗Use a user-assigned managed identity for each contractor.Wrong answer — click to see why▾
Why this is wrong here
User-assigned managed identities are for Azure resources (e.g., VMs, apps) to authenticate to Azure services, not for assigning Azure RBAC roles to human users. They cannot replace role assignments for a changing contractor pool.
★ When this WOULD be the correct answer
A question asks how to grant an Azure VM access to Key Vault secrets without storing credentials. The correct answer would be to assign a user-assigned managed identity to the VM and grant that identity the Key Vault Secrets User role.
Why candidates choose this
Candidates may confuse managed identities with security groups, thinking they can dynamically manage user access, or they may overcomplicate the solution by introducing an identity concept that is not designed for user role assignments.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Dynamic Membership Groups
Key term
Access control
Access control is the security practice of determining who or what is allowed to view, use, or enter a resource, and under what conditions.
Key term
Microsoft Entra ID
Microsoft Entra ID is a cloud-based identity and access management service that lets employees sign in and access resources both inside and outside of your organization.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.