# Tenant

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/tenant

## Quick definition

A tenant is like your organization's own private directory in the Microsoft cloud. It holds your users, groups, and apps and keeps your data separate from other companies. When you sign up for Microsoft 365 or Azure, you get a tenant automatically. It is the foundation for managing access and identity in Microsoft services.

## Simple meaning

Imagine you live in a large apartment building. The building itself is the Microsoft cloud, and each apartment is a separate, locked space for one family. Your apartment is your tenant. It has its own front door (your login page), its own set of keys (passwords and security settings), and its own furniture (your company’s users, apps, and data). No other family can walk into your apartment because the building is designed to keep every apartment completely separate.

In the Microsoft world, a tenant is exactly that private apartment. It is a dedicated instance of Microsoft Entra ID (formerly Azure Active Directory) that is created for your organization when you first sign up for a Microsoft cloud service like Azure, Microsoft 365, or Dynamics 365. Inside your tenant, you have your own list of users, your own security policies, your own apps, and your own data. Everything that belongs to your company lives inside that tenant, and no other company can see or access it unless you explicitly invite them.

Think of the tenant as your company’s home base in the cloud. Every time an employee signs in with their work email, they are authenticating against your tenant. Every time an admin sets a policy like requiring multifactor authentication, that policy applies only to your tenant. Every app your company builds or buys is registered in your tenant. Without a tenant, none of the Microsoft cloud services would know who you are, what your employees can do, or where your data should be stored. It is the fundamental container for identity and access in the Microsoft ecosystem.

## Technical definition

In the Microsoft cloud ecosystem, a tenant is a dedicated and isolated instance of Microsoft Entra ID (formerly Azure Active Directory) that is provisioned for an organization at the time of its first subscription to a Microsoft cloud service such as Microsoft 365, Azure, Dynamics 365, or Power Platform. Each tenant is associated with a unique Domain Name System (DNS) domain, typically of the form organizationname.onmicrosoft.com, and can also be linked to one or more custom domains owned by the organization.

From a technical standpoint, the tenant is the root of trust for identity and access management within Microsoft’s cloud infrastructure. It contains the directory of users, groups, devices, and applications. It also stores the configuration for authentication, authorization, conditional access policies, and identity protection. The tenant enforces security boundaries: data belonging to one tenant is cryptographically and logically isolated from data in other tenants. This isolation is achieved through tenant-specific encryption keys and strict request routing that validates the tenant context before granting access to any resource.

Microsoft Entra ID uses a multi-tenant architecture. Multiple tenants coexist on the same underlying infrastructure, but every request includes a tenant identifier (the tenant ID, a globally unique identifier or GUID) that ensures the request is processed against the correct directory. When a user authenticates, they specify their tenant either explicitly (e.g., by using a sign-in URL that includes the tenant domain) or implicitly (by entering a username that contains a domain, such as user@contoso.com, which is resolved to the correct tenant).

Tenants can be categorized by type, such as production tenants (for real organizational use), development tenants (for testing and development), and B2B collaboration tenants (for external partner access through guest users). Azure AD B2C (Business to Consumer) is a separate service that allows organizations to create custom authentication experiences for customers, but it is not the same as a standard tenant used for employee and partner access.

Key components of a tenant include the tenant ID (a GUID used in all API calls and configuration scripts), the primary domain (organizationname.onmicrosoft.com), custom domains (validated by DNS TXT records), service principals (representations of applications within the tenant), and the various Azure AD roles that delegate administrative control. Conditional access policies, identity protection risk detections, and administrative units are all configured at the tenant level. When an organization deletes a tenant, all data associated with it is permanently removed after a 30-day soft-delete period.

## Real-life example

Think of a tenant like a private office suite in a large co-working building. The building itself is Microsoft’s cloud. It has the electricity, internet, security guards (base infrastructure), and shared meeting rooms (shared services like Azure AD Graph API). But your company rents its own locked suite. That suite is your tenant.

Inside your suite, you have your own desk for each employee (user accounts), your own filing cabinet for company data (directory information), your own phone system (your apps and services), and your own keycard system (your security and authentication policies). Your suite number is your tenant ID, a unique number posted on your door. When a visitor (a user) arrives, they must show their badge at the front desk (login page) and say your suite number so the guard knows exactly which office they are allowed to enter.

