Visit here for our full Microsoft MD-102 exam dumps and practice test questions.
Question 81:
Your organization uses Microsoft Intune to manage iOS devices. You need to prevent users from using AirDrop to share corporate data from managed applications. What should you configure?
A) App protection policy with “Send org data to other apps” set to “Policy managed apps”
B) Device restrictions profile with AirDrop blocked
C) App configuration policy disabling AirDrop in managed apps
D) Compliance policy requiring AirDrop to be disabled
Answer: A
Explanation:
AirDrop is Apple’s proprietary peer-to-peer file sharing technology that allows iOS and macOS devices to transfer files, photos, links, and other data wirelessly between nearby devices. While AirDrop provides convenient sharing capabilities, it also represents a data leakage vector where corporate data could be transferred to unauthorized personal devices or unmanaged devices outside organizational control. Preventing corporate data from being shared through AirDrop requires application-level data transfer controls rather than device-level AirDrop blocking.
App protection policies provide granular control over data transfer from managed applications through the “Send org data to other apps” setting. This setting determines which destinations can receive corporate data when users attempt to share data from protected applications. When set to “Policy managed apps,” the setting restricts data sharing to only other applications that are also protected by Intune app protection policies, effectively creating a protective boundary around corporate data.
AirDrop integrates with iOS’s share sheet interface, appearing as a sharing option alongside options like Messages, Mail, and application-specific sharing destinations. When app protection policies restrict data sending to policy-managed apps, Intune-protected applications filter the share sheet to exclude sharing methods that would transfer data outside the protected app ecosystem. AirDrop, which transfers data to devices and applications outside organizational management, is blocked when users attempt to share corporate data from protected applications.
From a technical perspective, Intune-protected applications integrate with the Intune App SDK, which intercepts sharing operations and evaluates them against data transfer policies. When users tap the share button in managed applications like Outlook, OneDrive, or custom line-of-business apps, the SDK evaluates available sharing destinations against policy. Destinations that would transfer data to unmanaged contexts, including AirDrop to arbitrary devices, are removed from the share sheet or disabled to prevent selection.
This application-level control is more appropriate than device-level AirDrop blocking for several reasons. It allows granular control where corporate data is protected while personal data remains shareable through AirDrop, respecting user privacy on BYOD devices. It works on both enrolled and unenrolled devices since app protection policies function without device enrollment. It targets the specific security concern (corporate data leakage) without unnecessarily restricting device functionality for personal use.
Device-level AirDrop blocking through device restrictions profiles would prevent all AirDrop usage on the device, including for personal photos, documents, and data. On personally owned devices in BYOD scenarios, such broad restrictions are typically unacceptable to users and inappropriate given that the organization doesn’t own the device. Application-level controls through app protection policies provide proportional security that protects corporate interests without overreaching into personal device usage.
The “Send org data to other apps” setting controls all data transfer mechanisms, not just AirDrop. It also restricts sharing through Messages, Mail (to personal accounts), third-party sharing services, and any other iOS sharing extensions that would transfer data outside managed applications. This comprehensive coverage ensures corporate data protection across all potential sharing vectors rather than addressing only specific mechanisms like AirDrop.
Organizations can configure complementary settings within app protection policies to create layered data protection including “Receive data from other apps” to control inbound data transfer, “Restrict cut, copy, and paste” to limit clipboard operations, “Block screen capture” to prevent screenshots of corporate data, and encryption settings to protect data at rest within managed applications. Together, these controls create comprehensive mobile application data protection.
For scenarios requiring more restrictive controls on fully managed corporate-owned devices, device restrictions profiles could be used to block AirDrop entirely at the device level. This approach is appropriate when devices are exclusively for business use and users have no expectation of personal functionality. The device-level restriction ensures AirDrop cannot be used regardless of which application attempts sharing, providing absolute prevention at the cost of any legitimate AirDrop usage.
The effectiveness of application-level AirDrop blocking depends on applications properly integrating with Intune App SDK and respecting app protection policies. Microsoft applications like Office mobile apps have full integration. Custom line-of-business applications must integrate the SDK during development or be wrapped with the Intune App Wrapping Tool. Applications without SDK integration cannot be protected by app protection policies and would not block AirDrop sharing, highlighting the importance of ensuring all applications handling corporate data are properly integrated.
A is correct because app protection policies with “Send org data to other apps” set to “Policy managed apps” restricts data sharing mechanisms including AirDrop while allowing personal data to remain shareable, providing appropriate protection for BYOD scenarios. B is incorrect because device restrictions blocking AirDrop prevents all AirDrop usage including personal data sharing, which is overly restrictive for BYOD devices and doesn’t provide application-specific protection. C is incorrect because app configuration policies configure application settings and behaviors but don’t provide security controls like data transfer restrictions—app protection policies provide these controls. D is incorrect because compliance policies check device state but don’t actively prevent functionality like AirDrop sharing—they evaluate compliance rather than enforce data transfer restrictions.
Question 82:
You manage Windows 11 devices using Microsoft Intune. You need to configure devices to automatically connect to a VPN when users access specific internal websites. What VPN feature should you configure?
A) App-triggered VPN with website URLs configured as triggers
B) Always-on VPN with trusted network detection
C) VPN profile with automatic connection script
D) Per-app VPN with browser application specified
Answer: A
Explanation:
Modern VPN capabilities have evolved beyond manual user-initiated connections to include intelligent context-aware triggers that automatically establish VPN connections based on user activity. App-triggered VPN extends the per-app VPN concept to include website-based triggers where accessing specific URLs automatically initiates VPN connections, ensuring users seamlessly access internal resources without manual VPN connection management.
App-triggered VPN is a Windows capability that associates VPN connections with specific applications and optionally specific network destinations like internal website URLs or IP address ranges. When configured with website triggers, the VPN automatically connects when users navigate to specified internal URLs in web browsers, routes traffic for those destinations through the VPN tunnel, and can optionally disconnect when users leave those sites or after inactivity periods.
The VPN profile configuration includes settings that control trigger behavior including which applications can trigger automatic connection, which domain suffixes or URLs cause triggering, whether the VPN remains connected after triggered access ends or disconnects automatically, timeout periods for automatic disconnection, and whether users can see VPN connection status or control connections manually. These settings allow organizations to balance automation with user visibility and control.
App-triggered VPN works best with modern VPN protocols like IKEv2 that establish connections quickly, minimizing delay between when users request internal resources and when those resources become accessible. Slow VPN connection establishment can create noticeable delays in website loading, potentially frustrating users. Organizations should test VPN connection performance and tune configurations to minimize connection time.
Split tunneling configuration is important for app-triggered VPN deployments. Split tunneling allows traffic destined for the internet to bypass the VPN while routing only internal traffic through the tunnel. This approach provides optimal performance by avoiding unnecessary VPN routing for resources that don’t require it while ensuring internal resources always traverse the secure tunnel. The VPN profile can specify which IP ranges or domain suffixes should route through the VPN versus directly to the internet.
Always-on VPN represents a different approach where VPN connections establish automatically at system startup or user login and maintain constant connectivity. While always-on VPN ensures consistent secure connectivity, it routes all network traffic through VPN infrastructure (unless split tunneling is configured) and may impact performance for internet resources. Always-on VPN is more appropriate for scenarios requiring continuous secure connectivity regardless of which resources users access.
Per-app VPN focuses on associating specific applications with VPN connections, ensuring those applications always use VPN regardless of destination. This differs from app-triggered VPN with URL triggers, which connects VPN based on network destinations rather than just application usage. App-triggered VPN with URL triggers provides more granular control by connecting VPN only when accessing specific internal resources rather than for all traffic from specified applications.
Question 83:
Your organization uses Microsoft Intune to manage Android Enterprise devices. You need to configure a policy that allows only specific applications to run on dedicated kiosk devices. What enrollment type and configuration should you use?
A) Android Enterprise dedicated devices with multi-app kiosk mode configured
B) Android Enterprise fully managed with device restrictions allowing only specific apps
C) Android Enterprise work profile with app allowlist
D) Android device administrator with kiosk mode enabled
Answer: A
Explanation:
Dedicated device scenarios require specialized configuration approaches that lock devices to specific applications or functions, preventing users from accessing device settings, installing applications, or using functionality beyond the defined business purpose. Android Enterprise provides dedicated devices enrollment specifically designed for single-purpose devices like point-of-sale terminals, digital signage, inventory scanners, or time clocks.
Android Enterprise dedicated devices enrollment, formerly called Corporate-Owned Single Use (COSU), is designed for devices that serve specific business functions rather than serving as general-purpose devices for individual users. These devices typically don’t have a primary user assigned, may be shared among multiple employees, and need to be locked down to prevent misuse or access to unauthorized functionality. The enrollment type provides extensive management capabilities specifically for these scenarios.
A is correct because Android Enterprise dedicated devices enrollment with multi-app kiosk mode configuration provides the specialized kiosk functionality for allowing only specific applications on shared-use devices. B is incorrect because fully managed enrollment is for individual user devices rather than shared kiosk devices, and device restrictions don’t provide the comprehensive kiosk mode capabilities of dedicated devices. C is incorrect because work profile enrollment is for personal devices with work/personal separation and is inappropriate for shared kiosk devices. D is incorrect because Android device administrator is deprecated and lacks modern Android Enterprise capabilities including proper dedicated device support.
Question 84:
You are configuring Microsoft Intune to deploy certificates to iOS devices. You need to ensure that if users unenroll their devices from management, the certificates are automatically removed. What certificate deployment method ensures this behavior?
A) SCEP or PKCS certificate profiles deployed through MDM
B) Manual certificate installation through email
C) Certificate deployment through Safari web enrollment
D) User-installed certificates from a certificate authority website
Answer: A
Explanation:
Certificate lifecycle management is an important aspect of enterprise mobility management that ensures cryptographic credentials used for authentication and encryption are properly distributed during enrollment and properly removed when devices leave management. Understanding how different certificate deployment methods handle certificate lifecycle, particularly during unenrollment, ensures security credentials don’t persist on devices after management relationships end.
Mobile Device Management frameworks, including Apple’s MDM protocol used by Intune for iOS device management, provide mechanisms for deploying and managing various types of configuration including certificates. Certificates deployed through MDM profiles are managed payloads that are intrinsically linked to the MDM enrollment state. When devices are enrolled in MDM, they can receive certificate profiles that install certificates into the device’s certificate store. When devices are unenrolled from MDM, either through user-initiated unenrollment or IT-initiated remote management removal, iOS automatically removes all MDM-deployed profiles and their associated payloads including certificates.
SCEP (Simple Certificate Enrollment Protocol) and PKCS (Public Key Cryptography Standards) certificate profiles in Intune are MDM-based certificate deployment methods. SCEP profiles enable devices to request certificates from certificate authorities supporting the SCEP protocol, receiving certificates through automated enrollment. PKCS profiles deliver pre-issued certificates or integrate with certificate authorities through connectors to issue and deploy certificates. Both methods deploy certificates as MDM payloads that iOS recognizes as management-deployed configuration.
A is correct because SCEP and PKCS certificate profiles deployed through MDM are managed payloads that iOS automatically removes during device unenrollment, ensuring certificates don’t persist after management ends. B is incorrect because manual certificate installation through email installs certificates outside the MDM framework as user-installed certificates that persist after unenrollment. C is incorrect because Safari web enrollment installs certificates as user actions outside MDM profile management, causing them to persist after unenrollment. D is incorrect because user-installed certificates from certificate authority websites are not MDM-managed payloads and persist on devices after MDM unenrollment.
Question 85:
You manage Windows 11 devices using Microsoft Intune. You need to configure a policy that prevents users from copying files larger than 50MB to removable drives. What should you configure?
A) Attack surface reduction rule for removable storage with file size restrictions
B) Device configuration profile with custom OMA-URI for removable storage file size limits
C) BitLocker policy for removable drives with size-based encryption requirements
D) This specific requirement cannot be directly configured through Intune policies
Answer: D
Explanation:
Understanding the capabilities and limitations of management platforms is essential for setting appropriate expectations and identifying scenarios where policies can directly address requirements versus scenarios requiring alternative approaches. While Intune provides extensive device management capabilities, certain specific granular controls may not be available as direct policy settings, requiring administrators to evaluate workarounds or accept limitations.
Device management policies in Intune, including device configuration profiles, endpoint security policies, and compliance policies, are built on underlying Windows management technologies like Configuration Service Providers (CSPs), Group Policy equivalents, and MDM protocol standards. The available policy settings in Intune correspond to the configuration capabilities exposed by these underlying technologies. If a specific control doesn’t exist in the Windows management framework, Intune cannot directly expose it as a policy setting.
File size-based restrictions for removable storage operations represent a granular control that is not natively available in Windows management frameworks or Intune policies. While Intune can completely block removable storage devices, require encryption of removable drives through BitLocker To Go, and restrict device installation based on device classes or hardware IDs, it cannot enforce file size limits on individual copy operations to removable drives. This granularity exceeds the capabilities of standard Windows management policies.
D is correct because file size-based restrictions for copying files to removable drives are not available as direct configuration settings in Windows management frameworks or Intune policies, making this specific requirement not directly achievable through Intune alone. A is incorrect because attack surface reduction rules focus on malware protection and don’t include file size restrictions for removable storage copy operations. B is incorrect because while custom OMA-URI provides access to Windows CSP settings, the underlying Windows CSPs don’t include file size-based copy restrictions for removable storage. C is incorrect because BitLocker policies for removable drives control encryption requirements but don’t impose restrictions on file sizes that can be copied to removable drives.
Question 86:
Your organization uses Microsoft Intune to manage devices. You need to create a dynamic device group that includes all Windows devices that are compliant. What membership rule should you use?
A) (device.deviceOSType -eq “Windows”) -and (device.isCompliant -eq true)
B) (device.operatingSystem -eq “Windows”) -and (device.complianceState -eq “Compliant”)
C) (device.platform -eq “Windows”) -and (device.trustType -eq “Compliant”)
D) Dynamic device groups cannot filter based on compliance status
Answer: A
Explanation:
Dynamic groups in Azure AD use membership rules based on device or user attributes to automatically maintain group membership. Understanding the correct attribute names and values available for dynamic membership rules is essential for creating groups that accurately capture intended members. Compliance status is one of the device attributes that can be used in dynamic group rules, enabling automatic grouping of compliant versus non-compliant devices.
Device attributes available for dynamic group rules include properties like device operating system type, device name, enrollment type, management type, manufacturer, model, ownership type, and importantly, compliance status. These attributes are populated by various services including Intune, Azure AD device registration, and device enrollment processes. The compliance status attribute specifically reflects whether Intune has evaluated the device as meeting all configured compliance policy requirements.
The correct syntax for creating a dynamic device group containing Windows devices that are compliant uses the device.deviceOSType attribute to filter for Windows devices and the device.isCompliant attribute to filter for compliant status. The deviceOSType attribute contains values like “Windows,” “iOS,” “Android,” or “macOS” identifying the device’s operating system platform. The isCompliant attribute is a boolean that is true when devices are compliant with all assigned compliance policies and false when devices are non-compliant or not evaluated.
A is correct because (device.deviceOSType -eq “Windows”) -and (device.isCompliant -eq true) uses the correct Azure AD device attributes for operating system type and compliance status to create a dynamic group of compliant Windows devices. B is incorrect because while the logic is correct, the attribute names “operatingSystem” and “complianceState” are not the correct attribute names in Azure AD’s device schema—the correct names are deviceOSType and isCompliant. C is incorrect because “platform” and “trustType” are not the correct attribute names for operating system type and compliance status in Azure AD device attributes. D is incorrect because dynamic device groups can absolutely filter based on compliance status using the device.isCompliant attribute.
Question 87:
You are deploying a Win32 application through Microsoft Intune that requires administrator privileges during installation. The application installer is an MSI file. What installation command should you use?
A) msiexec /i “AppName.msi” /quiet
B) msiexec /i “AppName.msi” /passive /norestart
C) msiexec /i “AppName.msi” /qn /norestart
D) start /wait msiexec /i “AppName.msi” /s
Answer: C
Explanation:
MSI (Microsoft Installer) package deployment requires understanding msiexec command-line parameters that control installation behavior including user interface display, restart handling, logging, and installation context. Selecting appropriate command-line parameters ensures installations execute silently without user interaction, handle restarts appropriately for automated deployment scenarios, and complete reliably in unattended contexts.
C is correct because msiexec /i “AppName.msi” /qn /norestart provides silent installation without user interface and suppresses automatic restarts, which is appropriate for automated deployment through Intune. A is incorrect because while /quiet provides silent installation, omitting /norestart allows automatic restarts which could disrupt users without warning. B is incorrect because /passive displays
Question 88:
Your organization uses Microsoft Intune to manage iOS devices with Apple Business Manager integration. You need to configure devices so that specific built-in Apple apps cannot be removed by users. What should you configure?
A) Device restrictions profile with removal of built-in apps blocked
B) Home screen layout profile specifying apps that must remain
C) App configuration policy preventing app removal
D) Supervised device restrictions preventing app deletion
Answer: A
Explanation:
iOS management provides extensive control over built-in Apple applications including whether users can remove them from devices. Starting with iOS 10, Apple allowed users to remove many built-in apps like Calculator, Calendar, Contacts, Mail, Maps, and others from the home screen, though the apps aren’t fully uninstalled and can be reinstalled from the App Store. For enterprise deployments, organizations may need to prevent removal of specific built-in apps that are essential for business operations or compliance requirements.
Device restrictions profiles for iOS include comprehensive settings organized by category that control various device features and capabilities. Within the Built-in Apps category or similar section depending on interface version, you’ll find settings specifically controlling the removal of built-in Apple applications. These settings allow administrators to prevent users from removing specific categories or individual built-in apps from their devices.
When the restriction preventing removal of built-in apps is enabled and deployed to supervised iOS devices, the operating system enforces the restriction by removing the ability to delete those applications. When users long-press app icons to enter edit mode, the X button that normally appears to allow app deletion is absent for restricted built-in apps, preventing removal. This ensures essential applications remain accessible throughout the device lifecycle.
The restriction applies specifically to built-in Apple applications rather than third-party apps or enterprise apps deployed through MDM. Built-in apps are those that come pre-installed with iOS including productivity apps like Mail, Calendar, and Notes, utility apps like Calculator and Clock, communication apps like FaceTime and Messages, and media apps like Music and Podcasts. Third-party and enterprise app removal is controlled through different mechanisms.
A is correct because device restrictions profiles include specific settings to block removal of built-in Apple apps on supervised iOS devices, providing direct control over app deletion. B is incorrect because home screen layout profiles organize app placement and icon arrangement but don’t prevent users from removing apps—they focus on organization rather than restriction. C is incorrect because app configuration policies configure application settings and behavior but don’t provide device-level restrictions preventing app removal. D is incorrect because while supervision is required for many restrictions, “supervised device restrictions” isn’t a separate policy type—the restrictions are configured within device restrictions profiles and supervision is a prerequisite state for enforcement.
Question 89:
You manage Windows 11 devices using Microsoft Intune. You need to deploy a line-of-business application that should only install on devices with at least 20GB of free disk space. What should you configure in the Win32 app?
A) Requirements with disk space minimum set to 20GB
B) Detection rules checking for available disk space
C) Installation command with disk space validation script
D) Dependencies requiring a disk space checking application
Answer: A
Explanation:
Win32 application deployment in Intune includes requirement rules that define the conditions devices must meet before Intune attempts application installation. Understanding how to properly configure requirements ensures applications only install on devices that can support them, preventing installation failures due to insufficient resources and providing clear feedback about why installations are blocked on devices not meeting requirements.
Requirements in Win32 app configuration specify criteria that target devices must satisfy for the application to be applicable. These requirements are evaluated before installation attempts and prevent installation on devices not meeting the criteria. Common requirement types include operating system version requirements, device architecture requirements (32-bit vs 64-bit), disk space requirements, memory requirements, and processor requirements. These requirements protect against installation attempts that would fail due to inadequate device resources.
The disk space requirement specifically allows administrators to specify a minimum amount of free disk space that must be available on the system drive before installation proceeds. This requirement is particularly important for large applications or applications that create substantial data during operation. Setting a disk space requirement of 20GB ensures devices have adequate free space before attempting installation, preventing failures mid-installation due to insufficient disk space.
When Intune evaluates a device for Win32 app applicability, it checks all configured requirements before attempting installation. If a device doesn’t meet the disk space requirement, Intune marks the application as “Not Applicable” for that device and doesn’t attempt installation. This prevents installation failures and reduces support burden by clearly indicating why the application isn’t installing. Users or IT can take appropriate action like freeing disk space, after which the application automatically becomes applicable during the next policy evaluation.
A is correct because Win32 app requirements include disk space minimums that Intune evaluates before attempting installation, preventing installation on devices with insufficient free space. B is incorrect because detection rules identify whether applications are installed rather than checking device capabilities like disk space—requirements are the proper mechanism for disk space checking. C is incorrect because while installation commands could include disk space validation, this is unnecessarily complex compared to using built-in requirement capabilities and provides less clear reporting. D is incorrect because dependencies specify prerequisite applications that must be installed first, not device capability checks like disk space availability.
Question 90:
Your organization uses Microsoft Intune to manage macOS devices. You need to configure FileVault recovery keys to be escrowed to Intune so they can be retrieved if users forget their passwords. What should you configure?
A) Endpoint protection profile with FileVault enabled and “Escrow location description of personal recovery key” set to Intune
B) Device restrictions profile with recovery key backup settings
C) Compliance policy requiring recovery key backup to Intune
D) Custom configuration profile with FileVault escrow plist
Answer: A
Explanation:
FileVault full disk encryption for macOS provides strong data protection but requires recovery mechanisms for scenarios where users forget their passwords or authentication fails. Recovery key escrow ensures that when legitimate users are locked out of encrypted devices, IT can retrieve recovery keys from centralized storage to unlock devices and restore access. Understanding how to properly configure FileVault with recovery key escrow through Intune ensures business continuity while maintaining data protection.
Endpoint protection profiles in Intune for macOS include dedicated FileVault configuration sections that provide comprehensive encryption management. Within the FileVault settings, administrators can enable encryption, configure authentication methods, specify recovery key escrow locations, control whether users can defer encryption, and determine whether personal recovery keys are shown to users or only escrowed to the management system.
The recovery key escrow configuration is critical for enterprise FileVault deployments. When “Escrow location description of personal recovery key” is set to Intune or a similar setting indicating that recovery keys should be stored in the management system, macOS encrypts the FileVault recovery key and transmits it to Intune during the encryption process. Intune stores the encrypted recovery key associated with the specific device, making it retrievable by authorized administrators through the Intune admin center.
A is correct because endpoint protection profiles with FileVault configuration include recovery key escrow settings that specify Intune as the escrow location, enabling centralized recovery key storage and retrieval. B is incorrect because device restrictions profiles focus on feature enablement and restrictions rather than encryption configuration with recovery key escrow—endpoint protection profiles are the proper location. C is incorrect because compliance policies evaluate whether encryption is enabled but don’t configure encryption or handle recovery key escrow—they check state rather than configure settings. D is incorrect because while custom configuration profiles could configure FileVault, the endpoint protection profile provides a purpose-built interface for FileVault management including key escrow without requiring manual plist creation.
Question 91:
You are configuring Microsoft Intune app protection policies for Android devices. You need to ensure that users can only paste data into managed apps if the data was copied from other managed apps. What should you configure?
A) Data transfer settings: “Receive data from other apps” set to “Policy managed apps”
B) Data transfer settings: “Restrict cut, copy, and paste between other apps” set to “Policy managed apps”
C) Access requirements: “Require managed clipboard”
D) Data encryption: “Encrypt clipboard data”
Answer: B
Explanation:
Clipboard operations represent a significant data transfer mechanism on mobile devices where users frequently copy data from one application and paste it into another. App protection policies provide granular control over clipboard operations to prevent corporate data leakage while maintaining productivity. Understanding the specific settings that control clipboard behavior ensures appropriate data protection without unnecessarily restricting legitimate workflows.
The “Restrict cut, copy, and paste between other apps” setting specifically controls clipboard operations including both copying data out of managed apps and pasting data into managed apps. This setting offers multiple options that provide different levels of restriction: “Blocked” prevents all clipboard operations between managed and unmanaged apps, “Policy managed apps” allows clipboard operations only between policy-managed apps, “Policy managed apps with paste in” allows copying from managed apps with formatting restrictions when pasting into unmanaged apps, and “Any app” allows unrestricted clipboard operations.
When set to “Policy managed apps,” this setting creates bidirectional clipboard restrictions where data can only be copied and pasted between applications that are both protected by app protection policies. If users copy data from a managed app like Outlook and attempt to paste into an unmanaged personal app, the paste operation is blocked. Similarly, if users copy data from an unmanaged app and attempt to paste into a managed app, the paste operation is blocked. This creates a protective boundary around corporate data that prevents data movement outside the managed app ecosystem.
The bidirectional nature of “Policy managed apps” setting addresses both the outbound data leakage concern (preventing corporate data from being pasted into unmanaged apps) and the inbound data concern (preventing potentially malicious or inappropriate data from being pasted into corporate apps). While the question specifically asks about preventing pasting into managed apps from unmanaged sources, the “Policy managed apps” setting provides comprehensive clipboard protection in both directions.
B is correct because “Restrict cut, copy, and paste between other apps” set to “Policy managed apps” specifically controls clipboard operations to allow pasting only when data originates from policy-managed apps, preventing paste from unmanaged sources. A is incorrect because “Receive data from other apps” controls broader application-to-application data transfer mechanisms beyond clipboard operations and doesn’t specifically control paste behavior. C is incorrect because “Require managed clipboard” is not a standard access requirement setting in app protection policies—access requirements control application access conditions rather than clipboard operations. D is incorrect because clipboard encryption encrypts clipboard data but doesn’t prevent pasting from unmanaged sources—it protects data through encryption rather than blocking operations.
Question 92:
Your organization uses Windows Autopilot for device deployment. A user reports that their device failed during Autopilot deployment with an error during the device setup phase. What is the most likely cause?
A) Required device-targeted applications failed to install
B) User’s Azure AD account is disabled
C) Device doesn’t meet hardware requirements for Windows 11
D) Network connectivity was lost during deployment
Answer: A
Explanation:
Windows Autopilot deployment progresses through distinct phases tracked by the Enrollment Status Page: Device preparation, Device setup, and Account setup. Understanding which activities occur in each phase and what types of failures typically manifest in each phase is essential for efficient troubleshooting. The device setup phase specifically handles device-level configurations and application installations targeted at device groups rather than users.
Device setup phase activities include applying device-targeted configuration policies such as device restrictions, endpoint protection settings, and security baselines, installing applications assigned as required to device groups, joining the device to Azure AD, enrolling the device in Intune, and configuring device-level settings like device naming and regional settings. These activities prepare the device itself with corporate configurations before any user-specific settings are applied.
Required applications assigned to device groups are among the most common sources of device setup phase failures. Applications may fail to install due to various reasons including installation package corruption, incorrect installation commands, detection rules that don’t properly identify successful installation, missing dependencies, insufficient disk space, application conflicts with existing software, or network issues during content download. When required applications fail during device setup and the Enrollment Status Page is configured to block on application failures, the device setup phase fails and deployment halts.
The Enrollment Status Page configuration determines whether application failures cause deployment to halt or allow proceeding despite failures. If ESP is configured to block on app failures and track all required apps, any application installation failure causes the device setup phase to fail. Users see error messages indicating which application failed, though detailed troubleshooting requires reviewing device logs. If ESP allows proceeding despite app failures, device setup may complete successfully even when applications fail, though those applications won’t be available on the device.
A is correct because required device-targeted application installation failures are the most common cause of device setup phase failures during Windows Autopilot deployment, particularly when ESP is configured to block on application failures. B is incorrect because user account status affects the account setup phase where user-specific configurations apply, not the device setup phase which occurs before user context processing. C is incorrect because hardware requirement validation occurs during Windows installation before Autopilot begins—by the time device setup phase is reached, Windows is already installed indicating hardware requirements were met. D is incorrect because while network connectivity issues can cause deployment failures, they typically don’t manifest specifically as device setup phase failures with clear error messages about that phase—they more commonly cause timeout errors or connectivity-specific error codes.
Question 93:
You manage iOS devices using Microsoft Intune with Apple Business Manager. You need to configure devices to automatically install available updates during a maintenance window between 10 PM and 6 AM. What should you configure?
A) Device configuration profile with Software Update policy settings specifying the installation time window
B) Compliance policy requiring latest iOS version with time-based enforcement
C) App configuration policy with update schedule for iOS
D) Device restrictions profile with automatic update settings
Answer: A
Explanation:
iOS update management through MDM provides organizations with control over how and when devices receive operating system updates from Apple. Understanding the capabilities and limitations of iOS update policies helps organizations maintain security currency while minimizing disruption to users. Managed update policies can defer updates, schedule installation windows, and ensure devices remain current without requiring user intervention.
Device configuration profiles for iOS include Software Update policy settings (also called iOS/iPadOS update policies depending on interface version) that provide comprehensive control over update behavior. These policies allow administrators to specify update deferral periods delaying when updates become visible to users, scheduled installation windows defining time periods when automatic installation can occur, and enforcement settings determining whether updates install automatically or require user initiation.
The scheduled installation window setting specifically addresses the scenario described where updates should install during defined maintenance windows like overnight hours when devices are likely connected to power and users aren’t actively working. When configured with a window from 10 PM to 6 AM, iOS monitors for pending updates and automatically installs them during the specified time window when devices are plugged into power and connected to Wi-Fi.
The automatic installation behavior ensures updates install without requiring user action, which is important for maintaining fleet-wide security currency particularly when users might defer or ignore update notifications. By restricting installation to maintenance windows, organizations prevent update installations during business hours when unexpected device restarts could disrupt work or when users are actively using devices for time-sensitive tasks.
iOS update policies respect device conditions before initiating automatic installation including requiring Wi-Fi connectivity to avoid consuming cellular data for large update downloads, requiring device charging to ensure sufficient battery for installation and prevent devices from running out of power mid-update, and respecting the configured time window to ensure installation occurs during intended maintenance periods. These conditions ensure updates install under appropriate circumstances without negatively impacting users.
A is correct because device configuration profiles with Software Update policy settings provide the specific capability to schedule iOS update installations during defined time windows like overnight maintenance periods. B is incorrect because compliance policies check device state and enforce compliance requirements but don’t schedule when updates install—they evaluate whether devices are updated, not configure update installation timing. C is incorrect because app configuration policies configure application settings rather than system-level update behavior like iOS update scheduling. D is incorrect because device restrictions profiles control feature availability and prevent user actions but don’t provide the update scheduling capabilities needed for defining maintenance window installations—software update policies handle scheduling.
Question 94:
Your organization uses Microsoft Intune to manage devices. You need to deploy a Wi-Fi profile that uses PEAP authentication with MS-CHAPv2 for inner authentication method. What authentication method should you specify in the Wi-Fi profile?
A) EAP-PEAP with MS-CHAPv2 as the inner method
B) EAP-TLS with password authentication
C) LEAP with PEAP tunneling
D) EAP-TTLS with PAP
Answer: A
Explanation:
Enterprise Wi-Fi networks typically use WPA2-Enterprise or WPA3-Enterprise security with 802.1X authentication, which supports various Extensible Authentication Protocol methods for secure network authentication. Understanding the differences between EAP types and their inner authentication methods is essential for properly configuring Wi-Fi profiles that match infrastructure requirements and provide appropriate security levels.
PEAP (Protected Extensible Authentication Protocol) is an EAP method that creates an encrypted TLS tunnel between the client and RADIUS server, within which inner authentication occurs using simpler protocols. PEAP protects the inner authentication exchange from eavesdropping, allowing use of password-based authentication methods that would be insecure if transmitted in clear text. PEAP consists of two phases: the outer authentication establishing the TLS tunnel using server certificate validation, and the inner authentication occurring within the tunnel using various methods.
MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) is a password-based authentication protocol that can function as the inner authentication method within PEAP tunnels. When PEAP-MS-CHAPv2 is configured, users authenticate using username and password credentials. The PEAP tunnel protects these credentials from interception while they’re transmitted to the RADIUS server for validation against Active Directory or Azure AD credentials.
To configure Wi-Fi profiles for PEAP authentication with MS-CHAPv2 in Intune, you create a Wi-Fi profile specifying WPA2-Enterprise or WPA3-Enterprise as the security type, EAP as the authentication method, and PEAP as the specific EAP type. Within PEAP configuration, you specify MS-CHAPv2 as the inner authentication method or select PEAP-MS-CHAPv2 depending on interface organization. Additional settings include server certificate validation to ensure clients only connect to legitimate RADIUS servers and root certificate trust for validating server certificates.
A is correct because EAP-PEAP with MS-CHAPv2 as the inner authentication method is the proper configuration for PEAP authentication using MS-CHAPv2 inner method as specified in the requirement. B is incorrect because EAP-TLS uses certificate-based authentication rather than password-based authentication and doesn’t use MS-CHAPv2—certificates perform authentication without inner authentication methods. C is incorrect because LEAP is a deprecated proprietary protocol with security vulnerabilities and is not the same as PEAP—LEAP doesn’t use PEAP tunneling. D is incorrect because while EAP-TTLS can use various inner methods, the question specifically requires PEAP authentication rather than TTLS, and PAP is less secure than MS-CHAPv2 for inner authentication.
Question 95:
You manage Android Enterprise devices using Microsoft Intune. You need to configure a policy that prevents users from enabling USB debugging mode. What should you configure?
A) Device restrictions profile with USB debugging blocked
B) Compliance policy requiring USB debugging to be disabled
C) Device configuration profile with developer options disabled
D) Security policy preventing developer mode access
Answer: A
Explanation:
USB debugging is an Android developer feature that enables advanced device access through ADB (Android Debug Bridge) connections, allowing developers to execute commands, install applications outside normal channels, access device logs, and perform low-level device modifications. While essential for application development and testing, USB debugging poses security risks in production enterprise environments by enabling potential attack vectors, data exfiltration, and bypass of security controls.
Device restrictions profiles for Android Enterprise provide comprehensive control over device features and capabilities that can be enabled or disabled on managed devices. Within the device restrictions settings, you’ll find numerous controls organized by category including general device settings, password requirements, system features, application controls, and importantly, settings related to developer options and USB debugging.
The USB debugging restriction specifically prevents users from enabling USB debugging in Android’s developer options. When this restriction is enabled and deployed to Android Enterprise devices through Intune, the operating system enforces the restriction by making the USB debugging toggle unavailable or hidden in developer options. Even if users enable developer options (which requires tapping the build number repeatedly in About Phone), the USB debugging option is either absent or disabled with an indication that it’s restricted by device policy.
This restriction is particularly important for corporate-owned devices because USB debugging significantly reduces device security. With USB debugging enabled, anyone with physical access to unlocked devices or appropriate credentials could connect via ADB and potentially extract data, install unauthorized applications, modify system settings, or bypass security controls. Preventing USB debugging maintains the device security posture required for corporate data protection.
A is correct because device restrictions profiles include specific settings to block USB debugging, preventing users from enabling this developer feature on managed Android Enterprise devices. B is incorrect because compliance policies check whether USB debugging is enabled and report compliance status but don’t actively prevent users from enabling the feature—they evaluate state rather than enforce restrictions. C is incorrect because while developer options can be disabled entirely, the question specifically asks about preventing USB debugging, and the device restrictions profile’s USB debugging setting is the specific control for this feature. D is incorrect because “security policy” is not a distinct policy type in Intune for Android Enterprise—USB debugging restrictions are configured within device restrictions profiles rather than a separate security policy category.
Question 96:
Your organization uses Microsoft Intune and Conditional Access. You need to configure a policy that requires MFA for all users when accessing Azure portal but allows access from compliant devices without MFA. What should you configure?
A) Conditional Access policy targeting Azure portal with MFA required, excluding compliant devices through grant controls
B) Two separate Conditional Access policies: one requiring MFA for all access, one excluding compliant devices
C) Compliance policy requiring MFA with Azure portal exception for compliant devices
D) Azure portal access policy with device-based authentication exemption
Answer: B
Explanation:
Conditional Access policy design requires understanding how multiple policies combine and how grant controls function to achieve complex access scenarios. When requirements involve different access controls based on conditions like device compliance state, the policy design must properly structure conditions and controls to achieve the desired behavior. Understanding policy evaluation and combination is essential for implementing requirements that appear contradictory at first glance.
Conditional Access policies evaluate during authentication attempts, and multiple policies can apply to a single access attempt. When multiple applicable policies exist, all policies must be satisfied for access to be granted. This cumulative effect means that if one policy requires MFA and another policy requires compliant devices, both conditions must be met. Understanding this cumulative evaluation is critical for designing policy combinations that achieve intended access controls.
The requirement presents a scenario where all users must provide MFA when accessing Azure portal, except compliant device users who should be exempted from MFA. This represents a conditional MFA requirement where MFA is needed unless a specific condition (device compliance) is met. Conditional Access doesn’t support “require MFA unless device is compliant” within a single policy because grant controls don’t support conditional exemptions—grant controls specify what’s required, not what exempts users from requirements.
B is correct because achieving the requirement of MFA for all users except those on compliant devices requires two Conditional Access policies: one requiring MFA for all Azure portal access, and another applying to compliant devices that doesn’t require MFA, creating an exemption through policy interaction. A is incorrect because Conditional Access grant controls don’t support excluding compliant devices from requirements within a single policy—you can’t configure “require MFA except for compliant devices” directly. C is incorrect because compliance policies evaluate device state but don’t configure Conditional Access requirements or handle application access controls—Conditional Access policies control access requirements, not compliance policies. D is incorrect because there isn’t a separate “Azure portal access policy” distinct from Conditional Access—Conditional Access policies target cloud apps including Azure portal and are the proper mechanism for controlling access.
Question 97:
You are configuring Microsoft Intune to manage iOS devices. You need to deploy a VPN profile that automatically connects when users access email in the Outlook app. What VPN feature should you configure?
A) Per-app VPN with Outlook specified in the app list
B) On-demand VPN with email domain triggers
C) Always-on VPN with app-based activation
D) Automatic VPN with mail service connection rules
Answer: A
Explanation:
Per-app VPN is a mobile device management capability that associates VPN connections with specific applications, creating rules where VPN automatically connects when designated applications launch or access network resources. This application-centric VPN approach provides secure connectivity exactly when and where it’s needed without requiring constant VPN connections that impact battery life and performance or manual user VPN connection management.
Per-app VPN for iOS works by configuring VPN profiles with application associations that tell iOS which applications should trigger automatic VPN connectivity. When users launch applications configured for per-app VPN, iOS automatically initiates the VPN connection in the background, routes the application’s network traffic through the VPN tunnel, and manages the connection lifecycle based on application usage. From the user’s perspective, the application functions normally with transparent secure connectivity.
To configure per-app VPN in Intune for iOS, you create a VPN profile specifying standard VPN parameters including VPN server address, connection type, authentication method, and certificates if required. Within the VPN profile configuration, you enable per-app VPN and add applications that should trigger automatic connection. Applications are identified by their bundle identifiers (like com.microsoft.Office.Outlook for Outlook), and multiple applications can be associated with a single VPN profile.
When Outlook is specified in the per-app VPN profile and users launch Outlook, iOS detects the application launch, checks if it’s associated with a VPN profile, automatically initiates the VPN connection if not already connected, waits for VPN establishment, and then allows Outlook to proceed with network operations including email synchronization. The VPN connection provides secure encrypted tunnel connectivity for all Outlook network traffic including email retrieval, sending, calendar synchronization, and attachment operations.
A is correct because per-app VPN with Outlook specified in the application list provides automatic VPN connection when Outlook launches, creating transparent secure connectivity for email access. B is incorrect because on-demand VPN uses domain or network destination triggers rather than application launch triggers, making it less appropriate when the requirement specifically involves application usage. C is incorrect because always-on VPN maintains constant connectivity regardless of application usage rather than connecting specifically when particular applications like Outlook are used. D is incorrect because “automatic VPN with mail service connection rules” is not a standard iOS VPN feature—per-app VPN is the established iOS capability for application-triggered VPN connectivity.
Question 98:
You manage Windows 11 devices using Microsoft Intune. You need to configure a policy that prevents specific applications from accessing the camera. What should you configure?
A) App control policy with camera access restrictions for specific applications
B) Device restrictions profile blocking camera access
C) Privacy settings through Settings Catalog with app-specific camera permissions
D) Endpoint protection policy with application camera blocking
Answer: C
Explanation:
Windows privacy controls provide granular management of which applications can access privacy-sensitive resources like camera, microphone, location, and other device capabilities. Understanding how to configure application-specific privacy permissions ensures organizations can balance privacy protection with application functionality, preventing unauthorized access to sensitive device features while allowing legitimate applications to function.
Settings Catalog in Intune is a comprehensive policy configuration interface that provides access to thousands of Windows settings organized by category. Unlike traditional device configuration profile templates that expose common settings through simplified interfaces, Settings Catalog provides access to the complete breadth of Windows management settings including granular privacy controls that aren’t available in simplified templates.
Within Settings Catalog, privacy settings control application access to device capabilities on a per-application basis. For camera specifically, Windows privacy architecture allows configuring whether the camera is accessible at all, which applications can access the camera, and whether specific applications are explicitly allowed or denied camera access. These settings use Windows privacy policies that the operating system enforces, preventing applications from accessing camera when policy denies permission.
To configure application-specific camera restrictions, you create a Settings Catalog policy and search for camera or privacy-related settings. You’ll find settings that control global camera enablement and application-specific camera permissions. For each application, you can specify whether camera access is allowed or denied using the application’s package family name or executable path. When the policy deploys, Windows enforces camera restrictions by blocking API calls that denied applications make attempting to access camera functionality.
Question 99:
Your organization uses Microsoft Intune to manage devices. You need to create a report that shows all devices enrolled in the last 30 days along with their assigned primary users. What should you use?
A) Device enrollment report with date filter and user assignment data
B) All devices report filtered by enrollment date with custom columns
C) Audit logs filtered for enrollment events
D) Azure AD device report with enrollment date filter
Answer: A
Explanation:
Microsoft Intune provides comprehensive reporting capabilities designed to help administrators monitor and analyze various aspects of device management including enrollment trends, device inventory, compliance status, and policy deployment. Understanding which reports provide specific types of information and how to filter and customize those reports is essential for effective device management, capacity planning, and operational monitoring.
Device enrollment reports in Intune are specifically designed to track device enrollment activities over time, providing insights into enrollment patterns, methods, platforms, and associated metadata. These reports are purpose-built for understanding enrollment trends and include relevant data points like enrollment date, enrollment method (user enrollment, Autopilot, Apple DEP, etc.), device platform, assigned user, and enrollment status. The specialized nature of enrollment reports makes them more appropriate for enrollment-focused queries than general device inventory reports.
Question 100:
You manage iOS devices using Microsoft Intune. You need to prevent users from modifying notification settings for corporate applications. What should you configure?
A) Device restrictions profile with notification modification settings blocked for managed apps
B) App configuration policy with notification preferences locked
C) Notification settings cannot be restricted through Intune policies
D) Supervised device restrictions with system notification controls
Answer: C
Explanation:
Understanding the capabilities and limitations of mobile device management platforms is crucial for setting realistic expectations and identifying scenarios where policies can directly address requirements versus scenarios where workarounds are needed or limitations must be accepted. While iOS device management through Intune provides extensive control over device features and application configurations, certain specific granular controls fall outside available policy settings, requiring administrators to evaluate alternatives or acknowledge limitations.
iOS notification system architecture allows users to customize notification behaviors for each application individually through Settings > Notifications, where they can control notification styles (banners, alerts, badges), sounds, whether notifications appear on lock screen, grouping behavior, and other presentation options. This user control over notifications is fundamental to iOS user experience design, providing individuals with agency over how applications interrupt or inform them throughout the day.
From an MDM perspective, device restrictions profiles for iOS provide extensive controls over numerous device features organized into categories including built-in apps, cloud and storage, connected devices, general device settings, locked screen experience, password requirements, and restricted apps. However, within these comprehensive controls, there isn’t a specific setting that prevents users from modifying notification preferences for applications. Apple’s MDM framework doesn’t expose notification preference modification as a manageable restriction, meaning Intune cannot provide this control even though it might seem like a logical extension of application management capabilities.
