Deploy and manage a Microsoft 365 tenant practice questions

Verify domain ownership by adding a TXT record

Why wrong: Adding a TXT record to verify domain ownership is a secondary step that occurs only after the domain has been added to the Microsoft 365 admin center. The admin center generates a unique TXT value that must be published in public DNS, and this verification value does not exist until the domain is registered with the tenant. Attempting verification first is impossible because Microsoft 365 has no domain object to verify.

Configure DNS records for Microsoft services

Why wrong: Configuring DNS records such as MX, CNAME, and TXT for Exchange Online and other Microsoft services is performed only after domain ownership has been verified. Unverified domains cannot receive email or enforce routing rules, and Microsoft 365 will not provision a domain in DNS until the TXT verification is complete. This step is essential but chronologically later, so it cannot be the first action.

Set the domain as the primary email domain

Why wrong: Setting the domain as the primary email domain is a final administrative decision made only after the domain has been verified and its required DNS records are configured. The primary domain affects the default user principal name (UPN), email address policy, and the From address for new users, so changing it prematurely could disrupt existing user provisioning and mail flow. This should be deferred until all prerequisite checks have passed.

Conditional Access policy to block external users

Why wrong: A Conditional Access policy blocks sign-in sessions by evaluating conditions such as user, device, location, and risk after an identity attempts to authenticate. It can deny external users access to resources at sign-in time, but it has no influence over the B2B invitation process because invitation delivery is an administrative operation in Entra ID, not a sign-in event that Conditional Access can intercept or block.

Tenant restrictions

Why wrong: Tenant restrictions use a proxy-injected 'Restrict-Access-To-Tenants' header to prevent users in your organization from authenticating to unauthorized external tenant IDs, establishing an outbound security boundary. They do not govern the inbound B2B invitation workflow or who in your tenant has permission to send guest invitations, so they cannot stop external-user invites from being issued.

B2B direct connect

Why wrong: B2B direct connect creates a mutual, transparent trust relationship between your tenant and another tenant for collaborative scenarios like Teams Connect shared channels, and it does not require guest user accounts. It is an enabling feature for cross-tenant collaboration rather than a governance setting, and it neither grants nor blocks the ability to invite external users as B2B guests.

Password Hash Synchronization (PHS)

Why wrong: Password Hash Synchronization (PHS) synchronizes a hash of the on-premises password to Azure AD at intervals determined by the Azure AD Connect sync cycle (typically every 30 minutes, or more frequently with delta syncs). Because the cloud tenant validates the hash, a password change in on-premises Active Directory will not be recognized in Microsoft 365 until the next sync cycle completes, so there is an inherent and unavoidable delay before the new password is usable in the cloud. This latency directly fails the requirement that password changes be honored immediately, making PHS the wrong choice for an immediate-failover scenario.

Azure AD Seamless SSO

Why wrong: Azure AD Seamless SSO is a companion feature that works by automatically authenticating domain-joined devices to Azure AD without prompting for credentials a second time. It relies on a Kerberos ticket and integrates with either PHS or PTA, but it does not itself synchronize or validate password changes. If a user's password changes on-premises, Seamless SSO will continue to use the cached Kerberos ticket until it expires or is refreshed, and the actual password change propagation still depends on the underlying sync or federation mechanism. Therefore, Seamless SSO cannot be the sole mechanism to provide immediate password-change enforcement; it merely masks the initial authentication prompt.

Microsoft Entra admin center

Why wrong: Microsoft Entra admin center is not the correct portal for Microsoft 365 user license management because it is focused on identity and access policy configuration, such as Conditional Access, security defaults, and multifactor authentication. Although it contains directory user objects, its role is to govern how identities are authenticated and authorized, not to administer subscription-based Microsoft 365 services. License assignment for M365 is performed from the Microsoft 365 admin center, which integrates with Entra ID to handle the underlying directory writes.

Microsoft 365 Defender

