Microsoft identity terms are easier to understand when you separate products, organizational boundaries, application objects, and permission systems.
Don't assume familiar words describe the same authority or relationship in every context. A tenant, subscription, directory role, and resource role answer different questions.
Before building a cloud-identity lab, learn the distinctions that affect your scenario. You don't need a glossary of every feature. You need to know which system contains the object, which action you're performing, and which permission governs that action.
Active Directory and Entra ID are not interchangeable
Active Directory Domain Services is the directory technology associated with Windows domains. Microsoft Entra ID is the cloud identity service previously named Azure Active Directory.
The rename does not mean that on-premises Active Directory was renamed Entra ID. It also doesn't make the two systems identical.
Microsoft's naming guidance explains that distinction. In conversation, say which directory you mean rather than shortening both to “AD” and hoping the listener follows.
This matters when someone asks where an account is managed or which system authenticated a user.
A tenant is not the same thing as a subscription
A tenant is an identity boundary in Entra ID. An Azure subscription is associated with Azure resource management and billing.
They relate to each other, but they answer different questions. Knowing which tenant contains a user doesn't by itself tell you which Azure resources that user can manage.
In a lab diagram, label the identity boundary separately from the resource scope. That makes it easier to explain why an account can exist without having permission to operate a virtual machine or change a resource group.
Don't use “my Azure account” as a substitute for all those distinctions.
Separate directory administration from Azure resource access
Entra roles and Azure role-based access control govern different kinds of authority:
| Permission system | What it governs |
|---|---|
| Entra roles | Administrative tasks in the directory |
| Azure role-based access control | Access to Azure resources at the relevant scope |
A role containing “administrator” doesn't tell you enough on its own. Identify the permission system, object, action, and scope.
Microsoft explains the difference between Azure and Entra roles. Use that reference when planning the permissions for a test account.
Don't grant progressively broader roles until something works. First ask which specific action requires permission and where that authority is enforced.
That habit makes both the configuration and your explanation more precise than treating every administrator label as equivalent.
An application registration and a service principal are related objects
These terms often appear together, which makes them easy to merge mentally.
The application object describes the application. A service principal represents that application in a particular tenant. Microsoft explains the relationship in its application-object documentation.
For an early lab, you don't need to memorize every object property. You should understand why an application can have a definition and a tenant-specific representation with its own permissions and assignments.
Draw the relationship once. A small diagram can prevent a lot of confused clicking.
SSO and provisioning solve different problems
Single sign-on concerns authentication into an application. Provisioning concerns creating, updating, or removing the accounts and related information that the application needs.
A successful sign-in doesn't prove that a user's application account has the correct role. A provisioned account doesn't prove that the authentication flow is configured correctly.
When troubleshooting, ask which function failed. That question narrows the evidence you need before you change anything.
See the identity-provider and application relationship for a simpler starting diagram.
Keep a glossary tied to your own project
Create a two-column note: the term and where it appears in your lab.
For “tenant,” identify the boundary. For “role,” name the permission and scope. For “service principal,” identify the application representation you're discussing.
Definitions become more useful when you can point to an example and explain its effect. You also discover which words you have been repeating without understanding.
The Six-Figure IAM Career Playbook provides a $9 route from existing IT experience to a focused IAM role and practical lab evidence. Use it to choose which concepts deserve your attention first.
You don't need to learn every Microsoft name at once. Start by knowing which kind of thing each name describes.