If a different company rents the suite next door, they have their own keycards, their own desks, and their own filing cabinets. You cannot accidentally walk into their office, and they cannot access yours. Even though everyone shares the same building infrastructure, the suite walls keep everything separate. That is exactly how a Microsoft Entra ID tenant works: it provides a completely separate, secure space for your organization inside the shared cloud.

When your company grows and gets a bigger office (more users and subscriptions), you still stay in your same suite. You might add new furniture (register new apps) or change the locks (update your security policies), but you never share space with another organization. That dedicated, isolated space is what makes the tenant so important for security and compliance.

## Why it matters

Understanding what a tenant is matters because it is the backbone of identity and access management in the Microsoft cloud. Every decision an IT professional makes about users, security, app access, and compliance is contained within the tenant. If you misunderstand the tenant model, you can accidentally configure something that affects the wrong set of users or, worse, expose your organization’s data.

For example, when you create a new user in Azure, you are adding that user to a specific tenant. That user’s access to Microsoft 365, Azure resources, and thousands of SaaS apps is governed by policies defined within that same tenant. If an admin is working with two tenants (e.g., a production tenant and a development tenant) and confuses them, they might create a user in the wrong tenant, causing authentication failures and confusion. Similarly, conditional access policies, which are powerful tools for enforcing security requirements like requiring a device to be compliant, are applied at the tenant level. A single misconfigured policy can block all users across the entire organization if the tenant scope is not correctly understood.

the tenant is the boundary for compliance and data residency. Many organizations have regulatory requirements about where user data is stored. The tenant is created in a specific geographic region (like North America, Europe, or Asia Pacific) and that region determines where your directory data lives. Moving a tenant between regions is not possible; you would need to create a new tenant and migrate everything. IT professionals must choose the tenant region carefully at the time of sign-up because they cannot change it later.

Finally, the tenant is the unit of billing for many Microsoft services. While subscriptions are tied to a tenant, the tenant itself does not directly cause charges. However, the number of users, their licenses, and the resources they consume are managed within the tenant. Mistakes in tenant configuration can lead to over-provisioning, security gaps, or audit failures. For any IT professional working with Microsoft cloud services, the tenant is not just a concept, it is the operational reality they deal with every day.

## Why it matters in exams

The concept of a tenant is critical for three Microsoft certification exams: AZ-104 (Microsoft Azure Administrator), AZ-900 (Azure Fundamentals), and SC-900 (Microsoft Security, Compliance, and Identity Fundamentals).

For AZ-104, the tenant is a foundational concept that appears in multiple exam objectives. The exam objective “Manage Azure identities and governance” directly requires understanding how Azure AD tenants work, how to create and manage users and groups, how to configure tenant-level security settings, and how to manage Azure AD join and registration. Scenario-based questions often ask you to troubleshoot why a user cannot access a resource, and the answer frequently involves checking the tenant’s conditional access policies or verifying that the user exists in the correct tenant. You may also be asked to choose between managing resources at the subscription level versus the tenant level, or to explain why a guest user cannot sign in (often because their account is in a different tenant that has not been invited correctly).

For AZ-900 (Azure Fundamentals), the tenant is covered under the “Describe identity, governance, privacy, and compliance features” domain. At this level, you need to understand the basic definition, the fact that a tenant is a dedicated instance of Azure AD, and that it is separate from an Azure subscription. Expect simple multiple-choice questions asking which component holds user identities or how tenants relate to subscriptions. You will not need deep configuration knowledge, but you must understand the core concept.

For SC-900, the tenant is even more central because the entire exam covers Microsoft’s identity and security capabilities. The exam objective “Describe the capabilities of Microsoft Entra ID” includes understanding multi-tenant environments, tenant isolation, guest user access (B2B collaboration), and the role of the tenant in identity protection. SC-900 questions often present a scenario where a company acquires another company and asks how to allow access between the two organizations using Azure AD B2B collaboration. You must understand that each company has its own tenant and that you invite users as guests rather than creating new accounts in your tenant. Another common question type involves understanding that deleting a tenant removes all associated data, which is a consideration for compliance and backup strategies.

## How it appears in exam questions

On the AZ-104 exam, you may see a question like: "Your company has an Azure AD tenant named contoso.com. You need to ensure that external users from a partner company can access a specific application in your tenant without requiring them to have separate credentials. Which approach should you use?" The answer is Azure AD B2B collaboration, which involves inviting guest users from the partner’s tenant. A distractor might be to create local user accounts for the partner employees in your tenant, but that is incorrect because it creates identity management overhead and does not allow the partner to manage their own accounts.

