AZ-104 Manage Azure Identities and Governance: A Complete Guide

To succeed in the Microsoft Certified: Azure Administrator Associate certification, candidates must demonstrate a profound understanding of how to AZ-104 manage Azure identities and governance. This domain constitutes approximately 15-20% of the total exam weight, making it a critical pillar for any aspiring administrator. Beyond mere user creation, the exam requires proficiency in architecting secure, scalable identity solutions and enforcing organizational standards through automated governance tools. Mastery involves understanding the interplay between identity providers, granular access controls, and policy-driven resource management. This guide explores the technical mechanisms of identity synchronization, the logic of hierarchical inheritance, and the specific administrative workflows necessary to maintain a compliant cloud environment. By focusing on the structural relationships between tenants, subscriptions, and resources, candidates can develop the cause-effect reasoning needed to solve complex scenario-based questions encountered during the assessment.

AZ-104 Manage Azure Identities and Governance

Core Azure Active Directory (Azure AD) Concepts

Azure Active Directory for AZ-104, now increasingly referenced as Microsoft Entra ID, serves as the central nervous system for identity management. Unlike traditional on-premises Active Directory which uses Kerberos and LDAP, Azure AD is a cloud-based identity and access management service built on REST APIs and modern protocols like OAuth 2.0 and SAML. For the exam, you must distinguish between the Tenant—a dedicated instance of the service—and the Directory, which stores the user and group objects. A critical concept is the relationship between the tenant and the subscription: while a subscription trusts only one Azure AD tenant to authenticate users, a single tenant can be associated with multiple subscriptions. Candidates must understand the Service Principal object, which acts as the identity for applications or automated tools (like Terraform or GitHub Actions) to access specific Azure resources. Scoring well requires recognizing that identity is the new security perimeter, necessitating features like Self-Service Password Reset (SSPR) and Multi-Factor Authentication (MFA) to protect against credential compromise.

Creating and Configuring Users, Groups, and Licenses

To effectively configure Azure AD users and groups, an administrator must navigate the nuances of object types and licensing requirements. The exam tests your ability to manage User Accounts, including cloud-only identities and guest users invited via B2B collaboration. You must be able to perform bulk updates using CSV files in the portal or via PowerShell scripts. Groups are equally vital; you must differentiate between Security Groups, used for resource access, and Microsoft 365 Groups, which facilitate collaboration through shared mailboxes and calendars. A key technical requirement is the implementation of Dynamic Groups. Using a specific rule syntax (e.g., (user.department -eq "Sales")), these groups automatically update membership based on user attributes, reducing administrative overhead. Furthermore, license assignment is not just about ticking a box; you must understand Group-based Licensing, where licenses are inherited by members of a group. If a license conflict occurs—such as a user lacking a required service plan—you must know how to identify the "Error" state in the Azure portal and resolve the underlying attribute mismatch.

Implementing Role-Based Access Control (RBAC)

Understanding Built-in vs. Custom RBAC Roles

Azure RBAC roles explained in the context of the AZ-104 exam focus on the principle of least privilege. There are three primary built-in roles: Owner (full access including the ability to delegate access), Contributor (full access to manage resources but cannot delegate access), and Reader (view-only access). However, these are often too broad for specific administrative tasks. When built-in roles do not suffice, you must create a Custom Role. This involves defining a JSON object that specifies Actions, NotActions, and AssignableScopes. For example, a custom role might allow a user to restart a Virtual Machine (Microsoft.Compute/virtualMachines/restart/action) without giving them permissions to delete the resource. You must understand that NotActions is not a "deny" assignment; rather, it is a subtraction from the allowed actions. If a user is granted a permission through one role but excluded via NotActions in another, they may still have access if a third role explicitly grants it, as RBAC is additive.

Assigning Roles at Different Scopes (Management Group, Subscription, Resource)

Role assignments consist of three elements: a security principal, a role definition, and a Scope. The scope defines the boundary within which the permissions apply. Azure follows a strict hierarchy: Management Group > Subscription > Resource Group > Resource. For the AZ-104 exam, you must understand the mechanism of Inheritance. A role assigned at the Subscription level is inherited by all Resource Groups and individual resources within that subscription. You cannot override an inherited permission at a lower level to be more restrictive; you can only add more permissions. This logic is vital for troubleshooting access issues. For instance, if a user has "Reader" at the Subscription level but needs "Contributor" on a specific Web App, you apply the higher-level role at the Resource scope. The exam often presents scenarios where you must determine the effective permissions of a user based on overlapping assignments across different scopes.

Analyzing Access with Access Reviews and Azure AD Privileged Identity Management (PIM)

Security governance requires moving away from permanent "standing" access. Privileged Identity Management (PIM) is a premium feature that enables Just-In-Time (JIT) access. In PIM, users are not permanently assigned to a privileged role like Global Administrator; instead, they are made "Eligible." When they need to perform a task, they must "Activate" the role, potentially requiring MFA, a business justification, or approval from a designated authorizer. This reduces the attack surface significantly. Closely related are Access Reviews, which automate the periodic review of group memberships and role assignments. Administrators can configure reviews so that if a user (or their manager) does not respond to a prompt confirming they still need access, that access is automatically revoked. For the exam, remember that PIM requires Azure AD Premium P2 licenses and applies to both Azure AD roles and Azure Resource roles.

Azure Governance with Azure Policy

Creating and Assigning Policy Definitions and Initiatives

