Visit here for our full Microsoft MD-102 exam dumps and practice test questions.
Question 121:
Your organization uses Microsoft Intune to manage devices. You need to create a dynamic user group containing all users who are managers, based on the job title attribute in Azure AD. What membership rule should you configure?
A) (user.jobTitle -eq “Manager”)
B) (user.department -eq “Management”)
C) (user.role -eq “Manager”)
D) (user.userType -eq “Manager”)
Answer: A
Explanation:
Dynamic groups in Azure AD use membership rules based on user or device attributes to automatically maintain group membership without manual administration. Understanding correct attribute names and proper rule syntax ensures groups accurately capture intended members based on organizational data stored in Azure AD user profiles.
The user.jobTitle attribute in Azure AD contains job title information for users, typically populated from on-premises Active Directory through Azure AD Connect synchronization or entered directly in Azure AD for cloud-only users. Job titles provide role information that can be used for dynamic group membership rules when consistent titling conventions exist across the organization.
The membership rule (user.jobTitle -eq “Manager”) uses the equality operator (-eq) to match users whose job title exactly equals “Manager”. The rule evaluates each user’s jobTitle attribute, includes users with matching values in the group, and automatically maintains membership as job titles change. Case-insensitive comparison means “Manager”, “manager”, and “MANAGER” all match.
Dynamic group rules require exact attribute name matching. The user.department attribute contains department names rather than job titles, making it inappropriate for job title-based grouping. The user.role and user.userType attributes serve different purposes in Azure AD—userType distinguishes members from guests rather than indicating job roles.
Organizations using job title-based dynamic groups should ensure consistent job title values across user accounts. Variations like “Manager”, “Mgr”, “Management”, or “Managers” would require more complex rules using -contains or multiple -or conditions to capture all variations. Standardizing job title values simplifies rule construction and ensures reliable group membership.
A is correct because (user.jobTitle -eq “Manager”) uses the correct Azure AD user attribute for job title with proper equality comparison syntax to create dynamic membership based on manager job title. B is incorrect because user.department contains department names rather than job titles—the jobTitle attribute is appropriate for job role-based grouping. C is incorrect because “role” is not a standard Azure AD user attribute name for job titles—jobTitle is the correct attribute. D is incorrect because userType distinguishes member users from guest users rather than indicating job titles or roles—jobTitle is the appropriate attribute.
Question 122:
You are configuring app protection policies for iOS devices. You need to ensure that when users access managed apps, they must re-authenticate if the app has been in the background for more than 30 minutes. What should you configure?
A) Access requirements with recheck access requirements after (minutes) set to 30
B) Conditional launch with app timeout of 30 minutes
C) Data transfer settings with 30-minute session timeout
D) Access requirements with PIN timeout of 30 minutes
Answer: D
Explanation:
App protection policies provide multiple authentication controls that work together to balance security with user experience. Understanding the distinction between recheck intervals that control how frequently users must enter credentials during active usage versus timeout periods that determine how long apps can remain in background before requiring re-authentication helps administrators configure appropriate security controls.
PIN timeout settings in app protection policy access requirements control session-level authentication, specifically determining how long after an application moves to background before users must re-enter authentication credentials when returning to the application. When PIN timeout is set to 30 minutes, users switching away from managed applications to other tasks can return within 30 minutes without re-authenticating, but returning after 30 minutes requires fresh authentication.
The timeout mechanism tracks time elapsed since the application moved to background when users switch to other apps, receive phone calls, or interact with system interfaces. When users return to the managed application within the timeout period, the application remains accessible without authentication challenges. After the timeout expires, the application requires PIN entry, biometric authentication, or corporate credentials depending on configured authentication methods before displaying corporate data.
This session timeout provides security against scenarios where users leave applications open but unattended for extended periods. The 30-minute window allows reasonable multitasking without constant authentication challenges for quick task switching, while requiring re-authentication after extended absences ensures that unattended devices don’t provide prolonged access to corporate data.
Recheck access requirements intervals serve different purposes, controlling how frequently users must re-authenticate during continuous active application usage rather than after background periods. A 30-minute recheck interval would require authentication every 30 minutes even during active usage, which is typically more disruptive than necessary for most scenarios.
D is correct because PIN timeout settings control how long applications can remain in background before requiring re-authentication, providing session-level security appropriate for the 30-minute background timeout requirement. A is incorrect because recheck access requirements intervals control authentication frequency during active usage rather than background timeout periods—PIN timeout handles background session expiration. B is incorrect because “app timeout” in conditional launch relates to different conditions like offline intervals rather than background session timeout—PIN timeout is the specific control for background session expiration. C is incorrect because data transfer settings control how corporate data moves between applications rather than authentication timing—access requirements handle authentication timing.
Question 123:
You manage macOS devices using Microsoft Intune. You need to prevent users from installing applications from sources other than the Mac App Store. What should you configure?
A) Device restrictions profile blocking identified developer and unknown source applications through Gatekeeper settings
B) Compliance policy requiring App Store-only application installation
C) App control policy limiting installations to Mac App Store sources
D) Device configuration profile with application installation restrictions
Answer: A
Explanation:
macOS includes Gatekeeper security technology that controls which applications can be installed and executed based on their origin and code signing status. Understanding how to leverage Gatekeeper through MDM policies enables organizations to restrict application installation to trusted sources like the Mac App Store, reducing malware risks and maintaining standardized application environments.
Device restrictions profiles for macOS include Gatekeeper settings that control application installation and execution permissions. Gatekeeper options typically include allowing applications from Mac App Store only, allowing applications from Mac App Store and identified developers (applications signed with valid Apple Developer IDs), or allowing applications from anywhere including unsigned applications from unknown sources.
Configuring Gatekeeper to allow only Mac App Store applications provides the strictest application control, ensuring all installed applications have been reviewed by Apple and are distributed through official channels. This restriction prevents users from installing applications downloaded from websites, transferred from other devices, or developed internally without App Store distribution, significantly reducing malware and potentially unwanted program risks.
The Gatekeeper enforcement occurs at installation and execution time. When users attempt installing applications from sources other than the Mac App Store, Gatekeeper blocks the installation and displays messages indicating the application cannot be installed due to security policies. Applications already installed before policy deployment may continue functioning, but new installations from unauthorized sources are prevented.
Organizations requiring internal or line-of-business application deployment outside the Mac App Store should consider options including submitting applications to Mac App Store for distribution, code signing applications with Apple Developer Enterprise certificates and allowing identified developers in Gatekeeper settings, or using MDM application deployment which can bypass Gatekeeper for applications deployed by IT through management channels.
A is correct because device restrictions profiles include Gatekeeper settings that control application installation sources, allowing restriction to Mac App Store only by blocking identified developers and unknown sources. B is incorrect because compliance policies check device state but don’t actively prevent application installations from unauthorized sources—device restrictions enforce prevention. C is incorrect because “app control policy” is not a standard macOS policy type in Intune—device restrictions with Gatekeeper settings provide application installation control. D is incorrect because general “device configuration profile with application installation restrictions” is less specific than device restrictions profile with Gatekeeper settings, which is the proper mechanism.
Question 124:
Your organization uses Windows Autopilot for device deployment. After deployment completes, you need to automatically install a required application that was not included in the Enrollment Status Page tracking. What should you do?
A) Change the application assignment from Available to Required for the relevant device group
B) Configure Enrollment Status Page to track the application as a blocking app
C) Deploy the application as Required; it will install after ESP completes during normal policy sync
D) Create a provisioning package with the application for post-Autopilot installation
Answer: C
Explanation:
Windows Autopilot deployment and Enrollment Status Page tracking focus on ensuring devices are fully configured with essential applications and policies before users access them. However, not all applications need to block user access during initial provisioning. Understanding how application assignment timing and ESP tracking interact helps administrators design deployment strategies that balance thorough provisioning with reasonable deployment times.
Applications assigned as Required to device or user groups install automatically during policy sync cycles without user intervention. If applications are assigned before or during Autopilot deployment but are not configured as blocking apps in ESP settings, they install in the background after ESP completes and users reach the desktop. This asynchronous installation allows users to begin working while non-critical applications complete installation.
The deployment workflow proceeds as follows: Autopilot provisions devices with ESP tracking essential applications configured as blocking, users authenticate and reach the desktop after ESP completes, Intune Management Extension continues processing assigned policies and applications, Required applications not tracked by ESP install in the background, and installation completion appears in Company Portal or can be monitored through Intune reporting.
This approach is appropriate for applications that enhance productivity but aren’t essential for initial device security or functionality. Examples might include optional productivity tools, department-specific applications, or supplementary utilities that users can work without temporarily. Installing these applications after ESP completes reduces initial provisioning time while ensuring they deploy automatically without user intervention.
Changing assignment from Available to Required doesn’t affect ESP tracking or installation timing unless ESP configuration is also modified. Required assignment ensures automatic installation but doesn’t control whether ESP tracks and blocks on the application. ESP configuration specifically determines which Required applications block provisioning completion.
C is correct because applications assigned as Required will automatically install during normal policy sync after ESP completes, providing automatic deployment without blocking user access during initial provisioning. A is incorrect because changing to Required assignment alone doesn’t change ESP tracking—applications can be Required without being ESP-tracked, and they’ll install post-ESP automatically. B is incorrect because configuring ESP to track the application would make it block provisioning completion, which contradicts the requirement to install after ESP completes. D is incorrect because provisioning packages are used for applying configurations during deployment rather than post-deployment application installation, which normal Required assignment handles.
Question 125:
You are configuring Microsoft Intune to manage iOS devices. You need to deploy a VPN profile that only connects when accessing specific internal domains. What should you configure?
A) Per-app VPN with on-demand VPN rules specifying internal domains
B) Always-on VPN with domain-based routing rules
C) VPN profile with automatic connection script checking domains
D) On-demand VPN rules with domain evaluation
Answer: D
Explanation:
iOS VPN capabilities include sophisticated on-demand connection features that automatically establish VPN connections based on network conditions, domains being accessed, or other criteria. Understanding how to configure on-demand VPN rules enables organizations to provide transparent secure connectivity exactly when needed without requiring constant VPN connections or manual user initiation.
On-demand VPN rules in iOS VPN profiles define conditions that trigger automatic VPN connection establishment. Rules can evaluate domains being accessed, DNS server responses, network SSIDs, or other network characteristics to determine when VPN connectivity is necessary. For domain-based triggering, rules specify domain patterns (like “*.internal.company.com” or specific hostnames), and iOS automatically connects VPN when applications attempt accessing matching domains.
The configuration involves creating a VPN profile with standard VPN parameters including server address, authentication method, and connection type, then adding on-demand rules with domain evaluation criteria. Rules can use “Connect if needed” actions that establish VPN for matching domains, “Never connect” actions for domains that should bypass VPN, or “Always connect” for constant VPN regardless of domain access.
iOS evaluates on-demand rules before domain name resolution when applications make network requests. When applications attempt connecting to domains matching on-demand rules, iOS checks current VPN status, establishes VPN connection if not already connected, waits for VPN to be ready, and then proceeds with the connection through the VPN tunnel. This process is transparent to applications and users.
Per-app VPN represents a different approach where specific applications always use VPN connections regardless of destinations being accessed. While per-app VPN can be combined with on-demand rules, the domain-specific connection requirement suggests on-demand rules are the primary feature needed rather than application-specific VPN binding.
D is correct because on-demand VPN rules with domain evaluation provide automatic VPN connection when accessing specific internal domains, matching the requirement for domain-based VPN triggering. A is incorrect because while per-app VPN with on-demand rules could work, the requirement focuses on domain-based connection rather than application-based connection, making on-demand rules the primary feature needed. B is incorrect because always-on VPN maintains constant connectivity rather than connecting only when specific domains are accessed—on-demand provides selective connection. C is incorrect because VPN profiles don’t support custom connection scripts—on-demand rules provide the domain-checking functionality needed.
Question 126:
You manage Android Enterprise devices using Microsoft Intune. You need to configure devices to automatically connect to corporate Wi-Fi networks but prevent users from connecting to other Wi-Fi networks. What should you configure?
A) Wi-Fi profile with corporate network settings and device restrictions blocking user-configured Wi-Fi networks
B) Wi-Fi profile with exclusive network configuration preventing other connections
C) Device configuration profile with Wi-Fi-only mode restricting network options
D) Compliance policy requiring connection to corporate Wi-Fi only
Answer: A
Explanation:
Android Enterprise device management provides separate controls for deploying network configurations versus restricting user ability to modify network settings. Understanding how to combine Wi-Fi profile deployment with device restrictions creates comprehensive network control where corporate networks are automatically available while preventing users from adding potentially insecure personal networks.
Wi-Fi profiles in Intune deploy network configurations to Android Enterprise devices including network SSID, security type (WPA2-Enterprise, WPA2-Personal, etc.), authentication methods, certificates for authentication if applicable, and proxy settings if needed. When Wi-Fi profiles deploy, corporate networks appear in available networks and devices can automatically connect using the configured credentials without user intervention.
However, Wi-Fi profile deployment alone doesn’t prevent users from adding additional networks through Android settings. Users can still navigate to Wi-Fi settings and manually configure connections to home networks, public hotspots, or other networks not controlled by organizational policies. This user flexibility might violate security policies requiring exclusive corporate network usage on managed devices.
Device restrictions profiles for Android Enterprise include settings that control user ability to modify network configurations. The restriction for blocking user-configured Wi-Fi networks prevents users from adding, modifying, or removing Wi-Fi networks through Android settings. When this restriction is enabled, the Wi-Fi settings interface shows only MDM-deployed networks, and options to add networks are disabled or hidden.
The combination of Wi-Fi profile deployment and user configuration restriction creates a locked network environment where corporate Wi-Fi networks automatically connect and users cannot add alternative networks. This approach ensures devices only connect to approved secure networks, preventing data leakage through unencrypted public Wi-Fi or connection to potentially malicious rogue access points.
Implementation requires deploying both policy types to the same device groups—Wi-Fi profiles to provide corporate network configurations and device restrictions to prevent user additions. The policies work together where Wi-Fi profiles enable corporate connectivity and restrictions prevent unauthorized network additions.
A is correct because combining Wi-Fi profile deployment with device restrictions blocking user-configured networks provides both corporate network connectivity and prevention of unauthorized network additions. B is incorrect because Wi-Fi profiles deploy network configurations but don’t include “exclusive” settings preventing other connections—device restrictions must explicitly block user configuration. C is incorrect because “Wi-Fi-only mode” restricting network options is not a standard Android Enterprise configuration—the combination of Wi-Fi profiles and device restrictions achieves the requirement. D is incorrect because compliance policies check device state but don’t deploy network configurations or prevent user actions—configuration and restriction policies are needed.
Question 127:
Your organization uses Microsoft Intune to manage Windows 11 devices. You need to deploy a line-of-business application that requires Microsoft .NET Framework 4.8 Desktop Runtime. How should you ensure the runtime is installed before the application?
A) Configure the LOB application with a dependency on a Win32 app package containing .NET Framework 4.8 Desktop Runtime
B) Include .NET Framework installation in the LOB application’s installation command
C) Deploy .NET Framework using Windows Update before deploying the application
D) Use a PowerShell script to install .NET Framework triggered before application deployment
Answer: A
Explanation:
Win32 application dependency management in Intune provides systematic approaches for ensuring prerequisites are installed before dependent applications. Understanding how to properly structure dependencies using Win32 app relationships rather than embedding prerequisite installation in application commands ensures reliable installation sequencing with integrated detection, reporting, and retry logic.
The Win32 app dependency feature allows declaring relationships between applications where one application depends on another. When configuring dependencies, you first package the prerequisite (in this case .NET Framework 4.8 Desktop Runtime) as a Win32 app with appropriate installation command and detection rules. The detection rules verify the framework is present by checking registry keys, file versions, or other indicators that reliably identify successful installation.
After packaging the prerequisite as a Win32 app, the line-of-business application is configured with a dependency relationship referencing the framework app. During deployment, Intune automatically checks detection rules for dependencies before installing the primary application. If the framework isn’t detected, Intune installs it first. If already present, Intune skips prerequisite installation and proceeds directly to the primary application.
This approach provides significant advantages including automatic installation sequencing without manual timing coordination, reusability where the framework dependency can be referenced by multiple applications, integrated detection avoiding redundant installations if prerequisites are already present, and comprehensive reporting showing which component failed if installation issues occur.
The dependency detection ensures proper sequencing even when applications are assigned at different times or to different groups. If the primary application is assigned first but its dependency isn’t yet installed, Intune recognizes the dependency requirement and installs the prerequisite automatically during the primary application’s installation attempt.
Including framework installation in the application’s installation command creates monolithic installers that are harder to troubleshoot, cannot be reused across applications needing the same prerequisite, and don’t benefit from Intune’s detection and dependency management features. Separate dependency configuration provides cleaner separation of concerns.
A is correct because configuring Win32 app dependency relationships leverages Intune’s native dependency management, ensuring prerequisites install before dependent applications with proper detection and sequencing. B is incorrect because including framework installation in the application command creates monolithic installers without the modularity and reusability benefits of dependency relationships. C is incorrect because .NET Framework 4.8 Desktop Runtime is not distributed through Windows Update—it requires separate deployment, and Windows Update doesn’t integrate with application dependency sequencing. D is incorrect because PowerShell script deployment operates independently from Win32 app dependencies without integrated sequencing guarantees—Win32 app dependency relationships provide proper integration.
Question 128:
You are configuring app protection policies for iOS devices. You need to ensure that users can only save corporate documents to OneDrive for Business, preventing saves to personal cloud storage services. What should you configure?
A) Data transfer settings with “Save copies of org data” configured to allow specific services including OneDrive for Business
B) Data transfer settings with “Send org data to other apps” set to policy managed apps
C) Access requirements restricting storage locations to approved services
D) Conditional launch preventing unapproved cloud storage access
Answer: A
Explanation:
App protection policies provide granular control over where corporate data can be saved, preventing data leakage to unauthorized storage locations while maintaining productivity by allowing saves to approved cloud services. Understanding the “Save copies of org data” setting and service allowlisting enables organizations to create selective storage policies that protect data while supporting business workflows.
The “Save copies of org data” setting in app protection policy data transfer section controls where users can save corporate documents and files from managed applications. This setting offers multiple configuration options including blocking all save operations except to approved locations, allowing saves to any location, or selectively allowing saves to specific cloud storage services through service exemptions.
When configured to allow specific services, administrators can add approved cloud storage services to an allowlist. OneDrive for Business can be specifically allowed while blocking personal OneDrive, Dropbox, Google Drive, or other consumer cloud storage services. This selective allowlisting ensures corporate data flows only to IT-managed cloud storage where organizational security controls, compliance policies, and data governance apply.
The implementation occurs through Intune-protected applications that integrate with the Intune App SDK. When users attempt saving documents using Save As functionality or export features, the application checks whether the destination service is on the approved list. Saves to OneDrive for Business proceed normally, while attempts to save to unapproved services are blocked with notifications indicating organizational policy prevents the action.
This control is particularly important for preventing data exfiltration where users might intentionally or inadvertently upload sensitive corporate documents to personal cloud storage accounts accessible from unmanaged devices or shared with external parties. By restricting saves to approved corporate storage, organizations maintain control over data location and access.
The “Send org data to other apps” setting controls broader application-to-application data transfer through mechanisms like share sheets and open-in functionality, which is related but distinct from the specific save operation control that “Save copies of org data” provides. Both settings work together for comprehensive data transfer control.
A is correct because “Save copies of org data” setting with service allowlisting provides specific control over save destinations, allowing OneDrive for Business while blocking other cloud storage services. B is incorrect because “Send org data to other apps” controls application-to-application data transfer rather than save destination restrictions—”Save copies” handles save location control. C is incorrect because access requirements control authentication conditions rather than storage destination restrictions—data transfer settings handle save location control. D is incorrect because conditional launch triggers actions based on conditions like offline intervals or OS versions rather than controlling save destinations—data transfer settings provide save location control.
Question 129:
You manage Windows 11 devices using Microsoft Intune. You need to configure BitLocker to use 256-bit AES encryption for operating system drives. What should you configure?
A) Endpoint security Disk encryption policy with encryption method set to AES 256-bit
B) Device configuration profile with BitLocker settings specifying AES 256-bit
C) Compliance policy requiring 256-bit encryption for OS drives
D) Settings Catalog with BitLocker encryption algorithm configuration
Answer: A
Explanation:
BitLocker disk encryption configuration in Intune can be accomplished through multiple policy types, but Endpoint security Disk encryption policies provide the most streamlined and purpose-built interface for comprehensive encryption management. Understanding which policy type offers the most appropriate configuration experience for encryption scenarios helps administrators efficiently deploy security controls.
Endpoint security policies in Microsoft Intune organize security configurations into focused policy types that consolidate related settings. The Disk encryption policy type specifically addresses full disk encryption scenarios including BitLocker configuration for Windows devices, providing dedicated interfaces for encryption method selection, recovery key management, authentication requirements, and encryption enforcement settings.
Within Disk encryption policies, the encryption method setting allows selecting cryptographic algorithms and key strengths for different drive types including operating system drives, fixed data drives, and removable drives. Options typically include AES 128-bit and AES 256-bit with various cipher modes. Selecting AES 256-bit for operating system drives configures BitLocker to use the stronger encryption standard providing enhanced security for data at rest.
The 256-bit key length provides stronger cryptographic protection than 128-bit alternatives, requiring significantly more computational effort to break through brute force attacks. While both 128-bit and 256-bit AES are considered secure for current cryptographic standards, 256-bit provides additional security margin particularly valuable for highly sensitive data or organizations with stringent security requirements.
Endpoint security Disk encryption policies also handle complementary BitLocker configuration including requiring encryption before allowing writes to drives, specifying minimum operating system version for BitLocker enablement, configuring recovery key escrow to Intune or Azure AD, and setting authentication methods like TPM-only or TPM with PIN. This consolidated configuration simplifies BitLocker deployment compared to scattering settings across multiple policy types.
Device configuration profiles can include BitLocker settings through templates or Settings Catalog, providing alternative configuration paths. However, Endpoint security policies are specifically designed for security scenarios like encryption, offering more focused interfaces that security administrators find more intuitive than navigating comprehensive device configuration catalogs.
A is correct because Endpoint security Disk encryption policies provide purpose-built interfaces for BitLocker configuration including encryption method selection for AES 256-bit encryption on operating system drives. B is incorrect because while device configuration profiles can configure BitLocker, Endpoint security Disk encryption policies provide more focused and appropriate interfaces specifically designed for encryption scenarios. C is incorrect because compliance policies check whether encryption is enabled and meets requirements but don’t configure the encryption method or enable BitLocker—configuration policies set encryption parameters. D is incorrect because while Settings Catalog provides access to BitLocker settings, Endpoint security Disk encryption policies offer more streamlined purpose-built interfaces for encryption configuration.
Question 130:
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 completely
C) App configuration policy disabling AirDrop for managed applications
D) Data transfer settings with AirDrop explicitly disabled
Answer: A
Explanation:
AirDrop represents a significant data transfer mechanism on iOS devices that can bypass traditional data loss prevention controls if not properly managed. Understanding how app protection policies control AirDrop usage through data transfer restrictions prevents corporate data leakage while maintaining appropriate user flexibility for personal data on BYOD devices.
App protection policies control data transfer from managed applications through the “Send org data to other apps” setting, which governs all outbound data sharing mechanisms including AirDrop, share sheets, open-in functionality, and other iOS data transfer features. When this setting is configured to “Policy managed apps,” it restricts data sharing to only other applications protected by Intune app protection policies.
AirDrop integration with iOS’s share sheet means when users attempt sharing corporate data from managed applications, AirDrop appears as a sharing option. With app protection policies enforcing policy-managed-apps-only data transfer, the Intune App SDK integrated into protected applications filters the share sheet to exclude AirDrop and other sharing methods that would transfer data outside the managed app ecosystem.
This application-level control provides appropriate protection for BYOD scenarios where blocking AirDrop entirely would prevent legitimate personal usage. Users can still use AirDrop to share personal photos, documents, or other non-corporate data from personal applications, while corporate data in managed applications remains protected from AirDrop sharing.
The enforcement occurs transparently through Intune-protected applications without requiring system-wide AirDrop blocking. When users attempt sharing corporate data, they simply don’t see AirDrop as an option, or if visible, attempting to use it is blocked with notifications explaining organizational policy prevents the action.
Device-level AirDrop blocking through device restrictions would prevent all AirDrop usage including for personal data, which is overly restrictive for personally owned devices in BYOD programs. Application-level control through app protection policies provides proportional security protecting corporate data without unnecessarily impacting personal device functionality.
A is correct because app protection policies with “Send org data to other apps” set to “Policy managed apps” restricts all data sharing mechanisms including AirDrop, preventing corporate data sharing while maintaining personal AirDrop usage. B is incorrect because device restrictions blocking AirDrop completely prevents all AirDrop usage including personal data, which is overly restrictive for BYOD devices—application-level control is more appropriate. C is incorrect because app configuration policies configure application settings rather than enforcing data transfer restrictions—app protection policies provide data loss prevention controls. D is incorrect because “data transfer settings with AirDrop explicitly disabled” is not a specific configuration option—the “Send org data to other apps” setting provides the control mechanism for all sharing including AirDrop.
Question 131:
You are configuring Microsoft Intune to deploy a Win32 application to Windows 11 devices. The application should only install on devices with at least 8GB of RAM. What should you configure?
A) Requirements with minimum RAM set to 8GB
B) Detection rules checking for 8GB RAM before installation
C) Installation command with PowerShell script validating RAM
D) Applicability rules with memory requirements
Answer: A
Explanation:
Win32 application deployment in Intune includes requirement rules that define conditions devices must meet before applications are considered applicable for installation. Understanding how to properly configure requirements ensures applications only install on devices capable of running them, preventing installation failures and providing clear applicability status when devices don’t meet requirements.
Requirements in Win32 app configuration allow specifying minimum device capabilities including operating system version, processor architecture (32-bit or 64-bit), disk space, and physical memory (RAM). Setting minimum RAM to 8GB ensures Intune only attempts installation on devices meeting this memory requirement, preventing deployment to underpowered devices where the application might perform poorly or fail.
When Intune evaluates device applicability for applications, it checks requirements before attempting installation or downloading application content. Devices not meeting RAM requirements show the application as “Not Applicable” in deployment status rather than “Failed,” clearly communicating that the device lacks necessary resources rather than experiencing installation problems.
This pre-installation evaluation saves bandwidth by not downloading application content to devices that cannot run the application, prevents failed installation attempts that consume time and create error logs, and provides clear reporting about why applications don’t deploy to specific devices. Administrators reviewing deployment status immediately see resource-based applicability failures versus installation failures.
Detection rules serve different purposes, determining whether applications are already installed rather than whether devices can support applications. Detection rules evaluate after installation attempts to verify success, not before attempts to validate device capabilities. Using detection rules for RAM checking would be inappropriate and wouldn’t prevent installation attempts.
Including RAM validation in installation commands adds unnecessary complexity compared to native requirement functionality. Installation commands execute after applicability evaluation, meaning they run on devices that already passed requirement checks. Checking RAM in installation scripts provides redundant validation that native requirements handle more elegantly.
A is correct because Win32 app requirements include minimum RAM configuration that Intune evaluates before installation attempts, ensuring applications only deploy to adequately resourced devices. B is incorrect because detection rules determine whether applications are installed rather than whether devices meet resource requirements—requirements handle device capability validation. C is incorrect because installation commands execute after applicability evaluation, making RAM validation in scripts redundant to native requirement functionality. D is incorrect because “applicability rules” is not distinct terminology from requirements—requirements define applicability, making this answer less precise than specifying “requirements with minimum RAM.”
Question 132:
You manage macOS devices using Microsoft Intune. You need to configure devices to require administrator authentication for installing applications. What should you configure?
A) Device restrictions profile requiring administrator password for software installations
B) Gatekeeper settings requiring admin approval for installations
C) System extension policy with admin authorization requirements
D) This behavior is not configurable through Intune; it’s controlled by user account type
Answer: D
Explanation:
Understanding the distinction between settings configurable through MDM policies versus settings determined by operating system architecture or user account permissions helps administrators set realistic expectations and design appropriate security approaches. While macOS device management provides extensive configuration options, certain security behaviors are fundamentally controlled by user account types rather than policy settings.
macOS user account types include administrator accounts with privileges to install software, modify system settings, and access protected resources, and standard user accounts with restricted privileges requiring administrator authentication for privileged operations. Whether users must provide administrator authentication for software installation depends on their account type assignment rather than MDM policy configuration.
Standard user accounts on macOS automatically require administrator authentication for installing applications outside the Mac App Store, modifying system preferences, or performing other privileged operations. The operating system prompts for administrator credentials when standard users attempt these actions, enforcing security boundaries regardless of MDM policies.
MDM policies cannot make administrator accounts behave like standard accounts by requiring password prompts for installations. The account type determines privilege levels, and MDM policies work within those privilege boundaries rather than overriding fundamental account type behaviors. Organizations requiring administrator authentication for installations should assign standard user accounts rather than administrator accounts to users.
Device restrictions profiles for macOS include numerous settings controlling device features and capabilities, but requiring administrator authentication for installations is not among configurable options because this behavior is inherent to macOS account types. Restrictions can prevent certain actions entirely but cannot add authentication requirements to otherwise authorized actions.
Gatekeeper settings control which application sources are allowed (Mac App Store only, Mac App Store plus identified developers, or any source), but don’t add administrator authentication requirements to installation processes. Gatekeeper enforces application source restrictions regardless of user account type but doesn’t change authentication requirements based on account privileges.
Organizations should implement least privilege principles by assigning standard user accounts to employees for daily work and reserving administrator accounts for IT personnel performing system administration. This approach ensures users must request administrator assistance for installations, providing security oversight and reducing risks of malware installation or system misconfiguration.
D is correct because requiring administrator authentication for software installation is determined by user account type (standard vs administrator) rather than being configurable through MDM policies—organizations must assign appropriate account types to users. A is incorrect because device restrictions profiles don’t include settings to require administrator passwords for installations by administrator accounts—this behavior is controlled by account type. B is incorrect because Gatekeeper settings control application source restrictions rather than adding authentication requirements to installation processes. C is incorrect because system extension policies approve specific extensions for loading but don’t add administrator authentication requirements for application installations.
Question 133:
Your organization uses Microsoft Intune to manage devices. You need to deploy an iOS application that requires specific configuration settings before users can access it. What should you create?
A) App configuration policy for managed devices with the required application settings
B) App protection policy with configuration data for the application
C) Device configuration profile with application-specific settings
D) Managed app configuration through device restrictions
Answer: A
Explanation:
iOS application management distinguishes between app protection policies that secure corporate data within applications and app configuration policies that deliver configuration settings to applications. Understanding this distinction ensures administrators use appropriate policy types for configuration delivery versus data protection, preventing confusion about policy purposes and capabilities.
App configuration policies for managed devices deliver configuration settings to applications on enrolled iOS devices through Apple’s MDM protocol. These policies allow IT to pre-configure application behaviors including server addresses, authentication parameters, feature enablement or disablement, user interface customization, and application-specific operational settings. Applications supporting managed configuration can receive these settings automatically without requiring user input.
The configuration process involves creating an app configuration policy in Intune, specifying the target application by its bundle identifier, defining configuration key-value pairs using either the configuration designer interface (for applications providing XML configuration schemas) or custom XML/JSON configuration data, and assigning the policy to user or device groups. When enrolled devices receive the policy, iOS delivers configuration data to the application through the MDM framework.
Applications must be designed to support managed configuration by implementing Apple’s managed app configuration framework or following AppConfig community standards. When applications launch, they query for managed configuration and apply received settings, providing pre-configured experiences without requiring users to manually enter configuration details. This automation improves user experience and reduces support burden for complex enterprise applications.
App protection policies serve different purposes, providing data loss prevention controls like preventing screenshots, restricting data transfer, requiring authentication, and encrypting data. While app protection policies protect corporate data within applications, they don’t deliver configuration settings for application functionality. The two policy types complement each other where configuration policies set up applications and protection policies secure their data.
Device configuration profiles configure device-level settings like restrictions, features, certificates, and system preferences rather than application-specific functional configuration. Application configuration requires dedicated app configuration policies that use application management frameworks rather than device configuration mechanisms.
A is correct because app configuration policies for managed devices provide the proper mechanism for delivering configuration settings to iOS applications on enrolled devices through MDM channels. B is incorrect because app protection policies provide data security controls rather than delivering functional configuration settings to applications—app configuration policies handle configuration delivery. C is incorrect because device configuration profiles configure device-level settings rather than application-specific functional configuration—app configuration policies are purpose-built for application configuration. D is incorrect because device restrictions control feature availability rather than delivering application configuration data—app configuration policies provide configuration delivery mechanisms.
Question 134:
You are configuring Windows Update for Business in Microsoft Intune. You need to allow users to pause quality updates for up to 7 days. What should you configure?
A) Update ring with user pause option enabled and maximum pause period set to 7 days
B) Quality update deadline with 7-day grace period
C) Update ring with 7-day deferral period allowing user control
D) Windows Update policy with user-controlled pause feature
Answer: A
Explanation:
Windows Update for Business provides flexibility for balancing organizational control over update deployment with user autonomy for managing update timing around critical work periods. Understanding how to configure user pause capabilities while limiting pause duration ensures users can delay updates for legitimate reasons without indefinitely postponing security patches.
Update rings in Intune include user experience settings that control whether users can pause updates through Windows Update settings and, if pausing is allowed, the maximum duration users can maintain pauses. Enabling the pause option grants users temporary control over update installation timing, useful when users have critical deadlines, presentations, or other time-sensitive work where update-related disruptions would be particularly problematic.
The maximum pause period setting limits how long users can keep updates paused before Windows automatically ends the pause and proceeds with update installation. Setting this to 7 days allows users one week of pause time, providing reasonable flexibility for short-term critical work periods while ensuring updates don’t remain uninstalled indefinitely. After the pause period expires, Windows automatically resumes update installation according to configured deadlines and maintenance windows.
User pause functionality complements deadline enforcement where deadlines ensure updates eventually install even if users repeatedly postpone them, while pause capabilities provide users with some autonomy for timing installations around their work schedules. The combination balances organizational security needs with user productivity considerations.
The pause feature is particularly valuable during critical business periods where users need uninterrupted device operation for important deliverables, presentations, demonstrations, or customer interactions. Rather than forcing updates during inopportune times, the pause option respects user judgment about appropriate timing while maintaining overall update compliance through limited pause durations.
Quality update deadlines with grace periods serve different purposes, determining enforcement timing for update installation rather than user control over pausing. Deadlines specify when updates must install, while pause options give users temporary control before deadlines force installation.
A is correct because update rings include user pause options with configurable maximum pause periods, allowing users to temporarily pause quality updates for specified durations like 7 days. B is incorrect because quality update deadlines with grace periods control enforcement timing rather than user pause capabilities—pause options specifically grant user control over temporary update postponement. C is incorrect because deferral periods delay when updates become available rather than allowing user-controlled pausing—pause options specifically enable user postponement. D is incorrect because “Windows Update policy” is less specific than update rings, which are the specific policy type providing user pause configuration options.
Question 135:
You manage Android Enterprise devices using Microsoft Intune. You need to configure devices to prevent users from enabling USB debugging. What should you configure?
A) Device restrictions profile with USB debugging blocked
B) Compliance policy requiring USB debugging to be disabled
C) System security settings preventing developer options access
D) Device configuration profile with developer mode restrictions
Answer: A
Explanation:
USB debugging represents a significant security risk on Android devices by enabling advanced device access through ADB (Android Debug Bridge) connections that can install applications, extract data, or modify system settings. Understanding how to properly restrict USB debugging through device restrictions prevents this attack vector while maintaining appropriate device security posture.
Device restrictions profiles for Android Enterprise include settings controlling various device features and capabilities organized by category. Within developer-related settings, options exist for preventing USB debugging, blocking developer options entirely, or restricting specific developer features. The USB debugging restriction specifically prevents users from enabling USB debugging in Android’s developer options menu.
When USB debugging restrictions are enabled and deployed through Intune, Android enforces the restriction by making the USB debugging toggle unavailable, hidden, or disabled in developer options. Even if users enable developer options (which requires tapping the build number repeatedly in About Phone), the USB debugging setting cannot be activated, preventing ADB connections for unauthorized device access or data extraction.
USB debugging security concerns include potential data exfiltration where attackers with physical device access could use ADB to extract data, unauthorized application installation bypassing enterprise app management controls, system modification allowing attackers to disable security features or install malware, and debugging access providing information useful for exploiting vulnerabilities.
Android Enterprise fully managed devices and corporate-owned work profile devices support comprehensive developer option restrictions. Work profile devices on personally owned hardware may have more limited restrictions on device-level settings outside the work profile, reflecting the balance between corporate control and user privacy on personal devices.
Compliance policies can check whether USB debugging is currently enabled and mark devices non-compliant if detected, but compliance checking provides reactive detection rather than proactive prevention. Device restrictions actively prevent users from enabling USB debugging, providing better security than detection-based compliance checking that identifies problems only after they occur.
A is correct because device restrictions profiles include specific settings to block USB debugging, preventing users from enabling this developer feature that poses security risks. B is incorrect because compliance policies check whether USB debugging is enabled but don’t prevent users from enabling it—restrictions provide proactive prevention rather than reactive detection. C is incorrect because while system security settings might control some aspects, the specific USB debugging restriction is configured through device restrictions profiles rather than separate system security settings. D is incorrect because while developer mode restrictions exist, the specific terminology and proper location for USB debugging prevention is in device restrictions profiles.
Question 136:
Your organization uses Microsoft Intune to manage Windows 11 devices. You need to prevent specific users from logging into shared workstation devices. What should you configure?
A) Device configuration profile with logon restrictions specifying allowed users or groups
B) Conditional Access policy blocking specific users from accessing shared devices
C) Compliance policy requiring approved user list for device access
D) Settings Catalog with user logon restriction policies
Answer: D
Explanation:
Windows provides security policies for controlling which users or groups can log onto specific computers locally, enabling organizations to restrict shared device access to authorized personnel. Understanding how to configure these logon restriction policies through Intune ensures shared resources remain accessible only to appropriate users while preventing unauthorized access.
Settings Catalog in Intune provides access to comprehensive Windows configuration settings including security policies traditionally managed through Group Policy. Within Settings Catalog, administrators can find policies related to user rights assignment and logon restrictions, including settings that specify which users or groups are allowed or denied interactive logon to devices.
The relevant settings include “Allow log on locally” which specifies users or groups permitted to log into devices interactively, and “Deny log on locally” which explicitly blocks specific users or groups from interactive logon. Configuring these settings through Settings Catalog allows creating policies that apply to shared workstation devices, ensuring only authorized personnel can authenticate and access those systems.
Implementation involves creating a Settings Catalog policy, searching for logon-related settings, configuring allowed or denied user lists using user account names or group memberships, and assigning the policy to device groups containing shared workstations. The policy deploys to devices where Windows enforces logon restrictions at authentication time, preventing unauthorized users from successfully logging in even with valid credentials.
This approach is particularly valuable for shared workstations in environments like healthcare where specific computers should only be accessed by personnel working in particular departments, retail where shared POS terminals should only be accessible to cashiers and managers, or education where shared lab computers might restrict access to specific classes or faculty.
Device configuration profiles might include some restriction capabilities but Settings Catalog provides more comprehensive access to security policies including user rights assignments. Conditional Access policies control access to cloud applications and services rather than local device logon, operating at different authentication layers.
D is correct because Settings Catalog provides access to Windows security policies including user logon restrictions that control which users or groups can log onto devices locally. A is incorrect because while device configuration profiles offer some restrictions, Settings Catalog provides more direct access to the specific logon restriction security policies needed. B is incorrect because Conditional Access policies control access to cloud applications rather than local device logon—they operate at different authentication layers. C is incorrect because compliance policies check device state rather than enforcing logon restrictions—Settings Catalog security policies provide logon restriction enforcement.
Question 137:
You are configuring app protection policies for iOS devices. You need to prevent users from taking screenshots in managed applications. What should you configure?
A) Data protection settings with “Block screen capture and Android Assistant” enabled
B) Access requirements preventing screen capture functionality
C) Screenshot blocking is not available for iOS app protection policies
D) Conditional launch with screen capture detection and blocking
Answer: C
Explanation:
Understanding platform-specific capabilities and limitations of app protection policies helps administrators set realistic expectations and design security controls that work within platform constraints. While app protection policies provide extensive data loss prevention features, certain controls are available on specific platforms but not others due to operating system architecture differences.
iOS app protection policies in Intune include numerous data protection controls like preventing data transfer to unmanaged apps, encrypting corporate data, requiring authentication, restricting clipboard operations, and preventing app data backup. However, screenshot blocking is not among the available controls for iOS app protection policies, representing a platform limitation rather than an Intune deficiency.
The limitation stems from iOS’s app security architecture where Apple provides limited APIs for applications to prevent screenshots. Unlike Android where applications can set window flags (FLAG_SECURE) preventing system-level screenshot capture, iOS doesn’t provide equivalent application-level screenshot prevention mechanisms through standard APIs. This architectural difference means app protection policies cannot enforce screenshot blocking on iOS as they can on Android.
Organizations requiring screenshot prevention on iOS devices have limited options including using device restrictions on enrolled devices to block screenshots system-wide (though this affects all apps, not just managed apps), deploying applications that implement proprietary screenshot detection and response mechanisms (though these are limited in effectiveness), accepting the limitation and relying on other data loss prevention controls like restricting data export and requiring authentication, or evaluating whether the sensitivity of data warrants requiring fully managed enrolled devices where more comprehensive restrictions are possible.
The platform difference highlights the importance of understanding operating system capabilities when designing cross-platform security policies. Controls available on Android might not have iOS equivalents, and vice versa. Administrators must adapt security strategies to platform capabilities while maintaining appropriate security postures across diverse device fleets.
C is correct because screenshot blocking is not available as a configuration option in iOS app protection policies due to iOS platform limitations that don’t provide application-level screenshot prevention mechanisms. A is incorrect because “Block screen capture and Android Assistant” is an Android app protection policy setting that doesn’t exist for iOS—this control is platform-specific to Android. B is incorrect because access requirements control authentication conditions rather than screenshot functionality, and screenshot blocking is not available through any iOS app protection policy setting. D is incorrect because conditional launch triggers actions based on conditions like offline intervals but doesn’t include screenshot detection or blocking capabilities, which aren’t available for iOS app protection policies.
Question 138:
You manage Windows 11 devices using Microsoft Intune. You need to configure BitLocker to automatically encrypt new fixed data drives when connected to devices. What should you configure?
A) Endpoint security Disk encryption policy with fixed data drive encryption settings requiring encryption
B) Device configuration profile with removable drive encryption enabled
C) BitLocker policy with automatic drive encryption for all drive types
D) Compliance policy requiring encryption on all connected drives
Answer: A
Explanation:
BitLocker provides comprehensive disk encryption capabilities for different drive types including operating system drives, fixed data drives (internal hard drives or SSDs used for data storage), and removable drives (USB flash drives or external hard drives). Understanding how to configure encryption for specific drive types ensures appropriate data protection across different storage scenarios.
Endpoint security Disk encryption policies in Intune include separate configuration sections for different drive types, allowing administrators to set distinct encryption requirements for operating system drives, fixed data drives, and removable drives. This granular control enables appropriate security policies where operating system drives might have different encryption methods or recovery key management than data drives.
Fixed data drive settings control encryption behavior for internal secondary hard drives or SSDs used for data storage rather than operating system hosting. Configuration options include requiring encryption for fixed data drives, encryption method selection (AES 128-bit or 256-bit), recovery key management, and enforcement settings determining when encryption must complete.
Question 139:
Your organization uses Microsoft Intune to manage Android Enterprise devices. You need to configure email profiles for corporate Exchange Online accounts. What should you create?
A) Device configuration profile with email template for Android Enterprise
B) App configuration policy for Gmail with Exchange settings
C) App configuration policy for Outlook with Exchange Online settings
D) Email profile using native email client configuration
Answer: C
Explanation:
Email configuration for Android Enterprise devices in Microsoft Intune requires understanding which applications support managed email profiles and how to properly configure those applications through app configuration policies. Microsoft Outlook for Android provides comprehensive support for Exchange Online integration through managed configuration, making it the recommended solution for corporate email on Android Enterprise devices.
App configuration policies in Intune deliver configuration settings to managed applications that support the AppConfig community standards or vendor-specific managed configuration frameworks. For email scenarios on Android Enterprise, these policies pre-configure email applications with server details, authentication parameters, and security settings, providing users with ready-to-use email access without manual configuration.
Microsoft Outlook for Android supports extensive managed configuration capabilities specifically designed for Exchange Online and on-premises Exchange deployments. App configuration policies for Outlook can specify the user’s email address (often using variables like {{mail}} to automatically populate from Azure AD user attributes), Exchange server URLs, authentication methods, account name, signature settings, and various application feature toggles. This comprehensive configuration support makes Outlook the preferred email client for Intune-managed Android Enterprise devices.
The configuration process involves creating an app configuration policy for managed devices, selecting Microsoft Outlook as the target application, defining configuration key-value pairs either through the configuration designer (which provides user-friendly interfaces for supported apps like Outlook) or through custom JSON/XML configuration data, and assigning the policy to user or device groups. When users launch Outlook after policy deployment, the application automatically configures itself with the specified settings.
Native Android email applications vary by device manufacturer and don’t provide consistent managed configuration support across the Android Enterprise ecosystem. Samsung devices, Google Pixel devices, and other manufacturers include different email applications with varying capabilities and configuration mechanisms. This fragmentation makes native email client configuration unreliable for broad Android Enterprise deployments.
Gmail, while popular as a consumer and Google Workspace email client, has limited support for managed Exchange Online configuration compared to Outlook. Gmail’s primary focus is Google account integration, and while it can add Exchange accounts through manual configuration, the managed configuration support for Exchange connectivity doesn’t match Outlook’s purpose-built Exchange integration.
C is correct because app configuration policies for Microsoft Outlook provide comprehensive Exchange Online configuration support specifically designed for corporate email on Android Enterprise devices. A is incorrect because device configuration email profiles for Android Enterprise don’t provide the application-specific configuration that app configuration policies for Outlook offer—modern Android Enterprise email management uses app configuration. B is incorrect because Gmail has limited managed configuration support for Exchange compared to Outlook and is primarily designed for Google account integration. D is incorrect because native email clients vary by manufacturer and lack consistent managed configuration support across Android Enterprise devices—Outlook provides reliable cross-device email configuration.
Question 140:
You are configuring Microsoft Intune to deploy a VPN profile to macOS devices. The VPN should use IKEv2 protocol with certificate authentication. What must you deploy before the VPN profile?
A) Trusted certificate profile with root CA certificate and SCEP or PKCS certificate profile for client certificates
B) VPN client application with certificate configuration
C) Device restrictions profile allowing VPN connections
D) Network configuration profile with certificate trust settings
Answer: A
Explanation:
Certificate-based VPN authentication requires establishing complete certificate trust chains before VPN profiles can successfully authenticate. Understanding the proper sequence for certificate deployment ensures VPN connections function correctly by validating both server certificates presented by VPN infrastructure and client certificates used for device authentication.
IKEv2 (Internet Key Exchange version 2) is a modern VPN protocol providing secure encrypted tunnels for network communication. When configured with certificate authentication, IKEv2 uses certificates for mutual authentication where the VPN server presents a certificate to prove its identity to the client, and the client presents a certificate to prove its identity to the server. Both sides must validate the certificates presented by the other side, requiring proper certificate trust chains.
For client certificate validation by VPN servers to succeed, clients must have the root CA certificate that issued the VPN server certificate installed in their trusted certificate store. Without this root certificate, macOS cannot validate that the server certificate chains to a trusted authority, causing VPN connection failures with certificate validation errors. Trusted certificate profiles in Intune deploy root and intermediate CA certificates to device certificate stores.
For server validation of client certificates, clients must have valid client authentication certificates issued by a CA that the VPN server trusts. These client certificates are deployed through SCEP (Simple Certificate Enrollment Protocol) or PKCS (Public Key Cryptography Standards) certificate profiles in Intune. SCEP profiles enable automated certificate enrollment from certificate authorities, while PKCS profiles deliver pre-issued certificates or integrate with certificate authorities through connectors.
The deployment sequence is critical for success. First, deploy trusted certificate profiles containing root and intermediate CA certificates that will validate VPN server certificates. Second, deploy SCEP or PKCS certificate profiles that provision client authentication certificates to devices. Third, deploy VPN profiles that reference the client certificates for authentication. This sequence ensures all necessary certificates are in place before VPN connection attempts occur.
VPN profiles in Intune for macOS include configuration for connection type (IKEv2), server address, authentication method (certificate), and which certificate profile to use for authentication. The VPN profile references the previously deployed certificate profile rather than including certificate data directly, creating a dependency relationship where certificate deployment must precede VPN profile deployment.
A is correct because deploying trusted certificate profiles for root CAs and SCEP or PKCS certificate profiles for client certificates establishes the complete certificate infrastructure required before VPN profiles can successfully authenticate using certificate-based IKEv2. B is incorrect because IKEv2 is built into macOS and doesn’t require separate VPN client application deployment—the native macOS VPN framework handles IKEv2 connections. C is incorrect because device restrictions control feature availability but VPN connections are allowed by default—certificate deployment is the prerequisite for certificate-based authentication. D is incorrect because network configuration profiles are not the proper mechanism for deploying certificates—trusted certificate profiles and SCEP/PKCS profiles are the appropriate certificate deployment methods.