Why wrong: Microsoft 365 Defender is a security operations solution, not an administration tool, so it cannot be used to manage user accounts. It centralizes threat detection, incident response, and hunting across email, endpoints, and identities, giving security analysts a view of risky sign-ins and compromised accounts. Creating user accounts, assigning roles, or managing subscriptions is outside its scope and would be performed in a management portal such as Microsoft 365 admin center.

Azure Active Directory admin center

Why wrong: The Azure Active Directory admin center—the legacy predecessor to the Entra admin center—does support basic directory user creation and a limited set of account settings, but it is not the primary interface for Microsoft 365 user management. It lacks the Microsoft 365 service-specific administrative views, such as license quotas, product seat assignment, and usage reports, which are central to managing M365 accounts. Microsoft 365 admin center replaces it for day-to-day user and license administration in a subscription.

Synchronized identity

Why wrong: Synchronized identity copies password hashes from on-premises Active Directory to Microsoft Entra ID via Microsoft Entra Connect, and authentication subsequently happens in the cloud against those stored hashes. This directly conflicts with the requirement to authenticate users against the on-premises directory without syncing passwords, because the cloud becomes the authentication authority for password-validated logins. Even if seamless single sign-on or pass-through authentication is used with this model, the standard synchronized-identity deployment necessarily relies on password hash synchronization for cloud authentication.

Cloud-only identity

Why wrong: Cloud-only identity means every user account is created directly in Microsoft Entra ID with credentials stored and verified entirely in the cloud, and there is no connection to an on-premises Active Directory forest. Because the on-premises directory plays no role in provisioning or authentication, this model cannot satisfy the stated requirement that users authenticate against their existing on-premises Active Directory. It is only appropriate for organizations that do not need any hybrid identity integration.

Microsoft-managed identity

Why wrong: Microsoft-managed identity is not a user identity model for Microsoft Entra ID; rather, Azure managed identities are automatically managed service principals used to authenticate Azure resources (for example, a virtual machine or Azure Function) to Entra ID. They have no ability to authenticate human users against on-premises Active Directory and are not part of Microsoft's supported hybrid identity options (cloud-only, synchronized, or federated). This option appears to confuse Azure resource authentication with user identity architecture.

Create an Exchange mailbox manually

Why wrong: In Exchange Online, you cannot manually create a mailbox for a cloud user using the Exchange admin center—the EAC's 'Create a mailbox' action only applies to shared, room, and equipment mailboxes, which are not associated with a user sign-in account. User mailboxes are derived from licensed user objects, so there is no separate 'create user mailbox' workflow. Attempting to create one manually would be both unsupported and redundant, because the licensing pipeline already manages the mailbox lifecycle.

Run the Microsoft 365 Setup wizard

Why wrong: The Microsoft 365 Setup wizard is a tenant-level onboarding tool that guides initial configuration, such as adding a custom domain, setting up user accounts, and selecting security defaults. It does not provision mailboxes for individual user objects; it runs once during tenant creation, and rerunning it won't create a mailbox for a specific new user. To get a mailbox, you must assign an Exchange Online license to that user.

Configure DNS records for the domain

Why wrong: DNS records such as MX, SPF, DKIM, and Autodiscover CNAMEs control how mail is routed to and from your Microsoft 365 tenant, but they do not trigger or influence the creation of a user's mailbox. Without a license, the new user has no mailbox, and adding these records will not change that—email for an unlicensed user would simply fail or bounce. DNS configuration is a post-provisioning step that matters only after mailboxes exist and the tenant needs to accept mail for its domains.

Create user accounts with the new domain

Why wrong: User accounts with a new domain suffix cannot be created until the custom domain has been proven owned by the tenant. The initial default domain, such as contoso.onmicrosoft.com, remains the only usable UPN suffix until DNS verification succeeds; otherwise, account creation would fail with a domain-not-verified error. Verification must come first, and only after the domain is verified can you add it as a UPN suffix and assign it to new or existing users.

Configure Exchange Online connectors

Why wrong: Exchange Online connectors are an organizational mail-flow configuration that defines how messages enter or leave your tenant for hybrid systems, third-party cloud filters, or other remote SMTP servers. They do not perform any authentication of domain ownership and actually require a verified domain for proper setup—so configuring connectors before verification is both premature and ineffective. The initial domain verification step is a simple DNS TXT record lookup, not a mail-flow rule.

