1.2.1. Tenants and Directories
💡 First Principle: One tenant = one organization = one directory. The tenant is the trust boundary: everything inside it is administered under one set of policies, and nothing outside it is trusted unless you explicitly configure that trust.
When an organization signs up for Microsoft 365 or Azure, a tenant is created with a unique tenant ID (a GUID) and an initial domain like contoso.onmicrosoft.com. You can attach verified custom domains (contoso.com) later — proving ownership via DNS — so users sign in with familiar names. The directory inside the tenant stores every identity object and is replicated globally by Microsoft; you administer it through the Microsoft Entra admin center, Microsoft Graph, or PowerShell.
The boundary works in both directions. Inward, tenant-wide settings — user settings, external collaboration settings, device settings, branding — apply to everyone in the directory. Outward, nothing crosses without explicit configuration: B2B invitations, cross-tenant access settings, or federation. That's why so many exam scenarios hinge on which side of a tenant boundary a user or app sits.
Large enterprises often run multiple tenants (production, test, subsidiaries after mergers). Features you'll meet in Phase 3 — cross-tenant access settings, cross-tenant synchronization — exist precisely because the tenant boundary is strict and organizations need controlled bridges across it.
⚠️ Exam Trap: The onmicrosoft.com initial domain can never be deleted or transferred, and the tenant ID never changes. When a question asks which sign-in name survives a custom-domain removal, the initial domain is the answer.
Reflection Question: Why does Microsoft make the tenant boundary strict by default and force you to explicitly configure every cross-tenant bridge — what Zero Trust principle does that serve?