3.2 Identity Types and Directory Objects

The four identity types

Microsoft groups the identities Entra ID protects into four categories. SC-900 expects you to recognize all four, because a scenario may never say the word "user."

Users are the most familiar: member users (internal) and guest users (external, with a UPN containing #EXT#). But applications and automation also need identities — they cannot type a password — and that is where service principals and managed identities come in. Service principals and managed identities together are often called workload identities (non-human identities that apps, services, scripts, and automation use to authenticate and access resources).

The exam likes to test this breadth directly by describing an app, a script, or an Azure service and asking which identity applies — the trap is answering "user" when no human is involved.

Service principals and managed identities

An application object is the global definition of an app (registered once, in its home tenant). A service principal is the local representation of that app inside a specific tenant — it is what gets permissions and is granted access to resources. Think of the app object as the blueprint and the service principal as the instance in your tenant.

A managed identity is a special, automatically managed service principal that lets an Azure resource (a VM, App Service, Function, Logic App, etc.) authenticate to services that support Entra authentication without any developer-managed secret, certificate, or password. This eliminates stored credentials — a major security win and a frequent exam talking point.

Exam cue: "an Azure app needs to access Key Vault/Storage without storing credentials" → managed identity.

Groups: membership and type

Groups let admins manage access for many identities at once instead of one by one. Two dimensions matter on SC-900.

Membership type:

• Assigned — an admin manually adds/removes each member.
• Dynamic — membership is automatic, driven by rules over user or device attributes (e.g., department -eq "Sales"); a user joining or leaving the matching condition is added/removed automatically.

Group type:

• Security group — used to grant access to resources, apps, and assign roles/licenses.

• Microsoft 365 group — provides collaboration resources (shared mailbox, calendar, SharePoint site, Teams) in addition to access; can include guests.

• Many people needing the same access → use a group rather than individual assignments.

• Membership should follow an HR attribute automatically → dynamic membership.

• Need a shared mailbox/Teams for collaboration → Microsoft 365 group.

Device identities

Devices can be identities in Entra ID, which lets access decisions consider the endpoint and not only the person. This is foundational to Conditional Access "require a compliant/managed device" controls covered later.

Reading pattern for any 3.2 question: first decide human vs. non-human. If non-human (an app, script, or Azure service), think service principal / managed identity / workload identity. If the scenario stresses scale and repeatability, think group (and dynamic if attribute-driven). If it stresses the computer or phone state, think device identity. Choosing the right object before choosing the control is how you avoid the common distractors.

Why object type changes the right answer

The same access story produces a different correct answer when the requesting object changes, so the exam often varies one detail to test whether you noticed. One person needing app access is a user scenario. Many people needing the same access points to a group, and if membership should track an HR attribute it points to a dynamic group. An application that must call an API on its own is a service principal; if that app is an Azure resource that must do so without stored secrets, the answer shifts to a managed identity.

When the endpoint itself (its compliance or join state) factors into the decision, the relevant object is the device identity.

• Identify the requester before choosing the control — don't assume every identity is a person.
• Use groups when the problem emphasizes scale; use dynamic groups when it emphasizes automation.
• Treat app and automation access as identity problems (workload identities), not network problems.
• A credential-free Azure-resource requirement is the strongest single signal for a managed identity.

This discipline — name the principal first — is the single most useful habit for the identity-objects portion of the exam.