Set up MX records for email routing

Why wrong: MX records determine where incoming email for the domain is delivered and are a post-verification step when configuring Exchange Online's email routing. Microsoft does not accept an MX record as proof of domain ownership for a custom domain in this scenario; verification relies specifically on a DNS TXT record with a Microsoft-provided value. Attempting to set up MX records before verification will not satisfy the ownership check and could misdirect email if the corresponding tenant services have not been configured.

User Administrator

Why wrong: The User Administrator role is scoped to identity lifecycle actions such as creating, managing, and deleting users and groups, resetting passwords, and managing authentication methods. It does not possess the Microsoft Graph permissions required to assign or remove Microsoft 365 licenses, nor can it manage license-based groups. While User Administrators can delegate a limited subset of lower-privileged roles, this does not include the full role-assignment capability combined with license management required here, so it falls short.

Global Administrator

Why wrong: Global Administrator has unrestricted access to every administrative feature in Microsoft 365, including license management and role assignment, but that breadth is exactly the problem. Delegating this task to a Global Admin would also allow the delegate to elevate other users to Global Administrator, modify tenant-wide policies, and access all workloads, exceeding the minimal permissions needed. This violates the principle of least privilege and unnecessarily expands the attack surface, making License Administrator the correct scoped choice.

Helpdesk Administrator

Why wrong: Helpdesk Administrator is a support-focused role that can reset passwords, manage service requests, and perform device actions, but it has read-only access to directory information and no license management permissions. It also lacks the permission to assign administrative roles, so it cannot fulfill the 'assign roles' half of the requirement. Because it does not touch the licensing or role-assignment permission sets, it is not an appropriate delegate for this task.

Add a DNS TXT record for the custom domain.

Why wrong: Adding a DNS TXT record for the custom domain is part of the domain verification process to prove ownership to Microsoft 365. Although verification is a prerequisite for using the domain with services like Exchange Online, it does not control which domain is assigned to new user email addresses. Verification merely confirms that you control the DNS namespace; the default email domain is a separate configuration found in the Domains settings. Therefore, this action alone would not set the custom domain as the default for new users.

Change the primary domain in the tenant's organization profile.

Why wrong: Changing the primary domain in the tenant's organization profile only alters the initial Azure AD domain, such as yourtenant.onmicrosoft.com, that identifies the entire organization. This setting does not determine the email domain for new users, because the primary domain is independent of the default user-email domain configuration. The default email domain is managed specifically under Domains settings, while the organization profile's primary domain is used for administrative URLs and Azure AD-related services. Misinterpreting these two distinct settings is a common source of confusion.

Update the MX record for the custom domain to point to Exchange Online.

Why wrong: Updating the MX record for the custom domain to point to Exchange Online is necessary for incoming mail routing, ensuring that email sent to that domain is delivered to your Microsoft 365 mailboxes. However, the MX record has no effect on the email address format assigned to newly created users; it only governs how messages are delivered once an address already exists. New-user email addresses are drawn from the default domain setting in Microsoft 365, not from the MX record. Without changing the default domain, new users would still get the onmicrosoft.com suffix even if MX is correctly configured.

user@contoso.com

Why wrong: user@contoso.com would require a custom domain that you own and have registered as contoso.com, then added to the Microsoft 365 tenant and verified via DNS (usually a TXT record) before it can be used in user principal names. Since the sign-up only created the initial onmicrosoft.com tenant, no custom domain is automatically available, and until contoso.com is verified and optionally set as the default domain, new users cannot be assigned that email address.

user@microsoft.com

Why wrong: user@microsoft.com is invalid because microsoft.com is a Microsoft-owned corporate domain, not a domain registered to your tenant, and Microsoft 365 only allows user principal names to use domains that are verified as belonging to your organization. Attempting to assign a UPN with microsoft.com would fail during user creation because the domain is not in the tenant's accepted domains list, and mail routing to that address would conflict with Microsoft's own infrastructure.

