Manage Microsoft Entra Users and Groups
Creating and Securing User Identities
Within Microsoft Entra ID, administrators maintain security boundaries by distinguishing between internal employees and external collaborators. Internal employees are typically created as Member users and receive broad access to directory features, while external collaborators are invited as Guest users with highly restricted default permissions. To secure these accounts, Conditional Access policies evaluate real-time signals, such as user location or device health, before enforcing Multi-Factor Authentication (MFA). To automate threat mitigation, Microsoft Entra ID Protection uses machine learning to detect suspicious sign-in behavior, such as leaked credentials or impossible travel patterns, and adjusts security requirements dynamically. Organizations can also implement passwordless authentication or a Temporary Access Pass (TAP) to ensure secure, time-limited credential onboarding and recovery.
Automated Lifecycle Management and Managed Identities
Managing user lifecycles relies on automated workflows to prevent security gaps when employees join, move, or leave the company. This identity cycle uses HR-driven provisioning to synchronize authoritative data from HR software, such as Workday or SuccessFactors, shifting user accounts between provisioning and deprovisioning states. To secure connections between services without storing hardcoded credentials, administrators implement Managed Identities. A system-assigned managed identity is tied directly to the lifecycle of a single Azure resource and is automatically deleted when that resource is removed. In contrast, a user-assigned managed identity is created as a standalone resource that can be shared across multiple services to simplify credential management.
Managing Groups and Directory Roles
Group-based access control reduces administrative overhead by grouping individual users who require similar permissions to perform their tasks. Administrators can configure groups with manual assignments or automate them using dynamic membership rules that evaluate user or device attributes like department or operating system. Dynamic groups require a Microsoft Entra ID P1 license for each unique member, and each dynamic group must target either users or devices exclusively. Administrators can also assign privileged administrative directory roles to groups to delegate management capabilities without over-provisioning access. Nesting allows security groups to inherit permissions from one another, but this advanced structure is supported only for Security groups and not for Microsoft 365 groups.
External Identities and Secure Collaboration
Secure external collaboration is governed by tenant-wide settings that define who can invite external users and restrict directory browsing permissions. Through B2B collaboration, external guests can sign in using their own credentials from Google, SAML federation, or email one-time passcodes as a fallback. Administrators manage cross-tenant access settings to establish inbound and outbound trust policies for specific partners, allowing Entra ID to trust MFA and device compliance claims from other tenants. To govern access at scale, Entitlement Management packages groups, applications, and SharePoint sites into access packages that require approval and regular access reviews. For high-privilege access, Privileged Identity Management (PIM) protects sensitive groups by requiring users to request just-in-time (JIT) activation before their administrative permissions become active.
Configuring Self-Service Password Reset
Enabling Self-Service Password Reset (SSPR) allows users to securely change or reset their passwords without helpdesk intervention, reducing support ticket volume. SSPR policies require administrators to define how many authentication methods are needed for verification and which specific options, such as mobile apps, SMS, or security questions, are available to users. To keep hybrid environments synchronized, password writeback securely sends password changes made in the cloud back to an on-premises Active Directory in real-time. This writeback flow utilizes an Azure Service Bus relay to communicate over outbound port 443, eliminating the need for inbound firewall rules. Accounts with administrative roles are protected by a strict two-gate password policy that requires two forms of authentication and prohibits security questions.
Manage Access to Azure Resources
Implementing Azure Role-Based Access Control
Azure role-based access control (Azure RBAC) is the primary system used to manage access to cloud assets. Built-in Azure roles are predefined sets of permissions managed by Microsoft, such as Owner, Contributor, and Reader, which cannot be modified directly. A role assignment binds a role definition to a security principal, which can be a user, a group, a service principal, or a managed identity. This assignment occurs at a specific scope, ranging from a management group or subscription down to an individual resource group or resource, allowing administrators to enforce the principle of least privilege.
Custom Roles and Scope Inheritance
When built-in roles do not meet specific business requirements, administrators can create custom RBAC roles to define exact administrative permissions. These custom roles are defined using JSON structures with Actions, NotActions, DataActions, and NotDataActions to grant granular control plane or data plane rights. Role permissions flow downward through the Azure structural hierarchy via inheritance, meaning high-level assignments apply to all child resources. This inheritance is additive, meaning a user's permissions accumulate across all assignments they receive directly or through group memberships.
Evaluating Effective Permissions and Access Controls
When an access request occurs, the Azure Resource Manager calculates a user's effective permissions by combining all active role and deny assignments. The authorization system evaluates deny assignments first; if any matching deny exists, access is immediately blocked. In storage environments, the system evaluates traditional Access Control Lists (ACLs) alongside Azure RBAC to determine precise file-level permissions. To prevent accidental resource deletion or modification, administrators apply control plane locks directly to resources. These locks override all user permissions and prevent actions independent of individual RBAC roles.
Manage Azure Subscriptions and Governance
Implementing Scalable Governance with Azure Policy
Azure Policy enforces organizational standards by comparing resource properties against business rules written in JSON format. Each policy definition includes logical operators, conditions, and a policy rule that triggers specific effects like Audit, Deny, Modify, or DeployIfNotExists. To scale governance, administrators group multiple policy definitions into an initiative to track broad goals like regulatory compliance. Policies are assigned to specific scopes, and compliance scans run every 24 hours to transition resources into compliant, non-compliant, exempt, or unknown states.
Protecting Resources with Resource Locks
Administrators use resource locks as a safeguard to block accidental modifications or deletions of critical cloud infrastructure. The CanNotDelete lock allows authorized users to read and modify a resource but blocks its deletion, while the ReadOnly lock prevents both deletion and configuration updates. Because locks are inherited, a lock applied at a subscription or resource group automatically flows down to all child assets. However, these locks only restrict control plane operations managed through Azure Resource Manager and do not block data plane interactions like reading or writing data.
An Azure resource group serves as a logical container for resources that share the same operational lifespan. While the resources inside a group can span multiple physical regions, the group itself stores deployment metadata in a single specified location to meet data residency compliance. To further organize these assets, administrators apply Azure tags, which are metadata element key-value pairs that help categorize resources for billing. Tags are not automatically inherited by child resources, so administrators must use Azure Policy with a Modify effect to enforce tag propagation.
Subscription Management and Cost Optimization
Organizations use Azure Cost Management to proactively track and analyze spending across subscriptions, resource groups, and management groups. This system allows administrators to establish Azure Budgets that monitor actual or forecasted costs and trigger automated workflows via Action Groups when spending thresholds are breached. To optimize workloads, Azure Advisor evaluates virtual machine performance over a seven-day period, flagging instances with 5% or less CPU utilization. Administrators can use these recommendations to resize underutilized resources, shut down idle systems, or purchase reservations to reduce costs.
Structuring Hierarchies with Management Groups
Azure management groups provide a hierarchical structure above subscriptions to organize and govern multiple subscriptions at scale. The hierarchy begins with a single root management group, supporting a maximum depth of six nested levels to map complex corporate structures. Any policy or RBAC assignment applied to a parent management group automatically cascades to all nested subscriptions and child resources. This inheritance path must be managed carefully, as moving subscriptions between management groups can break paths between role definitions and active assignments.
StudyCerts
StudyCerts