Another typical AZ-104 scenario: "You are configuring conditional access policies. A policy requires that all users accessing the Azure portal must use multi-factor authentication. Which scope should you choose to apply this policy to every user in the organization?" The answer is to select "All users" at the tenant level. A trap might be to select only a specific group, which would leave other users unprotected.

On the AZ-900 exam, a question might read: "When you create an Azure account, what is automatically created?" The answer is an Azure AD tenant. An incorrect option might say an Azure subscription, because while a subscription is also created, the tenant is created first and is the identity container.

On the SC-900 exam, a typical question: "Company A has its own Azure AD tenant, and Company B has its own Azure AD tenant. Company A wants to grant its employees access to an application hosted in Company B's tenant. Which Azure AD feature should be used?" The answer is Azure AD B2B collaboration. A common distractor is Azure AD B2C, which is for consumer-facing applications, not for employee-to-employee collaboration.

Another SC-900 pattern: "A security administrator needs to ensure that if a user is compromised in one tenant, the malicious activity cannot spread to another tenant. What principle does this protection rely on?" The answer is tenant isolation. The question might then ask how it is achieved, with the correct answer being that each tenant has its own encryption keys and logical data separation.

## Example scenario

You work as an IT support technician for a mid-sized company called Northwind Traders. The company uses Microsoft 365 for email and collaboration, and it also has some resources in Azure. The CEO asks you to help a new intern named Alex get set up. Alex just joined the company and needs access to company email, Microsoft Teams, and a specific internal web application that is hosted in Azure.

To get Alex started, you first need to understand how the company’s tenant works. Northwind Traders has a tenant called northwindtraders.onmicrosoft.com. Every employee, including Alex, must have a user account inside this tenant. So you log into the Microsoft 365 admin center, which is part of the tenant, and create a new user account for Alex with the username alex@northwindtraders.com. Because the company’s custom domain northwindtraders.com is verified in the tenant, the email address works immediately.

Next, you assign Alex a license for Microsoft 365 so that they can use email and Teams. The license is purchased at the subscription level, but the user assignment happens inside the tenant. Then you need to give Alex access to the internal web app. That web app is registered as an enterprise application within the same tenant. You find it in the Azure portal, go to that app’s settings, and add Alex as a user who can access it.

Later, Alex tries to sign in from home on a personal laptop. The company has a conditional access policy in the tenant that requires multi-factor authentication for all users accessing the web app from outside the corporate network. Alex successfully authenticates with their password and then receives a prompt on their phone to approve the sign-in. That policy, stored in the tenant, enforces the extra security automatically. Without the tenant, none of this would be possible, the tenant is the central directory that knows who Alex is, what apps they can use, and what security rules apply.

## Common mistakes

- **Mistake:** Thinking a tenant and an Azure subscription are the same thing.
  - Why it is wrong: A tenant is the identity container (users, groups, policies), while a subscription is a billing and resource management container (VMs, storage, databases). One tenant can have many subscriptions, and one subscription can belong to only one tenant.
  - Fix: Remember: tenant holds identities, subscriptions hold resources. You manage who can do what in the tenant. You manage what they can use in the subscription.
- **Mistake:** Creating a new user in the wrong tenant.
  - Why it is wrong: If you create a user in a development tenant instead of the production tenant, that user cannot access production resources, and you have to recreate the account. This leads to confusion and duplicate administration.
  - Fix: Always check the tenant domain (e.g., contoso.onmicrosoft.com) in the portal header before creating users. Use a script that explicitly specifies the tenant ID.
- **Mistake:** Assuming you can move a tenant to a different geographic region after creation.
  - Why it is wrong: The tenant’s region is fixed when it is created. You cannot change it later. If your company moves to a country with new data residency requirements, you have to create a new tenant and migrate all users and data.
  - Fix: Choose the tenant region carefully when you first sign up. If you are unsure, consult legal or compliance teams before creating the tenant.
- **Mistake:** Believing that deleting a tenant is reversible without a grace period.
  - Why it is wrong: When you delete a tenant, it goes into a 30-day soft-delete state, after which it is permanently removed. Many administrators do not realize that all data, including users, groups, and app registrations, is lost permanently.
  - Fix: Before deleting a tenant, export all critical data. Consider using the restore option during the 30-day period if the deletion was accidental. Never delete a production tenant without extensive planning.