user@contoso.microsoft.com

Why wrong: user@contoso.microsoft.com is not a valid default domain format because Microsoft 365 only provisions the <tenantname>.onmicrosoft.com suffix, and microsoft.com cannot be used as a parent domain to create customer subdomains. You can add custom third-level domains like sub.contoso.com if you own them, but contoso.microsoft.com is under a Microsoft-owned domain that no customer can verify or claim, so it will never appear in the accepted domains list.

MX record

Why wrong: MX (Mail Exchange) records specify the servers that accept incoming email for a domain and route SMTP traffic according to priority. They do not contain Microsoft's verification token, and modifying an MX record during setup could misroute your email before verification completes. Microsoft requires a TXT record for the initial domain ownership proof because MX records serve a routing function, not a validation function.

CNAME record

Why wrong: CNAME (Canonical Name) records alias one hostname to another, such as autodiscover.yourdomain.com pointing to autodiscover.outlook.com, which is used for service connectivity after verification. However, CNAMEs cannot carry the arbitrary alphanumeric verification string that Microsoft generates, nor are they queried during the ownership check. The verification process specifically looks for a TXT record; a CNAME only configures hostname aliases and cannot prove you control the domain's root.

SPF record

Why wrong: SPF (Sender Policy Framework) is also published as a TXT record, but it is a structured email authentication directive that lists authorized sending servers (e.g., v=spf1 include:spf.protection.outlook.com ~all). It does not contain Microsoft's unique verification token, and Microsoft's verification lookup will ignore it when searching for the exact match TXT string. Using SPF for verification would fail and could introduce mail-delivery issues, as SPF is an authentication policy, not an ownership challenge.

Settings > Org settings > Security & privacy

Why wrong: The Settings > Org settings > Security & privacy node manages security-related tenant policies, such as password expiration policies, self-service password reset, and privacy statement URLs. While these settings may affect user authentication security, they do not include the ability to customize the sign-in page or display a custom help desk phone number/email. Sign-in branding is a separate feature that lives under Organization profile's custom branding section.

Billing > Licenses

Why wrong: Billing > Licenses is dedicated to purchasing, assigning, and managing user subscriptions and product licenses within the tenant. It tracks license quantity, seat usage, and per-user allocation, but it does not contain any settings that affect the appearance or content of the sign-in page. Help desk contact information is part of the sign-in branding, which is stored in the organization profile, not in licensing.

Health > Service Health

Why wrong: Health > Service Health provides operational status for Microsoft 365 services, including current incidents, advisories, and historical uptime information. It is a monitoring and diagnostic tool, not a configuration surface, so it cannot be used to alter the sign-in page's branding or contact details. The help desk info displayed on the sign-in page is a branding artifact, unrelated to service health.

Helpdesk Administrator

Why wrong: While the Helpdesk Administrator role can also view service health and manage service requests in many tenants, it additionally grants broad user management permissions such as password resets, license assignments, and user profile editing. These extra capabilities exceed what is required for the task, so using this role would violate the principle of least privilege. The Service Support Administrator role is narrower and therefore the better fit.

Service Administrator

Why wrong: There is no built-in role named 'Service Administrator' in Microsoft 365 or Microsoft Entra ID; the correct role name is 'Service Support Administrator.' Assigning a non-existent role is impossible, and a custom role would have to be created if such a name were required, which is unnecessary here. Always verify exact built-in role names to avoid this common distractor.

Security Reader

Why wrong: Security Reader is a read-only role focused on security-related areas such as identity protection, sign-in logs, and Conditional Access reports. It cannot view the Microsoft 365 service health dashboard because that data is outside its security-specific scope, nor can it create or manage service requests. Therefore it lacks both required permissions and is not suitable for this delegation.

Global Reader

Why wrong: The Global Reader role provides read-only access to every aspect of an Entra ID tenant, spanning user profiles, group memberships, device configurations, billing information, and directory settings that are unrelated to security monitoring. While it can view sign-in and audit logs, its breadth violates least privilege by exposing far more sensitive administrative data than necessary for a simple log-viewing task. This over-permissive scope makes it inappropriate for the delegation described.

