Microsoft MS-203 Exam Dumps & Practice Test Questions
Question 1:
Your organization uses a proxy that intercepts HTTPS traffic. After moving to Microsoft Exchange Online, users can't access their mailboxes and see certificate warnings for outlook.office.com. What should you do to fix this issue and ensure secure connectivity?
A. Deploy the organization's root CA certificate on every user's computer.
B. Set client machines to skip the proxy when accessing https://*.microsoft.com.
C. Turn off HTTPS traffic inspection on the proxy server.
D. Add the organization’s root CA certificate to the proxy server.
Correct Answer: C
Explanation:
This scenario revolves around HTTPS traffic interception, certificate trust, and Office 365 (Exchange Online) connectivity issues. In environments with transparent HTTPS inspection, the proxy server decrypts and re-encrypts HTTPS traffic, issuing a substitute certificate to the client. This helps with content filtering and security enforcement but can cause problems when dealing with services like Microsoft 365, which depend on certificate pinning for secure communication.
Let’s break down what’s happening in this case:
When a user tries to access https://outlook.office.com/mail, the proxy server intercepts the HTTPS request. It acts as a man-in-the-middle, decrypts the request, and presents a new certificate that was re-signed by your organization’s internal Certificate Authority (CA). This results in a certificate warning unless the client trusts the internal CA, and more importantly, this interception breaks Office 365 connections, because Microsoft services use certificate pinning and do not allow intermediaries to reissue or alter their certificates.
Here’s why each option matters:
A. Deploy the organization's root CA certificate on every user's computer
This would eliminate the certificate warning when accessing re-signed HTTPS sites via the proxy. However, it does not solve the root problem—Microsoft Outlook and other Office apps use certificate pinning, so even if the certificate appears trusted, the application will reject it because it knows what the real Microsoft certificate should look like. This may fix browser access but not full Outlook functionality. Therefore, this is not sufficient.
B. Set client machines to skip the proxy when accessing https://*.microsoft.com
This could work in theory but is unreliable and difficult to maintain. Microsoft services are hosted across hundreds of domains and IP ranges, which change frequently. Maintaining exception rules for all required Office 365 endpoints would be impractical and error-prone, potentially still leading to connectivity issues. Microsoft recommends allowing Office 365 traffic to bypass HTTPS inspection entirely via more targeted configurations.
C. Turn off HTTPS traffic inspection on the proxy server
This is the correct and recommended solution. Microsoft officially advises that HTTPS inspection be disabled for Microsoft 365 endpoints, particularly those used by Exchange Online, Teams, and other services that rely on certificate pinning. These applications will fail to establish secure connections if their certificates are tampered with—even by trusted proxies. Disabling inspection for Microsoft domains (not globally) ensures that clients see the authentic Microsoft certificate, which preserves functionality and security.
To properly configure this, organizations should:
Disable HTTPS decryption on the proxy for known Microsoft 365 endpoints.
Use Microsoft’s published IP and URL lists (via the Microsoft 365 IP Address and URL Web service) to automatically update the proxy exception rules.
Allow direct outbound access for this traffic.
D. Add the organization’s root CA certificate to the proxy server
This is unnecessary and irrelevant. The proxy server issues certificates signed by the organization’s internal CA—it doesn’t need to trust them itself. Clients need to trust the internal CA (as in A), but again, that still won't solve the pinning issue. So, this option is technically misguided.
The only way to ensure Office 365 services function correctly in a proxy-inspected environment is to stop HTTPS interception for Microsoft 365 domains, as per Microsoft's official guidance. That’s why C is the correct answer.
Question 2:
You're managing a hybrid Microsoft Exchange Server 2019 environment and want to prevent senior executives’ mailboxes from appearing in the Global Address List (GAL). What two methods can help you accomplish this?
A. Use the Set-Mailbox PowerShell command to alter each executive’s mailbox settings.
B. Update the Global Address List properties via the Exchange Admin Center (EAC).
C. In the Exchange Admin Center, adjust each executive’s mailbox settings.
D. Use the Set-GlobalAddressList PowerShell command to edit the GAL directly.
Correct Answer: A, C
Explanation:
In Microsoft Exchange—whether in a purely on-premises, hybrid, or cloud-based (Exchange Online) environment—the Global Address List (GAL) is the directory of all mail-enabled objects in the organization. Sometimes, organizations wish to hide sensitive or high-profile mailboxes, like those of senior executives, from appearing in the GAL for privacy and security reasons.
The standard and supported method to hide a mailbox from the GAL is to set the HiddenFromAddressListsEnabled property to $true for the mailbox. This can be done through PowerShell or the Exchange Admin Center (EAC).
Let’s evaluate each option:
A. Use the Set-Mailbox PowerShell command to alter each executive’s mailbox settings
This is correct. You can use the following PowerShell command on your Exchange Management Shell (on-premises) or via Exchange Online PowerShell (if managing remote mailboxes in a hybrid setup):
Set-Mailbox -Identity "John Doe" -HiddenFromAddressListsEnabled $true
This will hide the mailbox from the GAL and any other address lists. This approach is commonly used in both on-premises and hybrid environments, especially for automation or scripting across multiple users.
B. Update the Global Address List properties via the Exchange Admin Center (EAC)
This is incorrect. The EAC does not provide an interface for modifying the GAL itself in terms of what individual users are shown. GAL modification is not handled through a UI-based “exclude” list. The GAL is a dynamically generated list based on user properties—not a manually curated list that you can modify directly via EAC in this way.
C. In the Exchange Admin Center, adjust each executive’s mailbox settings
This is correct. In the EAC, you can select a user mailbox, open its properties, and there is an option like “Hide from address lists” (checkbox). Checking this option sets the same property (HiddenFromAddressListsEnabled = $true) behind the scenes. This is useful for administrators who prefer a graphical interface or when only a few mailboxes need to be updated.
D. Use the Set-GlobalAddressList PowerShell command to edit the GAL directly
This is incorrect for this purpose. The Set-GlobalAddressList cmdlet allows you to configure properties of the GAL itself, such as name, recipient filter, and domain controller. However, it does not support hiding specific users from the GAL manually. The visibility of a user in the GAL is controlled by user mailbox attributes, not by the GAL object. Attempting to exclude individuals via GAL filters is not a scalable or recommended method.
Key Takeaways:
The recommended method to hide a mailbox from the GAL is to set HiddenFromAddressListsEnabled = $true.
This can be done via PowerShell (Set-Mailbox) or through the EAC UI.
The GAL is dynamically populated based on attributes—not a static list where you can manually remove users.
These changes replicate to Azure Active Directory and Exchange Online in hybrid environments via directory sync, making them effective in both on-prem and cloud contexts.
Therefore, the two correct methods to achieve the desired result are A and C.
Question 3:
Your organization requires all iOS users to access Exchange Server 2019 mailboxes solely via the Outlook mobile app. What configuration step should you take to enforce this policy?
A. Execute the New-DeviceConditionalAccessPolicy command using the Exchange Management Shell.
B. Set up a mobile device access policy via the Exchange Admin Center.
C. Use the New-DeviceConfigurationRule command from the Exchange Management Shell.
D. Modify the default mobile device mailbox policy within the Exchange Admin Center.
Correct Answer: A
Explanation:
To enforce a policy that restricts mobile access to Exchange mailboxes only through the Microsoft Outlook mobile app, particularly for iOS users, you must control which devices and apps can connect to Exchange. This requires conditional access enforcement and specific app-based control mechanisms. In Exchange Server 2019, this level of control is achievable through Intune (Microsoft Endpoint Manager) when integrated with Exchange hybrid environments, or more locally, via Device Access Rules using PowerShell.
Here’s why A is the correct answer:
A. Execute the New-DeviceConditionalAccessPolicy command using the Exchange Management Shell
This is correct. The New-DeviceConditionalAccessPolicy cmdlet is used to create conditional access policies in environments where Intune is integrated with Exchange. These policies can enforce restrictions such as allowing only the Outlook mobile app to access Exchange mailboxes. When used correctly, this command allows the administrator to block native mail apps (like iOS Mail) and permit only supported applications—such as Outlook for iOS/Android.
A typical policy might look like this:
New-DeviceConditionalAccessPolicy -Name "iOS Only Outlook Mobile" -DevicePlatforms iOS -AllowApps "Outlook"
This command ensures that only devices using the Outlook mobile app on iOS can connect to Exchange, and all others will be blocked, supporting your company’s policy objective.
B. Set up a mobile device access policy via the Exchange Admin Center
This is incorrect. While the EAC provides options to create and enforce mobile device mailbox policies, these policies do not have app-level granularity. They control features like password enforcement, encryption, and device wipe, but cannot restrict which specific app is used (e.g., they can't say “allow Outlook, block iOS Mail”). So while helpful in setting general mobile device rules, EAC mobile policies do not meet the requirements of this scenario.
C. Use the New-DeviceConfigurationRule command from the Exchange Management Shell
This is also incorrect. There is no New-DeviceConfigurationRule cmdlet in Exchange Server 2019. This option appears to be a distractor or possibly a confusion with Intune policy terminology, which uses "configuration profiles" or device configuration policies—but those are managed through Microsoft Intune, not through the Exchange Management Shell. So, this command is invalid in Exchange PowerShell.
D. Modify the default mobile device mailbox policy within the Exchange Admin Center
This is incorrect for the same reason as B. The default mobile device mailbox policy defines general settings like:
Whether to require device encryption.
Whether to allow camera or Bluetooth.
How long a device can be idle before locking.
However, it cannot enforce app-specific access rules such as requiring Outlook mobile. Therefore, this policy is insufficient for the specific control required in your question.
Additional Context:
For a comprehensive, enterprise-grade solution, organizations often implement Intune App Protection Policies in conjunction with Azure AD Conditional Access to enforce such controls across all devices—including enforcing Outlook-only access and even blocking access on jailbroken/rooted devices.
However, in on-premises Exchange scenarios, the correct approach to limit mobile access by app is through the Exchange Management Shell using conditional access cmdlets—specifically New-DeviceConditionalAccessPolicy, assuming hybrid or hybrid-aware infrastructure.
Conclusion: The only option that directly allows you to enforce Outlook mobile as the exclusive app for accessing Exchange mailboxes is A, using the New-DeviceConditionalAccessPolicy cmdlet in the Exchange Management Shell.
So, the correct answer is A.
Get smarter responses, upload files and images, and more.
Question 4:
In your Exchange Server 2019 environment, how can you enforce a limit that restricts mobile devices using ActiveSync from syncing emails older than 14 days?
A. Create a new Outlook Web App (OWA) policy for mailbox access.
B. Define a mobile device mailbox policy.
C. Configure a device access rule under ActiveSync settings.
D. Apply a Conditional Access policy.
Correct Answer: B
Explanation:
In Exchange Server 2019, administrators can control how mobile devices interact with user mailboxes via ActiveSync by defining Mobile Device Mailbox Policies. These policies offer granular controls over what users can do when connecting via mobile email clients, such as how long messages are synced, device password requirements, encryption mandates, and other security features.
The specific requirement in this scenario is to restrict email sync to no more than 14 days. This setting is not managed through access rules or conditional access—it is configured via a Mobile Device Mailbox Policy.
Here’s a breakdown of each option:
A. Create a new Outlook Web App (OWA) policy for mailbox access
This is incorrect. OWA policies control settings related to web-based access to mailboxes using the Outlook Web App, such as whether users can access attachments, use rich text editing, or start instant messaging sessions. These settings do not affect mobile device sync behavior, and they do not apply to Exchange ActiveSync.
B. Define a mobile device mailbox policy
This is correct. Mobile Device Mailbox Policies (configured either in the Exchange Admin Center (EAC) or through Exchange Management Shell) provide the ability to control ActiveSync behavior on connected mobile devices.
To enforce the email sync window (such as 14 days), you can define this directly within the policy:
In EAC:
Go to Mobile > Mobile Device Mailbox Policies.
Create or edit a policy.
Under the Sync settings, set Email Age Filter to 2 weeks.
In PowerShell:
Set-MobileDeviceMailboxPolicy -Identity "Executive Mobile Policy" -EmailAgeFilter TwoWeeks
This setting limits how far back in time email messages are synced to the mobile device. If a user tries to sync messages older than 14 days, they will not be downloaded to the device. This helps in reducing data exposure and ensures that only recent messages are available on potentially vulnerable mobile endpoints.
C. Configure a device access rule under ActiveSync settings
This is incorrect. Device Access Rules allow administrators to permit, quarantine, or block specific devices based on characteristics like model or OS version. While useful for controlling what devices can connect, they do not provide settings to control synchronization behavior, such as how many days of email to sync.
D. Apply a Conditional Access policy
This is incorrect in an on-premises-only context. Conditional Access is a cloud-based feature in Microsoft Entra ID (formerly Azure AD) and requires Microsoft 365 or a hybrid setup. Even then, Conditional Access policies govern access conditions such as location, app type, or device compliance, but do not directly control email sync settings like the mail age filter. For Exchange Server 2019 standalone, Conditional Access doesn’t apply.
To enforce a sync age limit (e.g., restricting devices to only sync the last 14 days of email), the proper and only supported mechanism in Exchange Server 2019 is via a Mobile Device Mailbox Policy. This method offers security, control, and consistency across all users subject to the policy and applies specifically to ActiveSync clients (such as native mail apps on iOS and Android, and even Outlook mobile where applicable).
Therefore, the correct answer is B.
Question 5:
In a Microsoft 365 environment, User1—who holds an Enterprise F3 license—can access mail via OWA but gets the error "Encrypted connection to your mail server is not available" when using the Outlook desktop app. What is the best step to resolve this issue?
A. Use the Microsoft Support and Recovery Assistant for troubleshooting.
B. Enable Office 365 ProPlus installation.
C. Assign a different license to User1.
D. Install a valid certificate on User1’s device.
Correct Answer: C
Explanation:
This issue revolves around Microsoft 365 licensing, Outlook desktop app support, and protocol access eligibility. Let’s break it down carefully, based on what we know about the Enterprise F3 license and the error message presented.
Scenario Summary:
User1 has an Enterprise F3 license, which is a low-tier, frontline worker license.
User1 can access email through Outlook Web App (OWA), meaning mailbox provisioning and connectivity are functioning correctly.
User1 cannot set up Outlook desktop, receiving an error:
"Encrypted connection to your mail server is not available."
This message typically suggests that Autodiscover, Outlook connectivity protocols, or license-based access restrictions are the root cause.
Let’s examine the options:
A. Use the Microsoft Support and Recovery Assistant for troubleshooting
This tool (SaRA) is excellent for diagnosing a wide variety of Outlook and Microsoft 365 issues. However, in this case, the problem is license-related, not configuration-based. SaRA might confirm that Outlook cannot connect, but it cannot change license entitlements or enable blocked services. Therefore, this is not the best step—it’s not a solution, just a diagnostic tool.
B. Enable Office 365 ProPlus installation
Office 365 ProPlus (now known as Microsoft 365 Apps for enterprise) is the client software package that includes Outlook. However, enabling the installation isn’t relevant here because:
The issue is not about installing Outlook, but Outlook connectivity.
Even if User1 had Outlook installed, Enterprise F3 licenses don’t support full desktop Outlook connectivity to Exchange Online.
This option doesn’t resolve the underlying issue, which is tied to licensing.
C. Assign a different license to User1
This is correct. The Microsoft 365 (or Office 365) Enterprise F3 license does not include rights to connect to Exchange Online using the full Outlook desktop application. It is designed for frontline workers and supports access via:
Outlook on the Web (OWA)
Mobile email apps that use Exchange ActiveSync
It does not allow connection via Outlook for Windows/macOS using MAPI/HTTP or Exchange Web Services.
To enable Outlook desktop access, you need to assign a license that includes Exchange Online Plan 1 or Plan 2, such as:
Microsoft 365 E3 or E5
Office 365 E3 or E5
Microsoft 365 Business Standard or Premium
Once a compatible license is assigned, the user will gain the proper service plans and protocol access, resolving the connectivity issue.
D. Install a valid certificate on User1’s device
This is misleading. Outlook desktop connections to Exchange Online do not require users to install certificates manually. All communication is secured via TLS/SSL using Microsoft’s trusted certificates. If this were a certificate issue, it would likely affect more users, not just one, and not be license-dependent. This is a red herring.
The root cause here is that Enterprise F3 licenses do not permit Outlook desktop connectivity to Exchange Online. The error about "encrypted connection not available" is misleading but ultimately reflects that the Outlook client can’t authenticate or complete Autodiscover due to missing protocol permissions.
To fix this, the most appropriate solution is to upgrade User1 to a license that supports Outlook desktop access, making C the correct answer.
**Therefore, the correct answer is: ** C.
Question 6:
Your organization uses Exchange Online with 1,000 users. You need to prevent only the Finance team (100 users) from using Direct File Access in Outlook on the web (OWA), while leaving the rest of the organization unaffected.
What’s the appropriate administrative action to take?
A. Edit the organization’s default sharing policy.
B. Create a new OWA policy and assign it to the Finance group.
C. Build a dedicated sharing policy for the Finance team.
D. Change the default OWA policy and apply it across all users.
Correct Answer: B
Explanation:
This question involves understanding how to control user behavior in Outlook on the web (OWA), specifically regarding Direct File Access, which allows users to open, preview, or download file attachments directly through the OWA interface. In this scenario, the goal is to restrict access only for the Finance team—not for all users.
To do this effectively, Exchange Online provides administrators with the ability to manage Outlook Web App mailbox policies (also called OWA mailbox policies), which define what features are available in the web version of Outlook for specified users.
Let’s review each answer option and why B is the best:
A. Edit the organization’s default sharing policy
This is incorrect. Sharing policies in Exchange Online govern how users can share calendar information with people outside the organization (e.g., whether users can share free/busy info, full calendar details, etc.). These policies do not apply to file access or OWA behavior. Modifying the sharing policy will not restrict Direct File Access in Outlook on the web.
B. Create a new OWA policy and assign it to the Finance group
This is correct. The proper method to restrict functionality in Outlook on the web for a specific set of users (in this case, the Finance team) is to create a custom OWA mailbox policy. With such a policy, you can configure whether features like Direct File Access, calendar sharing, instant messaging, and others are available when users access their mailboxes through a browser.
To implement this:
Use PowerShell (Exchange Online Management Shell) to create a new OWA policy:
New-OwaMailboxPolicy -Name "FinanceRestrictedPolicy"
Then modify the policy to disable Direct File Access:
Set-OwaMailboxPolicy -Identity "FinanceRestrictedPolicy" -DirectFileAccessOnPublicComputersEnabled $false -DirectFileAccessOnPrivateComputersEnabled $fals
Apply the policy to the Finance team’s mailboxes:
Get-Mailbox -Filter {Department -eq "Finance"} | Set-CASMailbox -OwaMailboxPolicy "FinanceRestrictedPolicy"
This solution targets only the Finance group, satisfying the requirement that other users remain unaffected.
C. Build a dedicated sharing policy for the Finance team
This is incorrect for the same reason as A. Sharing policies only impact calendar sharing and external collaboration, not file access within OWA. Creating a custom sharing policy would be ineffective in limiting Direct File Access.
D. Change the default OWA policy and apply it across all users
This is incorrect because although it would achieve the desired restriction, it would do so for everyone, not just the Finance team. The question explicitly states that the restriction should be limited to 100 users in Finance, while the other 900 users should not be affected. Modifying and applying the default policy would break this requirement by enforcing the limitation globally.
The Outlook Web App mailbox policy (OWA policy) is the tool designed specifically for managing user experience and security features in Outlook on the web. It allows for fine-grained control over features like file access, offline access, and WebReady document viewing. In Exchange Online, administrators can create multiple OWA policies, each tailored to a user group’s needs, and apply them individually.
Therefore, the correct administrative action is to create a new OWA policy, configure it to disable Direct File Access, and assign it to the Finance team only.
The correct answer is B.
Question 7:
You are reviewing DNS settings to ensure proper Outlook client connectivity with Exchange Online. Which two DNS records are essential to validate for this purpose?
A. autodiscover.outlook.com
B. smtp.office365.com
C. outlook.office365.com
D. security.microsoft365.com
E. portal.office.com
Correct Answer: A, C
Explanation:
Outlook connectivity with Exchange Online depends heavily on correct DNS configurations. When users launch Outlook (especially the first time during autodiscover or profile setup), the application queries DNS records to determine where and how to connect to the mailbox hosted in Exchange Online.
There are two critical DNS endpoints Outlook uses for Exchange Online connectivity:
A. autodiscover.outlook.com — Correct
This is essential. The Autodiscover service is the mechanism that Outlook uses to:
Automatically configure user profiles.
Discover mailbox server settings.
Retrieve mailbox URLs and connection settings.
For Exchange Online, the correct CNAME record is:
autodiscover.yourdomain.com CNAME autodiscover.outlook.com
This redirects client requests from your organization’s domain to Microsoft’s Autodiscover endpoint, enabling automatic profile configuration and seamless access to mailboxes. If this record is missing or misconfigured, Outlook setup will fail with errors about being unable to connect or retrieve server settings.
B. smtp.office365.com — Incorrect
While this is the SMTP server hostname used for sending mail, it is not part of the DNS configuration required for Outlook connectivity to Exchange Online. Clients (like Outlook) don’t connect to this endpoint to retrieve mail or perform Autodiscover. It's used more for:
Configuring email relays or SMTP connectors.
Sending mail from multifunction devices or apps.
Thus, it’s relevant for mail flow, not Outlook profile setup or connectivity.
C. outlook.office365.com — Correct
This is the primary endpoint Outlook uses for connecting to Exchange Online after Autodiscover completes. Once Autodiscover provides the correct configuration, the Outlook client connects to:
outlook.office365.com
This endpoint supports MAPI over HTTP, Exchange Web Services (EWS), and other modern Outlook connectivity protocols. It is vital for accessing the mailbox, synchronizing email, calendar, and contacts.
If this endpoint is unreachable (due to DNS issues, firewall restrictions, etc.), Outlook cannot establish or maintain a connection to the mailbox.
D. security.microsoft365.com — Incorrect
This is the URL for the Microsoft 365 Defender portal, used by security admins to manage threat protection and security configurations. It has nothing to do with Outlook connectivity or DNS records required by mail clients.
E. portal.office.com — Incorrect
This is the web portal where users sign in to access Microsoft 365 services like Outlook Web App, Teams, OneDrive, and others. While useful for browser-based access, Outlook desktop does not rely on this endpoint, nor is it a necessary DNS record for client connectivity.
To ensure smooth Outlook client connectivity to Exchange Online, two DNS records are critical:
The Autodiscover CNAME (autodiscover.outlook.com) — Enables Outlook to auto-configure itself with minimal user input.
The Mailbox server endpoint (outlook.office365.com) — Used by the client to connect, sync, and interact with Exchange Online services.
Other endpoints like smtp.office365.com, security.microsoft365.com, or portal.office.com are useful for other functions but not for Outlook desktop client connectivity.
Therefore, the correct answers are: A, C.
Question 8:
In a hybrid Exchange Server 2019 and Exchange Online environment, how can you ensure that all newly created Exchange Online mailboxes are automatically assigned a specific retention policy?
A. Apply the policy using the Set-Mailbox cmdlet during provisioning.
B. Configure a default retention policy in the Exchange Online Admin Center.
C. Assign the policy manually to each user after mailbox creation.
D. Modify the Exchange Hybrid Configuration Wizard to assign the policy.
Correct Answer: B
Explanation:
Retention policies in Exchange Online are a part of Microsoft Purview Data Lifecycle Management (formerly known as MRM – Messaging Records Management). These policies help organizations retain or delete emails based on compliance and operational needs. In a hybrid Exchange deployment, it’s common for organizations to provision mailboxes either on-premises or directly in Exchange Online. When mailboxes are created in Exchange Online, administrators may want to ensure that certain default retention rules (like deleting items after a set period or archiving them) are automatically applied.
Let’s evaluate the options:
A. Apply the policy using the Set-Mailbox cmdlet during provisioning
This is partially correct but not the most effective or automated approach. While it’s true that you can use:
Set-Mailbox -Identity user@domain.com -RetentionPolicy "PolicyName"
to assign a retention policy at the time of mailbox provisioning, this method requires manual intervention or scripting every time a mailbox is created. It lacks scalability and consistency unless you're using automated scripts or provisioning tools. In large environments, relying solely on scripted Set-Mailbox calls is prone to human error or omissions, especially if different administrators are involved.
B. Configure a default retention policy in the Exchange Online Admin Center
This is the correct and most effective approach. Exchange Online allows administrators to define a default retention policy, which is automatically assigned to all new mailboxes unless explicitly overridden.
Steps:
Go to the Microsoft Purview compliance portal or the Exchange Admin Center (EAC) under Exchange Online.
Navigate to compliance management > retention policies.
Identify or create the retention policy you want to use.
Set it as the default policy by using PowerShell:
Set-RetentionPolicy -Identity "YourRetentionPolicy" -IsDefault $true
Once this is done, every newly provisioned mailbox in Exchange Online will automatically be associated with this policy, ensuring consistent compliance behavior without requiring additional steps.
C. Assign the policy manually to each user after mailbox creation
This is technically valid but highly inefficient and error-prone. Manual assignment doesn't scale in enterprise environments and introduces risk if admins forget to apply the policy. It also consumes unnecessary administrative time and effort, which violates the principle of automation and policy-based management.
D. Modify the Exchange Hybrid Configuration Wizard to assign the policy
This is incorrect. The Hybrid Configuration Wizard (HCW) is responsible for establishing and maintaining hybrid mail flow, free/busy sharing, and mailbox move capabilities between on-premises Exchange and Exchange Online. It does not include options to assign or manage retention policies. The HCW does not configure user-specific policies or manage mailbox settings such as retention or archive settings.
The most effective and scalable way to ensure that new Exchange Online mailboxes are automatically assigned a specific retention policy is to designate that policy as the default retention policy in Exchange Online. This ensures compliance consistency and reduces manual workload.
Therefore, the correct answer is B.
Question 9:
An Exchange Online user reports that emails from an important external partner are being delivered to their Junk Email folder. What is the best action to ensure these messages are always delivered to the user's inbox in the future?
A. Add the sender’s domain to the Safe Senders list in the user’s mailbox.
B. Use a transport rule to allow the sender’s email through.
C. Disable junk filtering for the mailbox.
D. Mark the sender as trusted from the Microsoft 365 Defender portal.
Correct Answer: A
Explanation:
The Junk Email folder in Exchange Online is primarily controlled by Microsoft’s anti-spam filters and user-level Safe Senders lists. When a message ends up in the Junk Email folder, it's often due to Microsoft 365’s built-in spam filtering or the user’s individual junk email settings in Outlook or Outlook Web App.
In this scenario, the issue is isolated to one user, and the sender is legitimate. The goal is to ensure that messages from this external partner consistently bypass the Junk Email folder for that specific user—not organization-wide.
Let’s analyze the options:
A. Add the sender’s domain to the Safe Senders list in the user’s mailbox — Correct
This is the most effective and targeted solution for this scenario. Every Exchange Online mailbox maintains a Safe Senders list, which users can manage themselves through Outlook or Outlook Web App (OWA), or which administrators can manage using PowerShell.
When a sender or domain is added to the Safe Senders list:
Their emails bypass the junk filter for that user.
The behavior is user-specific, not global—so it doesn't affect the entire organization.
This method is simple, fast, and reliable.
Admins can manage this using PowerShell. For example, to add a domain to a mailbox’s safe senders list:
Set-MailboxJunkEmailConfiguration -Identity user@domain.com -TrustedSendersAndDomains @{Add="partnerdomain.com"}
This ensures the trusted sender or domain is whitelisted only for that user, preventing future messages from being incorrectly marked as junk.
B. Use a transport rule to allow the sender’s email through — Incorrect in this context
Transport rules (mail flow rules) operate at the organization level and are ideal for broader email flow requirements like:
Adding disclaimers.
Redirecting mail.
Preventing delivery under certain conditions.
While it's technically possible to use a transport rule to bypass spam filtering for a specific sender, doing so organization-wide introduces risk—you might unintentionally allow spoofed messages or open the door to other threats. Also, transport rules don’t directly control Junk Email folder delivery behavior at the user mailbox level.
C. Disable junk filtering for the mailbox — Overly broad and insecure
You can disable junk filtering for a user using:
Set-MailboxJunkEmailConfiguration -Identity user@domain.com -Enabled $false
However, this removes all protection for that mailbox, meaning all potential spam will land in the inbox—including legitimate spam. This is a bad security practice, especially when only a single sender is affected. It’s like turning off your smoke alarm because it triggered once while cooking.
D. Mark the sender as trusted from the Microsoft 365 Defender portal — Not applicable at the user level
The Microsoft 365 Defender portal (formerly Security & Compliance Center) provides organization-wide tools for allow/block lists, threat policies, anti-phishing, and anti-spam settings. While admins can configure tenant-level allow lists or override phishing/spam detections, this approach is too broad for a single-user complaint.
It’s better to start with the least impactful, user-specific solution, which is to update the Safe Senders list. Using tenant-wide allow rules for individual cases can lead to misclassification of actual threats across the entire environment.
When a single Exchange Online user reports that messages from a known, important sender are going to Junk, the best solution is to add the sender or their domain to the user's Safe Senders list. This targets the issue only for that user, maintains organizational security, and prevents future emails from being misrouted.
Therefore, the correct answer is: A.
Question 10:
Your organization uses Microsoft Exchange Server 2019, and the security team needs to audit and report on non-owner mailbox access for compliance purposes. What action should you take to meet this requirement?
A. Enable mailbox audit logging for all mailboxes.
B. Configure journaling for all mail traffic.
C. Use Message Tracking logs to analyze access.
D. Create a transport rule to log access events.
Correct Answer: A
Explanation:
In an on-premises Microsoft Exchange Server 2019 environment, the most effective and supported method to audit non-owner mailbox access (i.e., when someone other than the mailbox owner accesses the mailbox) is by enabling mailbox audit logging. This functionality allows organizations to maintain a detailed record of mailbox activity, which is essential for meeting compliance, legal, and security requirements.
Let’s evaluate each option carefully:
A. Enable mailbox audit logging for all mailboxes — Correct
This is the best and intended solution for tracking non-owner access. Mailbox audit logging in Exchange Server 2019 can record actions performed by:
The mailbox owner.
Delegates (such as assistants with access).
Administrators (who might access mailboxes using elevated privileges).
When enabled, audit logs capture key actions such as:
Message sends and deletions.
Folder access.
Login events and item modifications by non-owners.
To enable audit logging, use PowerShell like so:
Set-Mailbox -Identity "User" -AuditEnabled $true
You can further configure which actions are logged and for which user roles (owner, delegate, admin). Audit log entries are stored in the mailbox and can be retrieved using:
Search-MailboxAuditLog -Identity "User" -LogonTypes Admin, Delegate -ShowDetails
For organization-wide auditing, you may automate enabling audit logging for all existing and future mailboxes using scheduled tasks or management scripts.
This is the industry-standard approach for auditing mailbox access and fulfills the compliance need precisely.
B. Configure journaling for all mail traffic — Incorrect for this use case
Journaling is designed to record copies of messages for archival or legal discovery, not to track who accessed which mailbox or messages. While useful for message retention, it does not provide access logs or information about mailbox interactions by non-owners.
In other words, journaling tells you what was sent or received, but not who accessed what and when, which is the requirement here.
C. Use Message Tracking logs to analyze access — Insufficient and unrelated
Message Tracking logs provide details about email flow, such as:
Who sent or received an email.
Message status (delivered, failed, queued).
Routing details between servers.
However, these logs do not track mailbox access events, especially those by non-owners. You cannot use these logs to detect whether an admin, for example, opened someone else's mailbox or read specific content. They are primarily used for troubleshooting mail flow issues, not for compliance auditing.
D. Create a transport rule to log access events — Not designed for mailbox access auditing
Transport rules (also called mail flow rules) allow administrators to inspect and take actions on messages as they travel through the transport pipeline (e.g., adding disclaimers, blocking sensitive info). They are not capable of detecting or logging mailbox access events.
Even if you tried to log message behaviors using transport rules, they wouldn't capture data about how a message was accessed, by whom, or whether a delegate opened a message on someone else's behalf.
Auditing non-owner mailbox access is a critical compliance feature in Exchange Server 2019. The only appropriate and reliable way to capture this information is through mailbox audit logging. It’s a built-in feature designed exactly for scenarios involving delegates, administrators, or service accounts accessing user mailboxes, ensuring transparency and accountability in mailbox interactions.
Therefore, the correct answer is: A.
