Topic 2: Litware inc
You need to meet the technical requirements for Windows AutoPilot.
Which two settings should you configure from the Azure Active Directory blade? To answer, select the appropriate settings in the answer area.
NOTE: Each correct selection is worth one point.
This question comes from the MD-102: Endpoint Administrator exam topic focusing on Windows Autopilot integration with Azure Active Directory (Entra ID). You are asked which two settings in the Azure AD blade must be configured to meet the technical requirements for Windows Autopilot deployment.
1️⃣ Configure – “Devices” (Required for Autopilot device management)
Under the Devices section of the Azure Active Directory blade, you configure settings that determine how devices join Azure AD and who can perform device joins. This is critical for Windows Autopilot because every Autopilot deployment ends with a device registration or join process — either Azure AD Join or Hybrid Azure AD Join.
Key configuration items under Devices:
Users may join devices to Azure AD → must be set to All or Selected users who will enroll Autopilot devices.
Additional local administrators on Azure AD joined devices → you can specify IT admin groups.
Require Multi-Factor Authentication to join devices → optional, depending on security policy.
Device settings for Windows Autopilot registration (e.g., device owner and MDM enrollment settings).
These configurations ensure that:
Autopilot devices can automatically join Azure AD.
The user signing in during OOBE (Out-Of-Box Experience) can complete enrollment.
Intune automatically manages the device post-deployment.
Hence, “Devices” must be configured to meet Autopilot technical requirements.
Reference:
Azure AD device settings
Set up automatic enrollment in Intune
2️⃣ Configure – “Users” (Required for user assignment and Autopilot profile association)
The Users section allows administrators to manage and configure user identities that will participate in the Autopilot deployment.
In Windows Autopilot:
Each device is assigned to a specific user or group in Intune.
The user account must exist in Azure Active Directory.
Licensing (Microsoft Intune and Azure AD Premium) must be assigned to the user.
From the Users blade, administrators ensure:
The user account has the correct licenses (Microsoft Intune, Azure AD Premium, and Windows 10/11 Enterprise).
The user belongs to the proper group for dynamic Autopilot deployment profiles.
The user has permissions to join devices to Azure AD (as defined in Devices settings).
Thus, configuring Users ensures that the correct end users are linked to Autopilot devices and can complete setup successfully.
Reference:
Assign licenses to users in Microsoft 365
Windows Autopilot user assignments
You need to recommend a solution to meet the device management requirements.
What should you include in the recommendation? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
The core requirement for both departments is to manage corporate data on personal devices without needing to manage the devices themselves. This is the exact purpose of App Protection Policies (APP), formerly known as MAM (Mobile Application Management).
App Protection Policies (APP) work by wrapping corporate data within managed applications (like Outlook, Word, Excel, etc.). This allows IT to enforce security policies—such as requiring a PIN to open the app, preventing data copy/paste to unmanaged apps, and encrypting corporate data—without enrolling the user's personal device into Intune. The management follows the identity and the data, not the device.
This solution meets the requirement perfectly because:
It protects corporate data accessed from the Research and Sales departments.
It does not require device enrollment, respecting the privacy of the employees' personal devices.
Why the Other Options are Incorrect for Both Departments
An app configuration policy:
This is used to pre-configure settings for an app when it is launched (e.g., pre-populating a username or configuring a specific server URL). It does not, by itself, provide the data security and access controls required to "manage corporate data."
Azure Information Protection (AIP):
While AIP is a powerful data protection service for classification and encryption, it is being superseded by the unified labeling client integrated into Microsoft Purview. More importantly, AIP is a data-level protection technology, not a primary device management solution. App Protection Policies can leverage the underlying protection services, but APP is the correct overarching management framework for this scenario.
iOS app provisioning profiles:
These are used to deploy and trust line-of-business (LOB) apps on corporate-owned, Intune-enrolled iOS devices. They are irrelevant for personal devices that are not enrolled, which is the stated scenario for both departments.
Reference:
Microsoft Learn - App protection policies overview:
"App protection policies (APP) are rules that ensure an organization's data remains safe or contained in a managed app... A policy can be a rule that is enforced when the user attempts to access or move 'corporate' data, or a set of actions that are prohibited or monitored when the user is inside the app."
Microsoft Learn - How to deploy app protection policies with Intune:
"Use app protection policies to help protect your organization's data on devices that are not enrolled with Intune."
You need to meet the OOBE requirements for Windows AutoPilot.
Which two settings should you configure from the Azure Active Directory blade? To answer, select the appropriate settings in the answer area.
NOTE: Each correct selection is worth one point.
When configuring Windows Autopilot, particularly its Out-of-Box Experience (OOBE) phase, administrators must ensure that users experience a streamlined sign-in and enrollment process. Two key Azure Active Directory (Azure AD) settings must be configured to achieve this:
Company branding — to customize the user sign-in and OOBE screens.
Mobility (MDM and MAM) — to automatically enroll devices into Microsoft Intune (Mobile Device Management).
These configurations are made directly from the Azure Active Directory blade in the Azure portal.
✅ 1. Company Branding
Purpose:
Company branding in Azure AD customizes the sign-in, enrollment, and OOBE screens with your organization’s logo, background image, and color scheme.
During Windows Autopilot OOBE, users see a personalized sign-in page with the company logo and name instead of the generic Microsoft login. This reassures users they’re connecting to their corporate environment and helps with a smooth onboarding experience.
Configuration Path:
Azure AD → Company branding → Configure sign-in page → Upload logo, background image, and define accent color.
Why It’s Required for OOBE:
Displays your organization’s logo and name during device setup.
Reduces confusion by ensuring users know they’re signing into the correct tenant.
Provides a consistent corporate look and feel across devices.
Without this configuration, the OOBE will show Microsoft’s default branding, which may cause user uncertainty, especially in multi-tenant or multi-domain environments.
Reference:
Microsoft Learn — Configure company branding in Azure Active Directory
Microsoft Learn — Overview of Windows Autopilot
✅ 2. Mobility (MDM and MAM)
Purpose:
The Mobility (MDM and MAM) settings in Azure AD define how devices are managed once they join the directory.
This setting allows automatic MDM enrollment into Microsoft Intune as part of the OOBE process.
In other words, when a user signs into their new device during Autopilot setup, the device is automatically enrolled in Intune without requiring manual steps.
onfiguration Path:
Azure AD → Mobility (MDM and MAM) → Select Microsoft Intune → Configure the following:
MDM user scope → Select Some or All.
MAM user scope → Select if using application-level management (optional).
URL for MDM terms (optional).
Why It’s Required for OOBE:
Enables automatic device enrollment in Intune during the OOBE.
Ensures devices receive configuration policies, compliance rules, and applications immediately after setup.
Integrates Azure AD Join and Intune MDM registration for hybrid and cloud-native management.
Without this configuration, users would need to manually enroll their device in Intune after setup, defeating the purpose of Autopilot’s zero-touch provisioning model.
Reference:
Microsoft Learn — Configure auto-enrollment for Intune
Microsoft Learn — Set up MDM authority
❌ Why the Other Options Are Not Correct
Users / Groups
These sections are used for managing accounts and access but do not affect OOBE behavior. They define who exists in Azure AD, not how Autopilot enrolls or displays the sign-in experience.
Enterprise Applications
Used for managing app access and SSO settings. OOBE customization and enrollment automation are unrelated to application registration.
App registrations / Application proxy
These are for integrating applications and publishing internal apps to external users. They don’t impact OOBE or the device provisioning process.
Roles and administrators
Controls access permissions in Azure AD (e.g., Global Administrator, Intune Administrator). While administrative roles are necessary for configuration, they don’t themselves affect the OOBE experience.
Devices
This node displays registered and joined devices, but it doesn’t allow configuring Autopilot OOBE settings. Devices appear here after OOBE completes.
Azure AD Connect
Used for synchronizing on-premises AD accounts with Azure AD. Although required for hybrid environments, it’s not directly part of OOBE branding or MDM auto-enrollment configuration.
Licenses
Licenses must be assigned (e.g., Intune and Azure AD Premium), but this setting is not used to configure the OOBE process itself.
Password reset / User settings
Control self-service password reset and Azure AD sign-in options — not related to Autopilot’s OOBE automation.
Company branding and Mobility (MDM and MAM) are the only settings that directly influence:
The appearance of the OOBE.
The automatic enrollment into Intune during setup.
You need to resolve the performance issues in the Los Angeles office.
How should you configure the update settings? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
To resolve performance issues in the Los Angeles office, you must optimize Windows Update delivery and prevent disruptions during working hours. The correct configuration achieves both goals:
HTTP blended with peering behind same NAT This mode allows devices on the same network (behind the same NAT) to share update content peer-to-peer while still downloading from Microsoft CDN. It reduces WAN bandwidth usage and improves update performance in branch offices.
Devices download updates from Microsoft and also from peers within the same subnet.
Ideal for offices with limited bandwidth or many devices downloading the same updates.
🔗 Reference:
Delivery Optimization overview
2. Active Hours Start:
10 AM, Active Hours End: 10 PM Active Hours define when devices are in use and should avoid automatic restarts. Setting them from 10 AM to 10 PM ensures updates and reboots do not interrupt users during business hours.
Prevents forced reboots during peak productivity.
Covers standard and extended work hours, especially in developer or support-heavy environments.
🔗 Reference:
Configure Active Hours
❌ Why Other Options Are Incorrect
Delivery Optimization Modes:
Bypass mode:
Disables Delivery Optimization entirely.
Forces all devices to download updates directly from Microsoft, increasing WAN usage.
Not suitable for branch offices with bandwidth constraints.
HTTP blended with internet peering:
Allows peering across the internet, which introduces latency and security concerns.
Less efficient than local NAT-based peering for office environments.
Simple download mode with no peering:
Disables peer-to-peer sharing.
All devices download updates individually, increasing bandwidth consumption.
Active Hours Start/End Options:
Start: 11 AM or 10 PM:
11 AM delays protection from restarts, risking disruption during early work hours.
10 PM is too late to start active hours.
End: 11 AM or 11 PM:
11 AM ends protection too early, allowing reboots during the afternoon.
11 PM may be excessive unless users work late; 10 PM is a safer default.
Summary
To resolve performance issues in a branch office like Los Angeles:
Use HTTP blended with peering behind same NAT to reduce WAN load and enable efficient update distribution.
Set Active Hours from 10 AM to 10 PM to prevent disruptive restarts during working hours.
| Page 2 out of 32 Pages |
| MD-102 Practice Test |