Reports Reader

Why wrong: The Reports Reader role is designed to view Microsoft 365 usage and adoption reports, such as active user counts and product usage analytics, but it does not have permission to access the underlying Entra ID sign-in logs or directory audit logs. Those logs are protected under the Security Reader or more privileged roles, so assigning Reports Reader would leave the delegate unable to view the required security data. This role is insufficient for the described monitoring task.

Security Administrator

Why wrong: The Security Administrator role carries significant write privileges, including the ability to configure conditional access policies, enforce multi-factor authentication, reset user passwords, and modify security roles, which goes far beyond read-only log viewing. Because the delegation scenario requires only visibility into sign-in and audit logs, granting this role would expose the organization to unnecessary security risk and violate the principle of least privilege. A read-only role such as Security Reader should be used instead.

Settings > Org settings > Organization profile

Why wrong: The Organization profile page under Microsoft 365 admin center > Settings > Org settings only stores tenant metadata like business name, address, contact information, and preferred language. It has no controls for the Azure AD/Microsoft Entra ID sign-in screen, and configuring it never alters the login page's logo, background, or text. Even though this section may appear related to identity branding, sign-in page customization is handled exclusively in Microsoft Entra ID under Company branding, not in organizational profile settings.

Security & Compliance center > Data classification

Why wrong: In the Security & Compliance center (now the Microsoft Purview portal), Data classification is used to create sensitivity labels, apply labels to content, and enforce policies like archive or retention. These settings operate on data stored in SharePoint, OneDrive, and email, not on authentication endpoints, so they cannot influence the look or text of a sign-in page. Sign-in theme changes are an identity-layer feature and must be applied through Microsoft Entra ID's Company branding, never via compliance or labeling workflows.

Exchange admin center > Mail flow > Accepted domains

Why wrong: The Exchange admin center's Mail flow > Accepted domains section designates which SMTP domains are authoritative/internal relay domains for message delivery, which determines where email is routed. This does not affect authentication, token issuance, or the Microsoft 365 sign-in experience; it only influences mail flow behavior in transport. If a tenant uses the same domain for user accounts and email, that domain appears in the user principal name, but the sign-in page visuals are still governed by Microsoft Entra ID's Company branding configuration.

A: Create a PowerShell script that runs on a schedule to assign licenses based on department attribute.

Why wrong: This approach requires you to build, deploy, schedule, and maintain a custom PowerShell automation pipeline, typically using the Azure AD PowerShell module or Microsoft Graph, to query each user's department attribute and then assign the matching license SKU. Because it runs on a timer, new users may wait until the next run before receiving a license, and any unhandled script error can leave users permanently unlicensed. It also creates operational debt for a scenario that Azure AD can handle natively, so it is not the most appropriate answer.

B: Use group-based licensing and assign each department's users to a security group with the appropriate license.

Why wrong: Group-based licensing itself is the correct underlying mechanism, but this option requires manually placing each new user into the appropriate department-specific security group as part of your provisioning process. Any new user who is not manually added will not receive a license, so the solution does not meet the 'all new users automatically' requirement. The missing piece is automatic membership: dynamic groups should drive the group membership, while group-based licensing automatically applies the license to whichever users become members.

D: Manually assign licenses to each user after creation.

Why wrong: Manually assigning licenses to each user after creation requires an administrator to identify every new user, determine the correct license SKU based on department, and click through the licensing UI for each account. This process does not scale, is error-prone, and can be easily missed for high-volume user creation, especially when the requirement is to ensure every new user is licensed at creation. It provides no automation and relies on continuous human action.

A: Microsoft 365 admin center

Why wrong: The Microsoft 365 admin center is the portal for tenant-wide configuration: managing users, licenses, billing, and service health. It does not include any mechanism for migrating on-premises mailbox data or configuring directory synchronization for hybrid mail flow. Its role is limited to cloud-side administrative tasks, so it cannot perform the mailbox replication or coexistence setup required for an Exchange hybrid migration.

B: Exchange Admin Center

