Domain 2 of 4 · Chapter 1 of 4

Entra ID and Identity Types

Microsoft Entra ID and the Entra family

Sign in to Microsoft 365, the Azure portal, or a connected SaaS app, and the directory that decides who you are is Microsoft Entra ID. It is Microsoft's cloud-based identity and access management service[1], which authenticates users, applications, and devices and then governs what each one may reach. Entra ID was named Azure Active Directory (Azure AD) until 2023; the service is the same, only the name changed.

Entra ID is not Active Directory in the cloud

The most common misconception is that Entra ID is on-premises Active Directory Domain Services (AD DS) moved to Azure. It is not. Entra ID has no domain controllers, no organizational units, and no Group Policy, and it authenticates with internet protocols such as SAML, OAuth 2.0, and OpenID Connect rather than Kerberos and LDAP. When a legacy application in Azure genuinely needs Kerberos, NTLM, LDAP, or Group Policy, that job belongs to a separate product, Microsoft Entra Domain Services[2], which stands up a managed domain for you.

One directory, one family

Microsoft Entra is the family name for a group of identity and network access products[1], and Entra ID is the foundational directory at its center. The specialized siblings build on that directory: Entra ID Protection scores sign-in and user risk, Entra ID Governance runs access reviews and identity lifecycle, Entra External ID handles customer and partner identities, Entra Workload ID secures application identities, and Entra Verified ID issues verifiable credentials. For the exam, keep the directory itself separate from these add-ons. A question that describes risk-based sign-in policies is pointing at ID Protection, not at Entra ID on its own.

Tenants and editions