- **Mistake:** Confusing Azure AD B2B and Azure AD B2C with the standard tenant.
  - Why it is wrong: B2B is a feature that allows guest users from other tenants to access your tenant’s resources. B2C is a separate service for consumer identities. Standard tenants are for employees and internal resources.
  - Fix: Use B2B for external partners. Use B2C only for customer-facing applications that need a custom sign-up experience. The standard tenant is for your organization’s own users.

## Exam trap

{"trap":"The exam might describe a scenario where a company has multiple Azure AD tenants and asks how to grant users from Tenant A access to an app in Tenant B. The trap answer is to create user accounts in Tenant B for those users.","why_learners_choose_it":"It seems simpler to just create a local user account. Many beginners think managing users in one place is easier than managing guest accounts or cross-tenant access.","how_to_avoid_it":"Remember that creating duplicate accounts creates administrative overhead, password sync issues, and security risks. The correct answer is to use Azure AD B2B collaboration, which allows users from Tenant A to authenticate in their own tenant and access resources in Tenant B as guests."}

## Commonly confused with

- **Tenant vs Azure Subscription:** A tenant is the identity and directory service (Microsoft Entra ID) that holds users, groups, and policies. An Azure subscription is a container for Azure resources like virtual machines and databases, and is linked to a billing profile. A single tenant can have multiple subscriptions, but each subscription is trusted to only one tenant. (Example: Your company has one tenant (contoso.onmicrosoft.com) but three subscriptions: one for development, one for production, and one for test. All three subscriptions rely on the same tenant for user authentication.)
- **Tenant vs Azure AD B2C Tenant:** A standard tenant is for employees and internal partners. An Azure AD B2C tenant is a separate service designed for consumer-facing applications where external users sign up with social accounts (like Google or Facebook) or email. B2C tenants have different configuration options and are not used for employee identity. (Example: A retail company uses its standard tenant for employee logins to Office 365. It creates a separate B2C tenant for its online shopping website where customers create accounts.)
- **Tenant vs Domain:** A domain is a DNS name (e.g., contoso.com) that you can add to a tenant and verify ownership. A tenant can host multiple domains, but the tenant itself is the directory service. Domains are just labels that help users sign in and send email from a recognizable address. (Example: Your tenant is myshop.onmicrosoft.com, and you add two custom domains: myshop.com and myshop.co.uk. Both domains point to the same tenant. Users can sign in with user@myshop.com or user@myshop.co.uk, and they both authenticate against the same tenant directory.)
- **Tenant vs Azure Active Directory (Entra ID) Instance:** The terms are often used interchangeably, but an Azure AD instance is the technical implementation of the directory service. A tenant is the logical container that owns that instance. Every tenant has exactly one Azure AD instance, but the word 'tenant' emphasizes the organizational and security boundary. (Example: When you say 'I am an admin for the Contoso tenant,' you mean you have administrative privileges for the Azure AD instance dedicated to Contoso.)

## Step-by-step breakdown

1. **Provisioning** — When an organization signs up for a Microsoft cloud service like Azure, Microsoft Entra ID automatically creates a new tenant. The tenant is assigned a unique tenant ID (GUID) and a default domain (organiztion.onmicrosoft.com).
2. **Directory population** — The admin adds users to the tenant. Each user gets a User Principal Name (UPN) and a password. Groups are created for organizing users. The directory stores these objects along with their attributes like name, email, job title, and department.
3. **Application registration** — Developers or admins register applications in the tenant. Each app gets a service principal, which is the app's identity within the tenant. This allows the app to authenticate and request permissions to access resources like Microsoft Graph or Azure Storage.
4. **Policy configuration** — Administrators configure security policies at the tenant level, including conditional access policies, identity protection risk policies, and password policies. These policies apply to all users in the tenant unless scoped differently.
5. **Authentication and authorization** — When a user signs in, Microsoft Entra ID verifies their credentials against the tenant directory. If the user is from a different tenant (guest), the home tenant is contacted. After authentication, the system checks policies to determine if the access is authorized (e.g., does the user meet MFA requirements?).
6. **Resource access** — Once authenticated and authorized, the user can access cloud resources. The tenant does not store the resources themselves (like a VM or SharePoint site), but it provides the identity context that allows the resource to trust the user's identity.

## Practical mini-lesson

As an IT professional, working with a tenant is a daily task. Here is how it works in practice.

When you first create an Azure account, you are asked to provide an email address and password. That email address becomes the first global administrator of the new tenant. The tenant’s default domain is immediately created as a placeholder. The first thing you should do after provisioning is add and verify your company’s custom domain. Verification requires adding a TXT record to your public DNS zone. Once verified, you can set that domain as the default so that new users get addresses like user@yourcompany.com instead of user@yourcompany.onmicrosoft.com.

