Azure Entra ID: Users, Groups, and Service Principals

Microsoft Entra ID components include users, groups, service principals, and managed identities. Users represent individuals, groups simplify permission management, and service principals allow applications to access resources. Managed identities further secure this by removing the need for developers to manage credentials, ensuring a robust, identity-driven security posture within Azure.

What are User Identities and how do you manage them in Entra ID?

When you first dive into Microsoft Entra ID (formerly Azure AD), you'll realize it's not just a list of usernames. User identities are the foundation of your security perimeter. You'll encounter two primary types: cloud-only identities, created directly in Azure, and synced identities, which are mirrored from an on-premises Active Directory using Entra Connect.

From a practical standpoint, managing users isn't just about creation; it's about lifecycle management. You need to ensure that Multi-Factor Authentication (MFA) is enforced for every user to prevent credential stuffing attacks. For the AZ-900 exam, remember that an identity is essentially a digital representation of a person that allows Entra ID to authenticate them and authorize their access to specific Azure resources based on their assigned roles.

Why should you use Groups instead of assigning permissions to individuals?

Imagine trying to assign access to 500 different Azure Virtual Machines for 50 different developers individually. You'd lose your mind, and your security posture would be a nightmare. This is where Groups come in. By adding users to a group and assigning permissions to that group, you create a scalable management system. If a developer leaves the project, you remove them from the group once, and their access is revoked across all associated resources instantly.

In Entra ID, you'll deal with Security Groups (used for resource access) and Microsoft 365 Groups (used for collaboration tools like Teams and SharePoint). Pro tip: focus on 'Assigned' membership versus 'Dynamic' membership. Dynamic groups use rules—like 'Department equals Sales'—to automatically add or remove users, which eliminates manual errors and saves you hours of administrative overhead.

What exactly is a Service Principal and how does it differ from a User?

Here is where many students get tripped up: not every 'identity' in Azure is a human. A Service Principal is essentially a 'user account' for an application. When you have a custom-coded app that needs to read data from an Azure SQL database or upload a file to a Storage Account, you don't give that app your own username and password. That would be a massive security risk.

Instead, you create an Application Object and a corresponding Service Principal. The Service Principal acts as the local representation of that application within your specific tenant. While a User account is designed for interactive login (someone typing a password), a Service Principal is designed for non-interactive authentication, typically using certificates or client secrets to prove its identity to Azure.

How do Managed Identities eliminate the risk of hardcoded credentials?

If you've ever looked at a piece of code and seen a password written in plain text—what we call 'hardcoded credentials'—you know it's a security disaster waiting to happen. Managed Identities are Azure's elegant solution to this problem. They provide an automatically managed identity for the Azure resource itself, meaning the resource (like a VM or a Function App) can authenticate to other Azure services without any credentials stored in the code.

There are two types you must know for the AZ-900: System-assigned and User-assigned. System-assigned identities are tied directly to a single resource and are deleted when the resource is deleted. User-assigned identities are created as separate Azure resources and can be assigned to multiple Azure resources. This 'secret-less' approach removes the burden of rotating keys and prevents accidental leaks of credentials to GitHub.

What are the responsibilities and risks of the Global Administrator role?

The Global Administrator is the 'God Mode' of Entra ID. This role has unrestricted access to every single administrative feature in the tenant. They can reset passwords for any user, manage all billing, and change critical security settings. Because this role is so powerful, it is a prime target for attackers. If a Global Admin account is compromised, your entire cloud environment is wide open.

To mitigate this risk, we always recommend the principle of least privilege. You should never use a Global Admin account for daily tasks like creating users or managing VMs. Instead, use a standard account and elevate to Global Admin only when necessary. In professional environments, we use Privileged Identity Management (PIM) to provide 'just-in-time' access, ensuring the account only has high-level permissions for a limited window of time.

How can you effectively practice these concepts for the AZ-900 exam?

Reading the documentation is a start, but the AZ-900 exam tests your ability to distinguish between similar concepts—like the subtle difference between a Service Principal and a Managed Identity. The best way to bridge that gap is through high-volume, high-quality practice. You need to see these scenarios from multiple angles to ensure you aren't just memorizing definitions, but actually understanding the logic.

That's exactly why we built Cert Sensei. We provide 1,000 expert-curated Microsoft Azure Fundamentals (AZ-900) practice questions that mirror the actual exam experience. Every single question comes with detailed expert reasoning, so when you get an answer wrong, you know exactly why. Plus, our domain-level analytics show you exactly where you're struggling—whether it's identity management or cloud architecture—so you can stop wasting time on what you already know and focus on your weak points.

❓ Frequently Asked Questions