Every organization that adopts a Microsoft cloud service gets its own tenant[1], a dedicated instance of Entra ID with an initial domain like contoso.onmicrosoft.com. Features are licensed in tiers: Entra ID Free covers the core directory and sign-in, while Entra ID P1 and P2 add premium capabilities. Naming the tier a feature needs is fair on SC-900 (Conditional Access requires P1, and ID Protection's risk detection requires P2[3]), but memorizing a full price sheet is out of scope.

Microsoft Entra familyEntra IDcloud identity + accessSpecialized Entra productsEntra IDProtectionEntra IDGovernanceEntraExternal IDEntraWorkload IDEntraVerified ID
The Microsoft Entra family: Entra ID is the foundational cloud directory, and the other products are specialized add-ons built on top of it.

The identity types Entra ID manages

Entra ID does not just track people. Anything it can authenticate and authorize is an identity, whether that is an employee, a background service reading a database, or a laptop checking in for a policy decision. Microsoft sorts identities into human and machine identities[4]: users are the human ones, and machine identities split into workload identities and devices.

Users: members and guests

A user identity represents a person. Your own employees are members. When you invite someone from outside, a partner or a vendor, Entra External ID B2B collaboration[5] adds them as a guest who keeps signing in with their own home credentials, so you never issue or manage a password for them. Member versus guest is the distinction this topic tests.

Workload identities: application, service principal, managed identity

A workload identity is an identity for software rather than a person. In Entra ID it takes three forms[4]: an application, a service principal, and a managed identity. The application object is the global blueprint of an app, and it lives once, in the tenant where the app was registered. The service principal[6] is the local instance of that app inside a specific tenant, and it is the thing that actually holds permissions and role assignments. One application object can have many service principals, one in every tenant that uses the app.

Managed identity: system-assigned versus user-assigned

A managed identity is a special service principal that an Azure resource uses to get Entra ID tokens with no secret to store, and it costs nothing extra. It comes in two flavors, and the difference is the single most tested point on this page. A system-assigned identity[4] is created on one Azure resource and shares that resource's lifecycle: delete the resource and Azure deletes the identity, so it is strictly one-to-one and cannot be shared. A user-assigned identity is created as its own standalone Azure resource with an independent lifecycle, and you can attach it to many resources, so it is the reusable choice when several workloads need the same access.

Devices

A device gets an identity so Entra ID can weigh it in an access decision, which is what makes device-based Conditional Access[7] and Intune management possible. There are three ways to get one: Entra registered for personal, bring-your-own devices; Entra joined for organization-owned Windows devices that live only in the cloud; and Entra hybrid joined for devices joined to both on-premises AD and Entra ID, a stepping stone for organizations that still run an on-premises domain.

Identity in Entra IDUsersWorkload identitiesDevicesMemberGuest (B2B)ApplicationServiceprincipalManagedidentityRegisteredJoinedHybridjoined
Identity types in Entra ID: users (member or guest), workload identities (application, service principal, managed identity), and devices (registered, joined, hybrid joined).

Hybrid identity: sync versus authentication

Picture an employee who has signed in to the on-premises domain for years and now needs Microsoft 365. You do not want a second, unrelated cloud account. Hybrid identity[8] solves this by giving the person one identity that works both on-premises and in the cloud.

The sync tool is a separate decision from the sign-in method

Two independent choices make hybrid identity work, and swapping them is the classic exam trap. The first is how accounts get into the cloud: Microsoft Entra Connect[3], or the lighter-weight Microsoft Entra Cloud Sync, synchronizes users and groups from on-premises Active Directory into Entra ID. The second is how a sign-in is verified, the authentication method. These are set independently, so the same directory sync can sit under any of the three authentication methods below.

Three ways to verify a hybrid sign-in

Password hash synchronization (PHS)[3] is the simplest: a hash of the on-premises password hash is synchronized to Entra ID, which then verifies sign-ins itself, in the cloud. Because it needs nothing on-premises beyond the sync server, Microsoft recommends enabling it even alongside the other methods, so cloud sign-in survives an on-premises outage. Pass-through authentication (PTA) instead installs a lightweight agent on-premises that validates the password directly against Active Directory, so the password check never happens in the cloud. Federation, usually with Active Directory Federation Services (AD FS) though other trusted identity providers are supported, hands the sign-in off entirely to that on-premises system, which verifies the password on-premises and needs its own server farm and TLS certificate. The overview's comparison table lines these three up side by side.

On-premisesActive DirectoryMicrosoft Entra IDcloud directorysync: Entra Connector Entra Cloud SyncUser sign-inPassword hash sync (PHS)verified in the cloudPass-through auth (PTA)agent checks on-prem ADFederation with AD FSverified on-premisescloudon-prem agentAD FS
Hybrid identity flow: Entra Connect synchronizes on-premises accounts into the cloud, then a sign-in is verified by PHS, PTA, or federation.

Exam-pattern recognition

SC-900 questions in this area almost always turn on one of a handful of look-alike pairs. Train yourself to spot which pair a stem is testing.

Sync tool versus authentication method

If a question asks how on-premises accounts get into the cloud, the answer names Microsoft Entra Connect[3] or Entra Cloud Sync. If it asks how a hybrid sign-in is verified, the answer is one of the three authentication methods (password hash synchronization, pass-through authentication, or federation). A stem that says an organization wants the simplest option, or wants cloud sign-in to keep working when the on-premises servers fail, is pointing at password hash synchronization.

System-assigned versus user-assigned managed identity

Watch the resource count. One resource that owns its identity for its whole life is system-assigned. An identity that several resources share, or that must outlive any single resource, is user-assigned. A stem that stresses reuse across multiple resources is user-assigned every time.

Member versus guest, and identity type versus product

An external partner who signs in with their own credentials is a guest, added through B2B collaboration[5], not a member. And keep identity types separate from Entra products: users, workload identities, and devices are identity types, while ID Protection and ID Governance are separate products in the Entra family, not identity types.

Entra ID versus AD DS

If a scenario needs Kerberos, LDAP, NTLM, or Group Policy in Azure, the answer is Microsoft Entra Domain Services[2], not Entra ID. Entra ID is a cloud identity service and does not provide those legacy directory protocols.

Hybrid identity authentication methods

CriterionPassword hash sync (PHS)Pass-through auth (PTA)Federation (AD FS)
Where sign-in is verifiedIn the cloud, by Entra IDOn-premises AD, via an agentOn-premises AD FS
On-premises servers neededNone beyond Entra ConnectOne or more lightweight agentsAD FS plus a proxy (WAP) farm
Relative setup effortLowest, the recommended defaultModerateHighest
Enforces on-prem account state at sign-inNo, subject to sync delayYesYes
TLS certificate requiredNoNoYes

Decision tree

What needs the identity?External to your org?Shared by many resources?Organization-owned?A personAzure workloadA deviceUser: memberyour own orgUser: guestexternal, B2BManaged identitysystem-assignedManaged identityuser-assignedEntra joinedorg-owned deviceEntra registeredpersonal / BYODNoYesNoYesYesNo

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Microsoft Entra ID is cloud identity, not Active Directory Domain Services

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud-based identity and access management service; it authenticates users, apps, and devices over internet protocols such as SAML, OAuth 2.0, and OpenID Connect. It is not on-premises AD DS relocated to the cloud, so it has no domain controllers, organizational units, or Group Policy. When a workload in Azure needs Kerberos, LDAP, NTLM, or Group Policy, that job belongs to Microsoft Entra Domain Services, a separate managed-domain product.

Trap Answering Microsoft Entra ID when a scenario requires LDAP, Kerberos, or Group Policy in Azure; those legacy directory features come from Microsoft Entra Domain Services, not from Entra ID.

2 questions test this
Microsoft Entra is the family; Entra ID is the directory inside it

Microsoft Entra is the umbrella name for a set of identity and network access products, and Entra ID is the foundational directory and access service at its center. Specialized siblings sit on top of it: Entra ID Protection for risk detection, Entra ID Governance for access reviews and lifecycle, Entra External ID for customer and partner identity, and Entra Workload ID for application identities. On the exam a described capability usually maps to one specific product rather than to Entra ID in general.

Trap Picking Entra ID Governance to detect risky sign-ins; risk detection is Entra ID Protection, while Governance handles access reviews and identity lifecycle.

2 questions test this
Entra ID identities are users, workload identities, and devices

Everything Entra ID authenticates is an identity, grouped as human identities (users) and machine identities (workload identities and devices). Users are members or guests; workload identities are applications, service principals, and managed identities; devices get an identity through registration or join. Knowing which bucket a thing falls into is the core of the identity-types objective.

Trap Listing groups as an Entra ID identity type; groups are collections used to assign access, not one of the identity types (users, workload identities, devices).

2 questions test this
External collaborators are guests added through B2B, not members

A member is a user from your own organization; a guest is an external person invited through Entra External ID B2B collaboration who signs in with their own home credentials, so you never issue or manage a password for them. Member versus guest is the user distinction SC-900 tests.

Trap Creating a full internal member account for an outside partner instead of inviting them as a B2B guest; the guest keeps their own home identity and you avoid managing their credentials.

5 questions test this
A workload identity is an identity for software, not for a person

Workload identities let applications, services, scripts, and containers authenticate to Entra ID. In Entra ID they take three forms: an application, a service principal, and a managed identity. Reach for one wherever code, rather than a human, needs to sign in and access a protected resource.

3 questions test this
The application object is the blueprint; the service principal holds the permissions

An application object is the single global definition of an app, living in the tenant where it was registered, and it acts as a template. A service principal is the local instance of that app inside a specific tenant, and it is the security principal that actually receives permissions and role assignments. One application object maps to many service principals, one in every tenant that uses the app.

Trap Assigning permissions to the application object; access is granted to the service principal, which is the app's local instance in the tenant.

2 questions test this
A managed identity is a service principal that removes stored secrets

A managed identity is a special type of service principal that an Azure resource uses to obtain Entra ID tokens with no credential to store or rotate, and it is available at no extra cost. It works only with resources and services that support Entra ID authentication.

8 questions test this
System-assigned managed identity is 1:1 with its resource; user-assigned is reusable

A system-assigned managed identity is created on a single Azure resource and shares that resource's lifecycle, so it is deleted with the resource and cannot be shared, a strict one-to-one binding. A user-assigned managed identity is a standalone Azure resource with its own lifecycle that you can attach to many resources, making it the reusable choice when several workloads need the same access or when the identity must outlive any one resource.

Trap Choosing a system-assigned managed identity when several resources must share one identity; system-assigned is bound to a single resource, so shared access needs a user-assigned identity.

6 questions test this
Devices need an identity for Conditional Access and Intune

Giving a device an identity in Entra ID lets policy engines weigh the device in an access decision, which is what enables device-based Conditional Access and Microsoft Intune management. Without a device identity, Entra ID cannot require, for example, a compliant or managed device.

3 questions test this
Entra registered is for personal devices; Entra joined is for org-owned

A device gets an Entra ID identity in one of three ways. Entra registered covers personal, bring-your-own devices, including phones and tablets. Entra joined is for organization-owned devices that live only in the cloud. Entra hybrid joined is for organization-owned devices joined to both on-premises AD and Entra ID, typically a transition step for companies that still run an on-premises domain.

Trap Requiring Entra join for a personal phone; a personal, bring-your-own device only needs Entra registration, while join is for organization-owned devices.

1 question tests this
Hybrid identity gives one identity that works on-premises and in the cloud

Hybrid identity provides a single user identity for authentication and authorization across both on-premises Active Directory and the cloud, so people use the same account everywhere. It is built through directory synchronization plus a chosen sign-in method, and it applies only to organizations that already run an on-premises directory.

6 questions test this
Entra Connect synchronizes accounts; it is not the authentication method

Microsoft Entra Connect, and the lighter-weight Entra Cloud Sync, is the tool that synchronizes users and groups from on-premises Active Directory into Entra ID. How a hybrid sign-in is actually verified is a separate choice among three authentication methods, and any sync configuration can sit under any of them.

Trap Naming Microsoft Entra Connect as an authentication method; Entra Connect only synchronizes directory objects, while sign-in is verified by password hash sync, pass-through authentication, or federation.

2 questions test this
Password hash synchronization verifies sign-in in the cloud and is the simplest method

With password hash synchronization (PHS), a hash of the on-premises password hash is synchronized to Entra ID, which then verifies sign-ins itself, in the cloud. It needs nothing on-premises beyond the sync server, so it is the simplest option, and Microsoft recommends enabling it even alongside another method so cloud sign-in survives an on-premises outage.

Trap Assuming password hash synchronization validates the password on-premises; PHS verifies sign-in in the cloud, unlike pass-through authentication, where an on-premises agent performs the check.

4 questions test this
Pass-through authentication validates the password on-premises via an agent

Pass-through authentication (PTA) installs a lightweight agent on an on-premises server that validates the user's password directly against Active Directory, so the password check never happens in the cloud. It suits organizations that must enforce on-premises account state, such as disabled, locked out, expired, or sign-in hours, at every sign-in.

Trap Standing up AD FS when pass-through authentication would do; PTA validates against on-premises AD with a lightweight agent and needs no federation server farm or TLS certificate.

1 question tests this
Federation hands sign-in off to a trusted system such as AD FS

Federated authentication delegates sign-in to a separate trusted system, typically on-premises Active Directory Federation Services (AD FS), which verifies the password on-premises. It fits requirements Entra ID cannot meet natively, such as certain third-party MFA or smartcard scenarios, but it needs its own server farm and a TLS certificate, which makes it the most complex option.

7 questions test this
Entra Cloud Sync uses a lightweight cloud-managed provisioning agent

Microsoft Entra Cloud Sync synchronizes on-premises Active Directory identities using a lightweight provisioning agent installed on-premises, with all synchronization configuration managed in the cloud. It supports scenarios that Connect Sync handles poorly, such as synchronizing from multiple disconnected AD forests during mergers and acquisitions.

Trap Assuming Cloud Sync and Connect Sync are interchangeable; Cloud Sync's agent is lightweight and cloud-configured, whereas Connect Sync installs a heavier server configured on-premises.

4 questions test this

Also tested in

References

  1. What is Microsoft Entra?
  2. Overview of Microsoft Entra Domain Services
  3. Authentication for Microsoft Entra hybrid identity solutions
  4. Managed identities for Azure resources
  5. Microsoft Entra External ID Overview
  6. Apps & service principals in Microsoft Entra ID
  7. What is device identity in Microsoft Entra ID?
  8. What is hybrid identity with Microsoft Entra ID?