An AZ-104 Azure Policy study guide would be incomplete without explaining the enforcement of organizational standards. Azure Policy evaluates resources by comparing their properties to business rules defined in JSON format. A Policy Definition contains the logic (e.g., "Only allow 'D' series VMs"), while an Initiative (or Policy Set) is a collection of multiple policy definitions grouped together for a single goal, such as achieving ISO 27001 compliance. When assigning a policy, you define the scope and can also set Exclusions for specific sub-resources. The effect of a policy is critical: Deny prevents the creation of non-compliant resources, Audit simply flags them in reports, and DeployIfNotExists can automatically trigger a template deployment to fix a missing configuration, such as an extension or a specific monitoring agent. Understanding these effects is paramount for answering questions about how to prevent "shadow IT" without disrupting existing workloads.

Evaluating Compliance and Remediating Non-Compliant Resources

Once a policy is assigned, Azure performs a Compliance Evaluation cycle. This happens during resource creation, every 24 hours, or when triggered manually via the CLI or PowerShell. If a resource is found to be non-compliant, it doesn't always mean it is deleted; if the policy effect was Audit, the resource remains but is highlighted in the Compliance Dashboard. To fix existing resources that do not meet new standards, you must use a Remediation Task. This task typically uses a Managed Identity to grant the Policy engine the necessary permissions to modify the non-compliant resources. For example, if a policy requires all Storage Accounts to have "Secure Transfer Required" enabled, a remediation task can automatically toggle this setting across hundreds of accounts. On the exam, focus on the workflow: Define > Assign > Evaluate > Remediate.

Using Azure Blueprints for Deployable Governance Packages

While individual policies and RBAC assignments are powerful, Azure Blueprints allows for the orchestration of environment creation. A Blueprint is a declarative way to orchestrate the deployment of various resource templates and other artifacts, such as Role Assignments, Policy Assignments, and Resource Groups. Unlike a standard ARM template, which is a "deploy and forget" mechanism, a Blueprint maintains a relationship with the deployed resources. This is known as Blueprint Locking. You can apply a "Read Only" or "Do Not Delete" lock via the blueprint itself, ensuring that even an Owner of a subscription cannot modify the core infrastructure defined by the central IT team. For the AZ-104 exam, understand that Blueprints are used to rapidly stand up new subscriptions that are "compliant by design," ensuring that governance is baked into the lifecycle of the environment from day one.

Securing Resources with Locks and Tags

Applying and Managing Resource Locks (CanNotDelete, ReadOnly)

As a resource locks AZ-104 exam topic, administrators must know how to protect critical infrastructure from human error. There are two types of resource locks: CanNotDelete and ReadOnly. A CanNotDelete lock allows authorized users to read and modify a resource but prevents its deletion. A ReadOnly lock is more restrictive, preventing any modifications to the resource, including updates to its configuration. These locks are applied at the Resource, Resource Group, or Subscription level and are inherited by all child resources. Crucially, locks override RBAC permissions. Even if a user is an "Owner" of a subscription, they cannot delete a resource protected by a CanNotDelete lock until the lock is explicitly removed. This mechanism is essential for "crown jewel" resources like production databases or core virtual networks where an accidental click could result in significant downtime.

Implementing a Consistent Tagging Strategy for Cost and Management

Tags are name-value pairs applied to resources to categorize them for billing and management purposes. While tags do not affect the functionality of a resource, they are vital for Cost Management and reporting. For example, applying a tag like Environment: Production or Department: Finance allows an administrator to filter the Azure Cost Analysis dashboard to see exactly which department is consuming the most budget. In the context of the AZ-104 exam, you should know that tags are not inherited from Resource Groups to the resources within them. To enforce tagging, you must use Azure Policy (specifically the Append or Modify effects) to ensure that every resource created in a specific scope automatically receives the required tags or that creation is blocked if tags are missing. This automation ensures data integrity in large-scale environments where manual tagging is prone to inconsistency.

Managing Subscriptions and Management Groups

Transferring Subscriptions Between Tenants

Transferring an Azure subscription to a different Azure AD tenant is a complex administrative task with significant security implications. When a subscription is moved, the trust relationship with the original tenant is severed, and a new trust is established with the target tenant. This means that all RBAC Role Assignments and Custom Roles are permanently deleted, as they are tied to the source tenant's identity objects. However, the actual resources (VMs, Storage, etc.) continue to run. The administrator must manually re-apply permissions in the new tenant. For the exam, remember that Azure Policy assignments remain, but any managed identities used for remediation will break. This process is often necessary during corporate mergers or divestitures, and understanding the "clean slate" effect on identity and access is a common point of assessment for advanced candidates.

Designing a Management Group Hierarchy for Enterprise Governance

For organizations managing hundreds of subscriptions, Management Groups provide a governance layer above the subscription level. They allow you to organize subscriptions into a tree structure. For example, a "Root Management Group" might sit at the top, with children for "Production," "Development," and "Shared Services." By applying an Azure Policy or an RBAC Assignment at the Management Group level, the setting is inherited by every subscription underneath it. This "write once, apply many" approach is the standard for enterprise-scale governance. The AZ-104 exam expects you to know that there is a limit of 10,000 management groups in a single directory and that the hierarchy can be up to six levels deep (excluding the Root level). Designing this hierarchy correctly is essential for maintaining a clear separation of duties and ensuring that global security standards are enforced across the entire cloud footprint without manual intervention for every new subscription created.