Next, you need to manage users. You can create users manually in the Azure portal, use bulk import with CSV files, or synchronize from an on-premises Active Directory using Microsoft Entra Connect. Synchronization is common in enterprises because it allows you to manage user identities in your on-premises AD and have them mirrored in the cloud tenant. You must configure attribute mapping and set up password hash synchronization or pass-through authentication so users can use the same password for both environments.

Group management is another critical task. You can create security groups for assigning permissions and distribution groups for email. Azure AD can also create dynamic groups that automatically add or remove users based on rules like department equals 'Sales'. This reduces manual administration.

One of the most important configuration areas is conditional access. For example, you can create a policy that requires all administrators to use MFA and a compliant device when accessing the Azure portal. This policy is stored in the tenant and evaluated every time an admin tries to sign in. If the user does not have a compliant device, they are blocked. Misconfiguring conditional access can lock out all users, so you should always test policies on a small group first using the 'Report-only' mode.

What can go wrong? A common issue is that a new employee cannot sign in because their account was created in the wrong tenant. Another problem is that a conditional access policy blocks users because the IP range of the office was incorrectly specified. Tenant-level settings can break things globally if not tested. Always use break-glass accounts (emergency admin accounts) that are excluded from conditional access policies to ensure you can always get back in.

Finally, understand tenant-to-tenant collaboration. If your company acquires another company, you may need to give their employees access to your apps. Do not create new user accounts for them. Instead, use Azure AD B2B collaboration to invite them as guest users. They will authenticate in their own tenant and be able to access your resources without you managing their passwords.

## Memory tip

Think of the tenant as your own locked room in the Microsoft cloud building, your room has its own door, its own key, and its own furniture, and no one else can walk in without your permission.

## FAQ

**Can I have more than one tenant for my organization?**

Yes, you can create multiple tenants, but it is not recommended for most organizations because it complicates identity management. Users and data are not shared between tenants, so you would need separate sign-ins and separate policies.

**Is a tenant the same as a directory?**

In the context of Microsoft Entra ID, a tenant is the container that owns a directory. Every tenant has exactly one directory, but the terms are often used interchangeably.

**How do I move a tenant to a different region?**

You cannot move a tenant. You must create a new tenant in the desired region and migrate your users, groups, and data. That is why choosing the region at sign-up is critical.

**What happens to my Azure resources if I delete the tenant?**

Deleting the tenant removes all identities. Any Azure subscriptions owned by that tenant become orphaned and cannot be managed. Azure resources in those subscriptions will eventually become inaccessible.

**Can I use the same custom domain in multiple tenants?**

No, a custom domain can be verified in only one tenant at a time. If you need to move a domain to a different tenant, you must remove it from the current tenant first.

**What is the difference between a tenant and a subscription for billing?**

The tenant does not have a direct cost. Billing is associated with subscriptions. The tenant determines which users can access the resources paid for by the subscription.

**How do I find my tenant ID?**

You can find the tenant ID in the Azure portal under Microsoft Entra ID -> Properties. The tenant ID is a globally unique identifier (GUID) used in scripts and API calls.

**What is the default domain of a tenant?**

The default domain is in the format yourorganization.onmicrosoft.com. You can add custom domains, but the default domain always remains.

## Summary

A tenant is the fundamental building block of identity in the Microsoft cloud. It is a dedicated, isolated instance of Microsoft Entra ID that an organization receives when it signs up for services like Azure or Microsoft 365. The tenant holds all user accounts, groups, applications, and security policies, and it ensures that an organization’s data is completely separate from every other customer.

Understanding the tenant is essential for any IT professional because it is the boundary for identity management, security, and compliance. Misunderstanding the tenant concept can lead to serious mistakes, such as creating users in the wrong tenant, losing data by deleting a tenant, or misconfiguring security policies that affect the entire organization. In exams like AZ-104, AZ-900, and SC-900, the tenant appears in questions about user management, conditional access, B2B collaboration, and tenant isolation.

The key exam takeaway is this: a tenant is not a subscription. Subscriptions pay for resources; the tenant controls who can access them. Always verify which tenant you are working in before making changes. Use B2B collaboration for external partners, and never create duplicate accounts across tenants. When you pass your exam and work in the real world, the tenant will be the first thing you configure and the last thing you delete.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/tenant