Why wrong: The Exchange admin center (EAC) in Exchange Online provides management of cloud mailboxes, groups, and transport rules, while the on-premises EAC manages the local Exchange environment. However, the EAC does not contain a built-in migration wizard that orchestrates the full hybrid configuration, including the secure service connection, organization relationship, and mailbox move endpoints. Those tasks are handled by the dedicated Hybrid Configuration Wizard, making the EAC an incomplete tool for this scenario.

D: Azure AD Connect

Why wrong: Azure AD Connect synchronizes on-premises directory identities (users, groups, and passwords) to Microsoft Entra ID, which is necessary before any hybrid migration so users have cloud identities. However, it does not copy mailbox content, calendar items, or folder permissions from the on-premises Exchange databases to Exchange Online. Identity synchronization alone leaves mailbox data untouched, so Azure AD Connect cannot fulfill the migration requirement on its own.

MX record

Why wrong: An MX record directs email flow to a specified mail server, but domain ownership verification in Microsoft Entra ID requires a TXT record containing a unique verification token provided by the tenant. The DNS system checks for this exact token string, not mail routing. An MX record is tempting because it is commonly added when configuring a custom domain for email services, and in a scenario where the goal were to route inbound messages to Exchange Online, an MX record would be the correct choice.

CNAME record

Why wrong: A CNAME record cannot verify domain ownership for Microsoft 365 because the verification process requires a TXT record containing a unique verification token provided by Microsoft Entra ID; a CNAME record aliases one hostname to another but does not carry the token data needed to prove control over the domain. This option is tempting because CNAME records are commonly used to route services like email or web traffic to Microsoft 365, and in scenarios such as configuring a custom domain for Exchange Online or SharePoint, a CNAME record would be the correct choice for service redirection rather than ownership verification.

record

Why wrong: An A record maps a hostname to a 32-bit IPv4 address, such as 192.0.2.1, and is used for name resolution to web servers or other services. It contains no verifier-generated token and cannot demonstrate that you control the DNS namespace for the domain. Domain ownership verification in Microsoft Entra ID hinges on a DNS query for a specific TXT record value, not on any address mapping. Adding an A record would never satisfy the domain validation challenge.

Number of affected users

Why wrong: The number of affected users is a business-impact metric that support may factor into severity or SLA response times, but it is not required to open a ticket. During initial triage, the engineer can proceed with the Tenant ID and a detailed problem description, then ask for the user count if needed. Specifically, this number can be updated later via an incident change request, so it should never block submission of the support request.

Network bandwidth graph from the past 24 hours

Why wrong: A network bandwidth graph is a specialized diagnostic artifact that support will explicitly request only after initial checks point to connectivity, jitter, or throughput as a root-cause candidate. Prematurely attaching it can mislead triage, because most M365 issues are due to identity or service-side states rather than local bandwidth. It is also not a standard field in the Microsoft 365 admin center support request form, so supplying it provides no benefit to the initial routing.

Cross-tenant access settings

Why wrong: Cross-tenant access settings control B2B collaboration at the level of entire Microsoft Entra ID tenants, not individual e-mail domains. You can block a specific tenant ID or set trust settings, but you cannot add 'contoso.com' as a blocked domain unless that domain is isolated to one tenant. Since contoso.com could belong to any tenant, this setting cannot enforce a domain-wide guest invitation block.

User settings

Why wrong: User settings in Microsoft Entra ID manage options such as self-service group creation, user registration, and allow or block users from signing in, but they do not include any domain-specific invitation restrictions. The ability to block guest invitations by domain is a separate capability scoped to the External collaboration settings page, not to user profile or user lifecycle settings. Therefore, configuring User settings cannot satisfy the requirement.

Domain federation

Why wrong: Domain federation configures an authentication trust between Microsoft Entra ID and an external identity provider, such as AD FS, using SAML or WS-Fed, for validating credentials of federated users. It does not manage B2B guest invitations or maintain a block list for e-mail domains. Federation is about how users authenticate, not about whether they can be added as guests, so it cannot prevent invitations to users at contoso.com.