Deploy and manage a Microsoft 365 tenant practice questions

Password Hash Synchronization (PHS)

Why it fails: Password Hash Synchronization (PHS) synchronizes a hash of the on-premises password to Microsoft Entra ID at intervals determined by the Microsoft Entra 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.

Microsoft Entra ID Seamless SSO

Why it fails: Microsoft Entra ID Seamless SSO is a companion feature that works by automatically authenticating domain-joined devices to Microsoft Entra ID 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.

Synchronized identity

Why it fails: 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 it fails: 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 it fails: 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.

Global Administrator

Why it fails: Global Administrator grants full tenant-wide control, including every other administrative workload, breaching the least-privilege requirement. It is tempting because it certainly includes password reset capability, and it would be the correct choice for a break-glass account or initial tenant setup.

User Administrator

Why it fails: User Administrator can also create, delete and manage users and groups, exceeding the password-reset-only scope. It is tempting because it clearly covers password resets, and it would be correct when staff must manage the full user lifecycle, not just credentials.

Helpdesk Administrator

Why it fails: Helpdesk Administrator can reset passwords for non-administrators and manage service requests, but it also holds other privileges such as managing service health and password resets for some admin roles, exceeding the stated scope. It is tempting because the name matches helpdesk duties, and it would suit broader first-line support tasks.

User Administrator

Why it fails: 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 it fails: 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 it fails: 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.

Global Administrator

Why it fails: The Global Administrator role has unrestricted access to all administrative features, which is too permissive.

License Administrator

Why it fails: The License Administrator can only assign and remove licenses, not reset passwords or manage user properties.

Helpdesk Administrator

Why it fails: The Helpdesk Administrator can reset passwords but cannot manage other user account properties or licenses.

Global Administrator

Why it fails: Incorrect. This role grants full access to all tenant settings, including billing, which is beyond the required scope.

Helpdesk Administrator

Why it fails: Incorrect. This role only supports password reset and service request management, not license management or role assignment.

License Administrator

Why it fails: Incorrect. This role only manages licenses, not user passwords or role assignments.

Helpdesk Administrator

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 Microsoft Entra ID/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 it fails: 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 it fails: 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: Microsoft 365 admin center

Why it fails: 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 it fails: 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: Microsoft Entra Connect

Why it fails: Microsoft Entra 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 Microsoft Entra Connect cannot fulfill the migration requirement on its own.

MX record

Why it fails: 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 it fails: 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 it fails: 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.

No additional step; subdomains are automatically verified after the root domain is verified.

Why it fails: Subdomains are never automatically considered verified as a result of verifying the root domain. Microsoft 365 treats each domain name, including subdomains, as a separate domain object, so sales.contoso.com must be added in the Microsoft 365 admin center and then independently proven as owned by placing the unique TXT value in its own DNS zone. The root domain’s verification record does not appear in (or prove control of) the subdomain’s DNS records.

Create a subdomain in Exchange Online using the Exchange admin center.

Why it fails: The Exchange admin center (EAC) is designed for managing mailboxes, transport rules, and accepted domains, but it has no capability to create new DNS domains or prove ownership of a subdomain. Any domain you want to use for email in Exchange Online must first exist as a verified custom domain in the Microsoft 365 tenant at large, because Exchange Online accepts domains that are already verified at the tenant level. A subdomain added only as an accepted domain in EAC without tenant-level verification would remain unverified and unusable for sending or receiving.

Modify the SPF record for the root domain to include 'sales.contoso.com'.

Why it fails: SPF records list authorized outbound mail servers and are used for SMTP authentication; they never prove domain ownership to Microsoft 365. Verifying sales.contoso.com requires placing a unique TXT record (or CNAME) generated for that subdomain in its DNS, not modifying the root domain's SPF. Changing SPF would not add the subdomain as a verified custom domain or affect the tenant's domain list.

Exchange admin center -> recipients -> mailboxes -> default mailbox quota

Why it fails: The Exchange admin center's 'default mailbox quota' option applies to on-premises Exchange mailbox databases, not Exchange Online. In Exchange Online, the default quota is managed via mailbox plans or the Microsoft 365 admin center.

Microsoft 365 admin center -> Users -> Active users -> default storage limit

Why it fails: The Microsoft 365 admin center's 'Active users' section allows setting storage limits per user, but not a default for all new users.

Exchange Online PowerShell: Set-OrganizationConfig -DefaultMailboxSize

Why it fails: Set-OrganizationConfig -DefaultMailboxSize is not a valid cmdlet in Exchange Online. The organization configuration does not have a parameter for default mailbox size; instead, mailbox plans are used.

Create an SPF record for the domain.

Why it fails: Creating an SPF record before adding the domain is ineffective because SPF is a DNS TXT record used to authorize senders for outbound email, not to prove domain ownership in Microsoft 365. Domain verification relies on a separate TXT record that Microsoft generates at the start of the add-domain process. SPF is added only after the domain is verified and you are ready to route or send email, and it must include Exchange Online's host.

Create a MX record pointing to Exchange Online.

Why it fails: An MX record is a DNS resource record that tells other email systems where to deliver mail, and you can only configure it correctly after fabrikam.com is added to the tenant and verified. Creating an MX record pointing to Exchange Online ahead of time doesn't demonstrate domain ownership, because verification requires the exact TXT record issued in the admin center. Without the verified domain, messages to those addresses will not be accepted by Exchange Online, so MX configuration belongs to the post-verification DNS step.

Assign Microsoft 365 licenses to users with @fabrikam.com addresses.

Why it fails: Assigning licenses with @fabrikam.com user principal names before the domain is added is impossible because the tenant has no authority over that mailbox domain and the user UPN cannot be set to an unverified suffix. You must first add and verify the domain, then create or update user accounts with that address, and only then assign licenses that enable features. Attempting to assign a license early will fail or leave users in a non-functional state because the identity domain is not recognized.

Global Administrator

Why it fails: Global Administrator holds unrestricted access to every Microsoft 365 workload, including service health, so it could technically complete the task. However, it is far from the minimum privilege because it also permits directory changes, user management, and security administration. Granting this role solely for service health notifications violates the least-privilege security model and unnecessarily increases the risk of compromise.

User Administrator

Why it fails: User Administrator is scoped to identity management tasks, such as creating users, managing licenses, resetting passwords, and assigning groups. It has no permissions on the Service Health dashboard and cannot configure or receive service health notifications. Therefore, assigning this role would not meet the user's need.

Security Reader

Why it fails: Security Reader is a read-only role for security analytics, including Microsoft 365 Defender alerts, conditional access policies, and identity protection. It does not include access to the Service Health dashboard or its notification settings, and it cannot open service requests. Thus, it is not suitable for this task.

MX record

Why it fails: MX (Mail Exchange) records are responsible for routing email to the correct mail servers for a domain, using SMTP delivery. They do not contain any arbitrary text or unique token that Microsoft 365 can read to confirm ownership. Adding an MX record only tells other mail servers where to send messages, so it cannot fulfill the domain verification requirement.

CNAME record

Why it fails: A CNAME record creates an alias that maps one hostname to another, such as www.fabrikam.com to fabrikam.com. While CNAMEs are used for services like Autodiscover or www redirection, they cannot carry an arbitrary verification token. Microsoft 365 specifically requires a TXT record at the domain root, so a CNAME record cannot be used to verify the domain.

record

Why it fails: An A record maps a hostname to an IPv4 address and is used for routing traffic to a server. It has no field for storing text or tokens, so it cannot contain the Microsoft 365 verification value. Adding an A record for fabrikam.com only points the domain to an IP address and does nothing to satisfy the TXT-based domain ownership check.

The on-premises Exchange server must have the MRS Proxy service installed and running

Why it fails: MRS Proxy is a service that supports server-initiated moves and is required for hybrid deployments where the on-premises Exchange server orchestrates the migration with Microsoft 365. In a cutover migration, the direction is reversed: Microsoft 365's migration service initiates the connection directly to the on-premises Exchange server's MRS endpoint, so the MRS Proxy component is not invoked. While both scenarios use the Mailbox Replication Service, cutover migrations rely on the on-premises server exposing its standard MRS endpoint over the internet, not the MRS Proxy. Therefore, having MRS Proxy installed and running is not a prerequisite for a cutover migration.

TLS certificate must be bound to the on-premises Exchange server for migration authentication

Why it fails: Cutover migration authenticates using Basic authentication (a username and password supplied during the migration batch), not certificate-based authentication. The connection itself is encrypted with TLS, which requires the on-premises Exchange server to present a certificate valid for the public FQDN and trusted by Microsoft 365—typically from a public CA. However, this is a general HTTPS prerequisite for exposing any Exchange endpoint for migration, not a distinct 'migration authentication' requirement. There is no separate certificate binding or special certificate type specifically for cutover migration authentication, so this option incorrectly describes the authentication mechanism.

The administrator executing the migration must have on-premises Exchange Organization Management role

Why it fails: The administrator account used for a cutover migration only needs the ApplicationImpersonation RBAC role on the on-premises Exchange server, which lets it access all mailboxes without needing a full Organization Management membership. The account must also have sufficient permissions in Microsoft 365 (e.g., Exchange Administrator or Global Administrator), but the on-premises side does not require the highest-privileged role group. The Organization Management role group includes many administrative functions (like server configuration and recipient management) that are not relevant to merely migrating mailbox data. So while some Exchange permissions are necessary, a member of Organization Management is not the required role; a delegated impersonation role is sufficient.

Use the Microsoft 365 admin center to directly edit and manage all user objects in the on-premises Active Directory to ensure synchronization consistency.

Why it fails: The Microsoft 365 admin center does not provide direct editing of on-premises Active Directory objects; it only manages cloud-side user attributes. Attempting to edit on-premises AD objects from the admin center would introduce sync inconsistencies because Microsoft Entra Connect's directory synchronization is one-way from on-premises to the cloud, and changes made in the cloud are not written back except for specific attributes. The correct approach is to manage on-premises users with AD admin tools or use Microsoft Entra Connect with directory extensions, not the admin center.

Disable multi-factor authentication (MFA) for all users during the initial deployment to simplify onboarding, and enable it after 30 days.

Why it fails: Disabling multi-factor authentication (MFA) for all users during initial deployment, even for 30 days, leaves the organization vulnerable to credential compromise and is contrary to Microsoft security best practices and conditional access policies. MFA is a foundational identity security control that should be enabled from the very start, especially because attackers quickly target newly provisioned cloud accounts. While you can phase MFA rollouts by pilot group, it should never be completely disabled for all users; at minimum, use security defaults as a temporary safeguard.

Microsoft 365 Business Basic: Includes everything in Business Standard plus advanced security.

Why it fails: Incorrect — this describes Business Premium, not Business Basic.

Microsoft 365 Business Standard: Includes Desktop Office apps and Intune.

Why it fails: Incorrect — Intune is in Business Premium, not Business Standard.

Create Data Loss Prevention (DLP) policies to block sharing.

Why it fails: DLP policies do not restrict Copilot's grounding.

Remove the sensitive documents from SharePoint Online.

Why it fails: Removing documents is not practical and may break business processes.

Configure Microsoft Search to exclude the sensitive documents.

Why it fails: Search exclusion does not prevent Copilot from grounding on documents.